云原生架構(gòu)需遵循七個原則

作為一種架構(gòu)模式，云原生架構(gòu)通過若干原則來對應用架構(gòu)進行核心控制。這些原則可以幫助技術主管和架構(gòu)師在進行技術選型時更加高效、準確，下面將展開具體介紹。

1. 服務化原則

在軟件開發(fā)過程中，當代碼數(shù)量與開發(fā)團隊規(guī)模都擴張到一定程度后，就需要重構(gòu)應用，通過模塊化與組件化的手段分離關注點，降低應用的復雜度，提升軟件的開發(fā)效率，降低維護成本。

如圖 1，隨著業(yè)務的不斷發(fā)展，單體應用能夠承載的容量將逐漸到達上限，即使通過應用改造來突破垂直擴展(Scale Up)的瓶頸，并將其轉(zhuǎn)化為支撐水平擴展(Scale Out)的能力，在全局并發(fā)訪問的情況下，也依然會面臨數(shù)據(jù)計算復雜度和存儲容量的問題。因此，需要將單體應用進一步拆分，按業(yè)務邊界重新劃分成分布式應用，使應用與應用之間不再直接共享數(shù)據(jù)，而是通過約定好的契約進行通信，以提高擴展性。

圖 1 應用服務化擴展

服務化設計原則是指通過服務化架構(gòu)拆分不同生命周期的業(yè)務單元，實現(xiàn)業(yè)務單元的獨立迭代，從而加快整體的迭代速度，保證迭代的穩(wěn)定性。同時，服務化架構(gòu)采用的是面向接口編程方式，增加了軟件的復用程度，增強了水平擴展的能力。服務化設計原則還強調(diào)在架構(gòu)層面抽象化業(yè)務模塊之間的關系，從而幫助業(yè)務模塊實現(xiàn)基于服務流量(而非網(wǎng)絡流量)的策略控制和治理，而無須關注這些服務是基于何種編程語言開發(fā)的。

有關服務化設計原則的實踐在業(yè)界已有很多成功案例。其中影響最廣、最為業(yè)界稱道的是 Netflix 在生產(chǎn)系統(tǒng)上所進行的大規(guī)模微服務化實踐。通過這次實踐，Netflix 在全球不僅承接了多達 1.67 億訂閱用戶以及全球互聯(lián)網(wǎng)帶寬容量 15% 以上的流量，而且在開源領域貢獻了 Eureka、Zuul、Hystrix 等出色的微服務組件。

不僅海外公司正在不斷進行服務化實踐，國內(nèi)公司對服務化也有很高的認知。隨著近幾年互聯(lián)網(wǎng)化的發(fā)展，無論是新銳互聯(lián)網(wǎng)公司，還是傳統(tǒng)大型企業(yè)，在服務化實踐上都有很好的實踐和成功案例。阿里巴巴的服務化實踐發(fā)端于 2008 年的五彩石項目，歷經(jīng) 10 年的發(fā)展，穩(wěn)定支撐歷年大促活動。以 2019 年“雙 11”當天數(shù)據(jù)為例，阿里巴巴的分布式系統(tǒng)創(chuàng)單峰值為每秒 54.4 萬筆，實時計算處理為每秒 25.5 億筆。阿里巴巴在服務化領域的實踐，已通過 Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade 等開源項目分享給業(yè)界， 同時，這些組件與 Spring Cloud的集成 Spring Cloud Alibaba 已成為 Spring Cloud Netflix 的繼任者。

雖然隨著云原生浪潮的興起，服務化原則不斷演進、落地于實際業(yè)務，但企業(yè)在實際落地過程中也會遇到不少的挑戰(zhàn)。比如，與自建數(shù)據(jù)中心相比，公有云下的服務化可能存在巨大的資源池，使得機器錯誤率顯著提高;按需付費增加了擴縮容的操作頻度;新的環(huán)境要求應用啟動更快、應用與應用之間無強依賴關系、應用能夠在不同規(guī)格的節(jié)點之間隨意調(diào)度等諸多需要考慮的實際問題。但可以預見的是，這些問題會隨著云原生架構(gòu)的不斷演進而得到逐一解決。

2. 彈性原則

