云原生2.0架構白皮書以云原生的思維踐行云原生構建萬物互聯的智能世界從業界首次提出云計算迄今為止的十多年歷程中，全球正在從面向個人消費者的開放式移動互聯以及面向企業、行業、政府的封閉IT

的兩極化時代，穩步邁向萬物互聯、數字化、智能化，各領域應用和業務統一走向云端的新時代，在這幾乎影響到全社會、全行業、國民經濟乃至日常生產生活方方面面的數字化轉型過程中，多樣化的云部署形態：無論公有云、私有云，以及行業云、政務云等，無不通過云服務為載體，將云計算、大數據、人工智能、物聯網等技術有機整合在一起，為企業提供一站式的“云原生”數字化底座引擎，從而使得企業

IT

信息系統的開發者和運維者可以從繁重的非業務平臺開發與維護的技術細節中解放出來，以更低的學習成本接入并使用云服務的能力，真正聚焦于業務本身，進而將企業業務的創新能力、經營優化與決策能力，乃至生產力水平帶上一個新的臺階。就云原生而言，其初衷更多是將彈性按需、水平擴展、高可靠高冗余、狀態與應用分離等關鍵云架構屬性特征以架構設計模式以規范參考架構及方法論的形式總結提煉出來，從而為企業應用的云化架構重構改造提供指引。后來

CNCF

云原生開源社區的誕生，通過

K8S

容器使得計算資源的輕量化、小型化，以及應用服務的集成打包封裝等，逐步成為標準化、模塊化的技術選擇，與此同時云原生的方法論、工具集，以及全棧云原生參考架構等方面，也在

CNCF

云原生社區中得到了進一步的定義與分解。雖然

CNCF

等開源社區的系列云原生開源技術，比之前的“抽象設計模式”更進了一步，為企業

IT

業務架構在無修改整體搬遷上云的基礎上，進一步展開更深度的云原生架構重構與改造，從而為最大限度地釋放云的技術與商業紅利提供了“技術組件與平臺”，序言然而要真正支撐完整的企業全棧

IT

的重構，僅僅依賴容器化平臺來承載企業自己開發的業務邏輯，以解決云原生應用的部署態及運行態彈性可靠性，及無單點高可靠、高可用問題，仍然是遠遠不夠的，為進一步提升企業核心業務處理及

AI

創新應用的端到端開發態效率，突破傳統垂直

IT

架構的數據層的擴展性瓶頸能力，解決大集中云資源池難以支撐時延敏感應用及數據主權隱私保護，DevOps

開發流水線工具集、去中心化架構的分布式中間件、分布式數據庫、云邊端及多云協同架構、乃至普惠

AI

開發平臺，無一不是未來全棧云原生重構所必須依賴的“基本要素”。由此，華為云通過自身在云原生開源社區的貢獻與引領，云原生架構、全棧云原生服務產品的持續創新開發，以及支撐千行百業客戶上云的實踐經驗，在業界已有的云原生系列概念與開源技術基礎上，首倡提出了“云原生

2.0”的理念與框架體系，旨在通過這本白皮書向華為云的生態伙伴及企業行業客戶闡述自己對企業云化、數字化轉型的系統化思考、建議與展望。云原生

2.0，代表了云計算下個十年的發展趨勢，即是云原生

1.0

的平滑延續，更為即將到來得全行業數字化經濟時代定義了標準化、開放式、可高效批量復制的“智能世界云底座”參考架構與事實標準，各位開發者、架構師、以及技術管理決策者們，讓我們一起迎接并盡情擁抱云原生

2.0

時代的到來，共同引領云原生

2.0

產業走向更加美好和生機勃勃的未來！編寫說明編寫單位：華為云編寫組成員華為云顧炯炯雷曉松黃

毽張

琦吳清輝張

煜伍華濤李

昆文

震龍

江郭奉民朱冠宇彭立勛傅

飛俞

岳曾正陽劉丙真曹宗南懷寶興顧震宇胡紅山胡

巍王顯雷李善航唐金根蘭修文禹英軻第一章

云原生概念與技術的歷史 / 0011.1

云原生的定義，什么是云原生（Cloud

Native）？/

002云原生

1.0

的技術特征 /006云原生

1.0

的典型架構模式 /

008云原生

1.0

面臨的挑戰

&

云原生

2.0 /

015第二章

云原生

2.0

的技術及架構特征關鍵特征一：分布式云 /023趨勢與需求

/

023關鍵特征與架構原則

/

024/ 022關鍵特征二：應用驅動基礎設施 /

031趨勢與需求

/

031關鍵特征與架構原則

/

032關鍵特征三：混合部署，統一調度 /

037趨勢與需求

/

037關鍵特征與架構原則

/

037關鍵特征四：無服務器化（Serverless） /

040趨勢與需求

/

040關鍵特征與架構原則

/

041關鍵特征五：存算分離趨勢與需求

/

044關鍵特征與架構原則/

044/

045目錄目錄關鍵特征六：數據治理自動化 /

046趨勢與需求

/

046關鍵特征與架構原則

/

047關鍵特征七：基于軟總線的異構集成 /

048趨勢與需求

/

048關鍵特征與架構原則

/

048關鍵特征八：可信、平民化

DevOps /

052趨勢與需求

/

052關鍵特征與架構原則

/

052關鍵特征九：多模態可迭代行業

AI /

055趨勢與需求

/

055關鍵特征與架構原則

/

057關鍵特征十：全方位立體化安全 /

061趨勢與需求

/

061關鍵特征與架構原則

/

062第三章

華為云云原生

2.0架構設計模式 / 067華為云原生架構設計方法

（Huawei

Cloud

Native

Architecting

Methodology） /

068企業數字化戰略

–

云原生技術架構的根本驅動力

/

069業務可持續發展

–

云原生技術架構的直接驅動力

/

070架構設計視角

–

云原生技術架構本身

/070組織變更視角

/

073工程變革視角

/

074架構持續演進閉環

/

075企業云原生架構的可持續演進與迭代能力：基于服務開發服務 /

075云原生

2.0

架構白皮書華為云云原生

2.0

的典型架構設計模式 /

076分布式云設計模式

/

076極致性價比驅動的軟硬協同架構設計模式

/

082多元算力統一資源池架構設計模式

/

084無服務器化（Serverless）架構設計模式

/

085存算分離架構設計模式

/

091數據治理自動化架構設計模式

/

094基于軟總線異構集成的架構設計模式

/

0993.3.8可信、平民化

DevOps架構設計模式

/

101多模態可迭代行業

AI架構設計模式

/

105全方位立體式安全防護架構設計模式

/

113第四章

華為云云原生

2.0典型案例實踐 / 142長沙政務云 /143夢餉集團 /1444.3

上海

12345

熱線 /1464.4

順豐科技/1484.5

新潮傳媒/1504.6

一汽紅旗/1524.7

國網信通/1544.8

江蘇財政/1554.9

深圳巴士/1564.10

信義玻璃/

158第五章

未來趨勢展望 / 160目錄001云原生

2.0

架構白皮書第一章云原生概念與技術的歷史002業界關于云原生的概念，最早出現在

