以業務需求為中心的雲原生架構體系建設

雲原生（Cloud-Native）的概念在國內提及的越來越多，但大部分人對雲原生的認識僅限於容器、微服務、DevOps等內容，把容器、微服務、 DevOps就等同於雲原生，這顯然是不對的。CNCF從其自身的角度定義了雲原生技術：雲原生技術使企業能夠在現代動態環境中構建和執行可擴充套件的應用程式，如在公共雲、私有云和混合雲環境中。包括容器、服務網格、微服務、不變的基礎設施和宣告式API等。採用這些技術可實現系統的鬆散耦合性、彈性、可管理性和可觀察性等。也可以與自動化相結合，實現以最少的工作量頻繁地、可預測地進行重大影響的功能的變更。

　　雲端計算提供了敏捷的、自服務的、不變的基礎設施等內容，使業務應用上雲逐漸成為一種共識，但不進行雲原生架構重構而直接上雲可能是危險的，傳統業務應用架構無法在雲上進行彈性擴充套件和敏捷響應，無法有效利用雲端計算的特性賦能企業。所以這可能需要對傳統架構的業務系統進行分散式微服務分拆重構，部署執行在容器雲平臺等之中，使用DevOps思想，透過CI、CD等持續提升交付效率，等等。使應用從一開始被建立就具備雲的特性，為雲而生，它是為了充分利用雲端計算的分散式和彈性擴充套件等特徵，使其具備或適應雲上部署執行的要求，或者直接用雲的思想、方法、工具在雲中建立，天生具備雲的特性。所以雲原生可以認為是一種基於雲來構建和執行雲應用程式的方法論和技術體系，使用雲原生技術和方法論來構建和執行管理雲應用。

　　Matt Stine在2015年發表《遷移到雲原生架構》一書中定義了符合雲原生架構的特徵：12要素應用、微服務、自服務敏捷基礎設施、基於API協作、扛脆弱性等。雲原生體系內容沒有明確的定義，不過通常認為雲原生技術體系和方法論包括微服務、容器、DevOps、持續交付、ServiceMesh、不可變基礎設施、宣告式API、混沌工程、安全、基於移動的客戶體驗等內容 。

　　圖 1 雲原生技術體系

　　十二個要素應用為雲原生應用的設計提供了原則指導；微服務架構為雲原生應用架構設計、分散式部署、敏捷變更等提供了方案；容器則為雲原生應用提供了彈性伸縮、一致性環境等能力，和微服務結合，支撐應用隨需擴充套件；自服務敏捷基礎設施則提供了雲原生應用持續交付的基礎設施資源等保障，可以和容器化PaaS平臺共同支撐雲原生應用的自動化彈性擴充套件、視覺化監控、自動化智慧化運維運營等，使使用者無需關注基礎設施資源，無需運維基礎設施資源，無需關注應用部署位置等；服務網格支撐著服務的管理和治理；混沌工程則持續增強系統的韌性和穩定性；DevOps最佳化組織間的協同，滿足彼此的關切，指導C ICD的落地和持續交付，實現應用全生命週期管理；宣告式 A PI則實現了服務標準化釋出和服務之間的協同；安全則涉及雲原生架構體系的方方面面，比如 D evOps安全 D evSecOps、容器映象安全、網路安全、應用安全、 A PI安全、認證授權、訪問控制等等；所有這些技術和方法、原則滿足客戶隨時隨地隨需的需求，簡化客戶操作，提升客戶體驗。

　　基於對雲原生架構體系的學習和理解，筆者覺得一個相對完整的雲原生架構體系內容包括如圖中的內容：

　　

圖 2 雲原生架構體系

　　隨著行動通訊技術的發展和移動裝置的普及，人們的工作、生活、社交、投資等方式發生了顯著的變化。當前人們透過手機基本上可以隨時隨地滿足需求。使用者可能在不同的時間（ 7x 24）透過不同終端、不同作業系統、不同版本、不同地方等訪問業應用系統，這就要求不僅僅是APP客戶端操作便利、互動友好，也要求後端服務和系統能夠敏捷響應。手機 App 應用 的體驗好壞可能直接決定著使用者是否繼續使用它。在移動互聯時代，使用者移動化體驗需求是應用設計的 關鍵驅動因素 。