彈性原則是指系統(tǒng)部署規(guī)?？梢噪S著業(yè)務量變化自動調(diào)整大小，而無須根據(jù)事先的容量規(guī)劃準備固定的硬件和軟件資源。優(yōu)秀的彈性能力不僅能夠改變企業(yè)的 IT 成本模式，使得企業(yè)不用再考慮額外的軟硬件資源成本支出(閑置成本)，也能更好地支持業(yè)務規(guī)模的爆發(fā)式擴張，不再因為軟硬件資源儲備不足而留下遺憾。

在云原生時代，企業(yè)構(gòu)建 IT 系統(tǒng)的門檻大幅降低，這極大地提升了企業(yè)將業(yè)務規(guī)劃落地為產(chǎn)品與服務的效率。這一點在移動互聯(lián)網(wǎng)和游戲行業(yè)中顯得尤為突出。一款應用成為爆款后，其用戶數(shù)量呈現(xiàn)指數(shù)級增長的案例不在少數(shù)。而業(yè)務呈指數(shù)級增長會對企業(yè) IT 系統(tǒng)的性能帶來巨大考驗。面對這樣的挑戰(zhàn)，在傳統(tǒng)架構(gòu)中，通常是開發(fā)人員、運維人員疲于調(diào)優(yōu)系統(tǒng)性能，但是，即使他們使出渾身解數(shù)，也未必能夠完全解決系統(tǒng)的瓶頸問題， 最終因系統(tǒng)無法應對不斷涌入的海量用戶而造成應用癱瘓。

除了面臨業(yè)務呈指數(shù)級增長的考驗之外，業(yè)務的峰值特征將是另一個重要的挑戰(zhàn)。比如，電影票訂票系統(tǒng)下午時段的流量遠超凌晨時段，而周末的流量相比工作日甚至會翻好幾倍;還有外賣訂餐系統(tǒng)，在午餐和晚餐前后往往會出現(xiàn)訂單峰值時段。在傳統(tǒng)架構(gòu)中，為了應對這類具有明顯峰值特征的場景，企業(yè)需要為峰值時段的流量提前準備大量的計算、存儲及網(wǎng)絡資源并為這些資源付費，而這些資源在大部分時間內(nèi)卻處于閑置狀態(tài)。

因此，在云原生時代，企業(yè)在構(gòu)建 IT系統(tǒng)時，應該盡早考慮讓應用架構(gòu)具備彈性能力，以便在快速發(fā)展的業(yè)務規(guī)模面前靈活應對各種場景需求，充分利用云原生技術及成本優(yōu)勢。

要想構(gòu)建彈性的系統(tǒng)架構(gòu)，需要遵循如下四個基本原則。

(1) 按功能切割應用

一個大型的復雜系統(tǒng)可能由成百上千個服務組成，架構(gòu)師在設計架構(gòu)時，需要遵循的原則是：將相關的邏輯放到一起，不相關的邏輯拆解到獨立的服務中，各服務之間通過標準的服務發(fā)現(xiàn)(Service Discovery)找到對方，并使用標準的接口進行通信。各服務之間松耦合，這使得每一個服務能夠各自獨立地完成彈性伸縮，從而避免服務上下游關聯(lián)故障的發(fā)生。

(2) 支持水平切分

按功能切割應用并沒有完全解決彈性的問題。一個應用被拆解為眾多服務后，隨著用戶流量的增長，單個服務最終也會遇到系統(tǒng)瓶頸。因此在設計上，每個服務都需要具備可水平切分的能力，以便將服務切分為不同的邏輯單元，由每個單元處理一部分用戶流量，從而使服務自身具備良好的擴展能力。這其中大的挑戰(zhàn)在于數(shù)據(jù)庫系統(tǒng)，因為數(shù)據(jù)庫系統(tǒng)自身是有狀態(tài)的，所以合理地切分數(shù)據(jù)并提供正確的事務機制將是一個非常復雜的工程。不過，在云原生時代，云平臺所提供的云原生數(shù)據(jù)庫服務可以解決大部分復雜的分布式系統(tǒng)問題，因此，如果企業(yè)是通過云平臺提供的能力來構(gòu)建彈性系統(tǒng)，自然就會擁有數(shù)據(jù)庫系統(tǒng)的彈性能力。

(3) 自動化部署