2010

年，由應用集成中間件廠商WSO2

提出，其關于云原生關鍵特征的提煉與描述包括：分布式、動態連接：云化應用與中間件需支持多個共享配置及共享會話狀態，且并行運行的節點，另外不能假設云化應用是一種單一語言開發的，因此各云化應用之間要支持動態按需連接（與具體開發語言無關）。●●●●彈性：也即云化應用與中間件的分布式子節點應能根據系統的動態負載情況，進行按需的實例伸縮，包括調用云基礎服務

API

啟停虛機鏡像。多租戶：云化應用與中間件的多租方式有

2

類，1

類為物理多租，另

1

類為邏輯多租；前者靠將應用實例復制多份

VM

或容器來實現，而后者則倡導“云化應用與中間件”內生的邏輯多租戶隔離，一般建議云化應用和中間件在可能的情況盡量使用邏輯多租，因為其在滿足多租能力需求的同時，占用相比物理多租更少的資源。自服務：自助式業務發放及管理對于最大化發揮云系統的效率至關重要，租戶彈性賬號內如果完全依賴管理員進行一切搭建、配置及管理活動，則不能稱之為

IaaS/PaaS/SaaS

服務，分別對應在基礎設施領域管理租戶自己的

VM

或容器，在平臺層領域管理并部署生產應用與中間件；在軟件層領域則在特定應從用中直接創建和管理“自己的租戶”。顆粒化的計量計費：按使用計費是云的基礎特征之一，按年計費與按小時計費顯然顆粒度有很大區別，即使對于私有云場景，對資源消費的計量也很重要，在一個自服務、多租戶、彈性的系統內資源和服務的使用情況就對應了系統的真實成本付出，因此深入理解、度量并監控資源的使用是至關重要的。●增量的部署和測試；在一個高度可擴展、具備超大容量的云環境內，即便大型云客戶的新版本已進行過充分的單元或者系統測試，他們仍然希望能在生產環境上展開新版本的試錯性測試，并且可以在新舊共存版本之間控制流量分發的百分比。而采用云原生可以帶來的價值則包括：更高的資源利用率，更快的發放效率，更好的應用治理；從上面的云原生特征總結來看，與

NIST

對云計算的關鍵要素定義看起來比較相似，但云計算的定義更多是從云平臺的視角出發，而云原生則更多是以云化應用為討論出發點。2013

年，亞馬遜

AWS及其戰略伙伴

Net?ix

的最佳實踐，進一步對云原生給出了自己的詮釋：基于不可靠、易失效的基礎設施，構建高度敏捷、高可用服務。1.1 云原生的定義，什么是云原生（Cloud

Native）？第一章

|

云原生概念與技術的歷史003云原生

2.0

架構白皮書目標：伸縮性、可用性、敏捷、效率。原則：關注點分離，反脆弱性，高度信任的組織。特點：基于公有云（Public

Cloud），微服務（Micro-services），反范式化數據（De-normalizeddata），混沌引擎（Chaos

Engines），持續部署（ContinuesDeployment），DevOps等。2015

年，由

Heroku

提出，AWS

Elastic

BeansTalk，Cloud

Foundry

等共同參與進一步對云原生的架構特征進行了系統化總結與補充，首次提出了云原生“十二因子”，微服務，以及

DevOps等云原生的關鍵要素與特征：十二因子應用（Twelve-Factor）因子

1：一份代碼，多份部署每個可部署

app

在版本控制系統中僅有一個獨立的代碼庫，可以在不同的環境中部署多個實例。因子

2：依賴App

應該使用適當的工具（如

Maven、Bundler、NPM）來對依賴進行顯式的聲明，而不該在部署環境中隱式的實現依賴。因子

3：配置配置或其他隨發布環境（如部署、類生產、生產）而變更的部分應當作為操作系統級的環境變量注入。因子

4：后端服務后端服務，例如數據庫、消息代理應視為附加資源，并在所有環境中同等看待。因子

5：構建，發布，運行嚴格區分構建，發布，運行這三個步驟。直接修改處于運行狀態的代碼是非常不可取的做法，因為這些修改很難再同步回構建步驟。因子

6：進程以一個或多個無狀態進程運行應用，任何需要持久化的數據存儲在后端服務內，比如數據庫。第一章

|

云原生概念與技術的歷史因子

7：端口綁定應用完全自我加載而不依賴于任何網絡服務器就可以創建一個面向網絡的服務。互聯網應用通過端口綁定來提供服務，并監聽發送至該端口的請求。因子

8：并發通過進程模型進行擴展，進程是一等公民。開發人員可以將不同的工作分配給不同的進程類型。例如，HTTP

請求交給前端

Web

進程來處理，而常駐的后臺工作則交由后臺任務處理進程負責。因子

9：易處理快速啟動和優雅終止可最大化健壯性，進程應是易處理的也即可以瞬間開啟或停止，從而有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健的部署應用。進程應當追求最小啟動時間，一旦接收終止信號就會優雅的終止，就網絡進程而言，優雅終止是指停止監聽服務的端口，即拒絕所有新的請求，并繼續執行當前已接收的請求，然后退出。對于任務處理進程來說，優雅終止是指將當前任務退回隊列。進程還應當在面對突然死亡時保持健壯。因子

10：開發與驗證環境等價通過保持開發、類生產和生產環境盡可能的相同來實現持續交付和部署。因子

11：日志不管理日志文件，將日志視為事件流，允許執行環境通過集中式服務收集、聚合、索引和分析事件。因子

12：管理進程日常管理類任務（如數據庫遷移），應該在與

app

長期運行的相同的環境中一次性完成。這些特性很適合快速部署應用程序，因為它們不需要對將要部署的環境做任何假定。對環境假設能夠允許底層云平臺使用簡單而一致的機制，輕松實現自動化，快速配置新環境，并部署應用，優化應用的部署速度。微服務（Microservices）微服務將單體業務系統分解為多個“僅做好一件事”可獨立部署的服務。這件事通常代表某項業務能力，或者最小可提供業務價值的“原子”服務單元。微服務架構通過以下幾種方式為速度、安全、可擴展性賦能：004005云原生

2.0

架構白皮書將業務領域分解為可獨立部署且有限能力的環境。同時，也將相關的變更周期解耦。通過擴展部署組織本身可以加快部署。由于學習業務領域和現有代碼的認知負擔減少，添加到每個沙箱的新開發人員可以更快速地提高并變得更高效。可以加快采用新技術的步伐，大型單體應用架構通常與對技術堆棧的長期保證有關。微服務提供獨立、高效的服務擴展。自服務敏捷基礎設施（Self-Service

Agile

Infrastructure）使用云原生應用架構的團隊通常負責其應用的部署和持續運營。云原生應用的成功采納者已經為團隊提供了自服務平臺。應用程序代碼簡單地以預構建的工件（可能是作為持續交付管道的一部分生成的）或

Git