　　雲應用12要素描述了一種雲應用原型，是一種雲應用（可獨立部署的單元）設計原則和方法論。它透過強調宣告式配置、水平擴充套件的無狀態/無共享程式，以及與部署環境的整體松耦合，來關注速度、安全性和可擴充套件性。Kevin Hoffman 於《Beyond the 12-factor App》中重新描述並擴充套件了雲原生應用的12因素並增加API優先 、遙測、認證和授權三個要素。新增的要素糅合了API協同、視覺化監控、安全性等內容，在指導雲原生應用的設計方面更加完善。

　　微服務架構是一種應用分散式架構方式，它將單體巨石應用拆分為若干個單一能力的可獨立部署的服務，就是微服務。通常一個微服務代表一種業務能力，或是提供業務價值的最小的“原子”服務單元。它解決了緊耦合的單體巨石系統難以變更難以更新的問題，實現輕量、敏捷變更。

圖 3 單體架構演化到微服務架構

　　中臺本質也是一種架構方式，其核心是實現複用。中臺一直被當作是一種企業架構，沒有很明確討論複用的粒度，所以其落地沒有明確的方式方法和標準。從應用架構角度來說，中臺和應用的前、中、後端層次劃分沒有本質區別，算不上一種新的架構方式。微服務分解架構從橫向將系統進行分解，中臺分層架構從縱向將系統分層，從而實現微服務在不同層次的複用和共享。從單個應用系統擴充套件到企業所有的系統，最終可以融合成一個分層分解的企業級系統，這就是筆者一直所提的 “ 系統融合 ” 思路。

　　容器是一種核心輕量級的作業系統層虛擬化技術，在流程級別提供隔離，為單一的應用程式提供執行一致的執行環境。每個應用程式及其環境都可以在隔離的環境中執行。容器特性和微服務架構非常契合，因此微服務通常部署在容器中，實現敏捷部署、自動化彈性伸縮、環境一致性等能力。但容器依然是相對底層的執行單元，眾多容器的管理和治理是個難題。Kubernetes（也稱為K8s）是一個開源容器管理和排程框架，用於自動化容器應用程式的部署、擴充套件和管理。它將構成應用程式的容器分組到邏輯單元中，以便於管理和發現。容器雲平臺是採用容器和容器管理及排程技術而構建的應用管理部署執行平臺，支援不同租戶的容器應用管理和治理能力。基於容器雲而把日誌、監控、認證、許可權、配置、中介軟體、工具平臺，以及演算法等統一部署維護，提供企業級平臺服務能力，構建輕量化P aaS平臺，結合自動化、智慧化實現自服務敏捷響應基礎設施能力。

　　圖 4 容器雲架構

　　雲原生的核心是雲原生應用。自服務敏捷響應基礎設施為雲原生應用的自動化環境準備、構建、部署、監控、反饋、健康檢查、故障自愈、資源排程、彈性伸縮、動態路由和負載均衡等提供支撐， 實現自主服務平臺進行雲原生應用的部署和執行，使配置管理自動化、基礎設施資源透明，無需關注應用執行在什麼地方；將IaaS和PaaS最終融合在一起，提供更流暢的、一致的體驗；企業內部可透過基礎設施資源管理（多雲管理平臺）實現異構資源的管理，統一的資源服務；實現持續交付，提升可用性、可擴充套件性、可管理性。