系統(tǒng)突發(fā)流量通常無法預計，因此常用的解決方案是，通過人工擴容系統(tǒng)的方式，使系統(tǒng)具備支持更大規(guī)模用戶訪問的能力。在完成架構(gòu)拆分之后，彈性系統(tǒng)還需要具備自動化部署能力，以便根據(jù)既定的規(guī)則或者外部流量突發(fā)信號觸發(fā)系統(tǒng)的自動化擴容功能，滿足系統(tǒng)對于縮短突發(fā)流量影響時長的及時性要求，同時在峰值時段結(jié)束后自動縮容系統(tǒng)，降低系統(tǒng)運行的資源占用成本。

(4) 支持服務降級

彈性系統(tǒng)需要提前設計異常應對方案，比如，對服務進行分級治理，在彈性機制失效、彈性資源不足或者流量峰值超出預期等異常情況下，系統(tǒng)架構(gòu)需要具備服務降級的能力，通過降低部分非關鍵服務的質(zhì)量，或者關閉部分增強功能來讓出資源，并擴容重要功能對應的服務容量，以確保產(chǎn)品的主要功能不受影響。

國內(nèi)外已有很多成功構(gòu)建大規(guī)模彈性系統(tǒng)的實踐案例，其中最具代表性的是阿里巴巴一年一度的“雙11”大促活動。為了應對相較于平時上百倍的流量峰值，阿里巴巴每年從阿里云采買彈性資源部署自己的應用，并在“雙 11”活動之后釋放這一批資源，按需付費，從而大幅降低大促活動的資源成本。另一個例子是新浪微博的彈性架構(gòu)，在社會熱點事件發(fā)生時，新浪微博通過彈性系統(tǒng)將應用容器擴容到阿里云，以應對熱點事件導致的大量搜索和轉(zhuǎn)發(fā)請求。系統(tǒng)通過分鐘級的按需擴容響應能力，大幅降低了熱搜所產(chǎn)生的資源成本。

隨著云原生技術的發(fā)展，F(xiàn)aaS、Serverless 等技術生態(tài)逐步成熟，構(gòu)建大規(guī)模彈性系統(tǒng)的難度逐步降低。當企業(yè)以 FaaS、Serverless 等技術理念作為系統(tǒng)架構(gòu)的設計原則時，系統(tǒng)就具備了彈性伸縮的能力，企業(yè)也就無須額外為“維護彈性系統(tǒng)自身”付出成本。

3. 可觀測原則

與監(jiān)控、業(yè)務探活、APM(Application Performance Management，應用性能管理)等系統(tǒng)提供的被動能力不同，可觀測性更強調(diào)主動性，在云計算這樣的分布式系統(tǒng)中，主動通過日志、鏈路跟蹤和度量等手段，讓一次 App 點擊所產(chǎn)生的多次服務調(diào)用耗時、返回值和參數(shù)都清晰可見，甚至可以下鉆到每次第三方軟件調(diào)用、SQL 請求、節(jié)點拓撲、網(wǎng)絡響應等信息中。運維、開發(fā)和業(yè)務人員通過這樣的觀測能力可以實時掌握軟件的運行情況，并獲得前所未有的關聯(lián)分析能力，以便不斷優(yōu)化業(yè)務的健康度和用戶體驗。

隨著云計算的全面發(fā)展，企業(yè)的應用架構(gòu)發(fā)生了顯著變化，正逐步從傳統(tǒng)的單體應用向微服務過渡。在微服務架構(gòu)中，各服務之間松耦合的設計方式使得版本迭代更快、周期更短;基礎設施層中的 Kubernetes 等已經(jīng)成為容器的默認平臺;服務可以通過流水線實現(xiàn)持續(xù)集成與部署。這些變化可將服務的變更風險降到最低，提升了研發(fā)的效率。

在微服務架構(gòu)中，系統(tǒng)的故障點可能出現(xiàn)在任何地方，因此我們需要針對可觀測性進行體系化設計，以降低 MTTR(故障平均修復時間)。

要想構(gòu)建可觀測性體系，需要遵循如下三個基本原則。

(1)數(shù)據(jù)的全面采集

指標(Metric)、鏈路跟蹤(Tracing)和日志(Logging)這三類數(shù)據(jù)是構(gòu)建一個完整的可觀測性系統(tǒng)的“三大支柱”。而系統(tǒng)的可觀測性就是需要完整地采集、分析和展示這三類數(shù)據(jù)。