遠程的原始源代碼的形式“推送”。然后，平臺構建應用程序工件，構建應用程序環境，部署應用程序，并啟動必要的進程。團隊不必考慮他們的代碼在哪里運行或如何到達那里，這些對用戶都是透明的，因為平臺會關注這些。除此之外，自服務敏捷基礎設施還具備如下能力：應用程序實例的自動化和按需擴展應用健康管理請求到或跨應用程序實例間的動態路由和負載均衡日志和指標的聚合基于

API

的協作（API-Based

Collaboration）在云原生應用架構中，服務之間的唯一互動模式是通過已發布和版本化的

API。這些

API

通常是具有

JSON

序列化的

HTTP

REST

風格，但也可以是其他協議和序列化格式。通過消費者驅動的協議，可以在服務間交互的雙方驗證協議的合規性。服務消費者不能訪問其依賴關系的私有實現細節，或者直接訪問其依賴關系的數據存儲。反脆弱性（Anti-fragility）提升系統的韌性能力，即便在遭受壓力時不會被破壞或變弱，例如通過“混沌猴”將隨機故障注入到生產組件中，目的是識別和消除架構中的缺陷。第一章

|

云原生概念與技術的歷史006DevOps，持續交付，康威定律系統即便在遭受壓力時不會被破壞或變弱，例如通過“混沌猴”將隨機故障注入到生產組件中。也是在

2015

年同年，CNCF

云原生計算基金會（Cloud

Native

Computing

Foundation，成員包括

Google、華為、IBM/Redhat、Intel

等

19

家）正式成立，標志著云原生從技術理念轉化為開源實現，并給出了目前被廣泛接受的定義：云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式

API。CNCF

致力于通過培養和維持一個開源、供應商中立的項目生態系統來推動云原生技術的廣泛采用，進而實現讓云原生無處不在的愿景。CNCF

對云原生的定義讓云原生的概念進一步具體化，從而讓云原生更容易被各行業理解，為云原生在全行業廣泛應用奠定了基礎。過去幾年中，云原生關鍵技術正在被廣泛采納，CNCF

調查報告顯示，超過

8

成的用戶已經或計劃使用微服務架構進行業務開發部署等，這使得用戶對云原生技術的認知和使用進入新階段，云原生技術生態也進入到快速更迭的階段。回顧云原生技術自誕生以來的發展歷程，站在企業應用軟件上云的視角，特別是上云過程本身對應用軟件本身遷移、重構、開發、部署乃至全生命周期管理的影響，及其對全棧云服務價值挖掘持續地由淺入深地地過程，不難將其歸納為如下

2個特征：云原生特征

1：容器化，微服務化以

AWS

之上的

NetFlix為代表，其傳統單體軟件架構被解耦拆分為微服務架構，每個微服務對應一個明確單一的業務功能單元，以及一個或多個運行態容器實例，所有微服務對外開放聲明式的

REST

或

gRPC

API，作為與其他微服務交互的“唯一契約”，微服務本身開發復雜度適合

10人左右小團隊承擔，所有微服務均有自己獨立的數據庫及持久化數層，而不與其他微服務有任何1.2

云原生1.0的技術特征007云原生

2.0

架構白皮書共享數據庫依賴，從而確保所有微服務可以完全運行態解耦，以獨立的版本節奏迭代演進，并支持不同的開發語言，且每個微服務可依據業務量需求，以容器為最小擴縮容單元進行秒級按需彈性伸縮（容器顆粒度一般遠小于

VM，且更輕量化，易于秒級啟停），每個容器的發布包，除應用鏡像外，也包含其業務應用運行時所需的依賴庫、環境變量等。此外，還將分布式微服務的管理與治理能力下沉到開源語言特定的微服務框架，例如

SpringCloud、ServiceComb、CSE

等，以及非侵入式通過邊車（Sidecar）與業務邏輯綁定注入微服務治理能力，也即通過應用無感知的

Istio服務網格

(ServiceMesh)

機制為拆分后的微服務提供注入服務發現、灰度升級、熔斷流控、流量治理等微服務公共基礎框架。云原生特征

2：基于云化應用中間件、數據庫，乃至可重用服務重構及開發企業應用或服務在解決了租戶面業務邏輯容器化的挑戰之后，對其所依賴的中間件，數據庫從應用空間到云服務商空間進行“下沉”。以

Salesforce

為代表，將企業應用中的共性業務邏輯下沉到應用平臺，在相同應用邏輯上實現跨租戶共享，并借助模型驅動架構

(MDA：Model-Driven

Architecture)

進行跨租戶應用邏輯的抽象，同時在平臺層進一步實現跨租戶的數據庫共享，也即基于統一的數據庫模板進行不同租戶對應數據表的裁剪、重映射等操作；總之，通過在應用和數據服務層提供跨租戶共享能力（也即邏輯多租），實現面向最終云租戶屏蔽資源層多租隔離的復雜性。另一種上云模式是與底層資源耦合、應用無需感知彈性資源伸縮控制的

PaaS

平臺，也即hcaPaaS（high-control

application

PaaS），AWS

BeansTalk、Google

的

GAE

等即屬于

hcaPaaS；或與底層資源解耦、面向開發者展開高效企業應用開發的

PaaS

平臺，也即

hpaPaaS（high-productivityapplication

PaaS），從而面向云租戶實現對應用屏蔽下層資源的操作，依賴應用平臺實現應用和

DB

級的伸縮操作。Salesforce

的

2

大平臺

Heroku

和

F

分別對應

hcaPaaS

及

hpaPaaS。hpaPaaS

的另一個內涵對應到

Low/No

Code，將應用的生產環境部署延展到開發環節，基于應用邏輯的理解，引入模板

/DSL

進行敏捷開發，對行業數字化起到了巨大的推動作用。第一章

|

云原生概念與技術的歷史008所謂云原生（Cloud

Native），是指構建、運行、管理基于云環境、利用云環境、適應云環境、受益云環境的軟件而發展起來的一系列的軟件系統實踐范式。包括充分利用云基礎設施與平臺服務，具備微服務架構、彈性伸縮、分布式、高可用、多租戶、自動化運維等關鍵特征的架構實踐；建立與系統架構匹配的全功能團隊、發展全棧工程師并高度協作的組織實踐；采用

DevOps、自動化工具，實現微服務持續交付的工程實踐。通過架構、組織、工程面向云環境的協同實踐，實現Cloud

Native

系統對外體現快速、可靠、規模、靈活、高效的價值收益。云原生

1.0階段的代表性技術架構模式包括：服務化架構模式服務化架構是現代云原生應用普遍適用的標準架構模式，與傳統軟件工程所強調的“高內聚、低耦合”架構模式在實現軟件功能的“分而治之”，以及公共軟件功能的“最大化重用”的目標方面是一致的，二者也均提倡通過

DDD（領域模型驅動）方法論指導將軟件面臨的業務應用問題分解為復雜度、交付質量、交付時間可控且更小顆粒度的應用單元，但在實現這些應用單元之間的隔離及復用手段方面，服務化架構與傳統軟件架構存在本質不同：傳統軟件架構更強調開發態靜態代碼的隔離與復用，而服務化架構則更強調進程級別的運行態隔離，并以接口契約（IDL，Swagger，RAML

等）定義每個服務應用單元可以為外部提供功能支撐，以標準協議（HTTP/HTTPS、gRPC