　　DevOps是一種理念和方法論，目的是為了協調和理順開發和運維團隊之間的關切，提升協作效率。DevOps旨在實現開發運維一體化，透過自動化、智慧化等工具實現應用全生命週期管理和組織之間的高效協同。基於D evOps方法論和理念所構建的平臺也稱為 D evOps平臺，通常要用自動化流水線等實現持續整合 C I、持續交付CD等能力。Google SRE是DevOps的一種具體實踐，它透過系統工程的思想來解決軟體工程的問題， 使運維自動化和智慧化。運維人員不低於 5 0%的時間做運維工具的研發，讓研發人員專注於業務應用的研發。Google SRE使用錯誤預算來協調研發和運維之間的關切，一旦錯誤預算用盡，則運維將拒絕業務應用的釋出部署，從而使研發要關注業務應用的穩定性和健壯性。

　　服務網格（ServiceMesh ）實現微服務東西向流量的管理和治理。其區別於API閘道器對服務南北向流量的管理和治理。其通常應用於容器環境，以sidecar的方式代理流量管理、可觀測性和安全能力。服務網格總體架構由流量代理元件和管理元件組成， 代理元件被稱為資料平面，直接處理入站和出站資料包，轉發、路由、健康檢查、負載均衡、認證、鑑權、產生監控資料等。管理元件被稱為控制平面，負責與代理通訊，下發策略和配置。筆者一直跟蹤著服務網格發展但一直沒有采用，原因在於一方面感覺其不夠成熟，另一方面其加層的方式會帶來延遲，和筆者推崇的簡單方式解決複雜問題思路有悖。

　　抗脆弱性由Naasim Taleb在《Antifragile》書中提出，將故障隨機注入到生產環境中，目的是為了識別和消除架構中的缺陷，找到應用架構中的弱點，並強制進行修復，架構會隨著時間的推移而變得強壯，提升其穩定性、可用性、耐久性等。在國內也稱之為混沌工程（Chaos Engineering）。中國信通院於2 020年開始組織 進行混沌工程技術研究，提出了應用混沌工程方法來驗證雲原生系統的韌性架構，同時成立混沌工程專案組。2 021年 釋出《混沌工程測試平臺能力》標準綱要，併發布行業標準《混沌工程平臺能力要求》。

　　雲原生應用之間的互動是透過已釋出和版本化的API來實現的，通常採用HTTP Rest 風格序列化JSON資料。透過API 可以提供一層可重用介面層。同時API封裝了業務邏輯內部細節，消費者不能直接訪問API服務內部資料，也在一定程度上增強了資料安全。

　　安全是任何系統不可或缺的部分。風險無處不在，雲原生架構體系中內容眾多，每個元件每個服務都可能帶來風險和安全問題（因此要透過 “ 減層 ” 方法最小化元件和服務，嚴格遵循 “ 非必要不採用原則 ” ）。從雲原生應用生命週期過程來說，雲原生安全可以簡單分為 “ 設計時安全 ” 和 “ 執行時安全 ” 兩段。設計時以靜態檢測分析為主，比如程式碼分析、映象漏洞掃描等；執行時以動態和互動式檢測、防護、分析為主，比如入侵檢測、病毒查殺、網路微隔離等。雲原生安全可以利用傳統的安全技術和方法，比如認證授權、訪問控制、加密解密、合規檢測、靜態安全檢測、動態安全檢測、網路隔離等等，重點是透過可用的安全機制增強雲原生安全能力。雖然我們提倡安全左移，儘可能將安全風險消除在設計時段，但執行時安全一樣不可少，安全漏洞隨時都可能出現，採用微服務、容器的雲原生架構也為執行時帶來了更多的風險點，安全防控更加不易。需要不斷提升系統可見性、錯誤隔離等能力提升安全管控能力。雲原生安全和傳統網路安全的分安全域模式不同，它需要動態的自動化和智慧化的管控能力。雲原生未來可能逐漸透過軟體定義邊界、增強的身份認證、微隔離等技術實現動態的網路安全管控。

　　

　　雲原生架構體系內容比較龐大，深入到每一個部分都有很多的工作。不過在對雲原生體系架構和體系內容有全面的瞭解之後，認識到彼此之間的聯絡和侷限，才能真正構建滿足客戶需求、支援移動化隨時隨地隨需的服務、具備雲端計算特性彈性擴充套件、敏捷響應、安全穩定的雲原生應用。