【華為】云原生2.0架構(gòu)白皮書以云原生的思維踐行云原生1716mb

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

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

IT

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

CNCF

云原生開源社區(qū)的誕生，通過

K8S

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

CNCF

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

CNCF

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

IT

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

IT

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

AI

創(chuàng)新應(yīng)用的端到端開發(fā)態(tài)效率，突破傳統(tǒng)垂直

IT

架構(gòu)的數(shù)據(jù)層的擴展性瓶頸能力，解決大集中云資源池難以支撐時延敏感應(yīng)用及數(shù)據(jù)主權(quán)隱私保護，DevOps

開發(fā)流水線工具集、去中心化架構(gòu)的分布式中間件、分布式數(shù)據(jù)庫、云邊端及多云協(xié)同架構(gòu)、乃至普惠

AI

開發(fā)平臺，無一不是未來全棧云原生重構(gòu)所必須依賴的“基本要素”。由此，華為云通過自身在云原生開源社區(qū)的貢獻與引領(lǐng)，云原生架構(gòu)、全棧云原生服務(wù)產(chǎn)品的持續(xù)創(chuàng)新開發(fā)，以及支撐千行百業(yè)客戶上云的實踐經(jīng)驗，在業(yè)界已有的云原生系列概念與開源技術(shù)基礎(chǔ)上，首倡提出了“云原生

2.0”的理念與框架體系，旨在通過這本白皮書向華為云的生態(tài)伙伴及企業(yè)行業(yè)客戶闡述自己對企業(yè)云化、數(shù)字化轉(zhuǎn)型的系統(tǒng)化思考、建議與展望。云原生

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

1.0

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

2.0

時代的到來，共同引領(lǐng)云原生

2.0

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

毽張

琦吳清輝張

煜伍華濤李

昆文

震龍

江郭奉民朱冠宇彭立勛傅

飛俞

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

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

云原生概念與技術(shù)的歷史 / 0011.1

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

Native）？/

002云原生

1.0

的技術(shù)特征 /006云原生

1.0

的典型架構(gòu)模式 /

008云原生

1.0

面臨的挑戰(zhàn)

&

云原生

2.0 /

015第二章

云原生

2.0

的技術(shù)及架構(gòu)特征關(guān)鍵特征一：分布式云 /023趨勢與需求

/

023關(guān)鍵特征與架構(gòu)原則

/

024/ 022關(guān)鍵特征二：應(yīng)用驅(qū)動基礎(chǔ)設(shè)施 /

031趨勢與需求

/

031關(guān)鍵特征與架構(gòu)原則

/

032關(guān)鍵特征三：混合部署，統(tǒng)一調(diào)度 /

037趨勢與需求

/

037關(guān)鍵特征與架構(gòu)原則

/

037關(guān)鍵特征四：無服務(wù)器化（Serverless） /

040趨勢與需求

/

040關(guān)鍵特征與架構(gòu)原則

/

041關(guān)鍵特征五：存算分離趨勢與需求

/

044關(guān)鍵特征與架構(gòu)原則/

044/

045目錄目錄關(guān)鍵特征六：數(shù)據(jù)治理自動化 /

046趨勢與需求

/

046關(guān)鍵特征與架構(gòu)原則

/

047關(guān)鍵特征七：基于軟總線的異構(gòu)集成 /

048趨勢與需求

/

048關(guān)鍵特征與架構(gòu)原則

/

048關(guān)鍵特征八：可信、平民化

DevOps /

052趨勢與需求

/

052關(guān)鍵特征與架構(gòu)原則

/

052關(guān)鍵特征九：多模態(tài)可迭代行業(yè)

AI /

055趨勢與需求

/

055關(guān)鍵特征與架構(gòu)原則

/

057關(guān)鍵特征十：全方位立體化安全 /

061趨勢與需求

/

061關(guān)鍵特征與架構(gòu)原則

/

062第三章

華為云云原生

2.0架構(gòu)設(shè)計模式 / 067華為云原生架構(gòu)設(shè)計方法

（Huawei

Cloud

Native

Architecting

Methodology） /

068企業(yè)數(shù)字化戰(zhàn)略

–

云原生技術(shù)架構(gòu)的根本驅(qū)動力

/

069業(yè)務(wù)可持續(xù)發(fā)展

–

云原生技術(shù)架構(gòu)的直接驅(qū)動力

/

070架構(gòu)設(shè)計視角

–

云原生技術(shù)架構(gòu)本身

/070組織變更視角

/

073工程變革視角

/

074架構(gòu)持續(xù)演進閉環(huán)

/

075企業(yè)云原生架構(gòu)的可持續(xù)演進與迭代能力：基于服務(wù)開發(fā)服務(wù) /

075云原生

2.0

架構(gòu)白皮書華為云云原生

2.0

的典型架構(gòu)設(shè)計模式 /

076分布式云設(shè)計模式

/

076極致性價比驅(qū)動的軟硬協(xié)同架構(gòu)設(shè)計模式

/

082多元算力統(tǒng)一資源池架構(gòu)設(shè)計模式

