作為一種架構模式，云原生架構通過(guò)若干原則來(lái)對應用架構進(jìn)行核心控制。這些原則可以幫助技術(shù)主管和架構師在進(jìn)行技術(shù)選型時(shí)更加高效、準確，下面將展開(kāi)具體介紹。
作為一種模式，架構通過(guò)若干原則來(lái)對應用架構進(jìn)行核心控制。這些原則可以幫助技術(shù)主管和架構師在進(jìn)行技術(shù)選型時(shí)更加高效、準確，下面將展開(kāi)具體介紹。
在軟件開(kāi)發(fā)過(guò)程中，當代碼數量與開(kāi)發(fā)團隊規模都擴張到一定程度后，就需要重構應用，通過(guò)模塊化與組件化的手段分離關(guān)注點(diǎn)，降低應用的復雜度，提升軟件的開(kāi)發(fā)效率，降低維護成本。
如圖 1，隨著(zhù)業(yè)務(wù)的不斷發(fā)展，單體應用能夠承載的容量將逐漸到達上限，即使通過(guò)應用改造來(lái)突破垂直擴展(Scale Up)的瓶頸，并將其轉化為支撐水平擴展(Scale Out)的能力，在全局并發(fā)訪(fǎng)問(wèn)的情況下，也依然會(huì )面臨數據計算復雜度和存儲容量的問(wèn)題。因此，需要將單體應用進(jìn)一步拆分，按業(yè)務(wù)邊界重新劃分成分布式應用，使應用與應用之間不再直接共享數據，而是通過(guò)約定好的契約進(jìn)行通信，以提高擴展性。
圖 1 應用服務(wù)化擴展
服務(wù)化設計原則是指通過(guò)服務(wù)化架構拆分不同生命周期的業(yè)務(wù)單元，實(shí)現業(yè)務(wù)單元的獨立迭代，從而加快整體的迭代速度，保證迭代的穩定性。同時(shí)，服務(wù)化架構采用的是面向接口編程方式，增加了軟件的復用程度，增強了水平擴展的能力。服務(wù)化設計原則還強調在架構層面抽象化業(yè)務(wù)模塊之間的關(guān)系，從而幫助業(yè)務(wù)模塊實(shí)現基于服務(wù)流量(而非網(wǎng)絡(luò )流量)的策略控制和治理，而無(wú)須關(guān)注這些服務(wù)是基于何種編程語(yǔ)言開(kāi)發(fā)的。
有關(guān)服務(wù)化設計原則的實(shí)踐在業(yè)界已有很多成功案例。其中影響最廣、最為業(yè)界稱(chēng)道的是 Netflix 在生產(chǎn)系統上所進(jìn)行的大規模微服務(wù)化實(shí)踐。通過(guò)這次實(shí)踐，Netflix 在全球不僅承接了多達 1.67 億訂閱用戶(hù)以及全球互聯(lián)網(wǎng)帶寬容量 15% 以上的流量，而且在開(kāi)源領(lǐng)域貢獻了 Eureka、Zuul、Hystrix 等出色的微服務(wù)組件。
不僅海外公司正在不斷進(jìn)行服務(wù)化實(shí)踐，國內公司對服務(wù)化也有很高的認知。隨著(zhù)近幾年互聯(lián)網(wǎng)化的發(fā)展，無(wú)論是新銳互聯(lián)網(wǎng)公司，還是傳統大型企業(yè)，在服務(wù)化實(shí)踐上都有很好的實(shí)踐和成功案例。阿里巴巴的服務(wù)化實(shí)踐發(fā)端于 2008 年的五彩石項目，歷經(jīng) 10 年的發(fā)展，穩定支撐歷年大促活動(dòng)。以 2019 年“雙 11”當天數據為例，阿里巴巴的分布式系統創(chuàng )單峰值為每秒 54.4 萬(wàn)筆，實(shí)時(shí)計算處理為每秒 25.5 億筆。阿里巴巴在服務(wù)化領(lǐng)域的實(shí)踐，已通過(guò) Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade 等開(kāi)源項目分享給業(yè)界， 同時(shí)，這些組件與 Spring Cloud的集成 Spring Cloud Alibaba 已成為 Spring Cloud Netflix 的繼任者。
雖然隨著(zhù)云原生浪潮的興起，服務(wù)化原則不斷演進(jìn)、落地于實(shí)際業(yè)務(wù)，但企業(yè)在實(shí)際落地過(guò)程中也會(huì )遇到不少的挑戰。比如，與自建數據中心相比，公有云下的服務(wù)化可能存在巨大的資源池，使得機器錯誤率顯著(zhù)提高;按需付費增加了擴縮容的操作頻度;新的環(huán)境要求應用啟動(dòng)更快、應用與應用之間無(wú)強依賴(lài)關(guān)系、應用能夠在不同規格的節點(diǎn)之間隨意調度等諸多需要考慮的實(shí)際問(wèn)題。但可以預見(jiàn)的是，這些問(wèn)題會(huì )隨著(zhù)云原生架構的不斷演進(jìn)而得到逐一解決。
彈性原則是指系統部署規?？梢噪S著(zhù)業(yè)務(wù)量變化自動(dòng)調整大小，而無(wú)須根據事先的容量規劃準備固定的硬件和軟件資源。優(yōu)秀的彈性能力不僅能夠改變企業(yè)的 IT 成本模式，使得企業(yè)不用再考慮額外的軟硬件資源成本支出(閑置成本)，也能更好地支持業(yè)務(wù)規模的爆發(fā)式擴張，不再因為軟硬件資源儲備不足而留下遺憾。
在云原生時(shí)代，企業(yè)構建 IT 系統的門(mén)檻大幅降低，這極大地提升了企業(yè)將業(yè)務(wù)規劃落地為產(chǎn)品與服務(wù)的效率。這一點(diǎn)在移動(dòng)互聯(lián)網(wǎng)和游戲行業(yè)中顯得尤為突出。一款應用成為爆款后，其用戶(hù)數量呈現指數級增長(cháng)的案例不在少數。而業(yè)務(wù)呈指數級增長(cháng)會(huì )對企業(yè) IT 系統的性能帶來(lái)巨大考驗。面對這樣的挑戰，在傳統架構中，通常是開(kāi)發(fā)人員、運維人員疲于調優(yōu)系統性能，但是，即使他們使出渾身解數，也未必能夠完全解決系統的瓶頸問(wèn)題， 最終因系統無(wú)法應對不斷涌入的海量用戶(hù)而造成應用癱瘓。
除了面臨業(yè)務(wù)呈指數級增長(cháng)的考驗之外，業(yè)務(wù)的峰值特征將是另一個(gè)重要的挑戰。比如，電影票訂票系統下午時(shí)段的流量遠超凌晨時(shí)段，而周末的流量相比工作日甚至會(huì )翻好幾倍;還有外賣(mài)訂餐系統，在午餐和晚餐前后往往會(huì )出現訂單峰值時(shí)段。在傳統架構中，為了應對這類(lèi)具有明顯峰值特征的場(chǎng)景，企業(yè)需要為峰值時(shí)段的流量提前準備大量的計算、存儲及網(wǎng)絡(luò )資源并為這些資源付費，而這些資源在大部分時(shí)間內卻處于閑置狀態(tài)。
因此，在云原生時(shí)代，企業(yè)在構建 IT系統時(shí)，應該盡早考慮讓?xiě)眉軜嬀邆鋸椥阅芰?，以便在快速發(fā)展的業(yè)務(wù)規模面前靈活應對各種場(chǎng)景需求，充分利用云原生技術(shù)及成本優(yōu)勢。
要想構建彈性的系統架構，需要遵循如下四個(gè)基本原則。
(1) 按功能切割應用
一個(gè)大型的復雜系統可能由成百上千個(gè)服務(wù)組成，架構師在設計架構時(shí)，需要遵循的原則是：將相關(guān)的邏輯放到一起，不相關(guān)的邏輯拆解到獨立的服務(wù)中，各服務(wù)之間通過(guò)標準的服務(wù)發(fā)現(Service Discovery)找到對方，并使用標準的接口進(jìn)行通信。各服務(wù)之間松耦合，這使得每一個(gè)服務(wù)能夠各自獨立地完成彈性伸縮，從而避免服務(wù)上下游關(guān)聯(lián)故障的發(fā)生。
(2) 支持水平切分
按功能切割應用并沒(méi)有完全解決彈性的問(wèn)題。一個(gè)應用被拆解為眾多服務(wù)后，隨著(zhù)用戶(hù)流量的增長(cháng)，單個(gè)服務(wù)最終也會(huì )遇到系統瓶頸。因此在設計上，每個(gè)服務(wù)都需要具備可水平切分的能力，以便將服務(wù)切分為不同的邏輯單元，由每個(gè)單元處理一部分用戶(hù)流量，從而使服務(wù)自身具備良好的擴展能力。這其中最大的挑戰在于數據庫系統，因為數據庫系統自身是有狀態(tài)的，所以合理地切分數據并提供正確的事務(wù)機制將是一個(gè)非常復雜的工程。不過(guò)，在云原生時(shí)代，云平臺所提供的云原生數據庫服務(wù)可以解決大部分復雜的分布式系統問(wèn)題，因此，如果企業(yè)是通過(guò)云平臺提供的能力來(lái)構建彈性系統，自然就會(huì )擁有數據庫系統的彈性能力。
(3) 自動(dòng)化部署
系統突發(fā)流量通常無(wú)法預計，因此常用的解決方案是，通過(guò)人工擴容系統的方式，使系統具備支持更大規模用戶(hù)訪(fǎng)問(wèn)的能力。在完成架構拆分之后，彈性系統還需要具備自動(dòng)化部署能力，以便根據既定的規則或者外部流量突發(fā)信號觸發(fā)系統的自動(dòng)化擴容功能，滿(mǎn)足系統對于縮短突發(fā)流量影響時(shí)長(cháng)的及時(shí)性要求，同時(shí)在峰值時(shí)段結束后自動(dòng)縮容系統，降低系統運行的資源占用成本。
(4) 支持服務(wù)降級
彈性系統需要提前設計異常應對方案，比如，對服務(wù)進(jìn)行分級治理，在彈性機制失效、彈性資源不足或者流量峰值超出預期等異常情況下，系統架構需要具備服務(wù)降級的能力，通過(guò)降低部分非關(guān)鍵服務(wù)的質(zhì)量，或者關(guān)閉部分增強功能來(lái)讓出資源，并擴容重要功能對應的服務(wù)容量，以確保產(chǎn)品的主要功能不受影響。
國內外已有很多成功構建大規模彈性系統的實(shí)踐案例，其中最具代表性的是阿里巴巴一年一度的“雙11”大促活動(dòng)。為了應對相較于平時(shí)上百倍的流量峰值，阿里巴巴每年從阿里云采買(mǎi)彈性資源部署自己的應用，并在“雙 11”活動(dòng)之后釋放這一批資源，按需付費，從而大幅降低大促活動(dòng)的資源成本。另一個(gè)例子是新浪微博的彈性架構，在社會(huì )熱點(diǎn)事件發(fā)生時(shí)，新浪微博通過(guò)彈性系統將應用容器擴容到阿里云，以應對熱點(diǎn)事件導致的大量搜索和轉發(fā)請求。系統通過(guò)分鐘級的按需擴容響應能力，大幅降低了熱搜所產(chǎn)生的資源成本。
隨著(zhù)云原生技術(shù)的發(fā)展，FaaS、Serverless 等技術(shù)生態(tài)逐步成熟，構建大規模彈性系統的難度逐步降低。當企業(yè)以 FaaS、Serverless 等技術(shù)理念作為系統架構的設計原則時(shí)，系統就具備了彈性伸縮的能力，企業(yè)也就無(wú)須額外為“維護彈性系統自身”付出成本。
與監控、業(yè)務(wù)探活、APM(Application Performance Management，應用性能管理)等系統提供的被動(dòng)能力不同，可觀(guān)測性更強調主動(dòng)性，在云計算這樣的分布式系統中，主動(dòng)通過(guò)日志、鏈路跟蹤和度量等手段，讓一次 App 點(diǎn)擊所產(chǎn)生的多次服務(wù)調用耗時(shí)、返回值和參數都清晰可見(jiàn)，甚至可以下鉆到每次第三方軟件調用、SQL 請求、節點(diǎn)拓撲、網(wǎng)絡(luò )響應等信息中。運維、開(kāi)發(fā)和業(yè)務(wù)人員通過(guò)這樣的觀(guān)測能力可以實(shí)時(shí)掌握軟件的運行情況，并獲得前所未有的關(guān)聯(lián)分析能力，以便不斷優(yōu)化業(yè)務(wù)的健康度和用戶(hù)體驗。
隨著(zhù)云計算的全面發(fā)展，企業(yè)的應用架構發(fā)生了顯著(zhù)變化，正逐步從傳統的單體應用向微服務(wù)過(guò)渡。在微服務(wù)架構中，各服務(wù)之間松耦合的設計方式使得版本迭代更快、周期更短;基礎設施層中的 Kubernetes 等已經(jīng)成為容器的默認平臺;服務(wù)可以通過(guò)流水線(xiàn)實(shí)現持續集成與部署。這些變化可將服務(wù)的變更風(fēng)險降到最低，提升了研發(fā)的效率。
在微服務(wù)架構中，系統的故障點(diǎn)可能出現在任何地方，因此我們需要針對可觀(guān)測性進(jìn)行體系化設計，以降低 MTTR(故障平均修復時(shí)間)。
要想構建可觀(guān)測性體系，需要遵循如下三個(gè)基本原則。
(1)數據的全面采集
指標(Metric)、鏈路跟蹤(Tracing)和日志(Logging)這三類(lèi)數據是構建一個(gè)完整的可觀(guān)測性系統的“三大支柱”。而系統的可觀(guān)測性就是需要完整地采集、分析和展示這三類(lèi)數據。
(2) 數據的關(guān)聯(lián)分析
讓各數據之間產(chǎn)生更多的關(guān)聯(lián)，這一點(diǎn)對于一個(gè)可觀(guān)測性系統而言尤為重要。出現故障時(shí)，有效的關(guān)聯(lián)分析可以實(shí)現對故障的快速定界與定位，從而提升故障處理效率，減少不必要的損失。一般情況下，我們會(huì )將應用的服務(wù)器地址、服務(wù)接口等信息作為附加屬性，與指標、調用鏈、日志等信息綁定，并且賦予可觀(guān)測系統一定的定制能力，以便靈活滿(mǎn)足更加復雜的運維場(chǎng)景需求。
(3) 統一監控視圖與展現
多種形式、多個(gè)維度的監控視圖可以幫助運維和開(kāi)發(fā)人員快速發(fā)現系統瓶頸，消除系統隱患。監控數據的呈現形式應該不僅僅是指標趨勢圖表、柱狀圖等，還需要結合復雜的實(shí)際應用場(chǎng)景需要，讓視圖具備下鉆分析和定制能力，以滿(mǎn)足運維監控、版本發(fā)布管理、故障排除等多場(chǎng)景需求。
隨著(zhù)云原生技術(shù)的發(fā)展，基于異構微服務(wù)架構的場(chǎng)景會(huì )越來(lái)越多、越來(lái)越復雜，而可觀(guān)測性是一切自動(dòng)化能力構建的基礎。只有實(shí)現全面的可觀(guān)測性，才能真正提升系統的穩定性、降低 MTTR。因此，如何構建系統資源、容器、網(wǎng)絡(luò )、應用、業(yè)務(wù)的全?？捎^(guān)測體系，是每個(gè)企業(yè)都需要思考的問(wèn)題。
韌性是指當軟件所依賴(lài)的軟硬件組件出現異常時(shí)，軟件所表現出來(lái)的抵御能力。這些異常通常包括硬件故障、硬件資源瓶頸(如 CPU 或網(wǎng)卡帶寬耗盡)、業(yè)務(wù)流量超出軟件設計承受能力、影響機房正常工作的故障或災難、所依賴(lài)軟件發(fā)生故障等可能造成業(yè)務(wù)不可用的潛在影響因素。
業(yè)務(wù)上線(xiàn)之后，在運行期的大部分時(shí)間里，可能還會(huì )遇到各種不確定性輸入和不穩定依賴(lài)的情況。當這些非正常場(chǎng)景出現時(shí)，業(yè)務(wù)需要盡可能地保證服務(wù)質(zhì)量，滿(mǎn)足當前以聯(lián)網(wǎng)服務(wù)為代表的“永遠在線(xiàn)”的要求。因此，韌性能力的核心設計理念是面向失敗設計，即考慮如何在各種依賴(lài)不正常的情況下，減小異常對系統及服務(wù)質(zhì)量的影響并盡快恢復正常。
韌性原則的實(shí)踐與常見(jiàn)架構主要包括服務(wù)異步化能力、重試 / 限流 / 降級 / 熔斷 / 反壓、主從模式、集群模式、多 AZ(Availability Zone，可用區)的高可用、單元化、跨區域(Region)容災、異地多活容災等。
下面結合具體案例詳細說(shuō)明如何在大型系統中進(jìn)行韌性設計。“雙 11”對于阿里巴巴來(lái)說(shuō)是一場(chǎng)不能輸的戰役，因此其系統的設計在策略上需要嚴格遵循韌性原則。例如，在統一接入層通過(guò)流量清洗實(shí)現安全策略，防御黑產(chǎn)攻擊;通過(guò)精細化限流策略確保峰值流量穩定，從而保障后端工作正常進(jìn)行。為了提升全局的高可用能力，阿里巴巴通過(guò)單元化機制實(shí)現了跨區域多活容災，通過(guò)同城容災機制實(shí)現同城雙活容災，從而最大程度提升 IDC(Internet Data Center，互聯(lián)網(wǎng)數據中心)的服務(wù)質(zhì)量。在同一 IDC 內通過(guò)微服務(wù)和容器技術(shù)實(shí)現業(yè)務(wù)的無(wú)狀態(tài)遷移;通過(guò)多副本部署提高高可用能力;通過(guò)消息完成微服務(wù)間的異步解耦以降低服務(wù)的依賴(lài)性，同時(shí)提升系統吞吐量。從每個(gè)應用的角度，做好自身依賴(lài)梳理，設置降級開(kāi)關(guān)，并通過(guò)故障演練不斷強化系統健壯性，保證阿里巴巴“雙11”大促活動(dòng)正常穩定進(jìn)行。
隨著(zhù)數字化進(jìn)程的加快，越來(lái)越多的數字化業(yè)務(wù)成為整個(gè)社會(huì )經(jīng)濟正常運轉的基礎設施，但隨著(zhù)支撐這些數字化業(yè)務(wù)的系統越來(lái)越復雜，依賴(lài)服務(wù)質(zhì)量不確定的風(fēng)險正變得越來(lái)越高，因此系統必須進(jìn)行充分的韌性設計，以便更好地應對各種不確定性。尤其是在涉及核心行業(yè)的核心業(yè)務(wù)鏈路(如金融的支付鏈路、電商的交易鏈路)、業(yè)務(wù)流量入口、依賴(lài)復雜鏈路時(shí)，韌性設計至關(guān)重要。
技術(shù)是把“雙刃劍”，容器、微服務(wù)、DevOps 以及大量第三方組件的使用，在降低分布式復雜性和提升迭代速度的同時(shí)，也提高了軟件技術(shù)棧的復雜度，加大了組件規模，從而不可避免地導致了軟件交付的復雜性。如果控制不當，應用就會(huì )無(wú)法體會(huì )到云原生技術(shù)的優(yōu)勢。通過(guò) IaC、GitOps、OAM、Operator 和大量自動(dòng)化交付工具在 CI/CD(持續集成 /持續交付)流水線(xiàn)中的實(shí)踐，企業(yè)可以標準化企業(yè)內部的軟件交付過(guò)程，也可以在標準化的基礎上實(shí)現自動(dòng)化，即通過(guò)配置數據自描述和面向終態(tài)的交付過(guò)程，實(shí)現整個(gè)軟件交付和運維的自動(dòng)化。
要想實(shí)現大規模的自動(dòng)化，需要遵循如下四個(gè)基本原則。
(1) 標準化
實(shí)施自動(dòng)化，首先要通過(guò)容器化、IaC、OAM 等手段，標準化業(yè)務(wù)運行的基礎設施，并進(jìn)一步標準化對應用的定義乃至交付的流程。只有實(shí)現了標準化，才能解除業(yè)務(wù)對特定的人員和平臺的依賴(lài)，實(shí)現業(yè)務(wù)統一和大規模的自動(dòng)化操作。
(2) 面向終態(tài)
面向終態(tài)是指聲明式地描述基礎設施和應用的期望配置，持續關(guān)注應用的實(shí)際運行狀態(tài)，使系統自身反復地變更和調整直至趨近終態(tài)的一種思想。面向終態(tài)的原則強調應該避 免直接通過(guò)工單系統、工作流系統組裝一系列過(guò)程式的命令來(lái)變更應用，而是通過(guò)設置終態(tài)，讓系統自己決策如何執行變更。
(3) 關(guān)注點(diǎn)分離
自動(dòng)化最終所能達到的效果不只取決于工具和系統的能力，更取決于為系統設置目標的人，因此要確保找到正確的目標設置人。在描述系統終態(tài)時(shí)，要將應用研發(fā)、應用運維、基礎設施運維這幾種主要角色所關(guān)注的配置分離開(kāi)來(lái)，各個(gè)角色只需要設置自己所關(guān)注和擅長(cháng)的系統配置，以便確保設定的系統終態(tài)是合理的。
(4) 面向失敗設計
要想實(shí)現全部過(guò)程自動(dòng)化，一定要保證自動(dòng)化的過(guò)程是可控的，對系統的影響是可預期的。我們不能期望自動(dòng)化系統不犯錯誤，但可以保證即使是在出現異常的情況下，錯誤的影響范圍也是可控的、可接受的。因此，自動(dòng)化系統在執行變更時(shí)，同樣需要遵循人工變更的最佳實(shí)踐，保證變更是可灰度執行的、執行結果是可觀(guān)測的、變更是可快速回滾的、變更影響是可追溯的。
業(yè)務(wù)實(shí)例的故障自愈是一個(gè)典型的過(guò)程自動(dòng)化場(chǎng)景。業(yè)務(wù)遷移到云上后，云平臺雖然通過(guò)各種技術(shù)手段大幅降低了服務(wù)器出故障的概率，但是卻并不能消除業(yè)務(wù)本身的軟件故障。軟件故障既包括應用軟件自身的缺陷導致的崩潰、資源不足導致的內存溢出(OOM)和負載過(guò)高導致的夯死等異常問(wèn)題，也包括內核、守護進(jìn)程(daemon 進(jìn)程)等系統軟件的問(wèn)題，更包括混部的其他應用或作業(yè)的干擾問(wèn)題。隨著(zhù)業(yè)務(wù)規模的增加，軟件出現故障的風(fēng)險正變得越來(lái)越高。傳統的運維故障處理方式需要運維人員的介入，執行諸如重啟或者騰挪之類(lèi)的修復操作，但在大規模場(chǎng)景下，運維人員往往疲于應對各種故障，甚至需要連夜加班進(jìn)行操作，服務(wù)質(zhì)量很難保證，不管是客戶(hù)，還是開(kāi)發(fā)、運維人員，都無(wú)法滿(mǎn)意。
為了使故障能夠實(shí)現自動(dòng)化修復，云原生應用要求開(kāi)發(fā)人員通過(guò)標準的聲明式配置，描述應用健康的探測方法和應用的啟動(dòng)方法、應用啟動(dòng)后需要掛載和注冊的服務(wù)發(fā)現以及配置管理數據庫(Configuration Management Data Base，CMDB)信息。通過(guò)這些標準的配置，云平臺可以反復探測應用，并在故障發(fā)生時(shí)執行自動(dòng)化修復操作。另外，為了防止故障探測本身可能存在的誤報問(wèn)題，應用的運維人員還可以根據自身容量設置服務(wù)不可用實(shí)例的比例，讓云平臺能夠在進(jìn)行自動(dòng)化故障恢復的同時(shí)保證業(yè)務(wù)可用性。實(shí)例故障自愈的實(shí)現，不僅把開(kāi)發(fā)人員和運維人員從煩瑣的運維操作中解放了出來(lái)，而且可以及時(shí)處理各種故障，保證業(yè)務(wù)的連續性和服務(wù)的高可用性。
基于邊界模型的傳統安全架構設計，是在可信和不可信的資源之間架設一道墻，例如，公司內網(wǎng)是可信的，而因特網(wǎng)則是不可信的。在這種安全架構設計模式下，一旦入侵者滲透到邊界內，就能夠隨意訪(fǎng)問(wèn)邊界內的資源了。而云原生架構的應用、員工遠程辦公模式的普及以及用手機等移動(dòng)設備處理工作的現狀，已經(jīng)完全打破了傳統安全架構下的物理邊界。員工在家辦公也可以實(shí)現與合作方共享數據，因為應用和數據被托管到了云上。
如今，邊界不再是由組織的物理位置來(lái)定義，而是已經(jīng)擴展到了需要訪(fǎng)問(wèn)組織資源和服務(wù)的所有地方，傳統的防火墻和虛擬專(zhuān)用網(wǎng)已經(jīng)無(wú)法可靠且靈活地應對這種新邊界。因此，我們需要一種全新的安全架構，來(lái)靈活適應云原生和移動(dòng)時(shí)代環(huán)境的特性，不論員工在哪里辦公，設備在哪里接入，應用部署在哪里，數據的安全性都能夠得到有效保護。如果要實(shí)現這種新的安全架構，就要依托零信任模型。
傳統安全架構認為防火墻內的一切都是安全的，而零信任模型假設防火墻邊界已經(jīng)被攻破，且每個(gè)請求都來(lái)自于不可信網(wǎng)絡(luò )，因此每個(gè)請求都需要經(jīng)過(guò)驗證。簡(jiǎn)單來(lái)說(shuō)，“永不信任，永遠驗證”。在零信任模型下，每個(gè)請求都要經(jīng)過(guò)強認證，并基于安全策略得到驗證授權。與請求相關(guān)的用戶(hù)身份、設備身份、應用身份等，都會(huì )作為核心信息來(lái)判斷請求是否安全。
如果我們圍繞邊界來(lái)討論安全架構，那么傳統安全架構的邊界是物理網(wǎng)絡(luò )，而零信任安全架構的邊界則是身份，這個(gè)身份包括人的身份、設備的身份、應用的身份等。要想實(shí)現零信任安全架構，需要遵循如下三個(gè)基本原則。
(1) 顯式驗證
對每個(gè)訪(fǎng)問(wèn)請求都進(jìn)行認證和授權。認證和授權需要基于用戶(hù)身份、位置、設備信息、服務(wù)和工作負載信息以及數據分級和異常檢測等信息來(lái)進(jìn)行。例如，對于企業(yè)內部應用之間的通信，不能簡(jiǎn)單地判定來(lái)源 IP是內部 IP 就直接授權訪(fǎng)問(wèn)，而是應該判斷來(lái)源應用的身份和設備等信息，再結合當前的策略授權。
(2) 最少權限
對于每個(gè)請求，只授予其在當下必需的權限，且權限策略應該能夠基于當前請求上下文自適應。例如，HR 部門(mén)的員工應該擁有訪(fǎng)問(wèn) HR相關(guān)應用的權限，但不應該擁有訪(fǎng)問(wèn)財務(wù)部門(mén)應用的權限。
(3) 假設被攻破
假設物理邊界被攻破，則需要嚴格控制安全爆炸半徑，將一個(gè)整體的網(wǎng)絡(luò )切割成對用戶(hù)、設備、應用感知的多個(gè)部分。對所有的會(huì )話(huà)加密，使用數據分析技術(shù)保證對安全狀態(tài)的可見(jiàn)性。
從傳統安全架構向零信任架構演進(jìn)，會(huì )對軟件架構產(chǎn)生深刻的影響，具體體現在如下三個(gè)方面。
第一，不能基于 IP 配置安全策略。在云原生架構下，不能假設 IP 與服務(wù)或應用是綁定的，這是由于自動(dòng)彈性等技術(shù)的應用使得 IP 隨時(shí)可能發(fā)生變化，因此不能以 IP 代表應用的身份并在此基礎上建立安全策略。
第二，身份應該成為基礎設施。授權各服務(wù)之間的通信以及人訪(fǎng)問(wèn)服務(wù)的前提是已經(jīng)明確知道訪(fǎng)問(wèn)者的身份。在企業(yè)中，人的身份管理通常是安全基礎設施的一部分，但應用的身份也需要管理。
第三，標準的發(fā)布流水線(xiàn)。在企業(yè)中，研發(fā)的工作通常是分布式的，包括代碼的版本管理、構建、測試以及上線(xiàn)的過(guò)程，都是比較獨立的。這種分散的模式將會(huì )導致在實(shí)際生產(chǎn)環(huán)境中運行的服務(wù)的安全性得不到有效保證。如果可以標準化代碼的版本管理、構建以及上線(xiàn)的流程，那么應用發(fā)布的安全性就能夠得到集中增強。
總體來(lái)說(shuō)，整個(gè)零信任模型的建設包括身份、設備、應用、基礎設施、網(wǎng)絡(luò )、數據等幾個(gè)部分。零信任的實(shí)現是一個(gè)循序漸進(jìn)的過(guò)程，例如，當組織內部傳輸的所有流量都沒(méi)有加密的時(shí)候，第一步應該先保證訪(fǎng)問(wèn)者訪(fǎng)問(wèn)應用的流量是加密的，然后再逐步實(shí)現所有流量的加密。如果采用云原生架構，就可以直接使用云平臺提供的安全基礎設施和服務(wù)，以便幫助企業(yè)快速實(shí)現零信任架構。
如今，技術(shù)與業(yè)務(wù)的發(fā)展速度都非?？?，在工程實(shí)踐中很少有從一開(kāi)始就能夠被明確定義并適用于整個(gè)軟件生命周期的架構模式，而是需要在一定范圍內不斷重構，以適應變 化的技術(shù)和業(yè)務(wù)需求。同理，云原生架構本身也應該且必須具備持續演進(jìn)的能力，而不是一個(gè)封閉式的、被設計后一成不變的架構。因此在設計時(shí)除了要考慮增量迭代、合理化目標選取等因素之外，還需要考慮組織(例如架構控制委員會(huì ))層面的架構治理和風(fēng)險控制規范以及業(yè)務(wù)自身的特點(diǎn)，特別是在業(yè)務(wù)高速迭代的情況下，更應該重點(diǎn)考慮如何保證架構演進(jìn)與業(yè)務(wù)發(fā)展之間的平衡。
(1) 演進(jìn)式架構的特點(diǎn)和價(jià)值
演進(jìn)式架構是指在軟件開(kāi)發(fā)的初始階段，就通過(guò)具有可擴展性和松耦合的設計，讓后續可能發(fā)生的變更更加容易、升級性重構的成本更低，并且能夠發(fā)生在開(kāi)發(fā)實(shí)踐、發(fā)布實(shí)踐和整體敏捷度等軟件生命周期中的任何階段。
演進(jìn)式架構之所以在工業(yè)實(shí)踐中具有重要意義，其根本原因在于，在現代軟件工程領(lǐng)域達成的共識中，變更都是很難預測的，其改造的成本也極其高昂。演進(jìn)式架構并不能避免重構，但是它強調了架構的可演進(jìn)性，即當整個(gè)架構因為技術(shù)、組織或者外部環(huán)境的變化需要向前演進(jìn)時(shí)，項目整體依然能夠遵循強邊界上下文的原則，確保領(lǐng)域驅動(dòng)設計中描述的邏輯劃分變成物理上的隔離。演進(jìn)式架構通過(guò)標準化且具有高可擴展性的基礎設施體系，大量采納標準化應用模型與模塊化運維能力等先進(jìn)的云原生應用架構實(shí)踐，實(shí)現了整個(gè)系統架構在物理上的模塊化、可復用性與職責分離。在演進(jìn)式架構中，系統的每個(gè)服務(wù)在結構層面與其他服務(wù)都是解耦的，替換服務(wù)就像替換樂(lè )高積木一樣方便。
(2) 演進(jìn)式架構的應用
在現代軟件工程實(shí)踐中，演進(jìn)式架構在系統的不同層面有著(zhù)不同的實(shí)踐與體現。
在面向業(yè)務(wù)研發(fā)的應用架構中，演進(jìn)式架構通常與微服務(wù)設計密不可分。例如，在阿里巴巴的互聯(lián)網(wǎng)電商應用中(例如大家所熟悉的淘寶和天貓等)，整個(gè)系統架構實(shí)際上被精細地設計成數千個(gè)邊界劃分明確的組件，其目的就是為希望做出非破壞性變更的開(kāi)發(fā)人員 提供更大的便利，避免因為不適當的耦合將變更導向難以預料的方向，從而阻礙架構的演 進(jìn)?？梢园l(fā)現，演進(jìn)式架構的軟件都支持一定程度的模塊化，這種模塊化通常體現為經(jīng)典的分層架構及微服務(wù)的最佳實(shí)踐。
而在平臺研發(fā)層面，演進(jìn)式架構更多地體現為基于“能力”的架構( Capability Oriented Architecture，COA)。在 Kubernetes 等云原生技術(shù)逐漸普及之后，基于標準化的云原生基礎設施正迅速成為平臺架構的能力提供方，而以此為基礎的開(kāi)放應用模型( Open ApplieationModel，OAM )理念，正是一種從應用架構視角出發(fā)，將標準化基礎設施按照能力進(jìn)行模塊化的 COA 實(shí)踐。
(3) 云原生下的架構演進(jìn)
當前，演進(jìn)式架構還處于快速成長(cháng)與普及階段。不過(guò)，整個(gè)軟件工程領(lǐng)域已經(jīng)達成共識，即軟件世界是不斷變化的，它是動(dòng)態(tài)而非靜態(tài)的存在。架構也不是一個(gè)簡(jiǎn)單的等式，它是持續過(guò)程的一種快照。所以無(wú)論是在業(yè)務(wù)應用還是在平臺研發(fā)層面，演進(jìn)式架構都是一個(gè)必然的發(fā)展趨勢。業(yè)界大量架構更新的工程實(shí)踐都詮釋了一個(gè)問(wèn)題，即由于忽略實(shí)現架構，且保持應用常新所要付出的精力是非常巨大的。但好的架構規劃可以幫助應用降低新技術(shù)的引入成本，這要求應用與平臺在架構層面滿(mǎn)足:架構標準化、職責分離與模塊化。而在云原生時(shí)代，開(kāi)發(fā)應用模型( OAM )正在迅速成為演進(jìn)式架構推進(jìn)的重要助力。
我們可以看到云原生架構的構建和演進(jìn)都是以云計算的核心特性(例如，彈性、自動(dòng)化、韌性)為基礎并結合業(yè)務(wù)目標以及特征進(jìn)行的，從而幫助企業(yè)和技術(shù)人員充分釋放云計算的技術(shù)紅利。隨著(zhù)云原生的不斷探索，各類(lèi)技術(shù)不斷擴展，各類(lèi)場(chǎng)景不斷豐富，云原生架構也將不斷演進(jìn)。但在這些變化過(guò)程中。典型的架構設計原則始終都有著(zhù)重要意義，指導我們進(jìn)行架構設計以及技術(shù)落地。
免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng )、來(lái)自本網(wǎng)站內容采集于網(wǎng)絡(luò )互聯(lián)網(wǎng)轉載等其它媒體和分享為主，內容觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如侵犯了原作者的版權，請告知一經(jīng)查實(shí)，將立刻刪除涉嫌侵權內容，聯(lián)系我們QQ:712375056，同時(shí)歡迎投稿傳遞力量。
Copyright ? 2009-2022 56dr.com. All Rights Reserved. 特網(wǎng)科技 特網(wǎng)云 版權所有 特網(wǎng)科技 粵ICP備16109289號
域名注冊服務(wù)機構:阿里云計算有限公司（萬(wàn)網(wǎng)） 域名服務(wù)機構：煙臺帝思普網(wǎng)絡(luò )科技有限公司（DNSPod） CDN服務(wù)：阿里云計算有限公司 百度云 中國互聯(lián)網(wǎng)舉報中心 增值電信業(yè)務(wù)經(jīng)營(yíng)許可證B2
建議您使用Chrome、Firefox、Edge、IE10及以上版本和360等主流瀏覽器瀏覽本網(wǎng)站
