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

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

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

圖1云原生技術體系

十二個要素應用為云原生應用的設計提供了原則指導；微服務架構為云原生應用架構設計、分布式部署、敏捷變更等提供了方案；容器則為云原生應用提供了彈性伸縮、一致性環(huán)境等能力，和微服務結合，支撐應用隨需擴展；自服務敏捷基礎設施則提供了云原生應用持續(xù)交付的基礎設施資源等保障，可以和容器化PaaS平臺共同支撐云原生應用的自動化彈性擴展、可視化監(jiān)控、自動化智能化運維運營等，使用戶無需關注基礎設施資源，無需運維基礎設施資源，無需關注應用部署位置等；服務網(wǎng)格支撐著服務的管理和治理；混沌工程則持續(xù)增強系統(tǒng)的韌性和穩(wěn)定性；DevOps優(yōu)化組織間的協(xié)同，滿足彼此的關切，指導C ICD的落地和持續(xù)交付，實現(xiàn)應用全生命周期管理；聲明式A PI則實現(xiàn)了服務標準化發(fā)布和服務之間的協(xié)同；安全則涉及云原生架構體系的方方面面，比如D evOps安全D evSecOps、容器鏡像安全、網(wǎng)絡安全、應用安全、A PI安全、認證授權、訪問控制等等；所有這些技術和方法、原則滿足客戶隨時隨地隨需的需求，簡化客戶操作，提升客戶體驗。

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

圖2云原生架構體系

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

云應用12要素描述了一種云應用原型，是一種云應用（可獨立部署的單元）設計原則和方法論。它通過強調聲明式配置、水平擴展的無狀態(tài)/無共享進程，以及與部署環(huán)境的整體松耦合，來關注速度、安全性和可擴展性。Kevin Hoffman于《Beyond the 12-factor App》中重新描述并擴展了云原生應用的12因素并增加API優(yōu)先、遙測、認證和授權三個要素。新增的要素糅合了API協(xié)同、可視化監(jiān)控、安全性等內容，在指導云原生應用的設計方面更加完善。

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

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

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

容器是一種內核輕量級的操作系統(tǒng)層虛擬化技術，在流程級別提供隔離，為單一的應用程序提供運行一致的運行環(huán)境。每個應用程序及其環(huán)境都可以在隔離的環(huán)境中運行。容器特性和微服務架構非常契合，因此微服務通常部署在容器中，實現(xiàn)敏捷部署、自動化彈性伸縮、環(huán)境一致性等能力。但容器依然是相對底層的運行單元，眾多容器的管理和治理是個難題。Kubernetes（也稱為K8s）是一個開源容器管理和調度框架，用于自動化容器應用程序的部署、擴展和管理。它將構成應用程序的容器分組到邏輯單元中，以便于管理和發(fā)現(xiàn)。容器云平臺是采用容器和容器管理及調度技術而構建的應用管理部署運行平臺，支持不同租戶的容器應用管理和治理能力。基于容器云而把日志、監(jiān)控、認證、權限、配置、中間件、工具平臺，以及算法等統(tǒng)一部署維護，提供企業(yè)級平臺服務能力，構建輕量化P aaS平臺，結合自動化、智能化實現(xiàn)自服務敏捷響應基礎設施能力。

圖4容器云架構

云原生的核心是云原生應用。自服務敏捷響應基礎設施為云原生應用的自動化環(huán)境準備、構建、部署、監(jiān)控、反饋、健康檢查、故障自愈、資源調度、彈性伸縮、動態(tài)路由和負載均衡等提供支撐，實現(xiàn)自主服務平臺進行云原生應用的部署和運行，使配置管理自動化、基礎設施資源透明，無需關注應用運行在什么地方；將IaaS和PaaS最終融合在一起，提供更流暢的、一致的體驗；企業(yè)內部可通過基礎設施資源管理（多云管理平臺）實現(xiàn)異構資源的管理，統(tǒng)一的資源服務；實現(xiàn)持續(xù)交付，提升可用性、可擴展性、可管理性。

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

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

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

云原生應用之間的交互是通過已發(fā)布和版本化的API來實現(xiàn)的，通常采用HTTP Rest風格序列化JSON數(shù)據(jù)。通過API可以提供一層可重用接口層。同時API封裝了業(yè)務邏輯內部細節(jié)，消費者不能直接訪問API服務內部數(shù)據(jù)，也在一定程度上增強了數(shù)據(jù)安全。

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

云原生架構體系內容比較龐大，深入到每一個部分都有很多的工作。不過在對云原生體系架構和體系內容有全面的了解之后，認識到彼此之間的聯(lián)系和局限，才能真正構建滿足客戶需求、支持移動化隨時隨地隨需的服務、具備云計算特性彈性擴展、敏捷響應、安全穩(wěn)定的云原生應用。