/

084無服務(wù)器化（Serverless）架構(gòu)設(shè)計模式

/

085存算分離架構(gòu)設(shè)計模式

/

091數(shù)據(jù)治理自動化架構(gòu)設(shè)計模式

/

094基于軟總線異構(gòu)集成的架構(gòu)設(shè)計模式

/

0993.3.8可信、平民化

DevOps架構(gòu)設(shè)計模式

/

101多模態(tài)可迭代行業(yè)

AI架構(gòu)設(shè)計模式

/

105全方位立體式安全防護架構(gòu)設(shè)計模式

/

113第四章

華為云云原生

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

上海

12345

熱線 /1464.4

順豐科技/1484.5

新潮傳媒/1504.6

一汽紅旗/1524.7

國網(wǎng)信通/1544.8

江蘇財政/1554.9

深圳巴士/1564.10

信義玻璃/

158第五章

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

2.0

架構(gòu)白皮書第一章云原生概念與技術(shù)的歷史002業(yè)界關(guān)于云原生的概念，最早出現(xiàn)在

2010

年，由應(yīng)用集成中間件廠商WSO2

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

API

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

2

類，1

類為物理多租，另

1

類為邏輯多租；前者靠將應(yīng)用實例復(fù)制多份

VM

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

IaaS/PaaS/SaaS

服務(wù)，分別對應(yīng)在基礎(chǔ)設(shè)施領(lǐng)域管理租戶自己的

VM

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

NIST

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

年，亞馬遜

AWS及其戰(zhàn)略伙伴

Net?ix

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

Native）？第一章

|

云原生概念與技術(shù)的歷史003云原生

2.0

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

Cloud），微服務(wù)（Micro-services），反范式化數(shù)據(jù)（De-normalizeddata），混沌引擎（Chaos

Engines），持續(xù)部署（ContinuesDeployment），DevOps等。2015

年，由

Heroku

提出，AWS

Elastic

BeansTalk，Cloud

Foundry

等共同參與進一步對云原生的架構(gòu)特征進行了系統(tǒng)化總結(jié)與補充，首次提出了云原生“十二因子”，微服務(wù)，以及

DevOps等云原生的關(guān)鍵要素與特征：十二因子應(yīng)用（Twelve-Factor）因子

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

app

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

2：依賴App

應(yīng)該使用適當?shù)墓ぞ撸ㄈ?/p>

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

3：配置配置或其他隨發(fā)布環(huán)境（如部署、類生產(chǎn)、生產(chǎn)）而變更的部分應(yīng)當作為操作系統(tǒng)級的環(huán)境變量注入。因子

4：后端服務(wù)后端服務(wù)，例如數(shù)據(jù)庫、消息代理應(yīng)視為附加資源，并在所有環(huán)境中同等看待。因子

5：構(gòu)建，發(fā)布，運行嚴格區(qū)分構(gòu)建，發(fā)布，運行這三個步驟。直接修改處于運行狀態(tài)的代碼是非常不可取的做法，因為這些修改很難再同步回構(gòu)建步驟。因子

6：進程以一個或多個無狀態(tài)進程運行應(yīng)用，任何需要持久化的數(shù)據(jù)存儲在后端服務(wù)內(nèi)，比如數(shù)據(jù)庫。第一章

|

云原生概念與技術(shù)的歷史因子

7：端口綁定應(yīng)用完全自我加載而不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個面向網(wǎng)絡(luò)的服務(wù)?；ヂ?lián)網(wǎng)應(yīng)用通過端口綁定來提供服務(wù)，并監(jiān)聽發(fā)送至該端口的請求。因子

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

請求交給前端

Web

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

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

10：開發(fā)與驗證環(huán)境等價通過保持開發(fā)、類生產(chǎn)和生產(chǎn)環(huán)境盡可能的相同來實現(xiàn)持續(xù)交付和部署。因子

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

12：管理進程日常管理類任務(wù)（如數(shù)據(jù)庫遷移），應(yīng)該在與

app

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

2.0

架構(gòu)白皮書將業(yè)務(wù)領(lǐng)域分解為可獨立部署且有限能力的環(huán)境。同時，也將相關(guān)的變更周期解耦。通過擴展部署組織本身可以加快部署。由于學(xué)習(xí)業(yè)務(wù)領(lǐng)域和現(xiàn)有代碼的認知負擔減少，添加到每個沙箱的新開發(fā)人員可以更快速地提高并變得更高效?？梢约涌觳捎眯录夹g(shù)的步伐，大型單體應(yīng)用架構(gòu)通常與對技術(shù)堆棧的長期保證有關(guān)。微服務(wù)提供獨立、高效的服務(wù)擴展。自服務(wù)敏捷基礎(chǔ)設(shè)施（Self-Service

Agile

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

Git