等）作為接口契約

API

的最終傳輸協議承載。各服務

/

微服務進程之間只能嚴格通過服務

API

為界面進行業務流程與邏輯地交互與協同，不允許直接訪問其他服務

/

微服務內部的數據信息。服務化架構采用運行態進程級軟件（服務

/

微服務）代替靜態開發態軟件模塊作為軟件隔離與共享基本單元的關鍵優勢：輕量級服務

/

微服務的開發、測試、部署、發布等全流程活動由獨立全功能團隊負責，不再需要多個有緊耦合關聯的開發測試功能團隊協作才能完成，因此有效地提高了軟件研發迭代效率；業務邏輯按照服務/

微服務解耦，使得服務/

微服務級別的故障，不會擴展至整個軟件系統；不同服務

/

微服務的代碼模塊所對應的部署實例數可依據實際業務情況各不相同，并且可以服務為單位進行更小顆粒度的水平伸縮，從而使得系統部署成本更優；1.3

云原生1.0的技術特征009云原生

2.0

架構白皮書每個服務

/

微服務可以根據具體的場景，獨立演進最優的技術堆棧，利于實踐新技術，享受額外的技術紅利；單個服務

/微服務職責單一、輕量化，利于實施持續交付，快速演進業務。當然，凡事必有其兩面性，服務化架構所帶來的也不僅僅是優勢，同樣也必然存在其約束和挑戰：數據隨同服務一起分布化后，需要妥善處理數據一致性問題，跨服務進程的遠程調用引發的性能問題導致系統部署運維復雜，涉及眾多服務實例，需要完善的工具做支撐；服務之間基于接口契約化，隱式的運行態依賴，導致依賴管理復雜度提升。服務進行不兼容升級時，需妥善處對上游服務的影響；系統劃分為多個服務，業務特性需要多個服務協作完成，增加了測試難度。因此，服務化架構下的軟件進程拆分顆粒度也不是一味追求越小越好。一方面要考慮與業務應用邊界的對齊，另一方面也要充分做好與服務化架構配套的工具自動化、治理流程方面地準備。對于軟件進程間交互對性能（時延、吞吐）高度敏感的場景，比如底層數據報文轉發、基于內存共享區的數據映射與交換等，不排除傳統的軟件進程解耦相比服務化/

微服務化拆分是更好的選擇。圖

1-1

傳統單體架構與微服務化架構對比Web

UIWeb

UI移動App移動AppREST

接口API

Gateway服務A接口開放業務邏輯數據訪問層數據庫接口開放業務邏輯數據訪問層數據庫接口開放業務邏輯數據訪問層數據庫服務C服務B模塊CREST

接口模塊A模塊B數據訪問層模塊A數據表 模塊B數據表 公共數據表 模塊C數據表數據庫傳統單體架構服務化/微服務化架構第一章

|

云原生概念與技術的歷史圖

1-2服務網格化架構實施服務網格化架構后，業務應用代碼自身只需聚焦做好業務應用邏輯的處理，而與具體業務應用邏輯無關、可公共共享的服務

/

微服務治理方面的處理均可交由服務網格機制來統一處理：包括服務能力發現、服務間交互韌性保護、服務彈性伸縮、零信任安全保護、按流量進行服務/微服務版本灰度上線與環境隔離、基于流量做自動化的冒煙

/

回歸測試等。可觀測的服務

/微服務架構在服務化/

微服務化架構模式下，由于傳統單體應用被拆分為更多顆粒度更小的微服務

/

組件，導致需獨立部署及升級變更的微服務

/

組件進程數有了數倍甚至數十倍增加，因此也必然對應用架構的“透明可觀測”能力提出了更高的要求。為數量眾多的微服務

/

組件進程之間點到點網狀010服務網格化架構模式服務網格化架構，可以認為是服務化架構的進一步“延伸與發展”，其本質是將服務化架構下跨服務

/

微服務之間與具體服務應用的業務邏輯無關的公共交互處理與消息流量治理功能，與每個服務

/

微服務特有的業務邏輯解耦，從而使得這些提供服務端點注冊發現、服務間消息交互鑒權認證與加解密保護、服務間的消息流控、熔斷、降級、重試、反壓、隔倉等分布式架構模式及其用到的中間件框架（比如緩存、異步消息、遠程過程調用等）從業務進程中徹底分離解耦，統一納入到服務化網格（Service

Mesh）的框架內，而業務進程中僅需要保留與服務化網格之間很薄的一層適配通信客戶端，甚至完全無需感知服務化網格能力的存在，其架構示意如下：業務進程業務進程業務應用代碼業務應用代碼業務應用代碼服務發現SDK流量治理SDK安全管控SDK消息跟蹤SDK服務網格進程（服務發現、流量治理、安全管控、消息跟蹤......）業務應用代碼服務發現SDK流量治理SDK安全管控SDK消息跟蹤SDK011云原生

2.0

架構白皮書解耦消息交互端到端跟蹤，從而確保系統運行一旦出現問題時，即可快速定位并尋找到問題產生源頭所對應的微服務和組件。服務/

微服務的可觀測性主要通過日志、跟蹤、統計指標3

類渠道獲得，其中日志提供多個級別（詳細

/

調試

/

警告

/

錯誤

/

致命）的詳細信息跟蹤，可由應用開發者主動提供日志信息的收集與上報；跟蹤則提供一個請求從前端接收到

API

請求到后端業務處理完成的端到端全調用鏈路跟蹤，對于分布式場景尤其有用；統計指標則提供對系統量化的多維度度量。服務

/微服務架構即可為自己選擇合適的、支持可觀測能力的開源框架（比如

OpenTracing、OpenTelemetry），或選擇自研的與服務

/微服務運維監控能力配套的監控運維系統（含被觀測對象側的運維代理，以及負責后端日志、跟蹤與統計指標處理的運維服務端），并規范化定義各服務/

微服務上報的日志、跟蹤及統計指標等觀測數據的具體類型與參數（比如用戶信息、地理位置、請求參數等），明確這些可觀測數據的產生端與消費端。利用日志和跟蹤信息中的“跟蹤實例

/ID信息”，可使得后臺分布式鏈路分析時將來自不同服務/

微服務實例的跟蹤消息做快速關聯分析，以實現快速排障與問題調試。除故障管理及業務連續性保障之外，構建服務

/

微服務可觀測能力也有助于衡量各個服務

/微服務組件是否達到了其面向服務租戶所承諾的

SLA/SLO(Service

LevelAgreement/Objective)，比如并發業務請求數、業務請求平均處理時長、持續提供不中斷服務的市場、系統的總體容量、剩余可用容量等。分布式事務模式服務

/

微服務架構模式下每個服務擁有自己獨立的數據源，不允許像單體應用那樣直接跨服務共享數據源，因此導致高復雜度、大顆粒度的業務往往需要跨多個分布式服務

/

微服務的數據訪問，由此也引發了分布式事務一致性問題，從而確保跨不同服務

/

微服務有關聯域的數據保持一致（多個微服務的關聯數據庫

/