指標：指標是指在多個連續(xù)的時間周期里用于度量的 KPI 數(shù)值。一般情況下，指標會按軟件架構(gòu)進行分層，分為系統(tǒng)資源指標(如 CPU 使用率、磁盤使用率和網(wǎng)絡帶寬情況等)、應用指標(如出錯率、服務等級協(xié)議 SLA、服務滿意度 APDEX、平均延時等)、業(yè)務指標(如用戶會話數(shù)、訂單數(shù)量和營業(yè)額等)。 鏈路跟蹤：鏈路跟蹤是指通過 TraceId 的唯一標識來記錄并還原發(fā)生一次分布式調(diào)用的完整過程，貫穿數(shù)據(jù)從瀏覽器或移動端經(jīng)過服務器處理，到執(zhí)行 SQL 或發(fā)起遠程調(diào)用的整個過程。 日志：日志通常用來記錄應用運行的執(zhí)行過程、代碼調(diào)試、錯誤異常等信息，如 Nginx 日志可以記錄遠端 IP、發(fā)生請求時間、數(shù)據(jù)大小等信息。日志數(shù)據(jù)需要集中化存儲，并具備可檢索的能力。

(2) 數(shù)據(jù)的關聯(lián)分析

讓各數(shù)據(jù)之間產(chǎn)生更多的關聯(lián)，這一點對于一個可觀測性系統(tǒng)而言尤為重要。出現(xiàn)故障時，有效的關聯(lián)分析可以實現(xiàn)對故障的快速定界與定位，從而提升故障處理效率，減少不必要的損失。一般情況下，我們會將應用的服務器地址、服務接口等信息作為附加屬性，與指標、調(diào)用鏈、日志等信息綁定，并且賦予可觀測系統(tǒng)一定的定制能力，以便靈活滿足更加復雜的運維場景需求。

(3) 統(tǒng)一監(jiān)控視圖與展現(xiàn)

多種形式、多個維度的監(jiān)控視圖可以幫助運維和開發(fā)人員快速發(fā)現(xiàn)系統(tǒng)瓶頸，消除系統(tǒng)隱患。監(jiān)控數(shù)據(jù)的呈現(xiàn)形式應該不僅僅是指標趨勢圖表、柱狀圖等，還需要結(jié)合復雜的實際應用場景需要，讓視圖具備下鉆分析和定制能力，以滿足運維監(jiān)控、版本發(fā)布管理、故障排除等多場景需求。

隨著云原生技術的發(fā)展，基于異構(gòu)微服務架構(gòu)的場景會越來越多、越來越復雜，而可觀測性是一切自動化能力構(gòu)建的基礎。只有實現(xiàn)全面的可觀測性，才能真正提升系統(tǒng)的穩(wěn)定性、降低 MTTR。因此，如何構(gòu)建系統(tǒng)資源、容器、網(wǎng)絡、應用、業(yè)務的全?？捎^測體系，是每個企業(yè)都需要思考的問題。

4. 韌性原則

韌性是指當軟件所依賴的軟硬件組件出現(xiàn)異常時，軟件所表現(xiàn)出來的抵御能力。這些異常通常包括硬件故障、硬件資源瓶頸(如 CPU 或網(wǎng)卡帶寬耗盡)、業(yè)務流量超出軟件設計承受能力、影響機房正常工作的故障或災難、所依賴軟件發(fā)生故障等可能造成業(yè)務不可用的潛在影響因素。

業(yè)務上線之后，在運行期的大部分時間里，可能還會遇到各種不確定性輸入和不穩(wěn)定依賴的情況。當這些非正常場景出現(xiàn)時，業(yè)務需要盡可能地保證服務質(zhì)量，滿足當前以聯(lián)網(wǎng)服務為代表的“永遠在線”的要求。因此，韌性能力的核心設計理念是面向失敗設計，即考慮如何在各種依賴不正常的情況下，減小異常對系統(tǒng)及服務質(zhì)量的影響并盡快恢復正常。

韌性原則的實踐與常見架構(gòu)主要包括服務異步化能力、重試 / 限流 / 降級 / 熔斷 / 反壓、主從模式、集群模式、多 AZ(Availability Zone，可用區(qū))的高可用、單元化、跨區(qū)域(Region)容災、異地多活容災等。