遠程的原始源代碼的形式“推送”。然后，平臺構(gòu)建應(yīng)用程序工件，構(gòu)建應(yīng)用程序環(huán)境，部署應(yīng)用程序，并啟動必要的進程。團隊不必考慮他們的代碼在哪里運行或如何到達那里，這些對用戶都是透明的，因為平臺會關(guān)注這些。除此之外，自服務(wù)敏捷基礎(chǔ)設(shè)施還具備如下能力：應(yīng)用程序?qū)嵗淖詣踊桶葱钄U展應(yīng)用健康管理請求到或跨應(yīng)用程序?qū)嵗g的動態(tài)路由和負載均衡日志和指標的聚合基于

API

的協(xié)作（API-Based

Collaboration）在云原生應(yīng)用架構(gòu)中，服務(wù)之間的唯一互動模式是通過已發(fā)布和版本化的

API。這些

API

通常是具有

JSON

序列化的

HTTP

REST

風(fēng)格，但也可以是其他協(xié)議和序列化格式。通過消費者驅(qū)動的協(xié)議，可以在服務(wù)間交互的雙方驗證協(xié)議的合規(guī)性。服務(wù)消費者不能訪問其依賴關(guān)系的私有實現(xiàn)細節(jié)，或者直接訪問其依賴關(guān)系的數(shù)據(jù)存儲。反脆弱性（Anti-fragility）提升系統(tǒng)的韌性能力，即便在遭受壓力時不會被破壞或變?nèi)?，例如通過“混沌猴”將隨機故障注入到生產(chǎn)組件中，目的是識別和消除架構(gòu)中的缺陷。第一章

|

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

2015

年同年，CNCF

云原生計算基金會（Cloud

Native

Computing

Foundation，成員包括

Google、華為、IBM/Redhat、Intel

等

19

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

API。CNCF

致力于通過培養(yǎng)和維持一個開源、供應(yīng)商中立的項目生態(tài)系統(tǒng)來推動云原生技術(shù)的廣泛采用，進而實現(xiàn)讓云原生無處不在的愿景。CNCF

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

調(diào)查報告顯示，超過

8

成的用戶已經(jīng)或計劃使用微服務(wù)架構(gòu)進行業(yè)務(wù)開發(fā)部署等，這使得用戶對云原生技術(shù)的認知和使用進入新階段，云原生技術(shù)生態(tài)也進入到快速更迭的階段?；仡櫾圃夹g(shù)自誕生以來的發(fā)展歷程，站在企業(yè)應(yīng)用軟件上云的視角，特別是上云過程本身對應(yīng)用軟件本身遷移、重構(gòu)、開發(fā)、部署乃至全生命周期管理的影響，及其對全棧云服務(wù)價值挖掘持續(xù)地由淺入深地地過程，不難將其歸納為如下

2個特征：云原生特征

1：容器化，微服務(wù)化以

AWS

之上的

NetFlix為代表，其傳統(tǒng)單體軟件架構(gòu)被解耦拆分為微服務(wù)架構(gòu)，每個微服務(wù)對應(yīng)一個明確單一的業(yè)務(wù)功能單元，以及一個或多個運行態(tài)容器實例，所有微服務(wù)對外開放聲明式的

REST

或

gRPC

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

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

云原生1.0的技術(shù)特征007云原生

2.0

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

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

SpringCloud、ServiceComb、CSE

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

Istio服務(wù)網(wǎng)格

(ServiceMesh)

機制為拆分后的微服務(wù)提供注入服務(wù)發(fā)現(xiàn)、灰度升級、熔斷流控、流量治理等微服務(wù)公共基礎(chǔ)框架。云原生特征

2：基于云化應(yīng)用中間件、數(shù)據(jù)庫，乃至可重用服務(wù)重構(gòu)及開發(fā)企業(yè)應(yīng)用或服務(wù)在解決了租戶面業(yè)務(wù)邏輯容器化的挑戰(zhàn)之后，對其所依賴的中間件，數(shù)據(jù)庫從應(yīng)用空間到云服務(wù)商空間進行“下沉”。以

Salesforce

為代表，將企業(yè)應(yīng)用中的共性業(yè)務(wù)邏輯下沉到應(yīng)用平臺，在相同應(yīng)用邏輯上實現(xiàn)跨租戶共享，并借助模型驅(qū)動架構(gòu)

(MDA：Model-Driven

Architecture)

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

PaaS

平臺，也即hcaPaaS（high-control

application

PaaS），AWS

BeansTalk、Google

的

GAE

等即屬于

hcaPaaS；或與底層資源解耦、面向開發(fā)者展開高效企業(yè)應(yīng)用開發(fā)的

PaaS

平臺，也即

hpaPaaS（high-productivityapplication

PaaS），從而面向云租戶實現(xiàn)對應(yīng)用屏蔽下層資源的操作，依賴應(yīng)用平臺實現(xiàn)應(yīng)用和

DB

級的伸縮操作。Salesforce

的

2

大平臺

Heroku

和

F

分別對應(yīng)

hcaPaaS

及

hpaPaaS。hpaPaaS

的另一個內(nèi)涵對應(yīng)到

Low/No

Code，將應(yīng)用的生產(chǎn)環(huán)境部署延展到開發(fā)環(huán)節(jié)，基于應(yīng)用邏輯的理解，引入模板

/DSL