數據表，要么同時更新成功，或要同時失敗）。架構師需要根據不同的場景選擇合適的分布式事務模式。1)

兩階段提交模式服務/

微服務應用中間件與數據庫通過

XA

接口規范，使用兩階段提交來完成一個全局事務，XA

規范的基礎是兩階段提交協議：一階段：表決階段，所有參與者都將本事務能否成功的信息反饋發給協調者；二階段：執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾采用強一致性機制。該模式的缺點是能低下，可能因為

XA

協議自身原因，造成事務資源長時間得不到釋放，鎖定周期長，而且在應用層上面無法干預，數據并發沖突高的場景性能很差。第一章

|

云原生概念與技術的歷史圖

1-4

TCC

模式事務開始時，業務應用會向事務協調器注冊啟動事務。之后業務應用會調用所有服務的

try接口，完成一階段準備。之后事務協調器會根據

try

接口返回情況，決定調用

con?rm

接口或者cancel

接口。如果接口調用失敗，會進行重試。TCC

方案讓應用可自定義數據庫操作的粒度，使得降低鎖沖突、提高吞吐量成為可能，不足之處體現在兩方面：一是業務侵入性強：業務邏輯的每個分支都需要實現

try、con?rm、cancel

三個操作；二是應用侵入性較強，改造成本高，實現難度較大。012第一階段事務協調器事務協調器預備就緒本地資源管理器本地資源管理器本地資源管理器本地資源管理器預備就緒提交成功提交成功第二階段2

調用Try接口1

啟動事務3

提交或回滾事務圖

1-3兩階段提交模式2)

TCC

模式：本質是兩階段提交的一種改進，將整個業務邏輯的每個分支顯式分為

Try、Con?rm、Cancel三個操作。Try

部分完成業務的準備工作，con?rm

部分完成業務的提交，cancel

部分完成事務的回滾，如下圖所示：服務A業務應用事務協調性Try接口Confirm接口Cancel接口服務ATry接口數據庫數據庫Confirm接口Cancel接口4)

非入侵的高性能事務方案（DTM

分布式事務中間件）其基本思路將分布式事務也即一個全局事務，劃分為若干個分支事務，每個分支事務均是一個滿足

ACID

的本地事務。為實現對本地事務的非入侵修改，引入資源管理器來攔截業務

SQL，對其解析并做額外的一些數據處理，產生

undo

log

并保存，一旦發生全局事務回滾，則通過各個分支事務對應的

undo

log

完成所有分支事務回滾。為防止兩個全局事務并行修改數據導致回滾數據錯誤，引入分布式鎖服務器對事務所修改數據加鎖，全局事務提交后立即放鎖，全局事務回滾則等待分支事務回滾完成放鎖。5.

事件驅動架構（EDA）隨著萬物互聯時代的到來，用于高效關聯集成事件監測與產生者，與對應的事件處理者的事件驅動架構EDA

正在迅速興起，用于促進事件的生產、檢測、處理和響應。事件可以是多種多樣的，比如某人拿起一件物品，某對象的測量指標達到一個閾值，或者一個特定的客戶到達零售店。EDA

由三個屬性定義。首先，它有選擇地將相關事件從傳入數據傳輸到數據庫。其次，它處理來自多個源的復雜事件，這些事件可以實時地相互影響。第三，它通過推式操作簡化了實時服務。事件驅動架構的用例示例包括滴滴、Uber

等資產共享解決方案、分配維護人員和備件的規定維護系統或動態客戶服務應用程序。013云原生

2.0

架構白皮書因此，TCC

方案雖多被研發實力強、有迫切需求的電商、金融公司采用，但由于事務處理邏輯多數需要在應用層完成，因此與微服務所倡導的服務輕量化思路不完全吻合。3)

基于消息的最終一致性方案通過消息中間件保證上下游應用數據操作的一致性。基本思路是將本地操作和發送消息放在一個本地事務中，保證本地操作和消息發送要么兩者都成功或者都失敗。下游應用向消息系統訂閱該消息，收到消息后執行相應操作。最終一致方案本質上是將分布式事務轉換為兩個本地事務，然后依靠下游業務的重試機制達到最終一致性，因此其對應用侵入性也很高，應用需要進行大量業務改造，成本也非常高。圖

1-5

基于消息的最終一致性方案訂單數據庫庫存數據庫消息隊列...

業務應用訂單服務庫存服務第一章

|

云原生概念與技術的歷史其中的“事件”常常是固定的，而“邏輯關系”往往體現的是業務規則或者核心邏輯，也常常是固定不變的。只有“響應”是可變的，或者說是可以配置或者需要改變的。響應事件而不是主動查詢目標系統將會帶來自主性，更好的容錯能力和彈性，但也有一點其他影響，會影響自治事件驅動系統的是“延遲”。EDA

+

CQRS（Command

and

Query

Responsibility

Split）模式強調命令和查詢的分離，也即各自獨立的類封裝：其中查詢負責請求獲取系統的狀態，而命令則負責請求系統修改其狀態。將EDA

與

CQRS

模式相結合，是系統設計的一個自然增量，因為命令本身就是事件的生成器。結合014●●●事件

(event)響應

(handler)事件與響應的“邏輯關系”圖

1-6事件驅動架構EDA

是一種非常流行的分布式異步架構模式，經常被用與構建高可伸縮性的應用程序。當然它也適合小型應用，復雜應用和規模比較大的應用。這種架構模式由一系列高度解耦的、異步接收和處理事件的單一職責的組件所組成。事件驅動架構由兩個主要的拓撲組成：分別是調停者拓撲和代理者拓撲。調停者拓撲通過一個中央的調停者來編排各種處理步驟。然而代理者拓撲適用于那些想將事件鏈式的聚在一起但不使用中央調停者的情況。事件流通過客戶端發送到消息隊列，事件隊列則傳遞消息到調停者。調停者接收到隊列傳遞過來的原始消息，然后編排成異步的消息發送到事件通道，事件通道則通過事件處理器執行處理過程的每一步。事件處理器則監聽事件通道，根據自身不同的業務邏輯來處理從調停者接受的事件。EDA

架構的

3要素為：The

Complementary

Use

of

Event

Stream

Analytics

and

Event

Brokers

in

Event-Driven

ComputingEvent

HandlersEvent

SourcesEvent

BrokerComplexEventStreamStream

Analytics（CEP）Transactional

Event

Stream盡管云原生技術自誕生以來經歷了蓬勃迅猛的發展，不斷臻于完善，然而隨著千行百業云化不斷走向縱深，人們也發現云原生技術正在面臨越來越多的不足與局限性亟待解決和突破，而對這些問題及其解決途徑的思考與探索，引發了云原生新代際的出現。挑戰

1：如何解決云資源池的大集中化，與實時應用上云要求低時延，及海量線下數據上云不滿足數據隱私合規，或者帶寬接入成本過高之間的矛盾？解決之道：分布式云眾所周知，云計算相比傳統計算模式最大的優勢：“彈性伸縮

&