下面結(jié)合具體案例詳細說明如何在大型系統(tǒng)中進行韌性設計。“雙 11”對于阿里巴巴來說是一場不能輸?shù)膽?zhàn)役，因此其系統(tǒng)的設計在策略上需要嚴格遵循韌性原則。例如，在統(tǒng)一接入層通過流量清洗實現(xiàn)安全策略，防御黑產(chǎn)攻擊;通過精細化限流策略確保峰值流量穩(wěn)定，從而保障后端工作正常進行。為了提升全局的高可用能力，阿里巴巴通過單元化機制實現(xiàn)了跨區(qū)域多活容災，通過同城容災機制實現(xiàn)同城雙活容災，從而大程度提升 IDC(Internet Data Center，互聯(lián)網(wǎng)數(shù)據(jù)中心)的服務質(zhì)量。在同一 IDC 內(nèi)通過微服務和容器技術實現(xiàn)業(yè)務的無狀態(tài)遷移;通過多副本部署提高高可用能力;通過消息完成微服務間的異步解耦以降低服務的依賴性，同時提升系統(tǒng)吞吐量。從每個應用的角度，做好自身依賴梳理，設置降級開關，并通過故障演練不斷強化系統(tǒng)健壯性，保證阿里巴巴“雙11”大促活動正常穩(wěn)定進行。

隨著數(shù)字化進程的加快，越來越多的數(shù)字化業(yè)務成為整個社會經(jīng)濟正常運轉(zhuǎn)的基礎設施，但隨著支撐這些數(shù)字化業(yè)務的系統(tǒng)越來越復雜，依賴服務質(zhì)量不確定的風險正變得越來越高，因此系統(tǒng)必須進行充分的韌性設計，以便更好地應對各種不確定性。尤其是在涉及核心行業(yè)的核心業(yè)務鏈路(如金融的支付鏈路、電商的交易鏈路)、業(yè)務流量入口、依賴復雜鏈路時，韌性設計至關重要。

5. 所有過程自動化原則

技術是把“雙刃劍”，容器、微服務、DevOps 以及大量第三方組件的使用，在降低分布式復雜性和提升迭代速度的同時，也提高了軟件技術棧的復雜度，加大了組件規(guī)模，從而不可避免地導致了軟件交付的復雜性。如果控制不當，應用就會無法體會到云原生技術的優(yōu)勢。通過 IaC、GitOps、OAM、Operator 和大量自動化交付工具在 CI/CD(持續(xù)集成 /持續(xù)交付)流水線中的實踐，企業(yè)可以標準化企業(yè)內(nèi)部的軟件交付過程，也可以在標準化的基礎上實現(xiàn)自動化，即通過配置數(shù)據(jù)自描述和面向終態(tài)的交付過程，實現(xiàn)整個軟件交付和運維的自動化。

要想實現(xiàn)大規(guī)模的自動化，需要遵循如下四個基本原則。

(1) 標準化

實施自動化，首先要通過容器化、IaC、OAM 等手段，標準化業(yè)務運行的基礎設施，并進一步標準化對應用的定義乃至交付的流程。只有實現(xiàn)了標準化，才能解除業(yè)務對特定的人員和平臺的依賴，實現(xiàn)業(yè)務統(tǒng)一和大規(guī)模的自動化操作。

(2) 面向終態(tài)

面向終態(tài)是指聲明式地描述基礎設施和應用的期望配置，持續(xù)關注應用的實際運行狀態(tài)，使系統(tǒng)自身反復地變更和調(diào)整直至趨近終態(tài)的一種思想。面向終態(tài)的原則強調(diào)應該避 免直接通過工單系統(tǒng)、工作流系統(tǒng)組裝一系列過程式的命令來變更應用，而是通過設置終態(tài)，讓系統(tǒng)自己決策如何執(zhí)行變更。

(3) 關注點分離

自動化最終所能達到的效果不只取決于工具和系統(tǒng)的能力，更取決于為系統(tǒng)設置目標的人，因此要確保找到正確的目標設置人。在描述系統(tǒng)終態(tài)時，要將應用研發(fā)、應用運維、基礎設施運維這幾種主要角色所關注的配置分離開來，各個角色只需要設置自己所關注和擅長的系統(tǒng)配置，以便確保設定的系統(tǒng)終態(tài)是合理的。

(4) 面向失敗設計

要想實現(xiàn)全部過程自動化，一定要保證自動化的過程是可控的，對系統(tǒng)的影響是可預期的。我們不能期望自動化系統(tǒng)不犯錯誤，但可以保證即使是在出現(xiàn)異常的情況下，錯誤的影響范圍也是可控的、可接受的。因此，自動化系統(tǒng)在執(zhí)行變更時，同樣需要遵循人工變更的好實踐，保證變更是可灰度執(zhí)行的、執(zhí)行結(jié)果是可觀測的、變更是可快速回滾的、變更影響是可追溯的。