進行敏捷開發(fā)，對行業(yè)數(shù)字化起到了巨大的推動作用。第一章

|

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

Native），是指構(gòu)建、運行、管理基于云環(huán)境、利用云環(huán)境、適應(yīng)云環(huán)境、受益云環(huán)境的軟件而發(fā)展起來的一系列的軟件系統(tǒng)實踐范式。包括充分利用云基礎(chǔ)設(shè)施與平臺服務(wù)，具備微服務(wù)架構(gòu)、彈性伸縮、分布式、高可用、多租戶、自動化運維等關(guān)鍵特征的架構(gòu)實踐；建立與系統(tǒng)架構(gòu)匹配的全功能團隊、發(fā)展全棧工程師并高度協(xié)作的組織實踐；采用

DevOps、自動化工具，實現(xiàn)微服務(wù)持續(xù)交付的工程實踐。通過架構(gòu)、組織、工程面向云環(huán)境的協(xié)同實踐，實現(xiàn)Cloud

Native

系統(tǒng)對外體現(xiàn)快速、可靠、規(guī)模、靈活、高效的價值收益。云原生

1.0階段的代表性技術(shù)架構(gòu)模式包括：服務(wù)化架構(gòu)模式服務(wù)化架構(gòu)是現(xiàn)代云原生應(yīng)用普遍適用的標準架構(gòu)模式，與傳統(tǒng)軟件工程所強調(diào)的“高內(nèi)聚、低耦合”架構(gòu)模式在實現(xiàn)軟件功能的“分而治之”，以及公共軟件功能的“最大化重用”的目標方面是一致的，二者也均提倡通過

DDD（領(lǐng)域模型驅(qū)動）方法論指導(dǎo)將軟件面臨的業(yè)務(wù)應(yīng)用問題分解為復(fù)雜度、交付質(zhì)量、交付時間可控且更小顆粒度的應(yīng)用單元，但在實現(xiàn)這些應(yīng)用單元之間的隔離及復(fù)用手段方面，服務(wù)化架構(gòu)與傳統(tǒng)軟件架構(gòu)存在本質(zhì)不同：傳統(tǒng)軟件架構(gòu)更強調(diào)開發(fā)態(tài)靜態(tài)代碼的隔離與復(fù)用，而服務(wù)化架構(gòu)則更強調(diào)進程級別的運行態(tài)隔離，并以接口契約（IDL，Swagger，RAML

等）定義每個服務(wù)應(yīng)用單元可以為外部提供功能支撐，以標準協(xié)議（HTTP/HTTPS、gRPC

等）作為接口契約

API

的最終傳輸協(xié)議承載。各服務(wù)

/

微服務(wù)進程之間只能嚴格通過服務(wù)

API

為界面進行業(yè)務(wù)流程與邏輯地交互與協(xié)同，不允許直接訪問其他服務(wù)

/

微服務(wù)內(nèi)部的數(shù)據(jù)信息。服務(wù)化架構(gòu)采用運行態(tài)進程級軟件（服務(wù)

/

微服務(wù)）代替靜態(tài)開發(fā)態(tài)軟件模塊作為軟件隔離與共享基本單元的關(guān)鍵優(yōu)勢：輕量級服務(wù)

/

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

微服務(wù)解耦，使得服務(wù)/

微服務(wù)級別的故障，不會擴展至整個軟件系統(tǒng)；不同服務(wù)

/

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

云原生1.0的技術(shù)特征009云原生

2.0

架構(gòu)白皮書每個服務(wù)

/

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

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

微服務(wù)化拆分是更好的選擇。圖

1-1

傳統(tǒng)單體架構(gòu)與微服務(wù)化架構(gòu)對比Web

UIWeb

UI移動App移動AppREST

接口API

Gateway服務(wù)A接口開放業(yè)務(wù)邏輯數(shù)據(jù)訪問層數(shù)據(jù)庫接口開放業(yè)務(wù)邏輯數(shù)據(jù)訪問層數(shù)據(jù)庫接口開放業(yè)務(wù)邏輯數(shù)據(jù)訪問層數(shù)據(jù)庫服務(wù)C服務(wù)B模塊CREST

接口模塊A模塊B數(shù)據(jù)訪問層模塊A數(shù)據(jù)表 模塊B數(shù)據(jù)表 公共數(shù)據(jù)表 模塊C數(shù)據(jù)表數(shù)據(jù)庫傳統(tǒng)單體架構(gòu)服務(wù)化/微服務(wù)化架構(gòu)第一章

|

云原生概念與技術(shù)的歷史圖

1-2服務(wù)網(wǎng)格化架構(gòu)實施服務(wù)網(wǎng)格化架構(gòu)后，業(yè)務(wù)應(yīng)用代碼自身只需聚焦做好業(yè)務(wù)應(yīng)用邏輯的處理，而與具體業(yè)務(wù)應(yīng)用邏輯無關(guān)、可公共共享的服務(wù)

/

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

/

回歸測試等?？捎^測的服務(wù)

/微服務(wù)架構(gòu)在服務(wù)化/