敏捷按需”，來源于云數據中心中的超大規模計算與存儲資源池，通過資源動態共享，一方面使得云租戶視角永遠感知到“取之不盡，用之不竭”的“彈性按需資源”，另一方面則通過不同租戶及租戶內不同虛擬化、容器負載之間的集約動態復用，獲得相比傳統獨占硬件平臺方式更高的有效資源利用率。然而云資源池的大集中化，必然面臨著該集中資源池距離多數最終云租戶

/

用戶接入距離較遠，甚至超過上云應用和業務可接受接入時延的上限（比如超過

50ms

時延），而對于一些特定行業用戶側產生的海量數據（如公安領域的視頻監控數據、醫療領域基因數據、工業互聯網制造領域的數字孿生建模數據等），要么由于國家區域或者行業的數據安全隱私保護規范的要求，希望相關核心數據資產永遠保留在自己得數據中心內，不得泄露到任何第三方（包括云服務商）；或者雖然對線下數據上云沒有隱私保護要求，但由于數據體量過大（單個企業租戶每天數十甚至上百

TB

得數據上傳量），使得數據上傳的成本可能反而超過從云端獲得彈性算力及算法服務可獲得的收益。與大集中的云資源池相對應，當前云原生微服務治理框架，也僅考慮了大規模云資源池站點內的服015云原生

2.0

架構白皮書使用

CQRS

和命令，為從傳統控制流架構向EDA

架構的過渡時的遷移數據提供了一個銜接的橋梁，在遷移結束后，可以移除該銜接橋梁。EDA

+

事件溯源（ES）模式：事件溯源表示能追查一個事件的源頭，甚至與之相關的其他事件的概念，通過將

ES

與

EDA

配合使用，ES

負責保存

EDA

產生的事件信息，使得我們對系統中的實體究竟是如何一步一步變成現在這個樣子能有一個清晰的了解，并且也為必要的Redo

撤銷重做機制提供了支撐。1.4 云原生1.0面臨的挑戰

&

云原生2.0第一章

|

云原生概念與技術的歷史務注冊、自動發現、流量治理、灰度升級等功能。隨著云、5G、物聯網、AI

技術的不斷成熟，云化、數字化從互聯網及企業后端

IT

支撐系統迅速延伸進入到智慧城市、智慧政務的物聯網終端系統，智慧制造的前端實時生產線，促使上述實時應用及海量數據上云難與云資源池大規模集約化之間的矛盾變得更為緊迫和突出，云原生迫切需要回答在云基礎設施及云原生框架兩個層面，如何從“大集中云”走向“大集中云”與“分布式云”共存，從而實現靈活敏捷、可編程的云邊端協同。挑戰

2：如何解決云原生應用對跨物理機、虛擬機，跨云服務商，以及跨云端和邊緣的云基礎設施無關性需求，與性能敏感的關鍵重載應用對云原生基礎設施的極致性能需求之間的矛盾？解決之道：應用驅動基礎設施云原生強調應用與基礎設施平臺各自水平分層解耦，特別是面向云租戶和開發的應用發布、部署以及全生命周期管理的“物理基礎設施無關性”，也即相同的容器發布方式，無論部署在物理服務器、KVM

虛擬化、乃至

VMware

虛擬化之上，均可保持其容器包發布與管理方式的一致性；然而隨著云原生改造所覆蓋的應用類型越來越廣泛，對于性能敏感的應用，比如

AI

訓練與推理、網絡吞吐敏感的視頻及大數據分析類業務、網絡與存儲時延敏感的數據庫業務等，傳統基于通用CPU

及

OS

內核態實現的虛擬化隔離及存儲、網絡協議棧功能，已越來越難以滿足應用對底層基礎設施的性能訴求，從而促使業界去思考如何在保持云服務管理面及數據面界面不變的前提下，通過軟硬件深度垂直整合以及必要的軟件重構，帶來極致性價比的可能性。挑戰

3：如何解決越來多樣化的云原生應用需獨占容器集群甚至資源池，且在CPU、內存、存儲

IO、網絡

IO

等各資源維度利用率不均衡所導致主機計算資源浪費的問題？解決之道：混合部署，統一調度當前多數云服務商的虛擬機層與

Kubernetes

應用容器層的資源調度是相對獨立的兩層（往往將容器資源的調度疊加在虛擬機資源調度層之上），甚至缺省針對不同的租戶應用，需為其申請相對獨立的容器集群，從而導致無論底層不感知租戶應用類型的彈性虛擬機層，還是上層具備一定應用感知能力的容器層，其資源調度邏輯完全各自獨立，彼此互不相通，形成了過多的“云原生資源碎片與孤島”。為整合這些“資源碎片與孤島”，急需我們在云基礎設施資源調度層水平統一打通應用感知的K8S

容器集群，以及更底層物理機、虛擬機資集群調度，基于統一的資源視圖，實現多種類型云原生應用（CPU、內存、存儲

IO，網絡

IO

密集型，或其任意組合）在統一資源016017云原生

2.0

架構白皮書池上的混合部署與統一并發調度，并進一步引入閉環的性能與

QoS

實時監控機制，從而驅動統一多維調度引擎在保障云原生應用性能的前提下，獲得更高的動態超分比資源利用率。挑戰

4：如何簡化運維復雜度、降低運維負擔的問題？解決之道：無服務器化（serverless）容器及微服務之后，云原生技術前沿已邁入

Serverless

無服務器時代。AWS

發布

FaaS（Function-as-a-Service）產品

Lambda

后，業界首次提出了

Serverless。Serverless是將應用程序（或其一部分）在遠程托管的執行環境中按需運行的架構，其不需要用戶維護自己的資源管理，甚至不需要構建與特定

OS

兼容的應用程序。FaaS

實質上是

Serverless架構中以計算為中心的部分，可以構成其中的一部分，但不代表整個系統。Serverless

上的應用只需為實際運行代碼的時間付費。FaaS

早期以無狀態業務邏輯運行，對有狀態應用無法支持，因此出現了

Serverless

2.0

=

FaaS+BaaS（Back-end

as

a

Service），需要將應用和數據服務均

Serverless

化，并充當計算邏輯的

Serverless特征后端服務。當前

Serverless

在推廣中遇到一些問題，包括有限的編程語言支持、供應商鎖定、SLA

難以保證（尤其是冷啟動）、只涉及應用的部分而無法

cover

整個應用，因此長期會同傳統應用模式共存。對編程語言受限問題，考慮采用統一的后端語言級

VM

來支持；供應商鎖定可通過跨廠商的標準和模型互通來支持（參考

AWS

SAM）；SLA

則可通過簡單的熱點代碼

Warm、以及

Serverless

平臺與資源層垂直優化來部分解決。挑戰

5：如何解決企業應用上云之后海量的結構化、半架構化及非結構化數據存儲格式各異，同一份數據多次重復拷貝，數據存儲與數據計算彈性需求不一致所導致的資源浪費，可靠性保障水平參差不齊的問題？解決之道：存算分離，分層池化在云原生初期階段，數據庫、大數據普遍采用存算一體的部署方案，數據處理進程與數據存儲是耦合部署的，例如開源數據庫

MySQL