業(yè)務實例的故障自愈是一個典型的過程自動化場景。業(yè)務遷移到云上后，云平臺雖然通過各種技術手段大幅降低了服務器出故障的概率，但是卻并不能消除業(yè)務本身的軟件故障。軟件故障既包括應用軟件自身的缺陷導致的崩潰、資源不足導致的內(nèi)存溢出(OOM)和負載過高導致的夯死等異常問題，也包括內(nèi)核、守護進程(daemon 進程)等系統(tǒng)軟件的問題，更包括混部的其他應用或作業(yè)的干擾問題。隨著業(yè)務規(guī)模的增加，軟件出現(xiàn)故障的風險正變得越來越高。傳統(tǒng)的運維故障處理方式需要運維人員的介入，執(zhí)行諸如重啟或者騰挪之類的修復操作，但在大規(guī)模場景下，運維人員往往疲于應對各種故障，甚至需要連夜加班進行操作，服務質(zhì)量很難保證，不管是客戶，還是開發(fā)、運維人員，都無法滿意。

為了使故障能夠?qū)崿F(xiàn)自動化修復，云原生應用要求開發(fā)人員通過標準的聲明式配置，描述應用健康的探測方法和應用的啟動方法、應用啟動后需要掛載和注冊的服務發(fā)現(xiàn)以及配置管理數(shù)據(jù)庫(Configuration Management Data Base，CMDB)信息。通過這些標準的配置，云平臺可以反復探測應用，并在故障發(fā)生時執(zhí)行自動化修復操作。另外，為了防止故障探測本身可能存在的誤報問題，應用的運維人員還可以根據(jù)自身容量設置服務不可用實例的比例，讓云平臺能夠在進行自動化故障恢復的同時保證業(yè)務可用性。實例故障自愈的實現(xiàn)，不僅把開發(fā)人員和運維人員從煩瑣的運維操作中解放了出來，而且可以及時處理各種故障，保證業(yè)務的連續(xù)性和服務的高可用性。

6. 零信任原則

基于邊界模型的傳統(tǒng)安全架構(gòu)設計，是在可信和不可信的資源之間架設一道墻，例如，公司內(nèi)網(wǎng)是可信的，而因特網(wǎng)則是不可信的。在這種安全架構(gòu)設計模式下，一旦入侵者滲透到邊界內(nèi)，就能夠隨意訪問邊界內(nèi)的資源了。而云原生架構(gòu)的應用、員工遠程辦公模式的普及以及用手機等移動設備處理工作的現(xiàn)狀，已經(jīng)完全打破了傳統(tǒng)安全架構(gòu)下的物理邊界。員工在家辦公也可以實現(xiàn)與合作方共享數(shù)據(jù)，因為應用和數(shù)據(jù)被托管到了云上。

如今，邊界不再是由組織的物理位置來定義，而是已經(jīng)擴展到了需要訪問組織資源和服務的所有地方，傳統(tǒng)的防火墻和虛擬專用網(wǎng)已經(jīng)無法可靠且靈活地應對這種新邊界。因此，我們需要一種全新的安全架構(gòu)，來靈活適應云原生和移動時代環(huán)境的特性，不論員工在哪里辦公，設備在哪里接入，應用部署在哪里，數(shù)據(jù)的安全性都能夠得到有效保護。如果要實現(xiàn)這種新的安全架構(gòu)，就要依托零信任模型。

傳統(tǒng)安全架構(gòu)認為防火墻內(nèi)的一切都是安全的，而零信任模型假設防火墻邊界已經(jīng)被攻破，且每個請求都來自于不可信網(wǎng)絡，因此每個請求都需要經(jīng)過驗證。簡單來說，“永不信任，永遠驗證”。在零信任模型下，每個請求都要經(jīng)過強認證，并基于安全策略得到驗證授權。與請求相關的用戶身份、設備身份、應用身份等，都會作為核心信息來判斷請求是否安全。

如果我們圍繞邊界來討論安全架構(gòu)，那么傳統(tǒng)安全架構(gòu)的邊界是物理網(wǎng)絡，而零信任安全架構(gòu)的邊界則是身份，這個身份包括人的身份、設備的身份、應用的身份等。要想實現(xiàn)零信任安全架構(gòu)，需要遵循如下三個基本原則。