微服務(wù)化架構(gòu)模式下，由于傳統(tǒng)單體應(yīng)用被拆分為更多顆粒度更小的微服務(wù)

/

組件，導(dǎo)致需獨立部署及升級變更的微服務(wù)

/

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

/

組件進程之間點到點網(wǎng)狀010服務(wù)網(wǎng)格化架構(gòu)模式服務(wù)網(wǎng)格化架構(gòu)，可以認為是服務(wù)化架構(gòu)的進一步“延伸與發(fā)展”，其本質(zhì)是將服務(wù)化架構(gòu)下跨服務(wù)

/

微服務(wù)之間與具體服務(wù)應(yīng)用的業(yè)務(wù)邏輯無關(guān)的公共交互處理與消息流量治理功能，與每個服務(wù)

/

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

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

2.0

架構(gòu)白皮書解耦消息交互端到端跟蹤，從而確保系統(tǒng)運行一旦出現(xiàn)問題時，即可快速定位并尋找到問題產(chǎn)生源頭所對應(yīng)的微服務(wù)和組件。服務(wù)/

微服務(wù)的可觀測性主要通過日志、跟蹤、統(tǒng)計指標3

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

/

調(diào)試

/

警告

/

錯誤

/

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

API

請求到后端業(yè)務(wù)處理完成的端到端全調(diào)用鏈路跟蹤，對于分布式場景尤其有用；統(tǒng)計指標則提供對系統(tǒng)量化的多維度度量。服務(wù)

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

OpenTracing、OpenTelemetry），或選擇自研的與服務(wù)

/微服務(wù)運維監(jiān)控能力配套的監(jiān)控運維系統(tǒng)（含被觀測對象側(cè)的運維代理，以及負責后端日志、跟蹤與統(tǒng)計指標處理的運維服務(wù)端），并規(guī)范化定義各服務(wù)/

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

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

微服務(wù)實例的跟蹤消息做快速關(guān)聯(lián)分析，以實現(xiàn)快速排障與問題調(diào)試。除故障管理及業(yè)務(wù)連續(xù)性保障之外，構(gòu)建服務(wù)

/

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

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

SLA/SLO(Service

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

/

微服務(wù)架構(gòu)模式下每個服務(wù)擁有自己獨立的數(shù)據(jù)源，不允許像單體應(yīng)用那樣直接跨服務(wù)共享數(shù)據(jù)源，因此導(dǎo)致高復(fù)雜度、大顆粒度的業(yè)務(wù)往往需要跨多個分布式服務(wù)

/

微服務(wù)的數(shù)據(jù)訪問，由此也引發(fā)了分布式事務(wù)一致性問題，從而確?？绮煌?wù)

/

微服務(wù)有關(guān)聯(lián)域的數(shù)據(jù)保持一致（多個微服務(wù)的關(guān)聯(lián)數(shù)據(jù)庫

/

數(shù)據(jù)表，要么同時更新成功，或要同時失?。＜軜?gòu)師需要根據(jù)不同的場景選擇合適的分布式事務(wù)模式。1)

兩階段提交模式服務(wù)/

微服務(wù)應(yīng)用中間件與數(shù)據(jù)庫通過

XA

接口規(guī)范，使用兩階段提交來完成一個全局事務(wù)，XA

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

XA

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

|

云原生概念與技術(shù)的歷史圖

1-4

TCC

模式事務(wù)開始時，業(yè)務(wù)應(yīng)用會向事務(wù)協(xié)調(diào)器注冊啟動事務(wù)。之后業(yè)務(wù)應(yīng)用會調(diào)用所有服務(wù)的

try接口，完成一階段準備。之后事務(wù)協(xié)調(diào)器會根據(jù)

try

接口返回情況，決定調(diào)用

con?rm

接口或者cancel

接口。如果接口調(diào)用失敗，會進行重試。TCC

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

try、con?rm、cancel

三個操作；二是應(yīng)用侵入性較強，改造成本高，實現(xiàn)難度較大。012第一階段事務(wù)協(xié)調(diào)器事務(wù)協(xié)調(diào)器預(yù)備就緒本地資源管理器本地資源管理器本地資源管理器本地資源管理器預(yù)備就緒提交成功提交成功第二階段2

調(diào)用Try接口1

啟動事務(wù)3

提交或回滾事務(wù)圖

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

TCC

模式：本質(zhì)是兩階段提交的一種改進，將整個業(yè)務(wù)邏輯的每個分支顯式分為

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

部分完成業(yè)務(wù)的準備工作，con?rm

部分完成業(yè)務(wù)的提交，cancel

部分完成事務(wù)的回滾，如下圖所示：服務(wù)A業(yè)務(wù)應(yīng)用事務(wù)協(xié)調(diào)性Try接口Confirm接口Cancel接口服務(wù)ATry接口數(shù)據(jù)庫數(shù)據(jù)庫Confirm接口Cancel接口4)

非入侵的高性能事務(wù)方案（DTM

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

ACID

的本地事務(wù)。為實現(xiàn)對本地事務(wù)的非入侵修改，引入資源管理器來攔截業(yè)務(wù)