采用虛擬機加云盤的部署方式，數據庫進程只能訪問本地掛載云盤的數據，增加只讀副本需要拷貝一份完整的數據，各節點之間無法共享數據和計算能力；同樣，大數據開源軟件

Hadoop

／

Spark

系列采用了

NDP（近數據處理）架構，大數據分析處理進程與

Hadoop

數據分片是緊耦合的關系，導致了大數據集群無法與云主機及云容器集群共享計算資源池，計算與存儲緊耦合的大數據集群始終無法與面向普通應用的云租戶計算和存儲集群實現物理共享；此外，對于企業應用上云之后所產生的海量結構化

MySQL、PQ-SQL，半結構化

NoSQL

Cassandra

／

MongoDB，以及搜索引擎

Elastic

Search，圖數據庫

Noe4j，乃至非結構化第一章

|

云原生概念與技術的歷史數據對象存儲

OBS，分布式文件系統等，為解決其數據水平橫向擴展的問題，均各自采用了特定于其數據組織結構及查詢變更邏輯的數據冗余分片、分布式一致性處理，分布式

RAID/EC

數據編碼，乃至持久化數據容災與恢復處理等邏輯，導致各類對海量容量及水平擴展能力，以及分布式可靠性容器保護能力的類型各異的持久化數據層采用了

N

套不同的技術機制來實現，增加技術棧復雜度與維護成本的同時，導致數據處理邏輯與底層數據持久化邏輯緊耦合，難以勝任高并發高彈性高可用的在線事務處理需求（例如電商大促期間對計算資源的需求遠大于對存儲容量的需求，社交平臺的歷史數據訪問頻率極低其容量需求遠大于計算資源需求）和相關海量數據分析對計算和存儲資源集群的非均衡彈性訴求（比如基于原始順聯大數據素材的機器學習或深度學習分析，其計算資源消耗量遠大于存儲；而對于分析調用頻度不高的日志匯總分析，則存儲資源消耗遠大于計算）；基于上述問題挑戰，業界開始積極嘗試所謂“云原生數據”架構，也即以“存算分離”架構模式為特征，重構所有的大數據、數據庫、NoSQL

乃至搜索引擎、圖數據庫等，以統一的分布式高可用存儲引擎支撐所有上述數據形態的數據分片、無限制水平按需擴展、秒級快照及恢復、數十倍的存儲節點故障或擴容的并發數據重分布效率，乃至無鎖化的并發

IO

讀寫等，使得所有云原生數據集群服務（含結構、半結構、非結構化）無論在水平擴展性、性能、容災可靠性，以及業務不中斷數據平滑擴容的能力均獲得了高度一致的大幅提升。在計算層與存儲層分離后，計算層也在進行進一步的解耦——即

CPU

資源和內存資源解耦。以分布式內存池的方式，提供像分布式存儲一樣的全局內存，使得CPU

資源和內存資源也可以單獨的進行彈性擴展，對于數據庫、大數據等有狀態的云服務，可以將全局狀態卸載到全局內存池上，可以更方便的實現計算節點之間的狀態轉移。云原生的“彈性按需擴展”架構能力主要聚焦于基于容器的無狀態應用業務邏輯，然而對于有狀態的應用事務、數據庫、大數據、消息與緩存中間件，互聯網應用雖有分表分庫等應用層與數據庫層配合的設計模式來實現有狀態應用的超大規模水平擴展，但隨著云原生存算分離數據庫、大數據，以及分布式事務技術的持續演進發展，使得企業應用系統的開發無需再關注任何與數據規模及其水平擴展能力問題，因為該層能力將完全卸載到持久化數據層。挑戰

6：如何解決企業數據治理平臺構建依然人工介入、效率低下的問題？解決之道：數據治理自動化企業將其應用事務處理及運營分析相關的數據通過數據庫、NoSQL，以及大數據平臺匯聚到云上海量數據湖后，還需要經過一系列人工介入過程對各類數據資產進行標簽分配，并對存在質量問題的數據進行識別并觸發相應的清洗過濾，由此可見企業數據治理平臺的構建在當前嚴重依賴于大量人力的投入，為解決這一條件，最好的途徑仍然是用

AI

替代人力進行數據質量規則稽核、018云原生

2.0

架構白皮書查重、修復和數據豐富，自動生成數據資產之間的關聯、發現與標簽分類，以及自動識別個人隱私數據和數據安全保護等。從而將企業數據治理的效率及數據資產準確性與質量水平提升到一個新的臺階，滿足企業業務的數據消費需求。挑戰

7：如何解決云原生新開發應用，與各行業已有的非云原生應用，特別是非互聯網領域的政企傳統行業

IT

應用的無縫互通及平滑演進的問題？解決之道：平滑演進，兼收并蓄千行百業的

IT

系統完成云原生的演進改造，顯然不是一蹴而就的過程，必將在相當長一段時間內，處于云原生應用與非云原生應用兼容并存的狀態，因此必須有機制確保云上與云下，云原生應用及其數據，非云原生應用及其數據，可以像原來在相同數據中心，相同軟件架構下一樣無障礙地彼此互聯互通及互相集成。挑戰

8：如何將誕生于互聯網的

DevOps

敏捷開發流水線能力，推廣引進到對產品研發質量及安全可信有更為嚴格要求的政府及傳統行業，以及讓行業的軟件開發效率不斷獲得提升？解決之道：可信、平民化

DevOps云原生

DevOps

敏捷開發流水線，源自于互聯網在線業務的快速迭代開發，強調通過可定制的從需求管理、開發、編譯鏈接、測試驗證、上線發布、生產環境運維監控等所有軟件生命周期階段流程及流程活動自動化帶來開發節奏的大幅加快，及客戶需求響應敏捷度的大幅提升，然而其缺點和不足是在流水線上的安全及質量管控和加固的機制缺失，無法滿足很多傳統行業（如汽車制造、金融等）對其軟件開發質量與安全合規的嚴格訴求，因此如何構建可信的

DevSecOps，成為大企業應用與軟件生產現代化最關注的課題之一。另外，除

Full

Code

的傳統軟件開發模式之外，各個行業也逐步積累沉淀了一些高于

PaaS

層、且行業特有的前端界面模板，及后端可重用業務邏輯/

應用及數據資產，這些資產能力通過高效的建模及編排，使得僅基于上述模板資產能力的編排及少量定制（低代碼

/

零代碼）即可實現行業應用的開發，從而使得行業應用效率得到大幅提升。挑戰

9：如何讓方興未艾的人工智能技術助力全棧云服務更好地服務于云租戶及云生態開發者，以及有效降低各行業開發者使用人工智能技術的門檻，更快捷地開發人工智能應用，并為行業生產力提升帶來核心價值？解決之道：全棧

AI

加持，全行業

AI

普惠019第一章

|

云原生概念與技術的歷史云原生全棧能力的不斷成熟，打破了人工智能

(

特別是深度學習

)

與云計算、大數據之間的技術與商業壁壘，使其融合成為有機整體：大數據、人工智能均轉變可按需消費的云服務，云計算為大數據分析和人工智能訓練與推理提供“統一算力”，大數據、數據庫則為人工智能提供“統一算據”，使得大數據、人工智能不再是成本高昂的“奢侈品”，加之人工智能技術近年來在計算機視覺識別、語音識別、自然語言