(1) 顯式驗證

對每個訪問請求都進行認證和授權。認證和授權需要基于用戶身份、位置、設備信息、服務和工作負載信息以及數(shù)據(jù)分級和異常檢測等信息來進行。例如，對于企業(yè)內(nèi)部應用之間的通信，不能簡單地判定來源 IP是內(nèi)部 IP 就直接授權訪問，而是應該判斷來源應用的身份和設備等信息，再結(jié)合當前的策略授權。

(2) 最少權限

對于每個請求，只授予其在當下必需的權限，且權限策略應該能夠基于當前請求上下文自適應。例如，HR 部門的員工應該擁有訪問 HR相關應用的權限，但不應該擁有訪問財務部門應用的權限。

(3) 假設被攻破

假設物理邊界被攻破，則需要嚴格控制安全爆炸半徑，將一個整體的網(wǎng)絡切割成對用戶、設備、應用感知的多個部分。對所有的會話加密，使用數(shù)據(jù)分析技術保證對安全狀態(tài)的可見性。

從傳統(tǒng)安全架構(gòu)向零信任架構(gòu)演進，會對軟件架構(gòu)產(chǎn)生深刻的影響，具體體現(xiàn)在如下三個方面。

第一，不能基于 IP 配置安全策略。在云原生架構(gòu)下，不能假設 IP 與服務或應用是綁定的，這是由于自動彈性等技術的應用使得 IP 隨時可能發(fā)生變化，因此不能以 IP 代表應用的身份并在此基礎上建立安全策略。

第二，身份應該成為基礎設施。授權各服務之間的通信以及人訪問服務的前提是已經(jīng)明確知道訪問者的身份。在企業(yè)中，人的身份管理通常是安全基礎設施的一部分，但應用的身份也需要管理。

第三，標準的發(fā)布流水線。在企業(yè)中，研發(fā)的工作通常是分布式的，包括代碼的版本管理、構(gòu)建、測試以及上線的過程，都是比較獨立的。這種分散的模式將會導致在實際生產(chǎn)環(huán)境中運行的服務的安全性得不到有效保證。如果可以標準化代碼的版本管理、構(gòu)建以及上線的流程，那么應用發(fā)布的安全性就能夠得到集中增強。

總體來說，整個零信任模型的建設包括身份、設備、應用、基礎設施、網(wǎng)絡、數(shù)據(jù)等幾個部分。零信任的實現(xiàn)是一個循序漸進的過程，例如，當組織內(nèi)部傳輸?shù)乃辛髁慷紱]有加密的時候，第一步應該先保證訪問者訪問應用的流量是加密的，然后再逐步實現(xiàn)所有流量的加密。如果采用云原生架構(gòu)，就可以直接使用云平臺提供的安全基礎設施和服務，以便幫助企業(yè)快速實現(xiàn)零信任架構(gòu)。

7. 架構(gòu)持續(xù)演進原則

如今，技術與業(yè)務的發(fā)展速度都非常快，在工程實踐中很少有從一開始就能夠被明確定義并適用于整個軟件生命周期的架構(gòu)模式，而是需要在一定范圍內(nèi)不斷重構(gòu)，以適應變 化的技術和業(yè)務需求。同理，云原生架構(gòu)本身也應該且必須具備持續(xù)演進的能力，而不是一個封閉式的、被設計后一成不變的架構(gòu)。因此在設計時除了要考慮增量迭代、合理化目標選取等因素之外，還需要考慮組織(例如架構(gòu)控制委員會)層面的架構(gòu)治理和風險控制規(guī)范以及業(yè)務自身的特點，特別是在業(yè)務高速迭代的情況下，更應該重點考慮如何保證架構(gòu)演進與業(yè)務發(fā)展之間的平衡。

(1) 演進式架構(gòu)的特點和價值

演進式架構(gòu)是指在軟件開發(fā)的初始階段，就通過具有可擴展性和松耦合的設計，讓后續(xù)可能發(fā)生的變更更加容易、升級性重構(gòu)的成本更低，并且能夠發(fā)生在開發(fā)實踐、發(fā)布實踐和整體敏捷度等軟件生命周期中的任何階段。