SQL，對其解析并做額外的一些數(shù)據(jù)處理，產(chǎn)生

undo

log

并保存，一旦發(fā)生全局事務(wù)回滾，則通過各個分支事務(wù)對應(yīng)的

undo

log

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

事件驅(qū)動架構(gòu)（EDA）隨著萬物互聯(lián)時代的到來，用于高效關(guān)聯(lián)集成事件監(jiān)測與產(chǎn)生者，與對應(yīng)的事件處理者的事件驅(qū)動架構(gòu)EDA

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

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

等資產(chǎn)共享解決方案、分配維護人員和備件的規(guī)定維護系統(tǒng)或動態(tài)客戶服務(wù)應(yīng)用程序。013云原生

2.0

架構(gòu)白皮書因此，TCC

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

基于消息的最終一致性方案通過消息中間件保證上下游應(yīng)用數(shù)據(jù)操作的一致性?；舅悸肥菍⒈镜夭僮骱桶l(fā)送消息放在一個本地事務(wù)中，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應(yīng)用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應(yīng)操作。最終一致方案本質(zhì)上是將分布式事務(wù)轉(zhuǎn)換為兩個本地事務(wù)，然后依靠下游業(yè)務(wù)的重試機制達到最終一致性，因此其對應(yīng)用侵入性也很高，應(yīng)用需要進行大量業(yè)務(wù)改造，成本也非常高。圖

1-5

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

業(yè)務(wù)應(yīng)用訂單服務(wù)庫存服務(wù)第一章

|

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

+

CQRS（Command

and

Query

Responsibility

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

與

CQRS

模式相結(jié)合，是系統(tǒng)設(shè)計的一個自然增量，因為命令本身就是事件的生成器。結(jié)合014●●●事件

(event)響應(yīng)

(handler)事件與響應(yīng)的“邏輯關(guān)系”圖

1-6事件驅(qū)動架構(gòu)EDA

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

架構(gòu)的

3要素為：The

Complementary

Use

of

Event

Stream

Analytics

and

Event

Brokers

in

Event-Driven

ComputingEvent

HandlersEvent

SourcesEvent

BrokerComplexEventStreamStream

Analytics（CEP）Transactional

Event

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

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

&

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

/

用戶接入距離較遠，甚至超過上云應(yīng)用和業(yè)務(wù)可接受接入時延的上限（比如超過

50ms

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

TB

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

2.0

架構(gòu)白皮書使用

CQRS

和命令，為從傳統(tǒng)控制流架構(gòu)向EDA

架構(gòu)的過渡時的遷移數(shù)據(jù)提供了一個銜接的橋梁，在遷移結(jié)束后，可以移除該銜接橋梁。EDA

+

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

ES

與

EDA

配合使用，ES

負責保存

EDA

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

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

&

云原生2.0第一章

|

云原生概念與技術(shù)的歷史務(wù)注冊、自動發(fā)現(xiàn)、流量治理、灰度升級等功能。隨著云、5G、物聯(lián)網(wǎng)、AI

技術(shù)的不斷成熟，云化、數(shù)字化從互聯(lián)網(wǎng)及企業(yè)后端

IT

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

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

虛擬化、乃至

VMware

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

AI

訓(xùn)練與推理、網(wǎng)絡(luò)吞吐敏感的視頻及大數(shù)據(jù)分析類業(yè)務(wù)、網(wǎng)絡(luò)與存儲時延敏感的數(shù)據(jù)庫業(yè)務(wù)等，傳統(tǒng)基于通用CPU

及

OS

內(nèi)核態(tài)實現(xiàn)的虛擬化隔離及存儲、網(wǎng)絡(luò)協(xié)議棧功能，已越來越難以滿足應(yīng)用對底層基礎(chǔ)設(shè)施的性能訴求，從而促使業(yè)界去思考如何在保持云服務(wù)管理面及數(shù)據(jù)面界面不變的前提下，通過軟硬件深度垂直整合以及必要的軟件重構(gòu)，帶來極致性價比的可能性。挑戰(zhàn)

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

IO、網(wǎng)絡(luò)

IO

等各資源維度利用率不均衡所導(dǎo)致主機計算資源浪費的問題？解決之道：混合部署，統(tǒng)一調(diào)度當前多數(shù)云服務(wù)商的虛擬機層與

Kubernetes

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

容器集群，以及更底層物理機、虛擬機資集群調(diào)度，基于統(tǒng)一的資源視圖，實現(xiàn)多種類型云原生應(yīng)用（CPU、內(nèi)存、存儲

IO，網(wǎng)絡(luò)

IO

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

2.0

架構(gòu)白皮書池上的混合部署與統(tǒng)一并發(fā)調(diào)度，并進一步引入閉環(huán)的性能與

QoS

實時監(jiān)控機制，從而驅(qū)動統(tǒng)一多維調(diào)度引擎在保障云原生應(yīng)用性能的前提下，獲得更高的動態(tài)超分比資源利用率。挑戰(zhàn)

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

Serverless