NLP、圖文

OCR、線性規劃最優次優求解、知識圖譜等領域的日益成熟及廣泛工程應用，使得

AI

技術無論面向全棧云自身的運維與優化效率提升，還是直接服務于各行業場景的運營優化與生產力提升，均蘊藏著巨大的潛能與無限的可能性。挑戰

10：如何讓云安全不僅作為對外產品直接為租戶和開發者提供立體式的數據、應用、網絡及認證鑒權等安全服務保障，更能對內與全棧各云服務能力緊密協同，實現租戶端到端應用架構的安全可信？解決之道：全方位立體式的云安全防護云原生對云安全能力的考慮，主要聚焦在容器化平臺及微服務治理框架范圍內，服務訪問合證鑒權，以及服務間互通的合法性、私密性保護相關的證書及安全憑證管理，缺少從網絡邊界、應用、數據、行業國家隱私、安全合規等全方位的云安全能力體系化設計，以及云服務及云上應用如何高效調用或適用這些云安全框架能力的設計模式與最佳實踐指導。企業仍主要依賴相對獨立和割裂的傳統商業化IT

安全軟件及“基于防火墻硬盒子”來承擔企業IT

免遭安全攻擊的屏障與保護層角色，但該安全防護模式顯然也越來越難以匹配與企業業務快速增長同步的潛在安全攻擊源和攻擊方式的隱蔽多樣化，以及多變性等特征，從而促使云安全也走向安全多租化、軟件化，以及智能化的趨勢。總之，為突破上述千行百業

IT

云化發展歷程中面臨的一系列困難和挑戰，云原生正在迎來一場更為深刻全面、全棧、全場景的云化架構變革，這就是云原生

2.0。云原生

2.0

時代序幕拉開的第一個重要標志，是

CNCF

云原生社區技術與開源版圖的蓬勃演進發展，從最初的容器、微服務、DevOps

等技術領域，迅速擴展到如今的底層云原生基礎設施技術、編排及管理技術、云安全技術、監測分析技術、大數據技術、人工智能技術、數據庫技術以及場景化應用等眾多分支，初步形成了支撐應用云原生化構建的全生命周期技術鏈。同時細分領域的技術也趨于多元化發展，CNCF

的云原生開源版圖，由開始單一的容器編排項目

Kubernetes，發展到如今

5

大類

100

多個項目，Kubernetes

已成為云原生的操作系統，在其上發展出面向各行業、不同功能、不同應用場景的開源項目，Spark、Flink、Kafka、Redis

等開源項目也陸續加入

CNCF

的云原生技術圖譜，進一步完善了云原生技術生態，也引領云原生再次迎來了前所未有的發展浪潮，極大加速了云原生在全球范圍內的快速應用和發展。020021云原生

2.0

架構白皮書圖1-7CNCFCloudNativeInteractive

Landscape來源：cf.io/而云原生

2.0

架構的商業價值與最終愿景，是面向千行百業（無論是孕育云原生的互聯網企業，還是呼喚云原生重構改造實現數字化賦能的非互聯網的政企客戶）的業務與應用開發與運維團隊，提供涵蓋云原生基礎設施、數據使能、應用使能、AI

使能、視頻使能、企業應用數據集成、萬物互聯、企業辦公協同等在內的全棧數字化平臺能力，從而將全棧云優勢最大限度地發揮出來，將企業

IT信息開發人員從云基礎設施、各類應用、數據、AI

等平臺中間件與使能組件的重復開發與日常運維管理等方面的繁重負擔中解放出來，并幫助企業從基礎平臺使能層構筑彈性敏捷自動化、水平彈性按需擴展、安全可信、韌性高可用高可靠等非功能的關鍵企業架構屬性能力，使得企業最終可將有限的精力和資金投入到核心業務競爭力上，從而實現數字化、智能化轉型中的投入產出效率最大化。第二章

|

云原生

2.0

的技術及架構特征022第二章云原生2.0的技術及架構特征023云原生

2.0

架構白皮書前文提到，伴隨著以企業應用及數據云化為手段的千行百業數字化、智能化轉型不斷走向縱深，為確保各產業及行業領域的客戶能更充分、全面地受益于云轉型所帶來的技術紅利，進而帶動相應產業及行業自身的升級換代及生產力變革，云原生技術迫切呼喚跨代際的突破和演進，云原生2.0由此應運而生，以下就針對前文提到的云原生

2.0

關鍵特征，對云原生

2.0

的價值驅動及架構原則逐一進行解讀和闡述。2.1.1

趨勢與需求分布式云是將云服務分布到不同物理位置，運營、治理和演進可由統一組織負責提供。當前業界的分布式云解決方案主要由公有云服務商提供，或由云服務供應商統一建設、交付、托管。使用分布式云，使組織能夠讓這些服務的物理位置更靠近本地，有助于支持低延遲場景、降低數據成本，并有助于遵守規定數據必須留在某個特定地區中的法律法規要求。隨著近年來企業數字化轉型不斷深入，企業云基礎設施的規模與復雜度快速提升，帶來的結果是自身

IT

團隊的大部分精力都投入到了基礎設施的管理與運維中。因此，分布式云通過管理平臺的集中部署和運維托管，可以使得組織不用管理自己的云基礎設施，從而專注于自己的業務本身。從地域覆蓋的角度看，分布式云應該充分覆蓋核心區域、熱點區域、客戶機房、業務現場四個不同的區域，在不同的層次為用戶提供最適合的服務。從基礎設施的角度看，承載分布式云上層業務的基礎設施可以由單一廠商提供，實現單一云內的分布式架構；基礎設施也可以由不同廠家提供，并由上層云原生管理平臺在云原生服務層面形成統一的平臺，從而形成跨云的云際計算。但不管是哪種形式，其上層的云原生平臺都應該具備統一化、全局化的特點，形成統一的分布式云服務化平臺。Gartner

預測到

2025年超過

50%的組織將在其選擇的地點使用分布式云。隨著移動終端及物聯網的技術發展和普及應用，以及企業業務的跨區域部署，從互聯網到政企客戶都產生了對分布式云的強烈需求。基于互聯網互動視頻的創新業務，AR/VR/

云游戲等，正在催生本地渲染的云基礎設施發展；另外低時延（OT

應用）、數據本地駐留（合規），本地數據處理（視頻監控）等政企應用，在催生本地計算的云基礎設施發展。基礎設施部署將從集中式向分布式演進，實現云的最后一公里覆蓋。2.1

關鍵特征一：分布式云第二章

|

云原生

2.0

的技術及架構特征024總結來說，分布式云發展的核心驅動力有如下幾點：●低時延：為滿足低時延要求，需要在離業務現場最近的位置構建解決方案，減少業務處理時延，業務本地閉環。海量數據分析

(

帶寬優化

)：5G/IoT

時代邊緣數據爆炸性增長，難以直接回傳至云端且成本高昂，數據在本地進行分析和過濾，僅回傳結果，節省網絡帶寬，如

AI

推理、流