演進式架構(gòu)之所以在工業(yè)實踐中具有重要意義，其根本原因在于，在現(xiàn)代軟件工程領域達成的共識中，變更都是很難預測的，其改造的成本也極其高昂。演進式架構(gòu)并不能避免重構(gòu)，但是它強調(diào)了架構(gòu)的可演進性，即當整個架構(gòu)因為技術、組織或者外部環(huán)境的變化需要向前演進時，項目整體依然能夠遵循強邊界上下文的原則，確保領域驅(qū)動設計中描述的邏輯劃分變成物理上的隔離。演進式架構(gòu)通過標準化且具有高可擴展性的基礎設施體系，大量采納標準化應用模型與模塊化運維能力等先進的云原生應用架構(gòu)實踐，實現(xiàn)了整個系統(tǒng)架構(gòu)在物理上的模塊化、可復用性與職責分離。在演進式架構(gòu)中，系統(tǒng)的每個服務在結(jié)構(gòu)層面與其他服務都是解耦的，替換服務就像替換樂高積木一樣方便。

(2) 演進式架構(gòu)的應用

在現(xiàn)代軟件工程實踐中，演進式架構(gòu)在系統(tǒng)的不同層面有著不同的實踐與體現(xiàn)。

在面向業(yè)務研發(fā)的應用架構(gòu)中，演進式架構(gòu)通常與微服務設計密不可分。例如，在阿里巴巴的互聯(lián)網(wǎng)電商應用中(例如大家所熟悉的淘寶和天貓等)，整個系統(tǒng)架構(gòu)實際上被精細地設計成數(shù)千個邊界劃分明確的組件，其目的就是為希望做出非破壞性變更的開發(fā)人員 提供更大的便利，避免因為不適當?shù)鸟詈蠈⒆兏鼘螂y以預料的方向，從而阻礙架構(gòu)的演 進。可以發(fā)現(xiàn)，演進式架構(gòu)的軟件都支持一定程度的模塊化，這種模塊化通常體現(xiàn)為經(jīng)典的分層架構(gòu)及微服務的好實踐。

而在平臺研發(fā)層面，演進式架構(gòu)更多地體現(xiàn)為基于“能力”的架構(gòu)( Capability Oriented Architecture，COA)。在 Kubernetes 等云原生技術逐漸普及之后，基于標準化的云原生基礎設施正迅速成為平臺架構(gòu)的能力提供方，而以此為基礎的開放應用模型( Open ApplieationModel，OAM )理念，正是一種從應用架構(gòu)視角出發(fā)，將標準化基礎設施按照能力進行模塊化的 COA 實踐。

(3) 云原生下的架構(gòu)演進

當前，演進式架構(gòu)還處于快速成長與普及階段。不過，整個軟件工程領域已經(jīng)達成共識，即軟件世界是不斷變化的，它是動態(tài)而非靜態(tài)的存在。架構(gòu)也不是一個簡單的等式，它是持續(xù)過程的一種快照。所以無論是在業(yè)務應用還是在平臺研發(fā)層面，演進式架構(gòu)都是一個必然的發(fā)展趨勢。業(yè)界大量架構(gòu)更新的工程實踐都詮釋了一個問題，即由于忽略實現(xiàn)架構(gòu)，且保持應用常新所要付出的精力是非常巨大的。但好的架構(gòu)規(guī)劃可以幫助應用降低新技術的引入成本，這要求應用與平臺在架構(gòu)層面滿足:架構(gòu)標準化、職責分離與模塊化。而在云原生時代，開發(fā)應用模型( OAM )正在迅速成為演進式架構(gòu)推進的重要助力。

結(jié)語

我們可以看到云原生架構(gòu)的構(gòu)建和演進都是以云計算的核心特性(例如，彈性、自動化、韌性)為基礎并結(jié)合業(yè)務目標以及特征進行的，從而幫助企業(yè)和技術人員充分釋放云計算的技術紅利。隨著云原生的不斷探索，各類技術不斷擴展，各類場景不斷豐富，云原生架構(gòu)也將不斷演進。但在這些變化過程中。典型的架構(gòu)設計原則始終都有著重要意義，指導我們進行架構(gòu)設計以及技術落地。

文章題目：云原生架構(gòu)需遵循七個原則
網(wǎng)站路徑：http://muchs.cn/news/203307.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供建站公司、全網(wǎng)營銷推廣、小程序開發(fā)、品牌網(wǎng)站建設、微信公眾號、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)