無服務(wù)器時代。AWS

發(fā)布

FaaS（Function-as-a-Service）產(chǎn)品

Lambda

后，業(yè)界首次提出了

Serverless。Serverless是將應(yīng)用程序（或其一部分）在遠程托管的執(zhí)行環(huán)境中按需運行的架構(gòu)，其不需要用戶維護自己的資源管理，甚至不需要構(gòu)建與特定

OS

兼容的應(yīng)用程序。FaaS

實質(zhì)上是

Serverless架構(gòu)中以計算為中心的部分，可以構(gòu)成其中的一部分，但不代表整個系統(tǒng)。Serverless

上的應(yīng)用只需為實際運行代碼的時間付費。FaaS

早期以無狀態(tài)業(yè)務(wù)邏輯運行，對有狀態(tài)應(yīng)用無法支持，因此出現(xiàn)了

Serverless

2.0

=

FaaS+BaaS（Back-end

as

a

Service），需要將應(yīng)用和數(shù)據(jù)服務(wù)均

Serverless

化，并充當計算邏輯的

Serverless特征后端服務(wù)。當前

Serverless

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

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

cover

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

VM

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

AWS

SAM）；SLA

則可通過簡單的熱點代碼

Warm、以及

Serverless

平臺與資源層垂直優(yōu)化來部分解決。挑戰(zhàn)

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

MySQL

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

Hadoop

／

Spark

系列采用了

NDP（近數(shù)據(jù)處理）架構(gòu)，大數(shù)據(jù)分析處理進程與

Hadoop

數(shù)據(jù)分片是緊耦合的關(guān)系，導(dǎo)致了大數(shù)據(jù)集群無法與云主機及云容器集群共享計算資源池，計算與存儲緊耦合的大數(shù)據(jù)集群始終無法與面向普通應(yīng)用的云租戶計算和存儲集群實現(xiàn)物理共享；此外，對于企業(yè)應(yīng)用上云之后所產(chǎn)生的海量結(jié)構(gòu)化

MySQL、PQ-SQL，半結(jié)構(gòu)化

NoSQL

Cassandra

／

MongoDB，以及搜索引擎

Elastic

Search，圖數(shù)據(jù)庫

Noe4j，乃至非結(jié)構(gòu)化第一章

|

云原生概念與技術(shù)的歷史數(shù)據(jù)對象存儲

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

RAID/EC

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

N

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

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

IO

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

CPU

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

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

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

AI

替代人力進行數(shù)據(jù)質(zhì)量規(guī)則稽核、018云原生

2.0

架構(gòu)白皮書查重、修復(fù)和數(shù)據(jù)豐富，自動生成數(shù)據(jù)資產(chǎn)之間的關(guān)聯(lián)、發(fā)現(xiàn)與標簽分類，以及自動識別個人隱私數(shù)據(jù)和數(shù)據(jù)安全保護等。從而將企業(yè)數(shù)據(jù)治理的效率及數(shù)據(jù)資產(chǎn)準確性與質(zhì)量水平提升到一個新的臺階，滿足企業(yè)業(yè)務(wù)的數(shù)據(jù)消費需求。挑戰(zhàn)

7：如何解決云原生新開發(fā)應(yīng)用，與各行業(yè)已有的非云原生應(yīng)用，特別是非互聯(lián)網(wǎng)領(lǐng)域的政企傳統(tǒng)行業(yè)

IT

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

IT

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

8：如何將誕生于互聯(lián)網(wǎng)的

DevOps

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

DevOps云原生

DevOps

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

DevSecOps，成為大企業(yè)應(yīng)用與軟件生產(chǎn)現(xiàn)代化最關(guān)注的課題之一。另外，除

Full

Code

的傳統(tǒng)軟件開發(fā)模式之外，各個行業(yè)也逐步積累沉淀了一些高于

PaaS

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

應(yīng)用及數(shù)據(jù)資產(chǎn)，這些資產(chǎn)能力通過高效的建模及編排，使得僅基于上述模板資產(chǎn)能力的編排及少量定制（低代碼

/

零代碼）即可實現(xiàn)行業(yè)應(yīng)用的開發(fā)，從而使得行業(yè)應(yīng)用效率得到大幅提升。挑戰(zhàn)

9：如何讓方興未艾的人工智能技術(shù)助力全棧云服務(wù)更好地服務(wù)于云租戶及云生態(tài)開發(fā)者，以及有效降低各行業(yè)開發(fā)者使用人工智能技術(shù)的門檻，更快捷地開發(fā)人工智能應(yīng)用，并為行業(yè)生產(chǎn)力提升帶來核心價值？解決之道：全棧

AI

加持，全行業(yè)

AI

普惠019第一章

|

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

(

特別是深度學(xué)習(xí)

)

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

NLP、圖文

OCR、線性規(guī)劃最優(yōu)次優(yōu)求解、知識圖譜等領(lǐng)域的日益成熟及廣泛工程應(yīng)用，使得

AI

技術(shù)無論面向全棧云自身的運維與優(yōu)化效率提升，還是直接服務(wù)于各行業(yè)場景的運營優(yōu)化與生產(chǎn)力提升，均蘊藏著巨大的潛能與無限的可能性。挑戰(zhàn)

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

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

免遭安全攻擊的屏障與保護層角色，但該安全防護模式顯然也越來越難以匹配與企業(yè)業(yè)務(wù)快速增長同步的潛在安全攻擊源和攻擊方式的隱蔽多樣化，以及多變性等特征，從而促使云安全也走向安全多租化、軟件化，以及智能化的趨勢?？傊瑸橥黄粕鲜銮邪贅I(yè)

IT

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

2.0。云原生

2.0

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

CNCF

云原生社區(qū)技術(shù)與開源版圖的蓬勃演進發(fā)展，從最初的容器、微服務(wù)、DevOps

等技術(shù)領(lǐng)域，迅速擴展到如今的底層云原生基礎(chǔ)設(shè)施技術(shù)、編排及管理技術(shù)、云安全技術(shù)、監(jiān)測分析技術(shù)、大數(shù)據(jù)技術(shù)、人工智能技術(shù)、數(shù)據(jù)庫技術(shù)以及場景化應(yīng)用等眾多分支，初步形成了支撐應(yīng)用云原生化構(gòu)建的全生命周期技術(shù)鏈。同時細分領(lǐng)域的技術(shù)也趨于多元化發(fā)展，CNCF

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

Kubernetes，發(fā)展到如今

5

大類

100

多個項目，Kubernetes

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

等開源項目也陸續(xù)加入

CNCF

的云原生技術(shù)圖譜，進一步完善了云原生技術(shù)生態(tài)，也引領(lǐng)云原生再次迎來了前所未有的發(fā)展浪潮，極大加速了云原生在全球范圍內(nèi)的快速應(yīng)用和發(fā)展。020021云原生

2.0

架構(gòu)白皮書圖1-7CNCFCloudNativeInteractive

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

2.0

架構(gòu)的商業(yè)價值與最終愿景，是面向千行百業(yè)（無論是孕育云原生的互聯(lián)網(wǎng)企業(yè)，還是呼喚云原生重構(gòu)改造實現(xiàn)數(shù)字化賦能的非互聯(lián)網(wǎng)的政企客戶）的業(yè)務(wù)與應(yīng)用開發(fā)與運維團隊，提供涵蓋云原生基礎(chǔ)設(shè)施、數(shù)據(jù)使能、應(yīng)用使能、AI

使能、視頻使能、企業(yè)應(yīng)用數(shù)據(jù)集成、萬物互聯(lián)、企業(yè)辦公協(xié)同等在內(nèi)的全棧數(shù)字化平臺能力，從而將全棧云優(yōu)勢最大限度地發(fā)揮出來，將企業(yè)

IT信息開發(fā)人員從云基礎(chǔ)設(shè)施、各類應(yīng)用、數(shù)據(jù)、AI

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

|

云原生

2.0

的技術(shù)及架構(gòu)特征022第二章云原生2.0的技術(shù)及架構(gòu)特征023云原生

2.0

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

2.0

關(guān)鍵特征，對云原生

2.0

的價值驅(qū)動及架構(gòu)原則逐一進行解讀和闡述。2.1.1

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

IT

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

預(yù)測到

2025年超過

50%的組織將在其選擇的地點使用分布式云。隨著移動終端及物聯(lián)網(wǎng)的技術(shù)發(fā)展和普及應(yīng)用，以及企業(yè)業(yè)務(wù)的跨區(qū)域部署，從互聯(lián)網(wǎng)到政企客戶都產(chǎn)生了對分布式云的強烈需求?；诨ヂ?lián)網(wǎng)互動視頻的創(chuàng)新業(yè)務(wù)，AR/VR/

云游戲等，正在催生本地渲染的云基礎(chǔ)設(shè)施發(fā)展；另外低時延（OT

應(yīng)用）、數(shù)據(jù)本地駐留（合規(guī)），本地數(shù)據(jù)處理（視頻監(jiān)控）等政企應(yīng)用，在催生本地計算的云基礎(chǔ)設(shè)施發(fā)展?；A(chǔ)設(shè)施部署將從集中式向分布式演進，實現(xiàn)云的最后一公里覆蓋。2.1

關(guān)鍵特征一：分布式云第二章

|

云原生

2.0

的技術(shù)及架構(gòu)特征024總結(jié)來說，分布式云發(fā)展的核心驅(qū)動力有如下幾點：●低時延：為滿足低時延要求，需要在離業(yè)務(wù)現(xiàn)場最近的位置構(gòu)建解決方案，減少業(yè)務(wù)處理時延，業(yè)務(wù)本地閉環(huán)。海量數(shù)據(jù)分析

(

帶寬優(yōu)化

)：5G/IoT

時代邊緣數(shù)據(jù)爆炸性增長，難以直接回傳至云端且成本高昂，數(shù)據(jù)在本地進行分析和過濾，僅回傳結(jié)果，節(jié)省網(wǎng)絡(luò)帶寬，如

AI

推理、流