《華為云：云原生2.0架構白皮書-以云原生的思維踐行云原生（2022）（172頁）.pdf》由會員分享，可在線閱讀，更多相關《華為云：云原生2.0架構白皮書-以云原生的思維踐行云原生（2022）（172頁）.pdf（172頁珍藏版）》請在三個皮匠報告上搜索。

1、云原生2.0架構白皮書以云原生的思維踐行云原生構建萬物互聯的智能世界從業界首次提出云計算迄今為止的十多年歷程中，全球正在從面向個人消費者的開放式移動互聯以及面向企業、行業、政府的封閉 IT 的兩極化時代，穩步邁向萬物互聯、數字化、智能化，各領域應用和業務統一走向云端的新時代，在這幾乎影響到全社會、全行業、國民經濟乃至日常生產生活方方面面的數字化轉型過程中，多樣化的云部署形態：無論公有云、私有云，以及行業云、政務云等，無不通過云服務為載體，將云計算、大數據、人工智能、物聯網等技術有機整合在一起，為企業提供一站式的“云原生”數字化底座引擎，從而使得企業 IT 信息系統的開發者和運維者可以從繁重的非

2、業務平臺開發與維護的技術細節中解放出來，以更低的學習成本接入并使用云服務的能力，真正聚焦于業務本身，進而將企業業務的創新能力、經營優化與決策能力，乃至生產力水平帶上一個新的臺階。就云原生而言，其初衷更多是將彈性按需、水平擴展、高可靠高冗余、狀態與應用分離等關鍵云架構屬性特征以架構設計模式以規范參考架構及方法論的形式總結提煉出來，從而為企業應用的云化架構重構改造提供指引。后來 CNCF 云原生開源社區的誕生，通過 K8S 容器使得計算資源的輕量化、小型化，以及應用服務的集成打包封裝等，逐步成為標準化、模塊化的技術選擇，與此同時云原生的方法論、工具集，以及全棧云原生參考架構等方面，也在 CNCF

3、云原生社區中得到了進一步的定義與分解。雖然 CNCF 等開源社區的系列云原生開源技術，比之前的“抽象設計模式”更進了一步，為企業 IT 業務架構在無修改整體搬遷上云的基礎上，進一步展開更深度的云原生架構重構與改造，從而為最大限度地釋放云的技術與商業紅利提供了“技術組件與平臺”，序言然而要真正支撐完整的企業全棧 IT 的重構，僅僅依賴容器化平臺來承載企業自己開發的業務邏輯，以解決云原生應用的部署態及運行態彈性可靠性，及無單點高可靠、高可用問題，仍然是遠遠不夠的，為進一步提升企業核心業務處理及 AI 創新應用的端到端開發態效率，突破傳統垂直 IT 架構的數據層的擴展性瓶頸能力，解決大集中云資源池難

4、以支撐時延敏感應用及數據主權隱私保護，DevOps 開發流水線工具集、去中心化架構的分布式中間件、分布式數據庫、云邊端及多云協同架構、乃至普惠 AI 開發平臺，無一不是未來全棧云原生重構所必須依賴的“基本要素”。由此，華為云通過自身在云原生開源社區的貢獻與引領，云原生架構、全棧云原生服務產品的持續創新開發，以及支撐千行百業客戶上云的實踐經驗，在業界已有的云原生系列概念與開源技術基礎上，首倡提出了“云原生 2.0”的理念與框架體系，旨在通過這本白皮書向華為云的生態伙伴及企業行業客戶闡述自己對企業云化、數字化轉型的系統化思考、建議與展望。云原生 2.0，代表了云計算下個十年的發展趨勢，即是云原生

5、1.0 的平滑延續，更為即將到來得全行業數字化經濟時代定義了標準化、開放式、可高效批量復制的“智能世界云底座”參考架構與事實標準，各位開發者、架構師、以及技術管理決策者們，讓我們一起迎接并盡情擁抱云原生 2.0 時代的到來，共同引領云原生 2.0 產業走向更加美好和生機勃勃的未來！編寫說明編寫單位：華為云編寫組成員華為云顧炯炯 雷曉松 黃 毽 張 琦 吳清輝 張 煜 伍華濤 李 昆 文 震龍 江 郭奉民 朱冠宇 彭立勛 傅 飛 俞 岳 曾正陽 劉丙真 曹宗南懷寶興 顧震宇 胡紅山 胡 巍 王顯雷 李善航 唐金根 蘭修文 禹英軻第一章 云原生概念與技術的歷史 /0011.1 云原生的定義，什么是

6、云原生（Cloud Native）？/0021.2 云原生 1.0 的技術特征 /0061.3 云原生 1.0 的典型架構模式 /0081.4 云原生 1.0 面臨的挑戰&云原生 2.0 /015第二章 云原生 2.0 的技術及架構特征 /0222.1 關鍵特征一：分布式云 /0232.1.1 趨勢與需求 /0232.1.2 關鍵特征與架構原則 /0242.2 關鍵特征二：應用驅動基礎設施 /0312.2.1 趨勢與需求 /0312.2.2 關鍵特征與架構原則 /0322.3 關鍵特征三：混合部署，統一調度 /0372.3.1 趨勢與需求 /0372.3.2 關鍵特征與架構原則 /0372.4

7、 關鍵特征四：無服務器化（Serverless）/0402.4.1 趨勢與需求 /0402.4.2 關鍵特征與架構原則 /0412.5 關鍵特征五：存算分離 /0442.5.1 趨勢與需求 /0442.5.2 關鍵特征與架構原則 /045目錄目錄2.6 關鍵特征六：數據治理自動化 /0462.6.1 趨勢與需求 /0462.6.2 關鍵特征與架構原則 /0472.7 關鍵特征七：基于軟總線的異構集成 /0482.7.1 趨勢與需求 /0482.7.2 關鍵特征與架構原則 /0482.8 關鍵特征八：可信、平民化 DevOps /0522.8.1 趨勢與需求 /0522.8.2 關鍵特征與架構原

8、則 /0522.9 關鍵特征九：多模態可迭代行業 AI /0552.9.1 趨勢與需求 /0552.9.2 關鍵特征與架構原則 /0572.10 關鍵特征十：全方位立體化安全 /0612.10.1 趨勢與需求 /0612.10.2 關鍵特征與架構原則 /062第三章 華為云云原生 2.0 架構設計模式 /0673.1 華為云原生架構設計方法（Huawei Cloud Native Architecting Methodology）/0683.1.1 企業數字化戰略 云原生技術架構的根本驅動力 /0693.1.2 業務可持續發展 云原生技術架構的直接驅動力 /0703.1.3 架構設計視角 云原

9、生技術架構本身 /0703.1.4 組織變更視角 /0733.1.5 工程變革視角 /0743.1.6 架構持續演進閉環 /0753.2 企業云原生架構的可持續演進與迭代能力：基于服務開發服務 /075云原生 2.0 架構白皮書3.3 華為云云原生 2.0 的典型架構設計模式 /0763.3.1 分布式云設計模式 /0763.3.2 極致性價比驅動的軟硬協同架構設計模式 /0823.3.3 多元算力統一資源池架構設計模式 /0843.3.4 無服務器化（Serverless）架構設計模式 /0853.3.5 存算分離架構設計模式 /0913.3.6 數據治理自動化架構設計模式 /0943.3.

10、7 基于軟總線異構集成的架構設計模式 /0993.3.8 可信、平民化 DevOps 架構設計模式 /1013.3.9 多模態可迭代行業 AI 架構設計模式 /1053.3.10 全方位立體式安全防護架構設計模式 /113第四章 華為云云原生 2.0 典型案例實踐 /1424.1 長沙政務云 /1434.2 夢餉集團 /1444.3 上海 12345 熱線 /1464.4 順豐科技 /1484.5 新潮傳媒 /1504.6 一汽紅旗 /1524.7 國網信通 /1544.8 江蘇財政 /1554.9 深圳巴士 /1564.10 信義玻璃 /158第五章 未來趨勢展望 /160目錄001云原生

11、2.0 架構白皮書第一章云原生概念與技術的歷史 002業界關于云原生的概念，最早出現在 2010 年，由應用集成中間件廠商 WSO2 提出，其關于云原生關鍵特征的提煉與描述包括：分布式、動態連接：云化應用與中間件需支持多個共享配置及共享會話狀態，且并行運行的節點，另外不能假設云化應用是一種單一語言開發的，因此各云化應用之間要支持動態按需連接（與具體開發語言無關）。彈性：也即云化應用與中間件的分布式子節點應能根據系統的動態負載情況，進行按需的實例伸縮，包括調用云基礎服務 API 啟停虛機鏡像。多租戶：云化應用與中間件的多租方式有 2 類，1 類為物理多租，另 1 類為邏輯多租；前者靠將應用實例復

12、制多份 VM 或容器來實現，而后者則倡導“云化應用與中間件”內生的邏輯多租戶隔離，一般建議云化應用和中間件在可能的情況盡量使用邏輯多租，因為其在滿足多租能力需求的同時，占用相比物理多租更少的資源。自服務：自助式業務發放及管理對于最大化發揮云系統的效率至關重要，租戶彈性賬號內如果完全依賴管理員進行一切搭建、配置及管理活動，則不能稱之為 IaaS/PaaS/SaaS 服務，分別對應在基礎設施領域管理租戶自己的 VM 或容器，在平臺層領域管理并部署生產應用與中間件；在軟件層領域則在特定應從用中直接創建和管理“自己的租戶”。顆?；挠嬃坑嬞M：按使用計費是云的基礎特征之一，按年計費與按小時計費顯然顆粒度

13、有很大區別，即使對于私有云場景，對資源消費的計量也很重要，在一個自服務、多租戶、彈性的系統內資源和服務的使用情況就對應了系統的真實成本付出，因此深入理解、度量并監控資源的使用是至關重要的。增量的部署和測試；在一個高度可擴展、具備超大容量的云環境內，即便大型云客戶的新版本已進行過充分的單元或者系統測試，他們仍然希望能在生產環境上展開新版本的試錯性測試，并且可以在新舊共存版本之間控制流量分發的百分比。而采用云原生可以帶來的價值則包括：更高的資源利用率，更快的發放效率，更好的應用治理；從上面的云原生特征總結來看，與 NIST 對云計算的關鍵要素定義看起來比較相似，但云計算的定義更多是從云平臺的視角出

14、發，而云原生則更多是以云化應用為討論出發點。2013 年，亞馬遜 AWS 及其戰略伙伴 Netflix 的最佳實踐，進一步對云原生給出了自己的詮釋：基于不可靠、易失效的基礎設施，構建高度敏捷、高可用服務。云原生的定義，什么是云原生（Cloud Native）？1.1第一章|云原生概念與技術的歷史 003云原生 2.0 架構白皮書 目標：伸縮性、可用性、敏捷、效率。原則：關注點分離，反脆弱性，高度信任的組織。特點：基于公有云（Public Cloud），微服務（Micro-services），反范式化數據（De-normalized data），混沌引擎（Chaos Engines），持續部署（

15、Continues Deployment），DevOps 等。2015 年，由 Heroku 提出，AWS Elastic BeansTalk，Cloud Foundry 等共同參與進一步對云原生的架構特征進行了系統化總結與補充，首次提出了云原生“十二因子”，微服務，以及DevOps 等云原生的關鍵要素與特征：十二因子應用（Twelve-Factor）因子 1：一份代碼，多份部署每個可部署 app 在版本控制系統中僅有一個獨立的代碼庫，可以在不同的環境中部署多個實例。因子 2：依賴App 應該使用適當的工具（如 Maven、Bundler、NPM）來對依賴進行顯式的聲明，而不該在部署環境中隱式

16、的實現依賴。因子 3：配置配置或其他隨發布環境（如部署、類生產、生產）而變更的部分應當作為操作系統級的環境變量注入。因子 4：后端服務后端服務，例如數據庫、消息代理應視為附加資源，并在所有環境中同等看待。因子 5：構建，發布，運行嚴格區分構建，發布，運行這三個步驟。直接修改處于運行狀態的代碼是非常不可取的做法，因為這些修改很難再同步回構建步驟。因子 6：進程以一個或多個無狀態進程運行應用，任何需要持久化的數據存儲在后端服務內，比如數據庫。第一章|云原生概念與技術的歷史 004因子 7：端口綁定應用完全自我加載而不依賴于任何網絡服務器就可以創建一個面向網絡的服務?；ヂ摼W應用通過端口綁定來提供服務

17、，并監聽發送至該端口的請求。因子 8：并發通過進程模型進行擴展，進程是一等公民。開發人員可以將不同的工作分配給不同的進程類型。例如，HTTP 請求交給前端 Web 進程來處理，而常駐的后臺工作則交由后臺任務處理進程負責。因子 9：易處理快速啟動和優雅終止可最大化健壯性，進程應是易處理的也即可以瞬間開啟或停止，從而有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健的部署應用。進程應當追求最小啟動時間，一旦接收終止信號就會優雅的終止，就網絡進程而言，優雅終止是指停止監聽服務的端口，即拒絕所有新的請求，并繼續執行當前已接收的請求，然后退出。對于任務處理進程來說，優雅終止是指將當前任務退回隊列

18、。進程還應當在面對突然死亡時保持健壯。因子 10：開發與驗證環境等價通過保持開發、類生產和生產環境盡可能的相同來實現持續交付和部署。因子 11：日志不管理日志文件，將日志視為事件流，允許執行環境通過集中式服務收集、聚合、索引和分析事件。因子 12：管理進程日常管理類任務（如數據庫遷移），應該在與 app 長期運行的相同的環境中一次性完成。這些特性很適合快速部署應用程序，因為它們不需要對將要部署的環境做任何假定。對環境假設能夠允許底層云平臺使用簡單而一致的機制，輕松實現自動化，快速配置新環境，并部署應用，優化應用的部署速度。微服務（Microservices）微服務將單體業務系統分解為多個“僅做

19、好一件事”可獨立部署的服務。這件事通常代表某項業務能力，或者最小可提供業務價值的“原子”服務單元。微服務架構通過以下幾種方式為速度、安全、可擴展性賦能：005云原生 2.0 架構白皮書 將業務領域分解為可獨立部署且有限能力的環境。同時，也將相關的變更周期解耦。通過擴展部署組織本身可以加快部署。由于學習業務領域和現有代碼的認知負擔減少，添加到每個沙箱的新開發人員可以更快速地提高并變得更高效?？梢约涌觳捎眯录夹g的步伐，大型單體應用架構通常與對技術堆棧的長期保證有關。微服務提供獨立、高效的服務擴展。自服務敏捷基礎設施（Self-Service Agile Infrastructure）使用云原生應用

20、架構的團隊通常負責其應用的部署和持續運營。云原生應用的成功采納者已經為團隊提供了自服務平臺。應用程序代碼簡單地以預構建的工件（可能是作為持續交付管道的一部分生成的）或 Git 遠程的原始源代碼的形式“推送”。然后，平臺構建應用程序工件，構建應用程序環境，部署應用程序，并啟動必要的進程。團隊不必考慮他們的代碼在哪里運行或如何到達那里，這些對用戶都是透明的，因為平臺會關注這些。除此之外，自服務敏捷基礎設施還具備如下能力：應用程序實例的自動化和按需擴展 應用健康管理 請求到或跨應用程序實例間的動態路由和負載均衡 日志和指標的聚合基于 API 的協作（API-Based Collaboration）在

21、云原生應用架構中，服務之間的唯一互動模式是通過已發布和版本化的 API。這些 API 通常是具有 JSON 序列化的 HTTP REST 風格，但也可以是其他協議和序列化格式。通過消費者驅動的協議，可以在服務間交互的雙方驗證協議的合規性。服務消費者不能訪問其依賴關系的私有實現細節，或者直接訪問其依賴關系的數據存儲。反脆弱性（Anti-fragility）提升系統的韌性能力，即便在遭受壓力時不會被破壞或變弱，例如通過“混沌猴”將隨機故障注入到生產組件中，目的是識別和消除架構中的缺陷。第一章|云原生概念與技術的歷史 006DevOps，持續交付，康威定律系統即便在遭受壓力時不會被破壞或變弱，例如通

22、過“混沌猴”將隨機故障注入到生產組件中。也是在 2015 年同年，CNCF 云原生計算基金會（Cloud Native Computing Foundation，成員包括 Google、華為、IBM/Redhat、Intel 等 19 家）正式成立，標志著云原生從技術理念轉化為開源實現，并給出了目前被廣泛接受的定義：云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。CNCF 致力于通過培養和維持一個開源、供應商中立的項目生態系統來推動云原生技術的廣泛采用，進而實現讓云原生無處不

23、在的愿景。CNCF對云原生的定義讓云原生的概念進一步具體化，從而讓云原生更容易被各行業理解，為云原生在全行業廣泛應用奠定了基礎。過去幾年中，云原生關鍵技術正在被廣泛采納，CNCF 調查報告顯示，超過 8 成的用戶已經或計劃使用微服務架構進行業務開發部署等，這使得用戶對云原生技術的認知和使用進入新階段，云原生技術生態也進入到快速更迭的階段?；仡櫾圃夹g自誕生以來的發展歷程，站在企業應用軟件上云的視角，特別是上云過程本身對應用軟件本身遷移、重構、開發、部署乃至全生命周期管理的影響，及其對全棧云服務價值挖掘持續地由淺入深地地過程，不難將其歸納為如下 2 個特征：云原生特征 1：容器化，微服務化以

24、AWS 之上的 NetFlix 為代表，其傳統單體軟件架構被解耦拆分為微服務架構，每個微服務對應一個明確單一的業務功能單元，以及一個或多個運行態容器實例，所有微服務對外開放聲明式的 REST 或 gRPC API，作為與其他微服務交互的“唯一契約”，微服務本身開發復雜度適合 10人左右小團隊承擔，所有微服務均有自己獨立的數據庫及持久化數層，而不與其他微服務有任何云原生1.0的技術特征1.2007云原生 2.0 架構白皮書共享數據庫依賴，從而確保所有微服務可以完全運行態解耦，以獨立的版本節奏迭代演進，并支持不同的開發語言，且每個微服務可依據業務量需求，以容器為最小擴縮容單元進行秒級按需彈性伸縮（

25、容器顆粒度一般遠小于 VM，且更輕量化，易于秒級啟停），每個容器的發布包，除應用鏡像外，也包含其業務應用運行時所需的依賴庫、環境變量等。此外，還將分布式微服務的管理與治理能力下沉到開源語言特定的微服務框架，例如 SpringCloud、ServiceComb、CSE 等，以及非侵入式通過邊車（Sidecar）與業務邏輯綁定注入微服務治理能力，也即通過應用無感知的Istio 服務網格(ServiceMesh)機制為拆分后的微服務提供注入服務發現、灰度升級、熔斷流控、流量治理等微服務公共基礎框架。云原生特征 2：基于云化應用中間件、數據庫，乃至可重用服務重構及開發企業應用或服務在解決了租戶面業務邏

26、輯容器化的挑戰之后，對其所依賴的中間件，數據庫從應用空間到云服務商空間進行“下沉”。以 Salesforce 為代表，將企業應用中的共性業務邏輯下沉到應用平臺，在相同應用邏輯上實現跨租戶共享，并借助模型驅動架構(MDA：Model-Driven Architecture)進行跨租戶應用邏輯的抽象，同時在平臺層進一步實現跨租戶的數據庫共享，也即基于統一的數據庫模板進行不同租戶對應數據表的裁剪、重映射等操作；總之，通過在應用和數據服務層提供跨租戶共享能力（也即邏輯多租），實現面向最終云租戶屏蔽資源層多租隔離的復雜性。另一種上云模式是與底層資源耦合、應用無需感知彈性資源伸縮控制的 PaaS 平臺，也

27、即 hcaPaaS（high-control application PaaS），AWS BeansTalk、Google 的 GAE 等 即 屬 于hcaPaaS；或與底層資源解耦、面向開發者展開高效企業應用開發的 PaaS 平臺，也即 hpaPaaS（high-productivity application PaaS），從而面向云租戶實現對應用屏蔽下層資源的操作，依賴應用平臺實現應用和 DB 級的伸縮操作。Salesforce 的 2 大平臺 Heroku 和 F 分別對應hcaPaaS 及 hpaPaaS。hpaPaaS 的另一個內涵對應到 Low/No Code，將應用的生產環境部署

28、延展到開發環節，基于應用邏輯的理解，引入模板/DSL 進行敏捷開發，對行業數字化起到了巨大的推動作用。第一章|云原生概念與技術的歷史 008所謂云原生（Cloud Native），是指構建、運行、管理基于云環境、利用云環境、適應云環境、受益云環境的軟件而發展起來的一系列的軟件系統實踐范式。包括充分利用云基礎設施與平臺服務，具備微服務架構、彈性伸縮、分布式、高可用、多租戶、自動化運維等關鍵特征的架構實踐；建立與系統架構匹配的全功能團隊、發展全棧工程師并高度協作的組織實踐；采用 DevOps、自動化工具，實現微服務持續交付的工程實踐。通過架構、組織、工程面向云環境的協同實踐，實現 Cloud Na

29、tive 系統對外體現快速、可靠、規模、靈活、高效的價值收益。云原生 1.0 階段的代表性技術架構模式包括：服務化架構模式服務化架構是現代云原生應用普遍適用的標準架構模式，與傳統軟件工程所強調的“高內聚、低耦合”架構模式在實現軟件功能的“分而治之”，以及公共軟件功能的“最大化重用”的目標方面是一致的，二者也均提倡通過 DDD（領域模型驅動）方法論指導將軟件面臨的業務應用問題分解為復雜度、交付質量、交付時間可控且更小顆粒度的應用單元，但在實現這些應用單元之間的隔離及復用手段方面，服務化架構與傳統軟件架構存在本質不同：傳統軟件架構更強調開發態靜態代碼的隔離與復用，而服務化架構則更強調進程級別的運行

30、態隔離，并以接口契約（IDL，Swagger，RAML 等）定義每個服務應用單元可以為外部提供功能支撐，以標準協議（HTTP/HTTPS、gRPC 等）作為接口契約 API 的最終傳輸協議承載。各服務/微服務進程之間只能嚴格通過服務 API 為界面進行業務流程與邏輯地交互與協同，不允許直接訪問其他服務/微服務內部的數據信息。服務化架構采用運行態進程級軟件（服務/微服務）代替靜態開發態軟件模塊作為軟件隔離與共享基本單元的關鍵優勢：輕量級服務/微服務的開發、測試、部署、發布等全流程活動由獨立全功能團隊負責，不再需要多個有緊耦合關聯的開發測試功能團隊協作才能完成，因此有效地提高了軟件研發迭代效率；業

31、務邏輯按照服務/微服務解耦，使得服務/微服務級別的故障，不會擴展至整個軟件系統；不同服務/微服務的代碼模塊所對應的部署實例數可依據實際業務情況各不相同，并且可以云原生1.0的技術特征1.3009云原生 2.0 架構白皮書服務為單位進行更小顆粒度的水平伸縮，從而使得系統部署成本更優；每個服務/微服務可以根據具體的場景，獨立演進最優的技術堆棧，利于實踐新技術，享受額外的技術紅利；單個服務/微服務職責單一、輕量化，利于實施持續交付，快速演進業務。當然，凡事必有其兩面性，服務化架構所帶來的也不僅僅是優勢，同樣也必然存在其約束和挑戰：數據隨同服務一起分布化后，需要妥善處理數據一致性問題，跨服務進程的遠程

32、調用引發的性能問題導致系統部署運維復雜，涉及眾多服務實例，需要完善的工具做支撐；服務之間基于接口契約化，隱式的運行態依賴，導致依賴管理復雜度提升。服務進行不兼容升級時，需妥善處對上游服務的影響；系統劃分為多個服務，業務特性需要多個服務協作完成，增加了測試難度。因此，服務化架構下的軟件進程拆分顆粒度也不是一味追求越小越好。一方面要考慮與業務應用邊界的對齊，另一方面也要充分做好與服務化架構配套的工具自動化、治理流程方面地準備。對于軟件進程間交互對性能（時延、吞吐）高度敏感的場景，比如底層數據報文轉發、基于內存共享區的數據映射與交換等，不排除傳統的軟件進程解耦相比服務化/微服務化拆分是更好的選擇。圖

33、 1-1 傳統單體架構與微服務化架構對比Web UIWeb UI移動App移動AppREST 接口API Gateway服務A接口開放業務邏輯數據訪問層數據庫接口開放業務邏輯數據訪問層數據庫接口開放業務邏輯數據訪問層數據庫服務C服務B模塊CREST 接口模塊A模塊B數據訪問層模塊A數據表模塊B數據表傳統單體架構服務化/微服務化架構數據庫公共數據表模塊C數據表第一章|云原生概念與技術的歷史 010服務網格化架構模式服務網格化架構，可以認為是服務化架構的進一步“延伸與發展”，其本質是將服務化架構下跨服務/微服務之間與具體服務應用的業務邏輯無關的公共交互處理與消息流量治理功能，與每個服務/微服務特有

34、的業務邏輯解耦，從而使得這些提供服務端點注冊發現、服務間消息交互鑒權認證與加解密保護、服務間的消息流控、熔斷、降級、重試、反壓、隔倉等分布式架構模式及其用到的中間件框架（比如緩存、異步消息、遠程過程調用等）從業務進程中徹底分離解耦，統一納入到服務化網格（Service Mesh）的框架內，而業務進程中僅需要保留與服務化網格之間很薄的一層適配通信客戶端，甚至完全無需感知服務化網格能力的存在，其架構示意如下：圖 1-2 服務網格化架構實施服務網格化架構后，業務應用代碼自身只需聚焦做好業務應用邏輯的處理，而與具體業務應用邏輯無關、可公共共享的服務/微服務治理方面的處理均可交由服務網格機制來統一處理：

35、包括服務能力發現、服務間交互韌性保護、服務彈性伸縮、零信任安全保護、按流量進行服務/微服務版本灰度上線與環境隔離、基于流量做自動化的冒煙/回歸測試等?？捎^測的服務/微服務架構在服務化/微服務化架構模式下，由于傳統單體應用被拆分為更多顆粒度更小的微服務/組件，導致需獨立部署及升級變更的微服務/組件進程數有了數倍甚至數十倍增加，因此也必然對應用架構的“透明可觀測”能力提出了更高的要求。為數量眾多的微服務/組件進程之間點到點業務進程業務進程業務應用代碼業務應用代碼業務應用代碼服務發現SDK流量治理SDK安全管控SDK消息跟蹤SDK業務應用代碼服務網格進程（服務發現、流量治理、安全管控、消息跟蹤.）服

36、務發現SDK流量治理SDK安全管控SDK消息跟蹤SDK011云原生 2.0 架構白皮書網狀解耦消息交互端到端跟蹤，從而確保系統運行一旦出現問題時，即可快速定位并尋找到問題產生源頭所對應的微服務和組件。服務/微服務的可觀測性主要通過日志、跟蹤、統計指標 3 類渠道獲得，其中日志提供多個級別（詳細/調試/警告/錯誤/致命）的詳細信息跟蹤，可由應用開發者主動提供日志信息的收集與上報；跟蹤則提供一個請求從前端接收到 API 請求到后端業務處理完成的端到端全調用鏈路跟蹤，對于分布式場景尤其有用；統計指標則提供對系統量化的多維度度量。服務/微服務架構即可為自己選擇合適的、支持可觀測能力的開源框架（比如 O

37、penTracing、OpenTelemetry），或選擇自研的與服務/微服務運維監控能力配套的監控運維系統（含被觀測對象側的運維代理，以及負責后端日志、跟蹤與統計指標處理的運維服務端），并規范化定義各服務/微服務上報的日志、跟蹤及統計指標等觀測數據的具體類型與參數（比如用戶信息、地理位置、請求參數等），明確這些可觀測數據的產生端與消費端。利用日志和跟蹤信息中的“跟蹤實例/ID 信息”，可使得后臺分布式鏈路分析時將來自不同服務/微服務實例的跟蹤消息做快速關聯分析，以實現快速排障與問題調試。除故障管理及業務連續性保障之外，構建服務/微服務可觀測能力也有助于衡量各個服務/微服務組件是否達到了其面向

38、服務租戶所承諾的SLA/SLO(Service Level Agreement/Objective)，比如并發業務請求數、業務請求平均處理時長、持續提供不中斷服務的市場、系統的總體容量、剩余可用容量等。分布式事務模式服務/微服務架構模式下每個服務擁有自己獨立的數據源，不允許像單體應用那樣直接跨服務共享數據源，因此導致高復雜度、大顆粒度的業務往往需要跨多個分布式服務/微服務的數據訪問，由此也引發了分布式事務一致性問題，從而確?？绮煌?微服務有關聯域的數據保持一致（多個微服務的關聯數據庫/數據表，要么同時更新成功，或要同時失?。?。架構師需要根據不同的場景選擇合適的分布式事務模式。1)兩階段提交

39、模式服務/微服務應用中間件與數據庫通過 XA 接口規范，使用兩階段提交來完成一個全局事務，XA 規范的基礎是兩階段提交協議：一階段：表決階段，所有參與者都將本事務能否成功的信息反饋發給協調者；二階段：執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾采用強一致性機制。該模式的缺點是能低下，可能因為 XA 協議自身原因，造成事務資源長時間得不到釋放，鎖定周期長，而且在應用層上面無法干預，數據并發沖突高的場景性能很差。第一章|云原生概念與技術的歷史 012事務開始時，業務應用會向事務協調器注冊啟動事務。之后業務應用會調用所有服務的 try接口，完成一階段準備。

40、之后事務協調器會根據 try 接口返回情況，決定調用 confirm 接口或者cancel 接口。如果接口調用失敗，會進行重試。TCC 方案讓應用可自定義數據庫操作的粒度，使得降低鎖沖突、提高吞吐量成為可能，不足之處體現在兩方面：一是業務侵入性強：業務邏輯的每個分支都需要實現 try、confirm、cancel 三個操作；二是應用侵入性較強，改造成本高，實現難度較大。2)TCC 模式：本質是兩階段提交的一種改進，將整個業務邏輯的每個分支顯式分為 Try、Confirm、Cancel三個操作。Try 部分完成業務的準備工作，confirm 部分完成業務的提交，cancel 部分完成事務的回滾，

41、如下圖所示：圖 1-3 兩階段提交模式圖 1-4 TCC 模式第一階段事務協調器事務協調器預備就緒本地資源管理器本地資源管理器本地資源管理器本地資源管理器預備就緒提交成功提交成功第二階段2 調用Try接口1 啟動事務3 提交或回滾事務業務應用事務協調性服務ATry接口Confirm接口Cancel接口服務ATry接口數據庫數據庫Confirm接口Cancel接口013云原生 2.0 架構白皮書3)基于消息的最終一致性方案通過消息中間件保證上下游應用數據操作的一致性?；舅悸肥菍⒈镜夭僮骱桶l送消息放在一個本地事務中，保證本地操作和消息發送要么兩者都成功或者都失敗。下游應用向消息系統訂閱該消息，收

42、到消息后執行相應操作。最終一致方案本質上是將分布式事務轉換為兩個本地事務，然后依靠下游業務的重試機制達到最終一致性，因此其對應用侵入性也很高，應用需要進行大量業務改造，成本也非常高。圖 1-5 基于消息的最終一致性方案4)非入侵的高性能事務方案（DTM 分布式事務中間件）其基本思路將分布式事務也即一個全局事務，劃分為若干個分支事務，每個分支事務均是一個滿足 ACID 的本地事務。為實現對本地事務的非入侵修改，引入資源管理器來攔截業務 SQL，對其解析并做額外的一些數據處理，產生 undo log 并保存，一旦發生全局事務回滾，則通過各個分支事務對應的 undo log 完成所有分支事務回滾。為

43、防止兩個全局事務并行修改數據導致回滾數據錯誤，引入分布式鎖服務器對事務所修改數據加鎖，全局事務提交后立即放鎖，全局事務回滾則等待分支事務回滾完成放鎖。5.事件驅動架構（EDA）隨著萬物互聯時代的到來，用于高效關聯集成事件監測與產生者，與對應的事件處理者的事件驅動架構 EDA 正在迅速興起，用于促進事件的生產、檢測、處理和響應。事件可以是多種多樣的，比如某人拿起一件物品，某對象的測量指標達到一個閾值，或者一個特定的客戶到達零售店。EDA 由三個屬性定義。首先，它有選擇地將相關事件從傳入數據傳輸到數據庫。其次，它處理來自多個源的復雜事件，這些事件可以實時地相互影響。第三，它通過推式操作簡化了實時服

44、務。事件驅動架構的用例示例包括滴滴、Uber 等資產共享解決方案、分配維護人員和備件的規定維護系統或動態客戶服務應用程序。訂單數據庫庫存數據庫消息隊列.業務應用訂單服務庫存服務因此，TCC 方案雖多被研發實力強、有迫切需求的電商、金融公司采用，但由于事務處理邏輯多數需要在應用層完成，因此與微服務所倡導的服務輕量化思路不完全吻合。第一章|云原生概念與技術的歷史 014EDA 是一種非常流行的分布式異步架構模式，經常被用與構建高可伸縮性的應用程序。當然它也適合小型應用，復雜應用和規模比較大的應用。這種架構模式由一系列高度解耦的、異步接收和處理事件的單一職責的組件所組成。事件驅動架構由兩個主要的拓撲

45、組成：分別是調停者拓撲和代理者拓撲。調停者拓撲通過一個中央的調停者來編排各種處理步驟。然而代理者拓撲適用于那些想將事件鏈式的聚在一起但不使用中央調停者的情況。事件流通過客戶端發送到消息隊列，事件隊列則傳遞消息到調停者。調停者接收到隊列傳遞過來的原始消息，然后編排成異步的消息發送到事件通道，事件通道則通過事件處理器執行處理過程的每一步。事件處理器則監聽事件通道，根據自身不同的業務邏輯來處理從調停者接受的事件。EDA 架構的 3 要素為：事件(event)響應(handler)事件與響應的“邏輯關系”其中的“事件”常常是固定的，而“邏輯關系”往往體現的是業務規則或者核心邏輯，也常常是固定不變的。只

46、有“響應”是可變的，或者說是可以配置或者需要改變的。響應事件而不是主動查詢目標系統將會帶來自主性，更好的容錯能力和彈性，但也有一點其他影響，會影響自治事件驅動系統的是“延遲”。EDA+CQRS（Command and Query Responsibility Split）模式強調命令和查詢的分離，也即各自獨立的類封裝：其中查詢負責請求獲取系統的狀態，而命令則負責請求系統修改其狀態。將 EDA 與 CQRS 模式相結合，是系統設計的一個自然增量，因為命令本身就是事件的生成器。結合圖 1-6 事件驅動架構The Complementary Use of Event Stream Analytics

47、 and Event Brokers in Event-Driven ComputingEvent SourcesEvent BrokerComplexEventStreamStream Analytics（CEP）Event HandlersTransactional Event Stream015云原生 2.0 架構白皮書使用 CQRS 和命令，為從傳統控制流架構向EDA架構的過渡時的遷移數據提供了一個銜接的橋梁，在遷移結束后，可以移除該銜接橋梁。EDA+事件溯源（ES）模式：事件溯源表示能追查一個事件的源頭，甚至與之相關的其他事件的概念，通過將 ES 與 EDA 配合使用，ES 負責保存

48、 EDA 產生的事件信息，使得我們對系統中的實體究竟是如何一步一步變成現在這個樣子能有一個清晰的了解，并且也為必要的 Redo 撤銷重做機制提供了支撐。盡管云原生技術自誕生以來經歷了蓬勃迅猛的發展，不斷臻于完善，然而隨著千行百業云化不斷走向縱深，人們也發現云原生技術正在面臨越來越多的不足與局限性亟待解決和突破，而對這些問題及其解決途徑的思考與探索，引發了云原生新代際的出現。挑戰 1：如何解決云資源池的大集中化，與實時應用上云要求低時延，及海量線下數據上云不滿足數據隱私合規，或者帶寬接入成本過高之間的矛盾？解決之道：分布式云眾所周知，云計算相比傳統計算模式最大的優勢：“彈性伸縮&敏捷按需”，來源

49、于云數據中心中的超大規模計算與存儲資源池，通過資源動態共享，一方面使得云租戶視角永遠感知到“取之不盡，用之不竭”的“彈性按需資源”，另一方面則通過不同租戶及租戶內不同虛擬化、容器負載之間的集約動態復用，獲得相比傳統獨占硬件平臺方式更高的有效資源利用率。然而云資源池的大集中化，必然面臨著該集中資源池距離多數最終云租戶/用戶接入距離較遠，甚至超過上云應用和業務可接受接入時延的上限（比如超過 50ms 時延），而對于一些特定行業用戶側產生的海量數據（如公安領域的視頻監控數據、醫療領域基因數據、工業互聯網制造領域的數字孿生建模數據等），要么由于國家區域或者行業的數據安全隱私保護規范的要求，希望相關核心

50、數據資產永遠保留在自己得數據中心內，不得泄露到任何第三方（包括云服務商）；或者雖然對線下數據上云沒有隱私保護要求，但由于數據體量過大（單個企業租戶每天數十甚至上百 TB 得數據上傳量），使得數據上傳的成本可能反而超過從云端獲得彈性算力及算法服務可獲得的收益。與大集中的云資源池相對應，當前云原生微服務治理框架，也僅考慮了大規模云資源池站點內的服云原生1.0面臨的挑戰&云原生2.01.4第一章|云原生概念與技術的歷史 016務注冊、自動發現、流量治理、灰度升級等功能。隨著云、5G、物聯網、AI 技術的不斷成熟，云化、數字化從互聯網及企業后端 IT 支撐系統迅速延伸進入到智慧城市、智慧政務的物聯網終

51、端系統，智慧制造的前端實時生產線，促使上述實時應用及海量數據上云難與云資源池大規模集約化之間的矛盾變得更為緊迫和突出，云原生迫切需要回答在云基礎設施及云原生框架兩個層面，如何從“大集中云”走向“大集中云”與“分布式云”共存，從而實現靈活敏捷、可編程的云邊端協同。挑戰 2：如何解決云原生應用對跨物理機、虛擬機，跨云服務商，以及跨云端和邊緣的云基礎設施無關性需求，與性能敏感的關鍵重載應用對云原生基礎設施的極致性能需求之間的矛盾？解決之道：應用驅動基礎設施云原生強調應用與基礎設施平臺各自水平分層解耦，特別是面向云租戶和開發的應用發布、部署以及全生命周期管理的“物理基礎設施無關性”，也即相同的容器發布

52、方式，無論部署在物理服務器、KVM 虛擬化、乃至 VMware 虛擬化之上，均可保持其容器包發布與管理方式的一致性；然而隨著云原生改造所覆蓋的應用類型越來越廣泛，對于性能敏感的應用，比如 AI 訓練與推理、網絡吞吐敏感的視頻及大數據分析類業務、網絡與存儲時延敏感的數據庫業務等，傳統基于通用CPU 及 OS 內核態實現的虛擬化隔離及存儲、網絡協議棧功能，已越來越難以滿足應用對底層基礎設施的性能訴求，從而促使業界去思考如何在保持云服務管理面及數據面界面不變的前提下，通過軟硬件深度垂直整合以及必要的軟件重構，帶來極致性價比的可能性。挑戰 3：如何解決越來多樣化的云原生應用需獨占容器集群甚至資源池，且

53、在CPU、內存、存儲 IO、網絡 IO 等各資源維度利用率不均衡所導致主機計算資源浪費的問題？解決之道：混合部署，統一調度當前多數云服務商的虛擬機層與 Kubernetes 應用容器層的資源調度是相對獨立的兩層（往往將容器資源的調度疊加在虛擬機資源調度層之上），甚至缺省針對不同的租戶應用，需為其申請相對獨立的容器集群，從而導致無論底層不感知租戶應用類型的彈性虛擬機層，還是上層具備一定應用感知能力的容器層，其資源調度邏輯完全各自獨立，彼此互不相通，形成了過多的“云原生資源碎片與孤島”。為整合這些“資源碎片與孤島”，急需我們在云基礎設施資源調度層水平統一打通應用感知的K8S容器集群，以及更底層物理

54、機、虛擬機資集群調度，基于統一的資源視圖，實現多種類型云原生應用（CPU、內存、存儲 IO，網絡 IO 密集型，或其任意組合）在統一資源017云原生 2.0 架構白皮書池上的混合部署與統一并發調度，并進一步引入閉環的性能與 QoS 實時監控機制，從而驅動統一多維調度引擎在保障云原生應用性能的前提下，獲得更高的動態超分比資源利用率。挑戰 4：如何簡化運維復雜度、降低運維負擔的問題？解決之道：無服務器化（serverless）容器及微服務之后，云原生技術前沿已邁入 Serverless 無服務器時代。AWS 發布 FaaS（Function-as-a-Service）產品 Lambda 后，業界首

55、次提出了 Serverless。Serverless 是將應用程序（或其一部分）在遠程托管的執行環境中按需運行的架構，其不需要用戶維護自己的資源管理，甚至不需要構建與特定 OS 兼容的應用程序。FaaS 實質上是 Serverless 架構中以計算為中心的部分，可以構成其中的一部分，但不代表整個系統。Serverless 上的應用只需為實際運行代碼的時間付費。FaaS 早期以無狀態業務邏輯運行，對有狀態應用無法支持，因此出現了 Serverless 2.0=FaaS+BaaS（Back-end as a Service），需要將應用和數據服務均 Serverless 化，并充當計算邏輯的 Se

56、rverless 特征后端服務。當前 Serverless 在推廣中遇到一些問題，包括有限的編程語言支持、供應商鎖定、SLA 難以保證（尤其是冷啟動）、只涉及應用的部分而無法 cover 整個應用，因此長期會同傳統應用模式共存。對編程語言受限問題，考慮采用統一的后端語言級 VM 來支持；供應商鎖定可通過跨廠商的標準和模型互通來支持（參考 AWS SAM）；SLA 則可通過簡單的熱點代碼 Warm、以及 Serverless 平臺與資源層垂直優化來部分解決。挑戰 5：如何解決企業應用上云之后海量的結構化、半架構化及非結構化數據存儲格式各異，同一份數據多次重復拷貝，數據存儲與數據計算彈性需求不一致

57、所導致的資源浪費，可靠性保障水平參差不齊的問題？解決之道：存算分離，分層池化在云原生初期階段，數據庫、大數據普遍采用存算一體的部署方案，數據處理進程與數據存儲是耦合部署的，例如開源數據庫 MySQL 采用虛擬機加云盤的部署方式，數據庫進程只能訪問本地掛載云盤的數據，增加只讀副本需要拷貝一份完整的數據，各節點之間無法共享數據和計算能力；同樣，大數據開源軟件 Hadoop Spark 系列采用了 NDP（近數據處理）架構，大數據分析處理進程與 Hadoop 數據分片是緊耦合的關系，導致了大數據集群無法與云主機及云容器集群共享計算資源池，計算與存儲緊耦合的大數據集群始終無法與面向普通應用的云租戶計算

58、和存儲集群實現物理共享；此外，對于企業應用上云之后所產生的海量結構化 MySQL、PQ-SQL，半結構化 NoSQLCassandra MongoDB，以及搜索引擎 Elastic Search，圖數據庫 Noe4j，乃至非第一章|云原生概念與技術的歷史 018結構化數據對象存儲 OBS，分布式文件系統等，為解決其數據水平橫向擴展的問題，均各自采用了特定于其數據組織結構及查詢變更邏輯的數據冗余分片、分布式一致性處理，分布式 RAID/EC數據編碼，乃至持久化數據容災與恢復處理等邏輯，導致各類對海量容量及水平擴展能力，以及分布式可靠性容器保護能力的類型各異的持久化數據層采用了 N 套不同的技術機

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

60、據庫等，以統一的分布式高可用存儲引擎支撐所有上述數據形態的數據分片、無限制水平按需擴展、秒級快照及恢復、數十倍的存儲節點故障或擴容的并發數據重分布效率，乃至無鎖化的并發 IO 讀寫等，使得所有云原生數據集群服務（含結構、半結構、非結構化）無論在水平擴展性、性能、容災可靠性，以及業務不中斷數據平滑擴容的能力均獲得了高度一致的大幅提升。在計算層與存儲層分離后，計算層也在進行進一步的解耦即 CPU 資源和內存資源解耦。以分布式內存池的方式，提供像分布式存儲一樣的全局內存，使得 CPU 資源和內存資源也可以單獨的進行彈性擴展，對于數據庫、大數據等有狀態的云服務，可以將全局狀態卸載到全局內存池上，可以更

61、方便的實現計算節點之間的狀態轉移。云原生的“彈性按需擴展”架構能力主要聚焦于基于容器的無狀態應用業務邏輯，然而對于有狀態的應用事務、數據庫、大數據、消息與緩存中間件，互聯網應用雖有分表分庫等應用層與數據庫層配合的設計模式來實現有狀態應用的超大規模水平擴展，但隨著云原生存算分離數據庫、大數據，以及分布式事務技術的持續演進發展，使得企業應用系統的開發無需再關注任何與數據規模及其水平擴展能力問題，因為該層能力將完全卸載到持久化數據層。挑戰 6：如何解決企業數據治理平臺構建依然人工介入、效率低下的問題？解決之道：數據治理自動化企業將其應用事務處理及運營分析相關的數據通過數據庫、NoSQL，以及大數據平

62、臺匯聚到云上海量數據湖后，還需要經過一系列人工介入過程對各類數據資產進行標簽分配，并對存在質量問題的數據進行識別并觸發相應的清洗過濾，由此可見企業數據治理平臺的構建在當前嚴重依賴于大量人力的投入，為解決這一條件，最好的途徑仍然是用 AI 替代人力進行數據質量規則稽核、019云原生 2.0 架構白皮書查重、修復和數據豐富，自動生成數據資產之間的關聯、發現與標簽分類，以及自動識別個人隱私數據和數據安全保護等。從而將企業數據治理的效率及數據資產準確性與質量水平提升到一個新的臺階，滿足企業業務的數據消費需求。挑戰 7：如何解決云原生新開發應用，與各行業已有的非云原生應用，特別是非互聯網領域的政企傳統行

63、業 IT 應用的無縫互通及平滑演進的問題？解決之道：平滑演進，兼收并蓄千行百業的 IT 系統完成云原生的演進改造，顯然不是一蹴而就的過程，必將在相當長一段時間內，處于云原生應用與非云原生應用兼容并存的狀態，因此必須有機制確保云上與云下，云原生應用及其數據，非云原生應用及其數據，可以像原來在相同數據中心，相同軟件架構下一樣無障礙地彼此互聯互通及互相集成。挑戰 8：如何將誕生于互聯網的 DevOps 敏捷開發流水線能力，推廣引進到對產品研發質量及安全可信有更為嚴格要求的政府及傳統行業，以及讓行業的軟件開發效率不斷獲得提升？解決之道：可信、平民化 DevOps云原生 DevOps 敏捷開發流水線，源

64、自于互聯網在線業務的快速迭代開發，強調通過可定制的從需求管理、開發、編譯鏈接、測試驗證、上線發布、生產環境運維監控等所有軟件生命周期階段流程及流程活動自動化帶來開發節奏的大幅加快，及客戶需求響應敏捷度的大幅提升，然而其缺點和不足是在流水線上的安全及質量管控和加固的機制缺失，無法滿足很多傳統行業（如汽車制造、金融等）對其軟件開發質量與安全合規的嚴格訴求，因此如何構建可信的 DevSecOps，成為大企業應用與軟件生產現代化最關注的課題之一。另外，除 Full Code 的傳統軟件開發模式之外，各個行業也逐步積累沉淀了一些高于 PaaS 層、且行業特有的前端界面模板，及后端可重用業務邏輯/應用及數

65、據資產，這些資產能力通過高效的建模及編排，使得僅基于上述模板資產能力的編排及少量定制（低代碼/零代碼）即可實現行業應用的開發，從而使得行業應用效率得到大幅提升。挑戰 9：如何讓方興未艾的人工智能技術助力全棧云服務更好地服務于云租戶及云生態開發者，以及有效降低各行業開發者使用人工智能技術的門檻，更快捷地開發人工智能應用，并為行業生產力提升帶來核心價值？解決之道：全棧 AI 加持，全行業 AI 普惠第一章|云原生概念與技術的歷史 020云原生全棧能力的不斷成熟，打破了人工智能(特別是深度學習)與云計算、大數據之間的技術與商業壁壘，使其融合成為有機整體：大數據、人工智能均轉變可按需消費的云服務，云計

66、算為大數據分析和人工智能訓練與推理提供“統一算力”，大數據、數據庫則為人工智能提供“統一算據”，使得大數據、人工智能不再是成本高昂的“奢侈品”，加之人工智能技術近年來在計算機視覺識別、語音識別、自然語言 NLP、圖文 OCR、線性規劃最優次優求解、知識圖譜等領域的日益成熟及廣泛工程應用，使得 AI 技術無論面向全棧云自身的運維與優化效率提升，還是直接服務于各行業場景的運營優化與生產力提升，均蘊藏著巨大的潛能與無限的可能性。挑戰10：如何讓云安全不僅作為對外產品直接為租戶和開發者提供立體式的數據、應用、網絡及認證鑒權等安全服務保障，更能對內與全棧各云服務能力緊密協同，實現租戶端到端應用架構的安全

67、可信？解決之道：全方位立體式的云安全防護云原生對云安全能力的考慮，主要聚焦在容器化平臺及微服務治理框架范圍內，服務訪問合證鑒權，以及服務間互通的合法性、私密性保護相關的證書及安全憑證管理，缺少從網絡邊界、應用、數據、行業國家隱私、安全合規等全方位的云安全能力體系化設計，以及云服務及云上應用如何高效調用或適用這些云安全框架能力的設計模式與最佳實踐指導。企業仍主要依賴相對獨立和割裂的傳統商業化IT安全軟件及“基于防火墻硬盒子”來承擔企業IT免遭安全攻擊的屏障與保護層角色，但該安全防護模式顯然也越來越難以匹配與企業業務快速增長同步的潛在安全攻擊源和攻擊方式的隱蔽多樣化，以及多變性等特征，從而促使云安

68、全也走向安全多租化、軟件化，以及智能化的趨勢?？傊?，為突破上述千行百業 IT 云化發展歷程中面臨的一系列困難和挑戰，云原生正在迎來一場更為深刻全面、全棧、全場景的云化架構變革，這就是云原生 2.0。云原生 2.0 時代序幕拉開的第一個重要標志，是 CNCF 云原生社區技術與開源版圖的蓬勃演進發展，從最初的容器、微服務、DevOps 等技術領域，迅速擴展到如今的底層云原生基礎設施技術、編排及管理技術、云安全技術、監測分析技術、大數據技術、人工智能技術、數據庫技術以及場景化應用等眾多分支，初步形成了支撐應用云原生化構建的全生命周期技術鏈。同時細分領域的技術也趨于多元化發展，CNCF的云原生開源版圖

69、，由開始單一的容器編排項目 Kubernetes，發展到如今 5 大類 100 多個項目，Kubernetes 已成為云原生的操作系統，在其上發展出面向各行業、不同功能、不同應用場景的開源項目，Spark、Flink、Kafka、Redis 等開源項目也陸續加入 CNCF 的云原生技術圖譜，進一步完善了云原生技術生態，也引領云原生再次迎來了前所未有的發展浪潮，極大加速了云原生在全球范圍內的快速應用和發展。021云原生 2.0 架構白皮書而云原生2.0架構的商業價值與最終愿景，是面向千行百業（無論是孕育云原生的互聯網企業，還是呼喚云原生重構改造實現數字化賦能的非互聯網的政企客戶）的業務與應用開發

70、與運維團隊，提供涵蓋云原生基礎設施、數據使能、應用使能、AI 使能、視頻使能、企業應用數據集成、萬物互聯、企業辦公協同等在內的全棧數字化平臺能力，從而將全棧云優勢最大限度地發揮出來，將企業 IT 信息開發人員從云基礎設施、各類應用、數據、AI 等平臺中間件與使能組件的重復開發與日常運維管理等方面的繁重負擔中解放出來，并幫助企業從基礎平臺使能層構筑彈性敏捷自動化、水平彈性按需擴展、安全可信、韌性高可用高可靠等非功能的關鍵企業架構屬性能力，使得企業最終可將有限的精力和資金投入到核心業務競爭力上，從而實現數字化、智能化轉型中的投入產出效率最大化。圖 1-7 CNCF Cloud Native Int

71、eractive Landscape來源：https:/cf.io/第二章|云原生 2.0 的技術及架構特征022第二章云原生2.0的技術及架構特征023云原生 2.0 架構白皮書前文提到，伴隨著以企業應用及數據云化為手段的千行百業數字化、智能化轉型不斷走向縱深，為確保各產業及行業領域的客戶能更充分、全面地受益于云轉型所帶來的技術紅利，進而帶動相應產業及行業自身的升級換代及生產力變革，云原生技術迫切呼喚跨代際的突破和演進，云原生2.0 由此應運而生，以下就針對前文提到的云原生 2.0 關鍵特征，對云原生 2.0 的價值驅動及架構原則逐一進行解讀和闡述。2.1.1 趨勢與需求分布式云是將云服務分

72、布到不同物理位置，運營、治理和演進可由統一組織負責提供。當前業界的分布式云解決方案主要由公有云服務商提供，或由云服務供應商統一建設、交付、托管。使用分布式云，使組織能夠讓這些服務的物理位置更靠近本地，有助于支持低延遲場景、降低數據成本，并有助于遵守規定數據必須留在某個特定地區中的法律法規要求。隨著近年來企業數字化轉型不斷深入，企業云基礎設施的規模與復雜度快速提升，帶來的結果是自身 IT 團隊的大部分精力都投入到了基礎設施的管理與運維中。因此，分布式云通過管理平臺的集中部署和運維托管，可以使得組織不用管理自己的云基礎設施，從而專注于自己的業務本身。從地域覆蓋的角度看，分布式云應該充分覆蓋核心區域

73、、熱點區域、客戶機房、業務現場四個不同的區域，在不同的層次為用戶提供最適合的服務。從基礎設施的角度看，承載分布式云上層業務的基礎設施可以由單一廠商提供，實現單一云內的分布式架構；基礎設施也可以由不同廠家提供，并由上層云原生管理平臺在云原生服務層面形成統一的平臺，從而形成跨云的云際計算。但不管是哪種形式，其上層的云原生平臺都應該具備統一化、全局化的特點，形成統一的分布式云服務化平臺。Gartner 預測到 2025 年超過 50%的組織將在其選擇的地點使用分布式云。隨著移動終端及物聯網的技術發展和普及應用，以及企業業務的跨區域部署，從互聯網到政企客戶都產生了對分布式云的強烈需求?；诨ヂ摼W互動視

74、頻的創新業務，AR/VR/云游戲等，正在催生本地渲染的云基礎設施發展；另外低時延（OT 應用）、數據本地駐留（合規），本地數據處理（視頻監控）等政企應用，在催生本地計算的云基礎設施發展?；A設施部署將從集中式向分布式演進，實現云的最后一公里覆蓋。關鍵特征一：分布式云2.1第二章|云原生 2.0 的技術及架構特征024總結來說，分布式云發展的核心驅動力有如下幾點：低時延：為滿足低時延要求，需要在離業務現場最近的位置構建解決方案，減少業務處理時延，業務本地閉環。海量數據分析(帶寬優化)：5G/IoT 時代邊緣數據爆炸性增長，難以直接回傳至云端且成本高昂，數據在本地進行分析和過濾，僅回傳結果，節省網

75、絡帶寬，如 AI 推理、流分析等。安全隱私：數據涉及企業生產和經營活動安全，在邊緣處理企業保密信息、個人隱私。本地自治&交互：不依賴云端的離線處理能力、自我恢復能力；能夠與本地系統進行交互。按需提供服務：公共云的服務可以按需靈活部署在其他區域，無需鏡像公共云的所有服務，以節省資源開銷。2.1.2 關鍵特征與架構原則分布式云的核心是跨地理位置以及用戶可以將全部基礎設施交由公共云服務提供商進行運營和運維管理。在實施上具有全域協同的特征：1)服務協同服務協同主要指分布在不同地理位置的業務，可以進行微服務之間的協同。具體包括微服務跨邊云發現和通信，通信全鏈路進行路由、限流、熔斷等治理能力，灰度發布、金

76、絲雀、藍綠發布等典型發布流程。2)業務管理協同業務管理協同是指用戶可以在云端對邊緣側的復雜業務模型進行管理，以集中式的管理方式降低管理運維成本，提升人效。3)數據協同支持分布式云的數據同步、共享，能夠完成應用在不同位置分布式云之間的無縫銜接，滿足應用在分布式云上使用數據的一致性。4)資源協同構建統一的分布式資源調度機制，能夠根據分不同位置的分布式的能力、位置、業務運行狀態、資源使用情況，以及用戶的習慣和意圖，選擇合適的站點進行資源分配、容災編排；另外，在物聯網場景的邊緣計算中，提供云-邊-端的資源協同管理，在云端統一管理邊-端的節點和設備。資源協同的核心就是對節點、設備進行功能抽象，在云-邊-

77、端之間通過各種協議完成數據接入，在云端統一管理和運維。025云原生 2.0 架構白皮書1.分布式基礎設施企業上云過程對云的訴求是由多維度的因素驅動而產生，用戶的所在行業、經營的業務、產生的數據、處于的位置等因素不同會對分布式云基礎設施提出不同的要求。所以，就要求分布式云基礎設施在不同的地理位置，支持以不同的接入方式，提供不同的資源和服務以滿足企業多樣化的需求?；A設施架構從云位置的視角觀察可以劃分為核心區域、熱點區域、本地機房、業務現場，這些區域內的基礎設施定位不同，對外提供不同的資源、網絡、SLA 等規格。圖 2-1 分布式云原生圖 2-2 處于不同位置的分布式基礎設施分布式集群統一管理云原

78、生服務中心分布式管理調度全域流量控制分布式數據管理中心區域熱點區域客戶機房業務現場華為云基礎設施（CCE）第三方設備（CCE Agile/IEF）核心區域熱點區域本地機房中心Region邊緣數據中心企業邊緣站點企業專屬RegionAloT邊緣節點業務現場傳感器|OT設備|機器人|攝像頭|無人機|智能手機|VR.第二章|云原生 2.0 的技術及架構特征026敏捷和效率是分布式云原生為用戶帶來的核心價值之一，所以需要快速敏捷的響應用戶需求，滿足用戶位置和網絡多樣性的訴求，例如，自建 DC、CDN 機房、PSTN 機房，甚至是場館、辦公環境、公網、專線、骨干網等等。滿足基礎設施高效敏捷訴求的關鍵技術

79、手段：高度模塊化的交付設計中心，可以樂高式模塊化搭建，快速批量的完成站點設計?？删幣诺某壸詣踊魉€，跨領域協同、跨工具協同、快速批量的完成站點部署。開箱即用、極簡交付，軟硬一體化的全棧軟硬件預安裝，降低交付復雜性。分布式基礎設保持與公有云或公共云架構同源，提供分布式算力集中化管理的能力，例如，云硬件、云網絡設備、云平臺、運維管理平臺、管理 API 等。海量分布式云站點通過中心云進行統一管理運維，邊緣側站點架構需要輕量化部署，管理能力由中心云提供并納管，避免多頭管理和管理復雜化。通過分布式網絡技術例如（分布式PoP），用戶可基于不同業務對網絡質量的不同需求（時延、抖動、故障率、成本等）選擇合

80、適的網絡接入方式（BGP、單線、CDN 網絡）以獲取分布式云算力進而實現業務需求與網絡質量的最佳匹配。圖 2-3 分布式網絡技術就近接入上云Region AAZAZAZ網絡服務區分布式云站點A分布式云可用區ARAZRAZ分布式云站點ARAZRAZ邊緣網絡服務分布式云可用區BRAZRAZ邊緣網絡服務Region BAZAZAZ網絡服務區互聯網/專線互聯網/專線EdgePOPEdgePOPEdgePOPEdgePOPEdgePOPCentralPOPCentralPOPCentralPOP骨干網絡027云原生 2.0 架構白皮書圖 2-4 云廠商統一運維托管，用戶免運維2.分布式云原生如今越來越多

81、的企業為其業務發展采用了多個云提供商，更多的云平臺意味著更多的復雜性。多云容器平臺為客戶提供集群資源集中管理的統一入口，幫助客戶從這些復雜性中跳脫出來。因此，需要通過多云治理對客戶本地數據中心以及各個云廠商的私有云、公有云的資源以及 Kubernetes集群進行統一納管，實現對異構資源的統一規劃、分配、調度、監控、運維等管理操作。分布式云原生包含如下技術：1)統一分布式云治理在分布式云中，業務分布式化以滿足分散部署的業務需求，管理則需要集中以降低管理成本。因此將分散至各處的分布式云基礎設施進行中心式的統一管理是非常重要的特性。對分布式云進行統一管理需要提供多基礎設施注冊、連接、統一認證、分區管

82、理、統一訪問、統一配置，合規治理等能力。用戶免運維，云廠商集中提供運維服務集中運維服務平臺云服務運維數據分布式云云服務分布式云云服務第二章|云原生 2.0 的技術及架構特征028隨著業務的發展，業務運行環境日益復雜，環境已經擴展到多數據中心，多云以及邊緣。每個環境都有自己獨立分散管理工具，客戶學習成本和操作復雜度都比較高。通過提供一致的多云和本地管理平臺來簡化治理與管理。通過統一認證將不同的環境的訪問控制進行統一。通過統一訪問將零碎的訪問入口進行統一，提升運維開發效率。通過統一配置確保應用程序和集群在大規模部署時保持一致性。通過合規治理滿足數據治理和安全要求，并有效地管理資產。2)全局應用調度

83、在多云多集群中部署時，應用具備根據一定的調度規則在不同的云中進行調度和遷移的能力。支持按權重部署，根據不同集群的權重設置自動計算和分發實例；根據 label 進行條件部署，通過集群 label 進行組合條件的設置，并根據條件的滿足情況進行實例分發；容器從故障集群中自動遷移，當集群發生故障時，位于該集群中的應用實例可自動遷移至正常集群中；跨集群彈性伸縮，當需要對應用進行整體伸縮時，可根據不同集群的權重進行實例分配，實現用戶優先在指定云上創建新資源的目的。另外，資源調度器根據全局資源的狀態和網絡 QoS 統計信息為每個租戶/域名決策資源分布。分布式云用戶在使用云資源時，由于無法掌握全局的動態資源信

84、息，當前只能靠人工經驗指定位置要求固定的資源容量。這樣對于用戶，沒有辦法獲取到最優質的資源改進業務服務質量，同時也缺乏應對業務突發的彈性手段。全域資源調度器，可以幫助用戶即時掌控全域資源狀態信息，包括動態的邊緣站點可用資源、臨近公有云資源以及優質的5G MEC資源，滿足用戶對服務(例圖 2-5 分布式云原生基礎設施統一管理公有云注冊連接合規治理統一訪問分區管理統一認證統一配置分布式云原生基礎設施統一管理邊緣云邊緣節點用戶IDC029云原生 2.0 架構白皮書如網絡時延)的要求，同時在保證整體 QoS 最優下，可以針對成本、服務質量、業務波動做針對性優化。資源調度的關鍵點是全局資源視圖和資源調度

85、算法。資源視圖包括用戶的位置、資源的成本、網絡的 QoS、接入的地理位置等。全域調度算法的設計會考慮任務的 QoS 要求、親和性、等待時長等一系列要求。另外還會基于利用率的評估，給用戶一些低價資源和突發性實例推薦，使租戶可以更好的優化自己的成本。圖 2-6 全局應用調度全域資源調度全域流量調度網絡QoS測量分析（全局裸機、容器（Node級別）、VM）位置分布算法成本優先算法邊緣節點/5G MECRegion（中心云）IOT/終端活躍IP探測QoS建模分析時延敏感算法地理就近接入時延優先接入負載感知切換云邊全局流量協同控制器智能DNS/HTTP DNS故障就近轉移多目標求解器3)全域流量調度據資

86、源的預留分布，流量調度器在流量級進行精細化調度。在給定資源分配的情況下，流量調度為用戶的每一位客戶決策流量的分配位置。流量調度具有與業務高度相關的特點，針對不同業務的類型，流量調度的方法各不相同。例如，CDN 業務中，流量調度要同時支持接入調度和回源調度，且調度算法的設計需要考慮到內容緩存策略的影響。云游戲業務中，流量調度只需要支持接入調度即可。流量調度的關鍵點是精準控制和調度執行器。全局優化器基于歷史數據完成流量粗粒度的流量規劃以保障基礎水位均衡，并基于分鐘級的流量特征學習，決策控制周期和分配策略，對流量進行全局性的優化。實時調度器負責針對每個區域租戶請求的毫秒級響應，執行、切換調度策略，并

87、當發生故障時，及時完成故障轉移。華為云當前的全域流量調度，支持多種策略的選擇，并基于流量的數據特征，充分發揮全局優化和區域靈活控制的特點，實現精準調度。第二章|云原生 2.0 的技術及架構特征0304)流量跨云協同流量跨云分發包含北向用戶訪問流量和東西向微服務間交互流量兩種。在北向流量的跨云分發中，通過 GSLB 技術，實現用戶流量的就近接入，同時具備對后端服務健康檢查的能力，自動屏蔽故障服務實例后端。另外，通過服務網關進行入云流量治理。服務網關部署于每個分布式云成員的流量入口處。接收網格控制面的配置，提供跨 Region、多云混合云、多種基礎設施的服務后端實例上的流量管理。包括但不限于：基于

88、權重和內容的流量切分、灰度、故障倒換、熔斷限流等。東西向微服務間流量交互，依賴于在多云多集群中建立安全可信的通信通道，VPN、wildguard 是這里的常用技術。另外可通過地址映射和轉換等方式處理多云中子網沖突的問題。在跨云網絡互通基礎之上，可以疊加 Service Mesh 技術實現東西向流量的治理能力。5.)數據協同數據跨云協同是指以應用為中心構建應用的克隆、遷移和容災能力。數據包含應用配置數據和應用業務數據?；诙嗉汗芾恚ㄈ?armada）平臺或云原生備份插件實現跨集群的配置數據的跨集群、跨 AZ、跨 Region、跨云數據協同能力。業務數據面對的場景比較復雜，整體可分為三層，也即：

89、基于存儲基礎設施的跨云數據協同：是指基于相同基礎設施的場景下，利用存儲基礎設施的數據同步復制/異步復制能力，構建同 Region RPO=0，跨云/跨 Region RPO 15 分鐘的數據容災能力。圖 2-7 全域流量調度邊，線，狐有費用，容量，時延等點、節點目的始發1613104912147204420135流找“可行”或“最優”路徑，考慮到量、成本、QoS等約束，可能有多路徑。031云原生 2.0 架構白皮書 基于云原生基礎設施的跨云數據協同：是指在云原生應用管理平臺（K8S）場景下，通過存儲抽象(PV/PVC)屏蔽存儲基礎設施的差異性，實現統一架構的跨集群、跨 AZ、跨 Region、

90、跨云數據協同能力?；趹弥虚g件生態的跨云數據協同：是指通過中間件生態平臺（如：OSC）提供通用的數據協同的接入定義，與中間件應用提供商一起構筑跨集群、跨AZ、跨Region、跨云數據協同能力。圖 2-8 數據協同MM存儲基礎設施數據備份存儲庫數據恢復中間件生態平臺數據協同存儲基礎設施存儲基礎設施1232.2.1 趨勢與需求隨著云計算的發展，越來越多的應用已經云化部署，從早期的微服務，到大數據/AI，再到中間件，這些應用也對云基礎設施不斷提出新的要求。微服務是云化部署的典型應用，根據用戶的使用情況，微服務對資源的請求會有較大的波動，需要云服務提供足夠的資源，并能夠快速啟動實例；同時，為了保障用

91、戶體驗，對時延及 SLA 也有較高要求。大數據與 AI 技術為企業提供智能化，幫忙企業應對復雜的商業環境；但大數據與 AI 業務不僅對資源性能有較高要求，而且資源需求增漲速度較快，因此需要云服務提供大量高性能資源。中件間對資源的穩定性和性能也提出了較高的要求。關鍵特征二：應用驅動基礎設施2.2第二章|云原生 2.0 的技術及架構特征032大規模的網絡資源供應、泛在的網絡安全隔離、極致的網絡彈性和細粒度的網絡 QoS 是承載大規模云原生業務的基礎網絡要求。資源供應方面，單 VPC 內多集群的容器端點數可以達到甚至超過百萬，災備場景的集群遷移要求容器級的網絡配置、隔離，例如 QoS，帶寬限速大批量

92、容器快速發放（10 萬/分鐘）；網絡彈性方面，Serverless/Function 等輕量級云原生運行時的要求毫秒級創建，秒級冷啟動（包含網絡端到端打通）；安全隔離方面，無邊界、零信任、海量端點和高動態性的云原生網絡安全，要求即時生效的容器粒度安全隔離與 ACL；資源力度方面，在/離線業務混部場景下，為了能夠發揮出云原生極致資源利用率和性價比，要求容器網口粒度的QoS（包括帶寬保障和優先級支持）。不斷變化的云原生業務訴求正推動著云網絡架構的不斷演進。2.2.2 關鍵特征與架構原則在云計算早期，通過架構分層為應用提供了靈活的基礎設施以滿足應用的多樣性；進入云原生時代以來，以容器、微服務以及動態

93、編排為代表的云原生技術蓬勃發展，面向應用形成了統一的行業標準，為軟硬協同、統一調度等能力提供了基礎。云原生 2.0 以后，企業云化從“ON Cloud”走向“IN Cloud”，網絡、存儲等基礎設施都面向應用做進一步優化，并催生了服務網格等新技術。1.軟硬協同：通過軟件卸載、硬件直通等技術，借助硬件的高性能為應用進行加速，從而達到降本增效的目的隨著越來越多的應用運行云化部署，各種應用對云基礎設施提出了更高的性能、穩定性及時延要求。為了應對這些新訴求，面向應用的軟硬協同技術應運而生；軟硬協同系統包含從芯片、硬件到軟件的全棧技術創新，例如共享存儲、高帶寬等。同時，隨著 5G 建設加速，5G 的低時

94、延、大帶寬等能力也在催化各行各業孵化創新應用，完成數字化轉型。典型的，互聯網行業，這是一個技術迭代特別快的行業，新的云游戲、云 VR 等互聯網應用對時延性能、確定性保障的要求會更高。政企行業，客戶則會更關注安全可信等合規保障，自身計算資源的利用率等效能優化情況。通過深度軟硬協同能力，為客戶提供了近裸機體驗的強勁性能、虛機/容器/裸機等多級計算粒度，和云上最豐富的算力。技術上，硬件卡是實現軟硬協同的關鍵。從圖中可以看到，之前運行在服務器內部的存儲、網絡、管控等能力，全部卸載至硬件卡實現，并進行芯片加速。033云原生 2.0 架構白皮書圖 2-9 虛擬化演進虛擬化1.0-2003發源于實驗室：純軟

95、件虛擬化VMVMBT/PVServerVMIBM 360斯坦福-Binary Translation劍橋-Para Virtualization虛擬化3.02018-計算存儲網絡Server硬件卡VMVMVM軟硬協同前后端硬隔離，簡約不簡單前端自研Hypervisor，打掉一橫、保留一縱資源“0”預留，虛擬化“0”開銷，業務“0”抖動，算力“0”損失后端硬件實現I/O卸載加速Virtio虛擬化語義硬件實現，前向無縫透傳VMlibvirtV qemu卸載，后向無縫接入云管控、云存儲、云網格存儲、網格卸載加速，性能硬隔離虛擬化2.02004-2017計算存儲網絡ServerVMVMVMKVM/Xe

96、n：硬件輔助虛擬化CPU硬件輔助虛擬化CPU虛擬化：VT-x實現CPU虛擬化，開銷較大Mem虛擬化：EPT實現內存隔離，開銷極小I/O虛擬化：VT-d、SR-IOV技術引入生態和彈性問題I/O性能飆升，成本高昂Workload干擾，業務抖動算力損失虛擬逃逸軟硬協同降低了之前通過軟件實現網絡、存儲等功能產生的 CPU 開銷，并通過芯片實現全IO 路徑的性能加速；例如，基于擎天卡與華為全棧自研的 CurreNET 網絡技術，實現 VF 直通與網絡零拷貝，時延可低至 10us。計算虛擬化：在計算虛擬化方面，通過硬件卡實現了 IO 虛擬化等能力，主機側僅保留了CPU 和內存的隔離和映射，最大限度將對虛

97、擬機的擾動降到最低；并通過動態調頻技術，讓每臺主機可降低能耗，實現效能極優。通過安全芯片，可確保主板固件零篡改，實現主機的安全啟動；最后，通過安全芯片與硬件卡構成的安全系統，將傳統依靠軟件來實現的身份證明，通過硬件實現密鑰保護，真正做到硬件身份證明，進一步確保全流程零差錯，做到安全可信。網絡虛擬化：在網絡虛擬化方面，為了避免大規模高速網絡環境下存在的擁塞情況，基于硬件能力實現了新的算法穩定擁塞控制，支撐更大組網規模提升，大幅降低長尾時延?；谟布▽?RDMA 網絡應用于虛擬機，為 HPC 高性能計算等場景帶來更強性能，與更高性價比。更進一步，除了性能、安全、能效方面的創新，通過軟硬協同也將實

98、現租戶業務的穩定和確定性 QoS。網絡通過虛擬機、網卡的兩級硬件 QoS，保障了虛擬機帶寬、PPS、會話連接數等多維度的確定性，更通過 Bucket 桶資源做到上限反壓時不丟包。存儲虛擬化：在存儲方面，將 DIF 校驗、EC 算法等過程也通過硬件卡來實現，在大幅降低時延的同時獲得較高的帶寬，可以大幅提升數據庫、AI 訓練等場景效率；除了性能外，安全芯片也幫助應用做到從主機啟動到 IO 處理等全流程的安全可信。在數據加密方面，一般傳統第二章|云原生 2.0 的技術及架構特征034軟件方式加密存在 10%20%左右的性能損耗；將加密的流程卸載至硬件卡后，實現了加解密過程的硬件加速，讓用戶基本感知不

99、到因加密帶來的性能損耗。2.云原生網絡：云原生網絡面向應用進行優化，將虛機網絡加容器網絡進行歸一，由多層變一層，提供高性能網絡；同時，通過服務網格(Service Mesh)解決應用的服務治理問題1)基礎網絡：以應用為中心，重構更加快速的，全新的云原生網絡很多客戶的業務對時延有較高的敏感性，尤其是短連接的 TCP 應用，因 TCP 建鏈需要多次報文交互，對首包時延非常敏感，比如游戲登陸平臺，在玩家登陸的時候，需要和數據庫進行數據交互獲取玩家賬號相關信息，首包時延大不僅影響玩家登陸體驗，同樣也會影響整個游戲登陸系統支持同時登陸玩家數量的能力?；谠?openstack 架構的數據面存在慢路徑問

100、題，通常情況下首包時延比后續建鏈后的報文時延高；下一代數據面在保證兼容原生openstack系統的基礎上，需要進行轉發路徑優化，所有報文不再有快慢路徑之分，從而降低首包時延。同時，客戶業務系統部署上云時，為了提高業務系統可靠性，一般會采用集群模式部署，其中很多系統需要通過主備集群模式來部署，典型如 RDS 數據庫、自建 NAT 服務器等，這就要求云上的平臺能支持便捷、高效的主備倒換能力。一般情況下，通過 VIP 或從網卡提供主備倒換能力；但 VIP 因底層實現方式差異，整體轉發能力比正常虛擬機網卡差；并且后續的 IPv6 VIP 也需要通過 API 切換，從網卡遷移會導致內網 IP 丟失等問題

101、。通過動態 IP 綁定彈性網卡(ENI/subENI)后，同時具備了私網及公網能力，彈性網卡在虛擬機間遷移，即可完成私有 IP 和公網 IP 的同時遷移。如下圖所示，可以支持三種遷移方式：EIP+ENI 遷移 EIP+subENI，跟隨 ENI 一起遷移 EIP+subENI 遷移 圖 2-10 遷移方案IPIPIPIPIPIPIPIPIP安全組2主網卡（subnet1）從網卡（subnet2）安全組1ECSECS安全組2安全組1安全組2安全組3VIPsubnet1VIPsubnet1ENI（subnet3）subENIsubnet1subENIsubnet1ENI（subnet1）subEN

102、Isubnet1subENIsubnet1更獨立的安全控制更多的IP地址規格035云原生 2.0 架構白皮書2)服務網絡：全新的應用級網絡，全面提升應用的治理能力隨著越來越多的應用進行云化部署，對各個服務之間的治理以及灰度發布等能力提出了更高的要求；目前基于流量、LB 等組件已經無法滿足大量微服務的訴求。為了應對服務治理及灰度發布的需求，業界引入了服務網格這一技術。服務網格以一種更加解耦的方式將服務治理能力變成獨立進程，對應用的訪問進行非侵入管理。在大部分容器場景下，通過容器部署形式再應用容器啟動過程中，將服務治理進程作為獨立容器注入到應用 Pod 中，并攔截出入應用的流量。從這里看出：網絡上

103、額外增加了兩跳，通信時延勢必有所增加。同時每個數據面代理自身的七層數據代理能力也對端到端請求處理的時延有較大影響。數據面代理和客戶應用部署在相同的主機空間內，一旦主機 CPU 使用率較高時，分配給數據面代理的時間片將會減少，這樣導致路由選擇和轉發率下降，更多應用發出的請求將被堆積，導致整體時延顯著增加。并且由于主流數據面代理為 Pod 內部署形式，無法進行綁核等操作，基于現有架構較難解決。每個 Pod 內都需要部署一個數據界面代理進程，實測每個代理將占用 70MB 以上的內存空間，因此實際分配給應用的內存將達不到需求獲知導致主機內存利用率較低。數據面代理運行在主機空間，多租環境下擁有節點登錄權

104、限的用戶有機會查看其他應用代理的運行狀態、攔截數據面通信網絡流量或下發額外的配置給其他應用的數據面代理，對節點內數據安全保障造成一定的風險。引入節點共享數據面模式，將節點內每個 Pod 內的 Sidecar 移到節點上進行整合，消除每個 Pod 內 Sidecar 額外內存占用。節點上共享數據面形成高可用，自動識別網格流量類型并進行攔截，對不同業務進行 QOS 連接保障。另外分離數據面代理與業務應用的生命周期便于對數據面代理自身所使用的系統資源進行預先規劃，同時可以利用節點內提供的其他硬件加速能力。優化應用到數據面代理之間、本節點數據面代理與其他節點數據面代理網絡通信。采用sockmap、用戶

105、態協議棧、RDMA 等技術進一步降低高并發連接情況下端到端網絡時延TP90 及提升吞吐 QPS。優化數據面代理自身線程模型提升網絡事件響應效率，優化連接調度減少工作線程對連接處理的不均衡問題降低端到端網絡時延 TP90?；谄邔泳W格數據面代理的硬件卸載，隔離用戶空間對數據面代理的訪問，保障節點內網格流量及網格運維的安全。進一步整合智能網卡內計算加速能力及協議棧硬件加速能力，同時就近集成大云環境下其他網絡通信特性。第二章|云原生 2.0 的技術及架構特征036引入共享數據面模式后，對于規格較大的節點內存資源消耗有較大的降低；預先綁定數據面CPU/NUMA 等資源后，代理效率提升明顯，減少端到端調

106、用時延；節點內流量采用 sockmap 端到端降低網絡時延；優化數據面代理自身線程模型及連接調度。3.云原生存儲：云原生存儲面向應用進行優化，通過獨立的存儲網絡通道解決網絡通道上限、性能折損和資源開銷等問題；并提供應用級的備份/恢復、遷移、數據監控等能力容器存儲面臨著共享存儲網絡讓吞吐受限，虛擬化讓性能折損和資源開銷增加等問題。多個塊存儲共享節點上存儲網絡通道，讓性能受限、時延增加。性能越高的塊存儲，虛擬化帶來的性能折損越明顯；文件存儲通過 virtio 技術共享給容器使用，疊加的虛擬化層讓存儲性能折損和資源開銷增加。云原生存儲將為每個 pod 分配獨立的存儲網絡通道，該 pod 中所有的容器

107、使用的塊存儲都掛載到該網絡通道上，解決了共享網絡通道上限、虛擬化/疊加虛擬化增加性能折損和資源開銷問題。塊存儲直通到安全容器中，業務負載對塊存儲的 IO 請求直接通過該通道交給卸載卡組件處理，大大降低了時延，也避免共享網絡通道上限的問題；文件存儲直接掛載到安全容器中，略去 virtio 虛擬化層，提高請求效率，提升請求處理效率。另一方面，隨著云原生技術的不斷成熟，基于 K8S 容器平臺的云原生應用快速增長?，F有容器存儲的解決方案面臨著云原生應用的跨集群遷移、緩存加速、完善的數據駕駛艙能力。通過Operator 機制構建云原生數據管理、云原生緩存、云原生監控能力，為云原生應用提供 K8S 元數圖

108、 2-11 Service Mesh來源：https:/ Mesh Control PlaneInstanceASidecarProxySidecarProxySidecarProxyInstanceBInstanceCControlPlaneData PlaneEast-WestTraffic037云原生 2.0 架構白皮書2.3.1 趨勢與需求在云計算早期，當應用進行云化部署時會根據應用的需求選擇不同的算力類型和粒度，并進行單獨規劃；煙囪式的部署極大的影響了資源的使用效率，同時也給應用的運維帶來了極大的不便。進入云原生時代以來，以容器、微服務以及動態編排為代表的云原生技術形成了統一的行業標

109、準，將不同應用統一到云原生標準下；智能調度等技術為應用提供了統一的資源池，讓多種應用可以混合部署，并與資源高效協同。2.3.2 關鍵特征與架構原則1.混合部署各種應用進行云化部署后，通過將所有應用混合部署在同一資源池中，并根據應用的不同屬性及資源請求，最大限度的復用資源，提升資源使用效率。同時，當多業務混合部署后，為了保證各個應用的服務質量，需要操作系統提供較強的資源隔離能力。企業核心業務全面云原生化后，降本增效和運維成本是困擾企業的主要難題。以應用為中心的調度是解決這些難題主要的途徑之一；通過面向應用的調度，可以在同一集群內支持多種不同的應用類型，借助業務資源請求的互補性可以大幅提升資源的使

110、用率；通過支持大規模集群，可以將大量的應用提交至同一的集群中，從而減少應用的運維成本。大規模場景下，基于共享視圖的并行多調度器架構，大幅提升集群整體調度的吞吐率，實現萬級任務并發。通過任務拓撲感知調度、網絡 IO 感知調度、NUMA 感知調度等多種應用和硬件感知調度技術，滿足不同類型應用模型對資源的訴求，為應用匹配最佳的資源。通過多業務類型的分時復用、混合調度、資源的超賣、隔離技術，減少集群資源的空閑比例，實現集群全時段資源最大化利用。關鍵特征三：混合部署，統一調度2.3據和 PV 數據卷的一鍵式備份/恢復、跨集群克隆/遷移、近算緩存加速和數據監控能力。松耦合、插件式、按需部署的備份/恢復、克

111、隆/遷移、監控/采集等插件集合：為云原生應用提供應用備份/恢復、應用克隆/遷移、應用數據監控能力。第二章|云原生 2.0 的技術及架構特征038不同的應用對性能有不同的需要，針對性能敏感型應用需要為其提供性能保證，而且對于普通型應用，僅需保證其有只足夠的資源量。為保證性能敏感型應用，需要在操作系統層提供隔離搶占技術，該技術涉及的資源包括 CPU、內存、網絡和 IO 等等，針對每一種資源，需要結合已有隔離技術來應對混合部署場景下的新需求。在離線混合部署對的資源的需求可歸納為兩點：對于使用分配情況優先供應給在線任務，對于回收情況優先從離線任務回收資源。圖 2-12 混合部署GPUDevicePlu

112、ginYangtseAgentedpfedpfedpf代碼注入QoS（優先級，流控）路由、轉發流觀測服務加速vNICEVSNIC/ENIiGPUCPU 調度策略調度網絡策略PodHost OS（openEuler/CentOS）Kubernetes 節點2.統一資源池越來越多的應用云化部署，希望云服務可以提供統一、無限的資源，從而減少資源申請及管理的復雜度，提升運維效率，快速應對業務峰值等需求。應用云化部署以后，統一的資源池將用戶從服務器的管理中解放出來，用戶只需要專注于自身業務。統一資源池為應用屏蔽了基礎設施，提供了自動化的運行環境、隨時按需使用、按實際用量計費的能力。目前大部分的云服務廠商

113、仍依據成本，用戶量等因素在不同的地域（Region）建設資源，用戶再根據業務、成本、性能等因素選擇相應的 Region 提交作業，不同 Region 的網絡時延、資源成本、數據就近訪問成為跨 Region 作業管理的難點。全域調度是面向跨 Region 場景的下一代統一調度，不僅能夠通過全局資源的調配來達到降本增效的目的，還能將用戶從多039云原生 2.0 架構白皮書Region 的管理與運維中解放出來，讓客戶聚焦到業務本身，提供真正的統一資源池體驗。全域調度維護的全局資源視圖包含了各 Region 的資源分配和使用情況、數據位置、地理位置、網絡時延、資源成本等信息，并通過資源、網絡成本最優，

114、跨 Region 時延最優，就近接入、數據親和等全域調度策略最大化資源使用率，為應用提供全網資源。在統一資源池以前，用戶為了保證服務的穩定性和性能通常按照波峰申請資源，大量的資源會在波谷期閑置，據第三方機構統計，大多數在線服務集群的平均使用率低于15%；而另外一方面，對資源消耗量非常大的大數據、AI、HPC 作業，資源常常到不到滿足；資源無法統一規劃和使用?；诮y一資源池，可以將用戶提交的 Web 應用、大數據、AI、HPC 作業根據其對資源的訴求和負載情況，優化調度方式，提供資源搶占，分時復用等機制減少集群資源的空閑比例。通過作業混合部署和資源超賣的方式，實現集群資源利用率的提升。作業進行統

115、一調度，在資源真正發生競爭之前進行規劃。同時提供諸如：節點資源監控，資源超賣，動態調度，離線業務重調度等功能。操作系統層面，支持在 cgroups 中進行物理資源隔離，資源發生競爭情況下，根據任務的優先級，保障高優先級任務不受影響，降低對低優先級任務傷害通過在離線作業混部，提升集群物理資源使用效率。當在線作業壓力較低時，節點上物理資源的使用率較低，調度器進行資源超賣，將離線作業調度到相應的節點上運行。當在線作業壓力變大時，調度器驅逐掉當前節點上的離線作業，保證在線作業能夠正常運行。3.多維度調度隨著應用的多樣化，對調度也提出了新的挑戰；要求云服務從應用、資源以及流量等多維度進行業務調度，在滿足

116、服務質量的同時，最大限度的降低成本，提高資源使用率。隨著應用以及計算資源的增多，云服務需要引入多維度的調度來提升資源的使用率，從而降低成本，提高應用穩定性及性能。因此，云計算規模發展和計算資源多元化趨勢，在資源有效利用、資源成本控制等方面對云提供商的資源供應提出了更高的要求，打造算力池化、技術棧統一、數據自驅的多維度資源管控平臺成為了技術發展的必然選擇。多維度資源管控平臺具有以下特點：資源調度：多維資源調度統一計算節點技術?；A，并在調度方面實現資源分層、協同調度。資源池調度系統屏蔽多元化算力資源差異，在資源池化基礎上完成在線資源調度、離線資源整理、資源自適應調整等功能，通過精細化調度實現資源

117、利用率的有效提升。問題建模、求解：使用統一的問題建模語言，應用統一的問題求解框架，解耦問題建模與算法求解過程，成為了一個趨勢。數據自驅演進：超大規模資源的管理和高效利用，高度依賴實時、自動化、智能化的數字化管理能力，為系統架構、功能的長期演進提供數據支撐。第二章|云原生 2.0 的技術及架構特征0402.4.1 趨勢與需求從 2006 年云計算初現端倪，到計算虛擬化、網絡虛擬化、Openstack 等技術層出不窮，第一個階段主要改變的是基礎設施管理的工作方式，從繁重的機房建設和維護工作中解放出來。云廠商提供虛擬服務器和網絡等資源的供給服務，讓用戶將應用從物理服務器遷移到虛擬服務器上，實現資源云

118、化，從而降低資源管理成本。隨后，Docker 容器、Kubernetes 等技術逐步流行，并出現了如 Spring-Cloud、Dubbo 等基于云服務的云原生開發框架，云廠商通過提供容器、代碼控制管理、編譯流水線、自動化測試、中間件等工具，實現應用環境標準化、實踐 DevOps、簡化應用遷移與托管，提高編排和運維效率。2015 年，AWS 發布 Lambda 標志著 Serverless 理念的 FaaS（Function-as-a-Service）函數計算模式出現，旨在屏蔽服務端的復雜配置和運維，簡化云開發以聚焦業務邏輯，改變開發人員的工作方式。Serverless 理念讓應用構建與云服務

119、深度結合，以發揮云平臺彈性伸縮、按需計費、免運維等能力，實現松耦合、快速上線、高性價比的現代化應用，從而降本增效。2019 年，各大云廠商開始積極擁抱 Serverless 理念，并推出多樣化的產品，總體而言，Serverless 應該具備的三個基本要素：提供一個小顆?；虼箢w粒的抽象，隱藏服務器以及編程和操作服務器的復雜性。提供現收現付成本模型，而不是基于預訂的模型，因此閑置資源不收費。自動、快速和無限擴展資源，以緊密匹配需求，從零到幾乎無限。一方面，Serverless 為用戶屏蔽云端復雜度，簡化云應用開發、托管和運維，提高應用開發上線效率，提供資源按需計費模型，降低應用部署和運維成本；另一

120、方面，云廠商通過 Serverless更靈活的管理閑置資源，提升系統資源利用率，實現用戶和云廠商雙贏。2019 年，加州大學伯克利分校在 Cloud Programming Simplified：A Berkerley View on Serverless Computing 的回顧中總結到，當前的云平臺在簡化運維和提升硬件利用率上仍然無法讓人滿意。因為開發者還需要管理虛擬機的可靠性、負載均衡、容災、擴容和縮容、監控、日志及系統升級，挑戰仍然較大。尤其規模較小的企業，很難雇傭到熟練的運維或 DevOps 人員，無法通過自動化工具、腳本、服務來解決這些問題。伯克利大學指出 Serverless

121、有望彌補這些不足。Serverless 弱化了存儲和計算之間的關系，使計算變得無狀態、調度及擴容/縮容更容易、數據更安全。開發者不再需要手動創建虛擬機或管理其他資源（網絡帶寬等），只需要專注在業務代碼開發上。同時，函數根據調用次數和每次計算的資源開銷來計費，更加合理。關鍵特征四：無服務器化（Serverless）2.4041云原生 2.0 架構白皮書2.4.2 關鍵特征與架構原則從開發者或商業的角度看來，Serverless 的價值在于全托管及創新的計費模式。但從技術的角度看，Serverless 從架構、開發模式、基礎設施等層面都呈現出區別以往的特征：1.Serverless 是事件驅動架構

122、的延伸Serverless 更容易實現事件驅動的應用。在分布式系統中，請求/響應的方式和事件驅動的方式都存在。請求/響應是指客戶端會發出一個請求并等待一個響應，該過程允許同步或異步方式。雖然請求者可以允許該響應異步到達，但對響應到達的預期本身就在一個響應和另一個響應之間建立了直接的依賴關系。事件驅動的架構是指在松耦合系統中通過生產和消費事件來互相交換信息。相比請求/響應的方式，事件的方式更解耦，并且更加自治。例如，在圖片上傳后進行轉換處理的場景，以往需要一個長時運行的服務去輪詢是否有新圖片產生，而在 Serverless 下，用戶不需要進行編碼輪詢，只需要通過配置將對象存儲服務中的上傳事件對接

123、到函數即可，文件上傳后會自動觸發函數進行圖片轉換。Serverless 架構的基本單元從微服務變為函數。微服務的每個 API 的非功能屬性有差異，比如對性能、擴展性、部署頻率的要求并不相同，進一步拆分的確有助于系統的持續演進，但相應會帶來指數級的服務數量增長，導致微服務的基礎設施和運維體系難以支撐。Serverless 架構可以將微服務的粒度進一步降低到函數級，同時不會對基礎設施和運維產生新的負擔，只是增加了少量的函數管理成本，相比其帶來的收益是完全可以接受的。2.Serverless 簡化了開發模式微服務提供了豐富的框架，方便開發者進行開發，但同時也增加了開發者的認知負擔，同樣是使用 Jav

124、a，基于 Serverless 開發服務，開發者只需掌握 Java 的基礎特性、函數編程框架及BaaS 的 SDK 即可，如下圖所示：圖 2-13 serverless 開發分布式事務SpringCloudSpringDataSpringBootSpring框架（loC，AOP）Java并發編程Java基礎語言特性/API分布式事務BaaS SDK函數編程框架Java基礎語言特性/API分布式事務BaaS SDK函數編程框架Java基礎語言特性/APICircuit Breaker ConfigOpenFeign Commons.第二章|云原生 2.0 的技術及架構特征042函數的編程框架相比

125、 Spring/SpringBoot 要簡單很多，開發者只需了解輸入輸出處理（通常為JSON）及如何處理業務邏輯?；诤瘮档木幊棠Ｐ?，可以繼續對數據進行抽象操作。3.Serverless 是不可變基礎設施的最佳實踐Serverless 直接以代碼方式部署，開發者不用再考慮容器鏡像打包、鏡像維護等問題。系統通常在部署時重新創建函數實例，在不使用時回收實例，每次處理用戶請求的可能都是全新的實例，降低了因為環境變化出錯的風險。而這些部署及變更的過程，對用戶來說只是更新代碼，其復雜度相比使用容器及 Kubernetes 大大降低。Serverless 在擴展性方面也具有優勢。FaaS 和 BaaS 對

126、開發人員來說沒有“預先計劃容量”的概念，也不需要配置“自動擴展”觸發器或規則?？s放由Serverless 平臺自動發生，無須開發人員干預。請求處理完成后，Serverless 平臺會自動壓縮計算資源，當面對突發流量時，Serverless 可以做到毫秒級擴容，保證及時響應?；?Serverless 的服務治理也更簡單。例如，通過 API 網關服務可以對函數進行 SLA（服務水平協議）設置限流，函數請求出錯后會自動重試，直至進入死信隊列，開發者可以針對死信隊列進行重放，最終保證請求得到處理。Serverless 平臺默認對接了監控、日志、調用鏈系統，開發者無須再費力單獨維護運維的基礎設施。雖然

127、當前 Serverless 的監控指標并不如傳統的監控指標豐富，但是其更關注的是應用的黃金指標，如延遲、流量、錯誤和飽和度。這樣可以減少復雜的干擾信息，使開發者專注在用戶體驗相關的指標上。Serverless 的關鍵技術可以基于如下 Serverless系統架構進行描述：圖 2-14 serverless 系統架構HTTP請求事件源函數編程模型FaaS平臺BaaS平臺API網關消息隊列觸發器事件事件異步/同步定時器loT.def handler（event，context）FaaS控制器云存儲身份認證消息隊列API網關NoSQL數據庫.函數實例容器eventcontext043云原生 2.0

128、架構白皮書 事件源（Event Sources）：事件的生產者，可能是 HTTP 請求、消息隊列的事件等，通過同步或異步的方式去觸發函數。觸發器（Trigger）：函數的 REST 呈現，通常是 RESTful URL。當事件源將事件推/拉到觸發器時，FaaS 平臺會查找觸發器和函數的映射關系，從而啟動該函數實例，以響應被推/拉到觸發器的事件。FaaS控制器（FaaS Controller）：FaaS平臺的核心組件，管理函數的生命周期、擴容和縮容等?？梢詫⒑瘮祵嵗s容為 0，同時在收到對函數的請求時迅速啟動新的函數實例。函數實例（Function Instance）：執行函數的環境，包含函數代

129、碼、函數運行環境（如 JRE、Node.js）、上下文信息（如函數運行的配置，通常以環境變量注入）。一個函數實例可以同時處理 1 個或 N 個事件（取決于平臺的具體實現）。函數實例通常內置可觀測性，將日志和監控信息上報到對應的日志和監控服務中。函數編程模型（Programming Model）：通常表現為函數的編碼規范，如簽名、入口的方法名等。函數的編程模型一般會提供同步/異步/異常處理機制，開發者只需要處理輸入（事件、上下文），并返回結果即可。BaaS 平臺：函數通常是無狀態的，其狀態一般存儲在 BaaS 服務中，如 NoSQL 數據庫等。函數可以基于 REST API 或 BaaS 服務提

130、供的 SDK 來訪問 BaaS 服務，而不用關心這些服務的擴容和縮容問題。結合上圖中典型 Serverless 架構的架構元素，從 Serverless 系統的實現來看，其關鍵技術需求包括以下幾點：函數編程模型：提供友好的編程模型，使開發者可以聚焦于業務邏輯，為開發者屏蔽編碼中最困難的部分，如并發編程等。同時，需要原生支持函數的編排，盡量減少開發者的學習成本?？焖贁U容：傳統的基礎設施通常都是從1到n擴容的，而Serverless平臺需要支持從0到n擴容，以更快的擴容速度應對流量的變化。同時，傳統基礎設施基于資源的擴容決策周期（監控周期）過長，而 Serverless 平臺可達到秒級甚至毫秒級的

131、擴容速度?？焖賳樱汉瘮当徽埱髸r才會創建實例，該準備過程會消耗較長的時間，影響函數的啟動性能。同理，對于新到達的并發請求，會產生并發的冷啟動問題。Serverless 平臺需要降低冷啟動時延，以滿足應用對性能的訴求。高效連接：函數需要將狀態或數據存放在后端 BaaS 服務中，而對接這些服務往往需要繁雜的 API，造成開發人員的學習負擔。如果能提供統一的后端訪問接口，則可以降低開發和遷移成本。另外，Serverless 平臺的函數實例生命周期通常較短，對于如 RDS 數據庫等后端服務無法保持長連接。然而，在并發冷啟動場景下，大量函數實例會同時創建與數據庫的連接，第二章|云原生 2.0 的技術及架

132、構特征044可能會導致數據庫負載增加而訪問失敗。為此，Serverless 平臺需要為函數提供完備、高效、可靠的 BaaS 服務連接/訪問接口。安全隔離：Serverless 是邏輯多租的服務，租戶的函數代碼可能運行在同一臺服務器上?；谌萜鞯姆绞?，一旦單個租戶的函數遭受攻擊，造成容器逃逸，會影響服務器上所有租戶的函數安全。所以，通常 Serverless 平臺會采用安全容器的方式，引入輕量級虛擬化技術來保證隔離性，但這同時會引入額外的性能（啟動）和資源開銷等問題。因此，Serverless 平臺需要兼顧極致性能和安全隔離。雖然業界涌現的各種 Serverless 系統在實現上可能有所不同，但

133、基本的概念、原理和關鍵技術是相通的，各個系統在實現時都需要應對以上所述的技術挑戰。4.Serverless 簡化了資源規劃高階服務 Serverless 會根據應用程序的需求自動啟動、關閉以及擴展或縮減容量，無需管理任何具體的實例，即可在云上運行。比如數據庫的 Serverless，手動管理數據庫容量需要提前規劃，也可能因為規劃不準確或負載經常變化導致數據庫資源的使用效率低下。借助數據庫 Serverless，只需創建數據庫節點，指定所需的數據庫容量范圍，然后數據庫處于工作狀態期間按照每秒使用的數據庫容量進行付費。2.5.1 趨勢與需求對于企業來說，數據處理系統云端部署、存算分離，逐漸替換傳統

134、線下存算合一的集群部署方式，成為企業構建數據處理平臺的首選方案。企業通過將服務托管上云，云廠商對數據處理平臺做全面優化，帶來更優的存、算體驗，企業只需要關注自身業務的開發和維護工作。但原有的存算合一的數據處理系統，存在如下問題：計算資源利用率低：隨著數據量的增長，集群整體擴容，計算需求沒有明顯增長，且算力的消耗具有潮汐性特征，導致計算資源利用率低，CPU 平均利用率低于 50%，方案整體成本高。數據拷貝成本高：數據全生命周期 Pipeline 計算，涉及多集群計算。在多計算集群之間數據關鍵特征五：存算分離2.5045云原生 2.0 架構白皮書共享難，數據拷貝代價大，多份數據存儲成本高等問題。數

135、據在線事務處理需要擴展讀能力也需要拷貝完整的數據，拷貝的時間開銷和存儲成本都很高?？煽啃燥L險大：大規模的存算合一集群，運維和可靠性的風險增大。如：組件版本升級會迫使全量業務配合，業務之間資源搶占嚴重，運維可靠性風險增大?？?AZ 部署難度大：為了系統的高可用，往往會需要將應用和數據都部署在多個 AZ 內，存算合一的數據處理系統，AZ 之間的數據一致性需要靠計算層來保證，特別是在線事務處理的數據庫中，跨 AZ 的部署還需要考慮事務的可見性，在計算層實現復雜度很高，對性能影響較大。另外，當前政企客戶數據治理也面臨如下主要挑戰：數據體量巨大：數據時代，各類數據增量巨大。如某醫療中心，存量 100PB

136、，增量 40T/天，100GB/全基因測序/人，一個國家級精準醫療量將超 EB 級別。數據實時要求高：IOT 時序數據測點數量龐大，上報頻率高。如某鋼鐵集團，20000+傳感器測點，平均 100ms1S 上報，趨勢分析，異常實時監測。業務如何實現端邊云聯動，進行時序數據壓縮、分析、預測。數據類型繁雜：多模態數據關聯分析處理成為常態。如在公安偵查工作中，涉及數據種類多，位置、社會關系、網絡行為，以及大量非結構化數據如語音通信，視頻人臉，案件存檔等。運用 AI 技術可以對非結構化數據挖掘，自動建立非結構化數據與結構化記錄關聯。數據需要融合計算：業務創新需要跨領域數據融合，如互聯網客戶精準畫像，精準

137、營銷，涉及位置/消費行為/社交關系/輿情等多數據關系碰撞，以及跨源跨域數據協同分析。數據跨 AZ 部署：業務數據安全要求高，對數據的分布往往要求多 AZ 的方式提高可靠性。如某醫保局點，要求至少兩 AZ 部署數據節點。2.5.2 關鍵特征與架構原則1.存算分離存算分離方案的實施，計算和存儲資源的解耦，可以實現如下關鍵特征：解耦彈性擴展：存儲和計算各自按需彈性擴展，通過容器化技術實現計算彈性伸縮，徹底釋放算力的流動，實現了資源價值的最大化。Pipeline 計算數據免拷貝：一份數據多協議共享訪問（S3/HDFS/Posix 協議），數據免拷貝，提高了計算分析效率，節省了數據保存成本。第二章|云原

138、生 2.0 的技術及架構特征046 只讀副本免拷貝：存算分離讓多個節點可以共享訪問同一份數據，通過增加只讀節點擴展讀性能時，只需要新建一個只讀計算節點，從寫節點同步元數據后即可讀取共享存儲上的同一份數據，節省了數據存儲成本，提升了擴展效率?？煽啃栽鰪姡悍植际綌祿鎯μ峁└鞣N類型數據持久化，歸一化解決底層數據的可靠性問題，性能問題，數據容災問題。從實踐的角度，可以使租戶在數據服務受益?？?AZ 部署：存算分離使得跨 AZ 可以在分布式存儲層完成，計算節點只需要讀取存儲層的數據，跨 AZ 一致性由存儲保證，大大簡化了跨 AZ 部署的數據一致性的實現。2.統一元數據管理通過統一數據湖內外的元數據管理

139、，形成企業級數據資產目錄。支持數據湖內外的技術元數據、業務元數據、ML 數據特征等企業級元數據統一管理，提供全文搜索體驗，讓用戶快速找到他想找的數據。提供自動數據推薦、數據關系挖掘、data profile、data feature 等能力，幫助業務人員快速數據探索和數據洞察。主要關鍵特性：數據關系圖譜：自動解析發現元數據之間的深度關系，包括血緣、主外鍵、logical-physical、parent-child、數據標準、分級、分類、主題目錄等，以知識圖譜的形式呈現；智能數據搜索：支持自然語言全文搜索，相關度機器學習排序，基于用戶特征的資產推薦等。2.6.1 趨勢與需求在數據驅動決策中有效利

140、用海量復雜數據是一個新趨勢。到 2023 年，增強分析市場預計將達到 184 億美元。然而，大數據智能領域沒有端到端系統，幫助增強人類智能，企業數據治理面臨以下痛點：相對于動態的業務，當前的數據治理產品過于死板，包括創建數據湖開發時間過長，需要過多的領域專業人員來改進和維護；缺乏智能化的可視化工具來幫助用戶在大數據系統中輕松探索、發現和分析；全有或全無的訪問控制迫使企業在協作和保護敏感數據免遭濫用之間難以做出權衡；數據集、用戶知識和模型之間沒有聯系，數據無法直接用于 BI 分析和科學計算，數據價值無法業務變現。關鍵特征六：數據治理自動化 2.6047云原生 2.0 架構白皮書2.6.2 關鍵特

141、征與架構原則在數據高效治理方面，通過對海量復雜數據驅動問題的有效分析，幫助用戶專注于現實世界的問題，在正確的時間將正確的數據提供給正確的人做正確的決策。主要包含以下特征：1.一鍵式數據入湖，提升數據湖構建效率數據自動化一鍵集成入湖，用戶只需要指定入湖的數據源和所屬業務主題域，系統自動化創建入湖任務，底層資源根據入湖數據量自動擴縮容，智能完成入湖數據的安全等級、分級分類、隱私等級等數據標簽的自動識別打標。關鍵特征包括：實時增量數據入湖，元數據自動發現：支持自動爬取存儲中的表 schema 等技術元數據信息，并寫入 Data Catalog 統一管理。遷移資源動態擴展：基于遷移任務數據量大小、fl

142、avor，動態計算并推薦遷移資源配置。智能入湖管理：入湖過程中，自動進行隱私數據自動識別、動靜態數據脫敏、數據質量六要素處理、數據關系圖譜構建。2.可視化“No Code”的 Auto ETL 技術，提升數據準備效率為數據科學家、業務分析師提供 no code 的數據準備能力，在 AI 治理引擎幫助下，交互式、迭代式的做數據準備，不需要 SQL 開發技能，就可以做數據清洗、數據自動 ETL、數據關系挖掘、數據特征分析、數據準備 pipeline 任務?；?AI 增強數據管理技術的數據預覽、數據剖析、schema mapping、算子推薦等能力實現數據準備引導式交互界面。關鍵特性包括：自動數據

143、質量評估：基于 AI 智能增強數據管理技術，自動統計數據相似度，并給出數據重復度等數據質量評估結果。數據豐富：基于湖內外標準數據集，通過關系挖掘實現對數據內容的豐富以及數據schema的補充。AutoETL：提供托拉拽可視化交互界面，基于 AI 技術自動生成表關系、轉換算子推薦，數據準備 pipeline 自動生成。圖 2-15 智能數據治理流程（-UserMultiple source 數據集導入新數據集Data profiling annotation processing validation準備高質量的數據數據打標、安全、分享添加知識以供分析數據建模轉換（Auto ETL)schema

144、 mapping將數據轉換為以業務為中心的模型DaaS(Auto multi-pass SQLs)按需提供ML、BI分析的數據數據發現、探索、見解基于搜索的數據驅動的決策一鍵入湖數據準備數據目錄/數據發現數據洞察第二章|云原生 2.0 的技術及架構特征0482.7.1 趨勢與需求1.“信息共享、業務協同”已成為企業新老應用共存場景下的基本需求。隨著云原生技術的普及，使用云原生技術或框架開發新應用成為了主流，但企業不可能完全拋棄“老”應用。政府、企業、園區等業務新老應用系統越來越多，底層基礎平臺能力逐漸豐富，各應用系統與基礎平臺之間的協同、互聯互通，以及應用系統之間的互聯互通高效協作尤為重要，但

145、是也面臨著嚴峻的挑戰：各平臺系統獨立建設，缺少統一的服務開放標準規劃，平臺之間無聯動；新老應用間、應用與基礎平臺之間點對點集成，形成日益復雜的網狀交錯結構，應用與基礎平臺高耦合；隨著應用系統的不斷建設，應用集成越來越多，集成的復雜度將不斷增加，后續維護難、擴展難等不可預知問題將逐漸凸顯出來；當應用、平臺分布式部署在不同的網絡環境時，如跨云、跨隔離網絡、跨企業、跨局點等情況下，傳統的 ESB 缺乏多節點組網方案?？梢?，企業新老應用共存時，信息獲取、互聯互通成本高，業務很難協同，“信息共享、業務協同”已成為基本需求。2.傳統集成模式應用新老應用對接面臨的挑戰 舊應用有很多私有協議，基于 Restf

146、ul 協議的新應用無法與之對接。很多舊應用已無法提供對接所需接口，就應用的改造性價比低。2.7.2 關鍵特征與架構原則應用融合集成：一站式的應用/數據/API/設備集成等能力，將API、數據、設備、消息靈活互轉，高效完成應用間集成；此外，融合集成作為iPaaS領域技術，還包含元數據、低代碼、事件驅動架構、多云管理、應用聚合、函數編排等技術。應用融合集成平臺在新老應用共存場景下的主要表現：關鍵特征七：基于軟總線的異構集成2.7049云原生 2.0 架構白皮書 新老應用均無需修改，非侵入式對接，大大減小云原生應用落地復雜度。多種集成方式配合使用，集成功能強大且靈活。通過協議轉換聯接新老業務，支持各

147、種協議適配插件。通過訪問數據庫或 Function 的方式生成標準云原生接口。滿足新業務跟隨新技術長期演進需求。解決了遺留數據、應用資產的利用問題。解決新系統短時間內難以替換老系統的現實。新老應用共存場景下，企業對應用融合集成的 API 集成、數據集成、消息集成、設備集成等技術也有不同的訴求。1.應用間 API 跨云集成集團與各地區子公司的 IT 系統集成，直接訪問對方各類數據庫方式過于復雜，且容易發生信息泄露風險，如果以 API 方式互相開放訪問，同時加強 API 調用安全防護，就能實現跨網絡跨地域協同辦公。1)API 跨網、分布式集成 簡單易用：只需簡單配置 API 信息，即可完成 API

148、 注冊與開放 跨網發布 API：支持 API 由內網到公網，云端到內網發布 大規模高性能：分布式部署，分區域運行，可自動擴展，低延時2)快速開放 DB 成 API 接口 API 接口：能快速開放 DB 為 Restful 接口 數據編排：支持 API 數據編排3)API 的安全與流控 流量控制：對 API 可設制調用量控制 安全可靠：提供 Appkey 認證、支持 SSL/TSL 加密，黑白名單設置2.異構數據間跨網集成同步很多企業部門間的數據源不一樣，難以形成部門間有效的信息傳輸。應用集成平臺需要提供多種數據源之間轉換的方式，支持 MySQL、Kafka、API 等主流格式之間的轉換。第二章

149、|云原生 2.0 的技術及架構特征050 支 持 多 種 異 構 數 據 源 間 同 步，如 API、ActiveMQ、ArtemisMQ、DB2、DIS、DWS、HL7、HANA、HIVE、IBM MQ、Kafka、MySQL、TaurusDB、MongoDB、MRS Hive、MRS HDFS、MRS HBase、OBS、Oracle、PostgreSQL、Redis、RabbitMQ、SAP、SNMP、SQL Server、WebSocket 等。支持復雜多樣網絡環境支持跨網絡、跨云、跨數據中心、跨機房等網絡環境數據同步。靈活調度按數據量（增量、全量）、時間（定時、實時）等任務觸發規則來

150、調度任務。數據安全防護機制提供數據安全（敏感數據加密）、系統安全、網絡安全（防火墻防入侵）、業務安全（租戶隔離）等多層安全防護機制。3.分布式消息集成企業與合作伙伴使用的消息系統不一樣，消息系統對接成本較高，而且難以保證對接之后消息傳輸的可靠性和安全性。支持公有云、集團、子公司自由組網，應用就近接入，消息本地發布本地消費，消費端決定路由策略。圖 2-16 應用與數據集成平臺大數據APISNMPRestful關系型數據庫文件商業/專有協議HL7消息IBM MQJDBCMessageFileHTTPRFCStreamJDBCStreamMessageFileHTTPRFC大數據API關系型數據庫文

151、件OBSHL7消息IBM MQ私有云公有云混合云私有云公有云混合云OBSSNMPRestful商業/專有協議應用與數據集成平臺051云原生 2.0 架構白皮書1)需要支持分布式消息部署 主備模式多節點集群模式 跨數據中心的多集群模式 跨數據中心的消息平臺通過統一路由連接2)消息統一路由，可實現應用就近接入 統一的服務發現與負載均衡模塊，實現應用就近接入消息平臺 自動發現消費端位置，統一路由模塊處理，路由到消費端本地消費3)支持混合云各種應用場景 消息 Proxy 代理消息到消息平臺 Proxy 負責認證、加密等安全措施 集團分子公司間全國 全球跨網集成 B2B 跨網間消息集成 公有云、私有云間

152、跨云消息集成4.設備數據快速集成工業場景中，設備的信息和生產過程中的參數比較分散。生產線出現故障時，如果靠人工采集每一臺設備的信息與參數，定位問題的過程緩慢。應用集成平臺需要能夠連接設備和 IT 系統、大數據平臺，將設備的運行狀態等信息上傳到 IT 系統或大數據平臺中，實現所有設備的信息可視化，一旦生產線出現故障，企業能夠快速定位問題。需要實現標準的 MQTT 協議：使用開源的標準 MQTT 設備端 SDK，輕松接入云端。設備多協議接入connector：持標準MQTT、MQTT Client SDK、設備集成Agent、軟/硬網關、HTTP 各種協議與方式實現設備數據接入云端。水平拓展：支持

153、海量設備低延時接入，支持百萬設備長連接。安全可靠：保障設備安全與唯一性，提供 TLS 標準的數據傳輸通道保障消息傳輸通道的安全。第二章|云原生 2.0 的技術及架構特征0522.8.1 趨勢與需求1.云原生應用研發趨向一體化模式云原生時代的應用研發趨向于從需求、計劃到上線、運維直至用戶反饋的全過程均在云上完成的應用研發一體化的新模式，業界也稱之為 DevOps。但一體化模式并非唯一選擇，企業仍然可以采取傳統研發模式來開發云原生應用，這樣就無法發揮或無法全面發揮云原生技術的優勢，應用研發效能只能處于較低水平。同時，要將一體化模式落到實處，提升應用研發效能，需要企業聚焦云原生應用研發轉型的目標和價

154、值，以能力屋及實施框架為指引，涵蓋人和組織、工程方法、最佳實踐、工具平臺、生態各方面，制定計劃并推動落實。關鍵是要正識正視，云原生應用研發實質上是研發模式甚至業務模式的變革轉型，需要通過有效的變革管理來保障轉型成功。2.從敏捷到 DevOps，是一體化趨勢的延續應用研發一體化模式并非從天而降，實則是從 20 世紀 90 年代起研發模式演變的趨勢延續。2001 年，敏捷運動興起，強調打破業務、開發與測試之間的壁壘。2009 年，DevOps 運動興起，致力于促進軟件開發、運維和質量保障部門之間的溝通、協作與整合。2012 年，Gartner 提出DevSecOps 概念，主張將安全性嵌入 Dev

155、Ops 鏈條每個環節，追求在開發過程早期而不是產品發布后識別安全問題，目標是讓每個人對信息安全負責。敏捷、DevOps 以及 DevSecOps，它們是一種延續，所代表的是打通管理與協同、設計與開發、CI/CD、應用管理、運維、安全可信等各個環節的一體化趨勢。關鍵特征八：可信、平民化DevOps2.82.8.2 關鍵特征與架構原則1.DevSecOps伴隨著 DevOps 在公司內的快速發展，研發安全保障的思維和技術也需要不斷演化發展，其中一個重要的思想就是 DevSecOps，它完全遵循 DevOps 的思想，將安全無縫集成到其中，使之升級成為 DevSecOps，相較于 DevOps，De

156、vSecOps 需要在以下原則加強：053云原生 2.0 架構白皮書1)安全左移（Shift Security Left）持續的發布不停地進行，靠以往把所有的檢查在發布之前進行根本跟不上這個速度。所以需要更多的關注研發流程的“左”邊，在更早的環節中（設計、編碼、自動測試）也要進行安全介入和管控。但安全工作必須從工程師的角度出發，制定更加輕量級可迭代的措施，并以有效、可重復和易于使用的方式實現自動化。這個想法雖好，但并不是那么容易落地，主要的原因是安全人員數量并不足夠，所以需要讓開發和運維人員承擔更多的安全責任，這里需要安全人員對他們進行更多的安全培訓（意識和能力），還有就是提供有效的工具來幫助

157、構建更安全的系統。2)默認安全（Secure by Default）拿編碼環節來說，持續的快速構建也意味著需要快速的產生代碼，而如何快速的產生安全的代碼變的越發重要。在開發人員能力短期無法質變（或不停的有人力交接或新人加入等）時，通過提供默認安全的開發框架或者默認安全的組件可能很好的防止犯低級錯誤，默認安全的原則并不僅僅限于代碼，Web 接入層上默認覆蓋的 WAF、默認安全配置的云/容器/數據庫/緩存等基礎系統和服務、統一的登錄鑒權認證服務、KMS（密鑰管理系統）、保護關鍵數據的票據系統、零信任（Zero Trust）架構等等，都是默認安全的很好實踐。這也要求安全團隊要參與到整個系統架構、基礎

158、設施等的建設中。反過來也會要求更多的組織架構保障以及安全與研發團隊之間的溝通協作能力。3)運行時安全（Runtime Security）在越來越快的發布之下，倒逼著安全的考量除了上述提到的左移和默認安全以外，更加需要特別關注和加強上線后運行時的異常監控和攻擊阻斷能力提升。需要有更加及時快速自動化的風險監控、發現、阻斷、恢復等的手段和機制。類似于致力于提升系統整體可用性的各種Monkey（混沌工程），安全機制也需要有類似的機制和能力，重點在識別內外部的安全風險上。再比如與應用運行時環境嵌入更緊密的運行時應用自我保護（RASP，Runtime Application Self-Protection

159、）技術，以前如果還猶猶豫豫，那以后可能會更多納入大家的視野中。雖然也有一些問題如部署比較麻煩、兼容性問題、性能問題等，但是借助于云、容器等成熟的大規?；A設施和技術之上通過優化完全有可能提供更優雅更易于接受和使用的方案，能夠帶來更快更精準更細致入微的安全檢查及防護能力。此外，對于很多安全風險來說，情報來源管理和自動化分級分析是第一步，然后如何更快的檢測？又如何快速地對問題進行響應，特別是為了提升安全響應效能，不能僅僅從單點來考慮，要從全網及整個系統架構層面來考慮，將分散的檢測和響應機制整合起來，這也導致了 Gartner 在 2015 年提出了安全編排自動化和響應（SOAR，SecurityO

160、rchestration，Automation and Response）的概念，更好的完成運行時的風險響應問題。第二章|云原生 2.0 的技術及架構特征0544)安全服務自動化/自助化（Security as Code/Pipeline）在 DevSecOps 中，安全并不是特殊或者擁有某種高權限的存在，跟其他所有研發環節和工具一樣，不能因為安全而中斷 DevOps 的流程。如果你的安全服務沒有實現自動化，那么就無法稱之為 DevSecOps。整個研發流程都在圍繞流水線運轉，你不可能突然在其中把開發人員支走，很莫名其妙并且無法被接受。應該向他們提供可使用且易于理解的安全工具，讓這些工具自己進

161、行配置和運行，保證這些工具能以合適的方式融入到流水線中，融入到各個流程中，成為DevSecOps 工具鏈中的一環，使用角度跟其他工具沒有大的區別?？偠灾?，需確保安全測試和檢查服務能夠自動化和自助化并且提供快速且清晰的反饋。業界有一些研究和嘗試比如漏洞代碼自動修復（MIT的CodePhage，GitHub發布的針對開源漏洞組件自動修復的Dependabot）等技術，雖然目前看有些成熟度可能還不高，這些方向雖然困難但絕對是正確的，是一種貫徹 DevSecOps思想的嘗試。但是這里也要小心陷入另一個誤區，需要清晰的認識到，安全領域是沒有“銀彈”的。如同所有風險類管控一樣，信息安全的管控本身一定是層

162、層防御的機制，對于很多營銷目的的所謂新技術一定要全面了解多方對比才能做出判斷，不太可能指望搞一個方案就一勞永逸的解決所有安全問題，就要達到 100%安全，這是不切實際的空想！就如同軟件研發領域“沒有銀彈”，系統可用性沒有 100%（一般我們說要做到 4 個或 5 個 9），安全也沒有 100%。5)利用基礎設施即代碼（IaC）基礎設施即代碼（Infrastructure as Code）思想和工具是以前成功構建實施 DevOps 的關鍵，安全管控也要積極的利用這些能力。利用他們確保大規模場景下配置、環境和系統行為等的一致性，通過版本控制、代碼審計、重構、動靜態分析、自動測試等手段持續交付流水線

163、來驗證和部署 IaC 設施，確保標準化、可審核并且使之更安全，減少攻擊者發現和利用運維漏洞的機會。各種安全系統和安全機制也積極使用這些設施，另外在出現安全漏洞或應急事件時，直接使用 IaC的一些機制快速安全可靠的修復漏洞或部署緩解措施。另一方面，也特別要保護這些基礎設施，保護持續集成和持續交付管道等研發流程中的關鍵系統，真的無法想象流水線系統被惡意控制之后會導致什么。所有的操作集中起來對于安全保護的要求會更高。2.BizOpsDevOps 從 IT 團隊的角度補齊了能力，實現了 IT 團隊內部從開發測試到運維的流程、組織、文化重構，通過實現 IT 從“穩態”到“敏態”的轉型和“雙態 IT”支持

164、，很大程度上能改善 IT應對市場及業務變化的能力；但是從整體上看，在數字化時代下，企業的商業價值需要更多由業務數據來驅動，業務和 IT 需要以商業價值的交付為目標，前端的業務決策、業務調整和執行，需要和 IT 實現以及 IT 運營數據形成更緊密的閉環。從 DevOps 向業務端進行擴展，實現業務、IT055云原生 2.0 架構白皮書開發運營的整合重構，就有了 BizDevOps 的概念。BizDevOps 需要實現業務和 IT 之間的連接，其中重要的一點就是通過低代碼（Low-Code）或是無代碼（No-Code）開發平臺，為業務人員、開發人員提供統一的交互基礎。核心 IT 團隊更關注于提供自

165、動化工具及平臺，以及支撐業務功能實現的服務化功能和組件，業務分析師/開發人員可通過自動化平臺工具以及服務組合，從業務需求出發對 IT 實現進行定義。當技術被隱藏起來時，它就易于為更廣泛的公眾所使用，被稱為平民化。低代碼開發的核心能力包含以下幾個方面：全?？梢暬幊蹋嚎梢暬瑑蓪雍x，一個是編輯時支持的點選、拖拽和配置操作，另一個是編輯完成后所及即所得（WYSIWYG）的預覽效果。傳統代碼IDE也支持部分可視化能力（如早年 Visual Studio 的 MFC/WPF），但低代碼更強調的是全棧、端到端的可視化編程，覆蓋一個完整應用開發所涉及的各個技術層面（界面/數據/邏輯）。全生命周期管理：

166、作為一站式的應用開發平臺，低代碼支持應用的完整生命周期管理，即從設計階段開始（有些平臺還支持更前置的項目與需求管理），歷經開發、構建、測試和部署，一直到上線后的各種運維（e.g.監控報警、應用上下線）和運營（e.g.數據報表、用戶反饋）。低代碼擴展能力：使用低代碼開發時，大部分情況下仍離不開代碼，因此平臺必須能支持在必要時通過少量的代碼對應用各層次進行靈活擴展，比如添加自定義組件、修改主題CSS樣式、定制邏輯流動作等。一些可能的需求場景包括：UI 樣式定制、遺留代碼復用、專用的加密算法、非標系統集成。2.9.1 趨勢與需求云的強大算力和海量存儲使深度學習的普及成為可能。隨著 AI 應用越來越廣

167、泛，諸如BERT、GPT-x 等預訓練模型的持續突破，AI 對算力和數據的需求越來越強烈。云提供了最佳算力和數據存儲載體，也為 AI 模型的全生命周期治理以及端邊云 AI 協同提供了統一控制點，可以大大促進全行業 AI 普惠。但是 AI 在行業的真正落地，面臨各種挑戰。眾所周知，一個 AI 產品的開發&交付運維過程，是一個復雜系列的工程，所需要的人員及技能范圍較廣，在實際的機器學習系統中，只有一小部分是由機器學習代碼組成的，所需的相關元素既龐大又復雜。系統的其余部分包括配置、自動化、數據收集、數據驗證、測試和調試、資源管理、模型分析、過程和元數據關鍵特征九：多模態可迭代行業AI2.9第二章|云

168、原生 2.0 的技術及架構特征056圖 2-17 As AI Matures,Inference will Dominate管理、服務基礎架構和監控。而且 AI 一旦進入核心系統，發現了更深層次的問題，行業建模和求解成本非常高：行業專家與AI專家合作：如何讓雙方能夠相互聽得懂，圍繞一個共同的目標相互促進是個難點；行業知識與 AI 模型結合：不同行業都有自己數十年甚至上百年的專業積累，形成了大量成熟的基于物理、化學、生物信息等知識表達的機理模型，這些模型能否提升數據驅動 AI 模型的求解效率與精度，及如何有效結合；行業數據與實驗模型結合：如何讓模型隨著客戶真實數據不斷適應變換，不斷自我迭代算法喻

169、模型是一個難題；行業應用與 AI 系統結合：行業自身多年積累的應用系統、控制系統和 AI 系統。如何讓這些行業應用平滑有序地升級為智慧系統。這些 AI 軟實力的背后，根本問題是知識表達（建模成本）和知識求解（求解成本）：行業知識如何與 AI 結合？解決這個機理性問題后，專家配合及系統配合的問題就將隨之清晰。AI 應用與傳統軟件不同，有分析機構統一發現，傳統軟件的毛利率比 AI 應用的毛利率高，原因還是開發成本和迭代成本高導致。另外傳統軟件的服務基本上一次性就可以完成，而 AI 應用軟件則需要長期訓練迭代，專人運維。并且可復制性上面，傳統軟件的可復制性更高（場景確定性高），而 AI 應用的可復制

170、性低（往往隨著環境變化，導致可用性低）。這些 AI 軟實力的背后，根本問題是落地管理（迭代成本）：行業數據如何與 AI 迭代？解決這個工程化問題后，實驗與真實系統配合的問題才將隨之解決。下面的這個概念圖顯示了建模與推理花費的百分比?？梢钥吹浇裉焓艿疥P注的一些應用程序隨著推理變得越來越主流。AutosHealthcareFinancial ServicesRetailMediaGovemment/DefenseCyber SecurityEducationModelingInference2030202520200%of Spending100Level 3 autonomous driving

171、,trafficoptimization,AR/VR,power grid,new paymentsystems,on-shore manufacturing,machineintelligent robots,content production,inrelligent call centers.Smart phone,Alexa,facial recognition,NLP,low level autonomous drixing（e.g.lane warnings）,Brave Browser（BAT）,DeFi/Blockchain,GamungFraud detection,adte

172、ch,pricing,weather,categorization,recommendation engines,supply chains,drug provenance.057云原生 2.0 架構白皮書對于企業使用AI而言，更關心的往往是AI應用（Inference）價值。當前，如防詐騙、廣告技術、預測天氣、預判價格、推薦引擎等方面，建模成本占比小于推理，但是上面的概念圖顯示了隨著時間推移，訓練和推理的花費百分比會到一個過程趨于平衡，并且隨著使用越多價值越大。該圖還顯示了，隨著推理成為主流，當前受到關注的一些應用會逐步走向成熟。隨著業界在算法/工程能力方向上面的持續創新，如 Built-i

173、n 大模型/MLOps 能力加持外，用戶在 Modeling 生產 AI模型的單位消耗和時間會逐步減低下來。在 2017 年訓練圖像識別需要花費 2000 美金，到 2020年訓練一個圖像識別模型僅僅需要 7.43 美金。2.9.2 關鍵特征與架構原則在各大平臺預測中到2025年，97%的大企業將采用AI，其中企業對AI的采用率 86%(Source：Huawei GIV)。在云原生 2.0 時代，已逐步出現如下特征：1.超大規模分布式算力提升建模效率（Modeling）對于Modeling而言，最核心的即模型的訓練過程。模型訓練通常需要大規模高質量訓練數據，并基于 AI 模型的特性表達不同行

174、業中復雜而龐大的業務體系。這涉及到如何利用行業知識刻畫行業特點。一方面，行業知識可以指導行業數據的獲取、標注等工作，幫助識別無效數據、補全缺失數據，解決不同場景下數據收集難、數據誤差大等問題，幫助構建符合行業特性的高質量數據；另一方面，行業知識可以幫助更高效地完成模型選擇、模型參數化等工作。隨著業界越來越多的 AI 落地，觸發對 Built-in 的 Models 模型越來越強烈，則對于 Training的過程越來越細分出來。從原來的一個團隊從算法開發+場景化開發，逐步走向了兩類人員，一類人群專門從事算法開發，另外一類人群負責做場景化迭代。如下圖，觸生了一部分有能力的算資源消耗ALL-One-

175、teamOne-teamOther-teamFuturePast500500045550AlgorithmsAlgorithmsDev WorkflowDev WorkflowDev Workflow.WorkflowUse WorkflowUse WorkflowUse Workflow.圖 2-18 AI 團隊合作模式的轉變第二章|云原生 2.0 的技術及架構特征058法團隊，會專門負責生產 Built-in Models。而客戶&ISV 則通過 Built-in Models 進行圍繞場景的Workflow 開發，解決場景化方案。面向未來對于 Built-in Models，則需要大量的

176、算力，而單純的幾臺機器算力已然無法滿足其需求，超大規模分布式成了業界必然趨勢。故在這個業界趨勢下，對于第一階段的訓練而言，Centralization 成為趨勢，去構建更大體量的算力。2.利用行業知識提升 AI 模型求解效率與精度（Solving）求解是確定模型參數值的過程，求解的效率限制了模型迭代的速度，求解的精度決定了模型在業務中的可靠性。為了提升 AI 模型的求解效率，通常會一次性喂給模型更多的數據，輔以先進的硬件計算資源，以加快模型求解速度。除此之外，科研人員也在不斷更新求解算法，進一步提升模型的求解精度。然而，由于諸多行業業務的復雜性，單純基于大數據的方式求解模型，往往難以得到令人滿

177、意的結果。以石油勘探為例，勘探數據具有海量、多維、多尺度、多屬性等復雜特點，需要基于大量的背景知識對數據進行分析推理，進而做出預測?；谶^往的實踐經驗，由于缺乏相關的領域知識，單純地基于大數據訓練 AI 算法，AI 算法難以從海量數據中學習油氣層的固定模式，往往精度較低，難以滿足業務需求。利用行業知識幫助AI模型高效求解，可以彌補數據偏差造成的影響，幫助AI模型尋求更優解，同時知識中所包含的約束、規則等信息能夠調整模型求解策略，得到更符合行業場景的 AI 解決方案，將成為 AI 模型求解的趨勢之一。3.MLOps 提升迭代效率（Iteration）MLOps(Machine Learning

178、Operation)是“機器學習”（Machine Learning）和“DevOps”（Development and Operations）的組合實踐。隨著機器學習的發展，人們對它的期待不僅僅是學術研究方面的領先突破，更希望這些技術能夠系統化地落地到各個場景中。但技術的真實落地和學術研究還是有比較大的差別的。在學術研究中，一個 AI 算法的開發是面向固定的數據集（公共數據集或者某個特定場景固定數據集），基于這單個數據集上，不斷做算法的迭代與優化，面向場景的 AI 系統化開發的過程中，除了模型的開發，還有整套系統的開發與運維，于是軟件系統開發中成功經驗“DevOps”被自然地引入進來。但是，

179、在人工智能時代，傳統的 DevOps 已經不能完全覆蓋一個人工智能系統開發的全流程了?；?Machine Learning 的 MLOps 就被提出來。059云原生 2.0 架構白皮書圖 2-19 MLOps如上圖，機器學習開發流程主要可以定義為四個步驟：項目設計、數據工程、模型構建、部署落地。AI 開發并不是一個單向的流水線作業，在開發的過程中，會根據數據和模型結果進行多輪的實驗迭代（如上圖箭頭指向）。算法工程師會根據數據特征以及數據的標簽做多樣化的數據處理以及多種模型優化，以獲得在已有的數據集上更好的模型效果。傳統的 AI 應用交付會直接在實驗迭代結束后以輸出的模型為終點。當應用上線后，

180、隨著時間的推移，會出現模型漂移的問題。新的數據和新的特征在已有的模型上表現會越來越差。在MLOps中，實驗迭代的產物將會是一條固化下來的流水線，這條流水線將會包含數據工程，模型算法，訓練配置等。用戶將會使用這條流水線在持續產生的數據中持續迭代訓練，確保這條流水線生產出來的模型的 AI 應用始終維持在一個較好的狀態。以一系列工程化的思想和實踐，幫助 AI 算法模型完善其在工程化及效能方面的短板。MLOps 是機器學習項目從實驗室走出來，走向規?；瘧玫挠行緩?。通過持續訓練、持續集成、持續部署、持續監控等多個自動化循環流程，大大減少迭代需要的開發周期，持續提高模型應用交付質量，降低對專業算法人員

181、依賴，整體提高研發效能，推動挖掘更多元化的業務價值。4.生態社區（Marketplace）有了一個好用的 AI 平臺，意味著有了趁手的生產工具，但如果要達到更高的生產力，沒有知識和經驗是不行的，AI 的開發和落地也是如此。AI 是一種通用的目的性技術，AI 的落地是一個系統級的工程，涉及到的知識和經驗體系具有很強的行業和技術縱深，開發者很難面面俱到。如何項目設計數據工程模型構建部署落地需求收集場景設計明確問題邊界定義數據收集數據數據標注數據可用性檢查數據工程算法開發模型訓練模型評估迭代優化應用集成應用部署模型監控系統運維DESIGNML DEVOPS第二章|云原生 2.0 的技術及架構特征06

182、0將 AI 相關的知識和經驗匯聚并沉淀，并為不同背景的開發者提供其所需的 AI 能力，成為了 AI 產業化落地、賦能千行百業征途中必須要解決的問題。而這個問題的一種解決思路，就是構建 AI 生態社區。生態社區并不是一個新鮮詞，這里所指的 AI 生態社區有什么特別之處呢？這和生態社區的核心，也就是“AI 知識和經驗的載體”密切相關。根據前文所述，我們知道 AI 開發和落地過程中，需要經過多次實驗、反復迭代。在端到端的過程中，優質的成果物可作為 AI 知識和經驗的載體，用來做后續的二次開發或同類場景復用，具備分享和交易價值。我們可為這些優質的成果物引入“AI資產”的概念。圍繞 AI 開發和落地端到

183、端流程中使用的 AI 生產要素，可梳理如下典型的 AI 資產：AI鏡像：用于AI訓練、推理的鏡像環境，其中包括了操作系統，GPU/NPU驅動，Python軟件，基礎 AI Frameworks 及高級的 Frameworks，一般都是以鏡像包的方式去呈現；DataSets 數據集：用于 AI 開發與訓練的樣例數據集，如 Imagenet、coco 等；Packages 領域組件：開源算法庫，如 pyod/egads/OctoML/shap/pysyft/interpret/OpenVINO；Algorithms 領域算法：參考算法代碼，如回歸、分類、評估、安全等；Pre-trained Mod

184、els 預訓練模型：預訓練算法模型，如 Backbone 大模型等；Models：模型應用包，可在云側、邊緣等環節部署運行進行推理預測；Experiment Pipeline：開發過程的工作流，面向訓練迭代過程，例如智能標注也是一種workflow；Solution Pipeline：模型組合的封裝工作流，面向應用過程；Project workspaces：項目工作空間，基于項目的端到端配置及工程等；EndPoints：API 服務；Tools：如第三方標注工具、模型評估工具等。AI 資產具有豐富的種類形態、多樣的使用方式，并且在數量上隨著開發者的共建共享會持續增長。為了讓 AI 開發者能夠更

185、加高效的開發、使用和管理 AI 資產，也讓 AI 平臺能夠聚焦在通用能力建設并靈活迭代升級，可以將 AI 資產和 AI 工具平臺解耦。開發者可使用工具平臺生產出 AI資產，發布到生態社區進行分享或交易；也可以從生態社區中獲得 AI 資產，快速的加載到工具平臺上使用，類似于微軟的 Office 工具軟件以及模板資源。場景示例：某工業質檢類業務場景下，數據科學家們收集原始數據，并運用 AI 平臺進行數據處理和標注，獲得可供訓練使用的數據集 Dataset，再基于 AI 平臺反復開發調測，獲得相應的訓061云原生 2.0 架構白皮書練算法 Algorithm，然后基于相應的自定義 AI 框架 Fra

186、meworks 進行訓練，訓練結束后得到模型Models，再通過 AI 平臺將模型部署起來，以 API 服務形式提供給業務做集成。這個過程可通過工作流 workflow 固化下來，方便后續迭代。從這個端到端環節中，我們可以看出來有哪些 AI 資產：Datasets，Algorithms，Frameworks，Models，workflows。這些 AI 資產都是 Data Scientist 的知識產物，都具有分享和交易價值。2.10.1 趨勢與需求云安全是什么？在最早期階段，云的安全包含了基于虛擬化技術的網絡安全（Virtualization-based Network Security），

187、基 于 資 源 池 化 的 網 絡 安 全（Resource-pool-based Network Security），基于云的網絡安全（Cloud-based Network Security）。傳統安全廠商，為了適應云化潮流，也紛紛提出以安全硬件、軟件形式而非服務形式提供 Offering，進一步衍生出來大量安全資源池的概念。在公有云的初期，由于公有云服務提供商提供的安全能力較少，用戶仍然部署了不少非云服務商提供的安全產品，我們姑且稱為用戶部署的安全產品（Customer-deployed Security Product）。造成這一局面的原因可能是用戶依然有大量專業安全產品的生命周期沒有

188、終止，或者已經購買的產品產生了較強的依賴，或者經過評估云服務商安全產品后發覺無法達到專業安全廠商同等產品的水平。當前各個公有云服務提供商除了提供數量不少的云安全服務如保護工作服務的安全產品（CWPP，Cloud Workload Protection Platform），監控云安全態勢的安全產品（CSPM，Cloud Security Posture Management），云 原 生 應 用 保 護（Cloud Native Application Protect Platform）等技術。上述這些階段，這些階段并不是替代關系，而是仍然并存。隨著公有云廠商對云的理解逐步深入，對云安全的思考也

189、從狹義的安全概念引申到如何在云上幫助客戶構建全方案的安全體系這個理論了，這些理念和技術可以解決傳統安全過去很難、甚至是無法解決的安全風險，比如大型企業部署應用時如何進行安全架構設計、如何管理復雜組織和系統的權限和賬號；如何進行現代化的安全運營以應對安全攻擊、入侵風險等，這些都是云原生 2.0 展現給客戶的。關鍵特征十：全方位立體化安全 2.10第二章|云原生 2.0 的技術及架構特征0622.10.2 關鍵特征與架構原則1.統一權限管理 隨著安全合規的要求越來越嚴格，在訪問控制方面需要嚴格遵守最小授權原則，這就要求云平臺提供精細化的權限控制手段，企業利用這些細粒度授權方法可以精確設置訪問控制的

190、 5 個要素：Who、What、How、Where、When。Who 表示誰可以訪問云資源，What 表示可以訪問哪些云資源，How 表示有權執行該資源的哪些操作，Where 表示允許用戶從哪里訪問，When 則表示允許訪問的時間段。細粒度授權體現在以下幾個方面：細粒度資源：授權時可以指定特定的資源組甚至單個資源，而不是把租戶內所有的資源都授權出去，這個可以通過企業項目、標簽等方式來限定授權的資源范圍。如果需要授權特定資源，可以先把這些資源歸集到一個企業項目或者打上一個標簽，然后按照企業項目或標簽來設置權限。細粒度操作：將云資源的讀、寫、列表等操作進一步細化，對其細化操作進行鑒權，并將這些細化

191、操作變成可供用戶配置的權限操作。以云主機為例，將其讀操作細化為讀取規格、讀取標簽、讀取服務器詳情、讀取掛載的磁盤、讀取網卡等細粒度操作，這些細粒度操作在用戶配置權限的時候是可以自由選擇的，這樣就可以將權限控制到用戶所需的最小操作集合。ABAC(Attribute-Based Access Control)：即基于屬性的訪問控制，相比 RBAC（Role-Based Access Control）更加靈活，可以在權限設置的時候附加各種基于屬性的條件，在權限判定的時候檢查當前的訪問請求是否滿足這些屬性所對應的條件，滿足條件時才允許訪問。屬性通常包含三類：一是訪問主體的屬性，比如用戶姓名、創建時間、

192、是否啟用 MFA 等；二是環境的屬性，比如訪問的IP地址、訪問時間、訪問的設備等；三是資源的屬性，比如資源的標簽、創建日期、資源名稱等。通過 ABAC 可以更細粒度地設置訪問控制的權限，例如運維人員只有啟用了 MFA 認證后并且只能在晚上 12 點后、凌晨 4 點之前對云資源進行關機和重啟操作。2.統一安全憑證管理賬號密碼、數據密鑰、應用 AK/SK 憑證是業務安全最基本的要素，這些憑證的安全生成和保管對于任何企業都是非常重要的。但是我們不能忽視的問題是，憑證管理有如下風險：弱密碼、特征密碼 密碼、密鑰因為規范性的要求，設置很長，系統管理員記不住而明文存儲在業務系統中 應用憑證通過編碼的方式記

193、錄在軟件中 使用缺省口令或偽隨機數生成密碼、憑證，且長時間不更換 企業有大量的人機、機機賬號，海量憑證管理困難063云原生 2.0 架構白皮書對于上云業務系統，可以充分利用云原生的技術來管理憑證，做到人機、機機賬號憑證的有效管理，在安全和效率之間得到充分協同。使用密鑰管理服務 KMS 來管理密鑰，KMS 服務是云原生的密鑰管理系統，其原理是對用戶密鑰進行托管，將用戶的密鑰存儲在專業的加密機（HSM）中，只有正式的用戶登錄后才能通過KMS訪問加密機來獲取相關密鑰。徹底解決密鑰明文存儲、硬編碼在代碼中等問題。同時，云原生的密鑰管理服務天然與云數據類服務（如對象存儲、塊存儲、數據庫服務等）進行了對接

194、，用戶在安全使用密鑰時，還減免了和對應數據服務對接的開發工作量。使用證書管理服務來管理各類證書，通過云上的證書管理服務，將證書的申請、發放、配置、替換的生命周期流程管理起來，確保證書申請過程中不會泄露系統信息，證書下載過程不泄露證書公私鑰。密鑰、密碼等憑據的輪轉，對于業務系統中的密鑰和憑據，需要定期進行更換以避免管理漏洞帶來的數據丟失，云上憑證管理支持密鑰的定期輪詢和自動替換，替換后自動更新到上下游業務系統中。在業務效率不下降的情況下，最大化保證安全。隨著云技術的發展，API、SDK 的廣泛引用，憑證的安全管理顯得越發重要，使用云原生的服務是被廣泛認知的有效、安全、必要的方式。同時，類比傳統

195、IDC 環境下動輒數十萬甚至數百萬一套的加密機、CA簽發系統，云原生技術也極大的降低了相關服務的開通復雜度和使用成本，為租戶安全管理密鑰、密碼、憑證提供的有利條件。3.安全可信多方計算在政策驅動和市場需求同時作用下，隱私計算技術、產業、應用迅速發展，成為保護數據擁有者的權益安全及個人隱私的前提下，實現數據的流通及數據價值深度挖掘的重要方法。一方面，多方數據融合需求強烈。然而受制于數據的分散性、高復制成本以及價值聚合性，數據仍呈高度分散狀態；另一方面，隱私保護需求強烈。然而“野蠻掘金”誘惑下的數據盜用，濫用頻發。同時法律監管日趨嚴格，公眾個人信息保護意斷提升?；谝陨弦蛩?，以安全多方計算、聯邦計

196、算為核心技術的隱私計算增強了數據流通過程中對用戶隱私、商業秘密的保護，為數據的融合應用和價值釋放提供了新思路。4.面向大企業客戶的“單企業多租安全治理”對于規模較小的企業云客戶，往往一個企業客戶對應一個云服務租戶賬號，但對于大型的企業云客戶而言，因其業務單元眾多，組織層次架構復雜，為了實現企業內各業務單元的安全和故障隔離，往往選擇將該企業不同業務單元的應用系統分別部署在不同的云服務租戶賬號中。從企第二章|云原生 2.0 的技術及架構特征064業安全治理管控的角度，云服務租戶賬號承擔了如下 3 個關鍵作用：各業務單元或組織的資源容器，用戶可以在其中部署任意云資源和上層業務應用系統，不同的賬號相當

197、于不同的資源容器，賬號之間是完全隔離的。因此在一個賬號中的故障和安全風險不會影響和傳播到其他賬號。各業務單元或組織的安全管理邊界，每個賬號都有獨立的身份和權限管理系統，一個賬號內的用戶只能訪問和管理本賬號的資源，未經允許，一個賬號內的用戶不能訪問其他賬號的資源、數據和應用。各業務單元或組織的獨立的賬單實體，每個賬號可以單獨在公有云上充值、購買云資源、結算和開票。因此對于大企業內部的多個業務單元和組織而言，設置多個云服務賬號不僅有利于實現不同業務單元和組織之間的故障和安全隔離，還可用于將多個業務單元和組織的財務和資源配額進行獨立管理。另外，從可靠性、可用性角度出發，為了避免單點故障帶來雪崩效應、

198、減少單點故障的爆炸半徑，核心辦法就是不要把所用業務系統及其云資源部署在單一賬號，也就是不要“把雞蛋放在一個籃子里”。單一賬號存在兩個嚴重的問題：其一是單一賬號的爆炸半徑太大，如果該賬號發生崩潰將導致企業所有業務系統不可用；其二是云平臺上賬號的資源配額是有上限的，不能在一個賬號內無限擴容云資源。綜合上述，針對大企業上云的場景，多賬號架構往往是最佳的選擇。按照康威定律，大企業的多賬號架構通常會與其組織架構或業務架構保持一致。采用多賬號架構后可以實現職責分離，不同的賬號負責不同的事情、承載不同的業務，每個賬號可以對本賬號內的資源進行自治管理，但同時從 IT 治理角度肯定要求一定程度的統一管控，比如多

199、賬號的統一運維管理、安全管控、資源管理、網絡管理、財務管理等。針對大企業的上述核心訴求，需要為大企業客戶在云上構建安全合規、可擴展的多賬號運行環境，實現與同一大企業客戶對應的多個云服務賬號之間的資源共享，以及相應的“人財物權法”的統一管控。人的管理：多賬號環境下對組織單元、賬號、用戶、用戶組、角色等進行統一管理。財的管理：多賬號環境下對資金、預算、成本、發票、折扣等進行統一管理。物的管理：多賬號環境下對計算、存儲、網絡、數據、應用等云資源進行統一運維和管理。權的管理：多賬號環境下對云資源的訪問權限進行統一管理，確保訪問權限符合最小授權原則。法的管理：多賬號環境下對安全合規進行統一管理，確保符合

200、國家、行業和企業自身的安全合規要求。065云原生 2.0 架構白皮書企業成功實施了上述“單企業多賬號”解決方案之后，可以有效規避大規模上云之后的管理失控、安全失控、成本失控的風險，全面應對各種 IT 治理挑戰，幫助企業建立分統結合的 IT 治理體系和完善的安全合規體系。分統結合的 IT 治理體系：即在分權分域分級管理的基礎上進行一定程度的統一管控，如統一運維、統一安全等；完善的安全合規體系：云上運行環境（包括云資源、數據、應用等）滿足國家、行業和企業自身的安全合規標準，“單企業多賬號”提供了以下主要安全措施：SOD（Separation of Duty）：通過多賬號架構實現 SOD，一個賬號就

201、是一個 SOD 單元，企業可以按照業務單元、地理單元、功能單元等維度劃分賬號，任何單一賬號的崩潰不會影響全局系統，減少爆炸半徑。操作審計：為每個賬號開啟操作審計，記錄任何主體對資源訪問的日志，也就是確保所有的操作都留下痕跡，同時將所有賬號的審計日志進行集中存儲和分析。配置變化跟蹤：為每個賬號開啟資源配置記錄功能，記錄資源配置的變更日志，確保資源的所有變化都有跡可循，同時將變更日志進行集中存儲和分析。安全護欄：安全護欄有兩類，一類是安全紅線，設定成員賬號不能做什么事情，相當于強制限定成員賬號的權限，避免成員賬號權限過大帶來的安全風險，在設置安全紅線時可以采用上文中的細粒度授權，安全紅線也叫做預防

202、性安全護欄；另一類是安全基線，要求成員賬號滿足基本的安全合規要求，如根用戶要啟用 MFA、云硬盤要加密等，安全基線也叫做檢測性安全護欄。統一身份權限管理：統一管理多賬號環境下的用戶、用戶組和權限，使得一個用戶即可訪問多個賬號下的資源，統一身份權限管理可以減少權限管理的工作量，也有利于在企業范圍內制定和實施統一的權限標準，避免權限設置不當造成的安全風險。統一安全管控：統一檢測、處理和分析多賬號環境下的安全事件、安全風險，并統一進行事件處理和響應，統一安全管控可以減少安全管控的工作量，也有利于在企業范圍內制定和實施統一的安全規范。5.全方位立體化的安全運營，端到端閉環風險1)安全運營目標：安全運營

203、的工作圍繞兩個大目標進行：防入侵，防攻擊；防入侵的運營子目標有：消除自身脆弱性、消減安全入侵威脅、掌握更新更全的脆弱性及威脅的情報知識；第二章|云原生 2.0 的技術及架構特征066 防攻擊的運營子目標有：快速消減 DDos 威脅、快速消減掃斷威脅、持續發現并清理招來DDos 及掃斷的灰黑產業務；2)安全運營流程：端到端可閉環風險的安全運營，主要分如下階段：安全日志集成：基于分布式無碼采集技術，對云原生的產品的安全日志、以及多云日志集成，集成過程中完成歸并、富化等初始加工；建模分析：基于大數據分析引擎，自動化的關聯分析，基于 AI 構建流式模型，自動冒泡預警安全風險；安全風險預警及呈現：可拖拽

204、的安全風險可呈現與大屏、報告中，可以被安全管理人員、安全值班人員感知到；告警響應及處置：對所有預警進行全生命周期的閉環管理，基于 SOAR 技術自動化源編排、排班值班、響應處置、轉事件、調查、關單等；3)安全運營要素：為了可閉環風險的安全運營流程，安全運營需要具備如下要素：具備安全運營經驗的專家團隊；可沉淀安全運營經驗的運營平臺；安全防護套件及工具，提供安全數據以及執行安全策略；4)安全運營場景：安全運營的大型場景，主要分為如下幾類：日常安全運營：日常過程中，基于各安全要素，對各個安全目標，執行各安全運營流程，發現、消減風險，并對流程進行持續改進，避免風險再次發生；重大保障：重大節日、假日、活

205、動、會議期間，進行高強度 7*24 的安全保障，側重于防攻擊，保障業務可用性不因安全攻擊受影響；防護演練：國家機關單位、地方政府、企業組織的攻防演練中，進行高強度的安全防守保障，側重于防入侵，保障不因入侵失分被問責：通報、批評等；安全評估：重大保障及防護演練前，信息全面的脆弱性盤點，包括白盒方式的基線評估、黑盒方式的攻擊面、攻擊路徑探測。067云原生 2.0 架構白皮書第三章華為云云原生2.0架構設計模式 068華為持續為千行百業的企業及政府客戶提供基于華為云服務的解決方案與最佳實踐，特別是全棧云原生的技術與架構方案，完成其數字化、智能化戰略轉型，并積累了豐富的經驗教訓與方案樣板?？紤]到華為自

206、身也是一家以數字化產品與解決方案制造為核心的大型企業，在近 10 年以來以云技術為底座的流程與 IT 數字化轉型過程中，也總結沉淀了一整套體系化的企業信息架構云化的方法論及最佳實踐，華為通過將華為云服務的外部企業、行業客戶，以及華為流程 IT 自身數字化、智能化轉型的核心關注點、企業組織與文化、工程實施能力等方面，與云原生架構與技術等進行有機結合，形成了華為獨有的云原生架構設計方法HCNAM（Huawei Cloud Native Architecting Methodology）。HCNAM 是一個2+3+1的云原生戰略解碼及架構設計的端到端閉環流程，2代表企業戰略視角，以及業務發展視角，是

207、云原生架構重構及演進的商業及業務層面的驅動力及規劃的源頭，3代表架構視角、工程視角，以及組織視角，是云原生架構重構及演進的設計及落地實施過程，1表示貫穿上述2+3要素的云原生架構的架構持續演進閉環。2+3+1華為云原生架構設計閉環的整體構成如下圖所示：華為云原生架構設計方法(Huawei Cloud Native Architecting Methodology)3.1上一章節系統化地闡述分析了為充分釋放全棧云服務的潛力，作為云原生 1.0 升級版的云原生 2.0，應具備哪些新的關鍵技術與架構原則，以及相應的技術架構特征背后的商業驅動力。而本章節，我們將更進一步逐一分享華為云具體是如何將上述云

208、原生 2.0 的關鍵技術與架構原則應用到全棧云服務產品及其組合的開發、測試、上線再到運營運維的全生命周期過程，以及相關的典型業務應用場景中，并總結提煉了一系列與之對應的云原生 2.0 架構設計模式，從而為華為云生態千行百業客戶的 IT 云化、智能化轉型開發者、運營運維人員提供更具參考和指導意義的最佳實踐與經驗模板。第三章|華為云云原生 2.0 架構設計模式069云原生 2.0 架構白皮書3.1.1 企業數字化戰略 云原生技術架構的根本驅動力任何技術架構首先必須服務于企業的數字化戰略，而云原生架構作為企業數字化轉型的核心引擎與黑土地平臺，不僅僅是一個技術升級過程，更是一個通過不斷迭代重構技術架構

209、，使其與企業的核心業務生產業務流程和數據流程不斷對齊，從而更進一步推動企業核心業務更敏捷地響應客戶的需求，并將創新能力持續提升的過程。換言之，云原生架構本身就是企業整體數字化戰略轉型實施過程中不可或缺的一個關鍵環節與使能器，這也完全符合“康威定律”的總結：僅當技術架構與企業組織與業務架構高度吻合時，才能達到最高效的運作效率。不僅僅是高科技互聯網企業，隨著企業數字化、智能化不斷滲透到千行百業，特別是面向實體經濟的制造業、服務業、政府惠民便民服務等場景，與實體世界一一對應的數字化孿生世界對云計算、大數據、AI、IOT以及音視頻等技術與服務能力提出了更為廣泛與深入的需求。事實上，越來越多的企業正在越

210、來越重視 IT 數字化與云轉型戰略在企業整體戰略中的位置，而圍繞企業 IT 與業務橋梁建立、企業信息安全可信、企業核心數據資產沉淀梳理的關鍵崗位角色如 CTO（Chief Technology Officer）、CIO（Chief Information Officer）、CTIO（Chief Technology&Information Officer）、CDO（Chief Data Officer）等也應運而生。圖 3-1 華為云原生架構設計架構（微）服務架構自動化運維高可用自服務云基礎設施與平臺服務分布式彈性伸縮多租戶組織全功能團隊AM團隊FSD全棧工程師工程微服務持續交付DevOps自

211、動化研發環境外在價值企業可持續發展企業數字化戰略架構設計持續改進與閉環快速規?？煽快`活高效第三章|華為云云原生 2.0 架構設計模式0703.1.2 業務可持續發展 云原生技術架構的直接驅動力華為云基于為企業提供的云服務和咨詢最佳實踐，總結數字化業務對云架構的主要訴求是業務連續性、業務快速上線、成本以及科技賦能業務創新。業務連續性訴求主要包括了數字化業務必須能夠持續為用戶提供服務，不能因為軟硬件故障或者 bug 導致業務不可用，也能夠抵御黑客攻擊、數據中心不可用、自然災害等意外事故。此外，當業務規?？焖僭鲩L時，不能因為軟硬件資源來不及購買或者部署而導致不能拓展新用戶。市場瞬息萬變，數字化業務由

212、于比傳統實體業務更靈活可變而被要求更快的推向市場能力，包括新業務快速構建的能力、現有業務快速更新的能力。這些能力訴求被云原生架構深刻理解并在產品、工具、流程等層面得到不同程度的處理，需要注意的是這個訴求同時對組織結構帶來了新的要求，也可能要求應用進行徹底的重構（比如微服務化）。云計算作為新的技術必須為企業釋放成本紅利，幫助企業從原來的 CAPEX 模式轉變為 OPEX 模式，不必事先購買大批軟硬件資源，而是用多少付多少；同時大量采用云原生架構也會降低企業開發和運維成本，有數據展示通過采用容器平臺技術就降低了 30%以上的運維支出。傳統模式下如果要使用高科技技術賦能業務，有一個冗長的選型、POC

213、、試點和推廣的過程，而大量使用云廠商和三方的云服務，由于這些云服務具備更快的連接和試錯成本，且在不同技術的集成上具備統一平臺和統一技術依賴的優勢，從而可以讓業務更快速的應用新技術進行創新。3.1.3 架構設計視角 云原生技術架構本身1.服務化能力以服務/微服務為最小運行態單元構建業務應用，參照業務功能及其迭代周期進行單體應用的解耦拆分，并將多個服務/微服務以標準化 API 形式進行集成與編排；服務間采用事件驅動的方式集成，盡量減小相互依賴；通過可度量建設不斷提升服務/微服務的 SLA 能力。2.彈性能力服務/微服務需要能依據動態業務峰值的變化，進行相應的資源負載實例的擴充和收縮。3.可觀測能力

214、為保障企業業務的不中斷連續運作，企業 IT 基礎設施及其業務應用中的任何軟硬件發生錯誤后均需要能快速修復，由此要求相關的服務/微服務具有全面的可觀測性，從傳統的日志方、監控、告警/事件，到面向微服務的端到端鏈路跟蹤，以及服務 QoS/SLA 度量。071云原生 2.0 架構白皮書4.韌性能力要求業務應用基于微服務框架能力，或基于自身業務直接構建常用的熔斷、限流、降級、自動重試、反壓等能力，同時進一步構建面向可靠性魯棒性的高可用容災、異步化的特性。5.安全可信能力關注企業業務的數字化安全，除充分利用云安全服務加固企業業務應用的全方位應用安全、數據安全、網絡安全、平臺安全的同時，將安全可信管控制引

215、入到 DevSecOps 軟件生命周期開發的全流程各個關鍵里程碑點，確保企業應用符合 ISO27001、PCIDSS 等級保護等國家區域與行業的云安全合規要求。6.自動化水平隨著企業大顆粒的單體業務應用被重構改造為小顆粒的服務/微服務解耦架構，相關服務/微服務的全生命周期管理，包括開發、構建、測試、部署、升級、擴容等過程與活動如不能實現敏捷自動化，則可能反而為企業業務應用 IT 系統的運維效率及復雜度帶來巨大挑戰，為應對這一挑戰，服務/微服務軟件的發布部署從基于物理機或虛擬機的軟件包安裝配置演進為基于容器技術的集裝箱式封裝，并通過引入 IaC（Infrastructure as Code，基礎

216、設施即代碼）自動化編排機制，以及 TOSCA/Terraform，及 CNCF OAM 等主流生態兼容的 DSL 云服務編排部署腳本；GitHub/Jerkins 等自動化 CI/CD 流水線及運維工具能力，從而打通各層云服務，以及自動化運維工具之間的信息斷點與流程斷點，實現從企業業務原始需求輸入，到需求開發實現并上線驗證部署，乃至后續修改變更的全流程自動化。7.云邊協同能力隨著互聯網行業內上云業務流程從非實時移動互聯網業務迅速向低時延互動視頻直播、游戲AR/VR 驗證發展滲透，同時隨著全面云化、數字化進一步從互聯網領域延伸到千行百業，也必然對上云業務與工業互聯網生產現場設備、智慧城市物聯終端

217、設備之間的接入時延提出了更高要求：通常工業互聯控制邊緣場景小于 5ms 時延，互動直播、AR/VR 游戲則要求小于 20ms。因此，唯有將云端應用靠近數據產生端的部署，才能可能解決上述這些日益苛刻的云業務接入時延訴求。除時延外，海量智能物聯設備所產生的海量數據的上傳云端的成本也不容忽視，隨著物聯網時代邊緣數據爆炸性增長，全球數以百億計物聯終端接入到互聯網的數據容量高達 50 萬億 GB。如此海量的數據全部回傳至云端顯然成本過高，需要數據在上傳云端前即在本地就近的邊緣節點側展開分析和過濾，再向云端上傳預處理后的數據，從而大幅節省網絡帶寬；而鑒于部分企業客第三章|華為云云原生 2.0 架構設計模式

218、072戶對其核心或涉密業務數據場景的數據敏感隱私安全需求，可能要求數據處理變換在客戶本端數據中心內完成，從而實現企業敏感數據及個人隱私信息的僅在本地處理，杜絕了不可控的數據外傳風險。最后，云邊協同的邊緣節點雖然日常要求與云端保持長連接，從而使得云端保持對邊緣節點運行健康狀態的管理能力，但在本地網絡與云端斷連的情況下，要求邊緣側可在一段時間內不依賴云端連接控制及終端的離線處理能力、自我恢復能力。8.無服務器化程度在業務中盡量使用云服務而不是自己持有三方服務，特別是自己運維開源軟件的情況；并讓應用的設計盡量變成無狀態的模式，把有狀態部分保存到云服務中；盡量采用 FaaS、容器/應用無服務器的云服務

219、。指標維度HCNAM-L1（1 分）HCNAM-L2（2 分）HCNAM-L3（3 分）HCNAM-L4（4 分）HCNAM-L5（5 分）服務化能力無(單體應用)部分服務化 有跨服務數據共享全部服務化，無治理體系全部服務化，嵌入式微服務治理平臺全部服務化，服務網格化彈性能力手工擴容（月/周級）資源監控+人工干預擴縮容（天級）資源監控+代碼實 現 基 于 VM 的自動擴縮容（分鐘級）資源&應用監控+代碼實現基于VM 自 動 擴 縮 容（分鐘級）資源&應用監控+代碼實現基于容器的自動擴縮容（秒級）無服務器化程度應用邏輯及底層中間件、DB 均采用進程資源，物理多租事件驅動的無狀態計算數據庫、中間件

220、、文件系統提供邏輯多租服務數據庫、大數據等有狀態服務的Serverless 化端到端有狀態中間件/數據庫+無狀態應用的Serverless 化可觀測能力無有基礎監控、告警、日志類監控在 L2 基礎上，支持端到端跟蹤，性能指標上報及故障根因定位在 L3 的運維監控日志大數據，支持多維度分析，監控數據事件精度分鐘級監控數據事件精度秒級，基于實時監控流數據的洞察觀測能力安全可信能力防火墻+傳統安全 3 方件安全及網絡功能軟件化、分布式可 擴 展，IAM 多租身份標識與認證管理租戶級數據安全加解密及隱私數據脫敏，租戶內資 源 分 組 RBAC控制安全威脅與態勢感知，自動化風險響應，租戶內資源實例級細粒

221、度權限ABAC 控制基于零信任的安全多方計算，行業合規自動化評估，聯邦學習，安全能力融入 DevOps 全生命周期流水線073云原生 2.0 架構白皮書根據對上述 8 個云原生架構維度分別展開評分并匯總，并最終基于匯總評分對企業業務應用進行云原生架構成熟度的定級：云原生架構成熟度1 級入門級2 級基礎級3 級標準級4 級發展級5 級 成熟級級別與定義=34-1213-2829-3738-40表 3-1 企業云原生成熟度評估模型表 3-2 云原生架構成熟度級別與定義指標維度HCNAM-L1（1 分）HCNAM-L2（2 分）HCNAM-L3（3 分）HCNAM-L4（4 分）HCNAM-L5（5

222、 分）韌性能力無冗余，無流控及容災機制本 地 主 備/負 載均衡 HA 冗余(RTO 10 分鐘級)基本流控能力跨地主備或多活容 災（50-100 公里）增強流控能力（峰值 10 倍于可處理流量）本地主備或多活容災，跨地冷備容 災（數 百 至1000 公里）先彈性擴展，再出發流控及反壓；面向微服務的熔斷、限流、反壓控制機制全 球 化 Serverless業務分發，切流無感 知，容 災、流控失效后，系統具備降級能力，確保最小功能集可連續提供，并提供逃生 機制自動化水平無單層平臺或單個服務軟件支持基于文件的半自動化安裝 CI/CD單各云服務/微服務基于容器自動化的 CI/CD 流水線基于終態+過程

223、驅動相結合的 DSL自動化的全棧業務應用及其所賴的云服務、公共的自動化發放AI 使能的系統運行參數優化，以及無人干預自動化修復云邊協同能力無云端資源池拉遠到與分布式 CDN站點共站址，下沉云服務 10%云端資源池拉遠到與客戶的 On-Premise 數據中心站點，下沉云服務 40%云端 K8S 容器通過 KubeEdge 邊緣將容器拉遠部署在邊緣節點上，并支持邊緣證書發布及管理跨云邊統一協同、事 件 EDA 驅 動 的Serverless 開 發 與編排支持云服務 Traffic全球性智能路由3.1.4 組織變更視角云原生架構涉及到的架構升級對企業中的開發、測試、運維等人員都帶來了巨大的影響，

224、技術架構的升級和實現需要企業中相關的組織匹配，特別是架構持續演進需要有類似“架構治理委員會”這樣的組織，不斷評估、檢查架構設計與執行之間的偏差從開發團隊視角，必須實現從原有水平細化分工的瀑布式開發到 DevOps 敏捷式全功能開發的轉變。第三章|華為云云原生 2.0 架構設計模式0743.1.5 工程變革視角DevOps 運維工具、數字化運維運營平臺是企業云原生架構落地不可或缺的前提條件。構建Cloud Native 工具鏈，實現從開發人員提交代碼，到構建、測試、發布、反饋的自動化和持續交付流水線；基于 IaaS 和 PaaS 建設軟件開發云 2.0，給產品提供完整的 IaaS 和 PaaS

225、服務，實現服務共享、互通和版本配套；產品要基于開發云環境和 Cloud Native 工具鏈進行開發。3.1.6 架構持續演進閉環云原生架構演進是一個不斷迭代的過程，每一次迭代都是從企業戰略、業務訴求到架構設計與實施的一個完整閉環，整體關系如下圖：圖 3-2 架構持續演進閉環從上圖不難看出，整個企業云原生架構持續演進閉環中初始關鍵輸入為企業戰略及業務發展策略，及其層層解碼后映射到 IT 技術視角的一系列原始包需求與設計分解需求；而該云原生架構持續演進閉環中的關鍵過程則包括：參照持續更新的原始包需求及設計分解需求，不斷識別業務痛點和架構債務、確定架構迭代目標、評估架構風險、選取云原生技術、制定迭

226、代計劃、架構評審和設計評審、架構風險控制、迭代驗收和復盤。企業戰略視角業務發展視角架構持續演進閉環識別業務痛點和架構債務01.確定架構迭代目標02.評估架構風險03.選取云原生技術04.制定迭代計劃05.架構評審和設計評審06.架構風險控制07.迭代驗收和復盤08.075云原生 2.0 架構白皮書1.統一認證鑒權企業基于全棧云原生服務能力進行云化業務應用開發或重構，基于“零信任選擇”，企業應用業務軟件必須統一對接華為云的 IAM 認證系統，已獲取訪問全棧云服務能力的合法權限，如自身開發的服務希望以多租行業云服務形式進一步對外開放，則也需要完成與 IAM 對接，從而實現租戶模型、認證和權限管理的

227、統一。2.統一運營計費若新開發的 SaaS/行業 aPaaS 也需提供面向企業 2B 多租用戶的計量計費功能，則各云服務軟件必須遵從統一的計量話單和計費規范，實現計量話單的標準化輸出和計費模式的統一。圖 3-3 華為云云原生架構企業云原生架構的可持續演進與迭代能力：基于服務開發服務3.2云原生應用網絡云原生基礎網絡云原生硬件智能網卡OVS卸載（182x）通用計算CPU（X86/鯤鵬）異構計算NPU/GPU（昇騰/笛卡爾）容器引擎/虛擬化卸載云原生網絡直通及服務網格加速云原生存儲卸載（SDI）超融合機柜（FusionPod）云原生低時延網絡UBUS云原生操作系統輕量級容器引擎 Container

228、d/iSulad/WASM安全容器 輕量級虛擬化Qemu/Stratovirt云原生負載均衡ELB云原生虛擬化網絡VPC(CNOS)云原生網絡高速軟交換Gaea云原生L4負載均衡IPVS/CVS云原生應用L7負載均衡Nginx/Envoy云原生網格Terrace云原生超低時延鏈路協議CurreNET云原生網關xGW云原生容災管理云原生存儲網關（K-V/S3/HDFS/CIFS）云原生分布式K-V存儲引擎（DFV）云原生對象存儲OBS云原生塊存儲EVS云原生文件系統SFS云原生容器引擎 CCEServerless容器引擎 CCI云原生統一資源調度(瑤光+柔性計算）云邊拉通、跨Region全域調度

229、云原生Serverless Runtime調度 元戎內核/KNative云原生統一應用調度 Volcano云原生批量計算BCE/EKS云原生消息中間件DMSAI開發套件云原生微服務框架云原生CloudIDE云原生軟件調試云原生可信代碼倉可信二進制倉云原生編譯構建云原生測試工廠云原生服務網格 ASM（非侵入式，服務發現/流量治理/應用代理/RPC)云原生服務市場OSC(服務目錄&管理)容器鏡像倉庫 SWR(容器Registry)多云容器編排MCP(Karmada)微服務治理ServiceStage（侵入式，Java/Go）云原生應用編排IAC/AOS(Terraform&TOSCA)無服務器應用

230、托管（WebHosting etc.）CleanCode監控告警全鏈路跟蹤CMDB配置變更日志分析故障管理容器洞察CIE(Prometheus)云原生開源治理AI市場視頻直播 LIVE視頻點播 VOD媒體處理 MPCCloud XR實時音視頻 RTC云會議 meetingIoT行業生態工作臺IoTStageIoT邊緣IoTEdgeIoT數據分析IoTA設備接入管理IoTDA認知計算AI(行業知識圖譜)感知計算AI(視頻，OCR，語音，NLP,時序預測.)ModelArts OS底座云原生緩存中間件DCS云原生應用集成Connect云原生資產運營Exchange云原生函數FunctionGrap

231、h云原生Serverless事件中心云原生HC Linux(含云原生容器OS/CNOS)云原生應用系統加速Runtime-CNSR云原生硬件云原生OS云原生彈性資源云原生應用平臺云原生應用生命周期管理云原生生態使能云原生計算云原生中間件用戶標識與認證授權IAM租戶資源組隔離EPS云原生多租認證與權限管理客戶管理訂購與交易履行產商品管理計費/賬單/成本管理服務信控計量話單SDR云原生運營與計費管理面APIGW（外部）管理面APIGW（內部）租戶面APIGAPI治理云原生API開放Web前端框架Web后端NGINX云服務ConsoleConsole代理云原生Web Console云原生AI云原生視

232、頻云原生物聯網云原生服務開發流水線DevSecOps云原生服務治理與編排云原生物聯網云原生數據庫混合云 CCE敏捷版邊緣容器服務 IEF(KubeEdge)邊緣系統 IES邊緣站點 IEC云原生邊緣及混合云云原生安全可信云原生大數據云原生存儲數據智能基礎設施 DII數據治理中心 DGC數據湖目錄 DLCatalogue物理多租 批處理MRS邏輯多租多引擎DLI數據倉庫DWS搜索引擎CSS多方計算TICSNo SQL大數據 CloudTable流式數據集成DIS數據搬遷CDMAPI/SDK(JDBC/C/C+/Python/.NET)分布式DB Server&分布式鎖（Share Everyth

233、ing&Share Nothing）Tool Kit DB管理(DAS)DB容災(DRS)分布式SQL引擎分布式文檔引擎分布式K-V/時序引擎分布式圖引擎流量清洗 AntiDoS檢測與響應類憑證類Web防火墻 WAF云堡壘機CBH態勢感知 SA安全策略管理SPM主機安全HSS容器安全CGS數據庫安全DBSS數據加密DEW證書管理CCM憑證管理CCMS審計類政企與互聯網應用與開發生態入口第三章|華為云云原生 2.0 架構設計模式0763.統一服務 API 開放對于新開發產品必須開放 API，并遵從統一的 API 開發設計規范，實現開放 API 的標準。4.統一 API 網關統一各新開發的服務直接

234、對接到統一的 API 網關，為后續業務應用的開發者用戶提供統一的入口調用各個服務的 API。5.運維管理統一新開發運營的日志、告警、監控等功能必須使用統一的租戶運維管理工具服務。6.通過基于服務開發服務，實現公共組件的“云原生歸一化”嚴格遵從“基于服務開發服務”的架構原則，實各服務盡量統一到優選的數據庫、集群管理、負載均衡、消息隊列等。7.統一安全可信管理服務各云服務遵守統一的云領域的可信架構方法，與相應的安全性、韌性、隱私等可信管理服務集成，實現相關可信能力的落地。3.3.1 分布式云設計模式分布式云設計的核心是基礎設施的部署方式。其中中心云可以通過公有云承載，也可以通過云服務供應商交付全棧

235、云架構到企業的本地機房。分布節點根據其業務訴求也會有所差別。業務場景較為簡單、清晰，但是又一定計算能力訴求的分布式節點可以通過邊緣云承載；跨國、跨區域業務，可通過公有云跨 region 業務部署模式承載；分支節點業務量大、業務場景復雜的場景，也可以考慮本地專屬 region 的交付方式。因此，分布式云的設計模式，按照云服務的交付模式可以大致分為三種：華為云云原生2.0的典型架構設計模式3.3077云原生 2.0 架構白皮書1.公有云+邊緣云邊緣云上部署 CDN、就近接入視頻直播、AI 媒體轉換處理，邊緣云服務是華為云基礎設施的一種延伸形態，部署在城域熱點區域的位置，滿足大流量和低延時的業務需求

236、。圖 3-4 公有云+邊緣云架構圖 3-5 內容源站場景互動直播中心云邊緣云視頻RTCVR渲染資源調度覆蓋熱點區域沉浸式智真協作智真會議終端PC桌面智慧屏手機平板/電腦20ms流量調度站點部署管理運維云游戲引擎視頻AI在線教育應用加速智能視頻智能邊緣云IEC管理面云游戲云VRIEC邊緣站點高階服務基礎服務擎天架構多元算力網絡轉發IEC邊緣站點高階服務基礎服務擎天架構多元算力網絡轉發IEC邊緣站點高階服務基礎服務擎天架構多元算力網絡轉發1)內容源站場景多運營商線路同站點接入，快速獲取資源降低客戶內容源站壓力。為客戶提供彈性、安全、可靈活擴展和伸縮的邊緣計算網絡服務，為短視頻、游戲、直播、教育等多

237、場景提供一站式內容分發解決方案。華為云IEC邊緣站點CDN內容中心全局調度負載均衡內容緩存內容訪問信令交互內容源站日志分析IEC邊緣站點負載均衡內容緩存內容訪問信令交互第三章|華為云云原生 2.0 架構設計模式0782)就近視頻接入場景高性價比的海量視頻接入能力，助力客戶實現業務可持續經營。通過智能存儲、視頻 AI，多線網絡接入等技術有效解決視頻接入中心云流量成本高，以及熱點區域覆蓋問題。圖 3-6 就近視頻接入場景圖 3-7 互動直播媒體轉換場景3)互動直播媒體轉換場景借助多元算力、AI 智能服務、就近接入網絡技術，滿足用戶解決降低成本和時延、提升業務處理性能等訴求，助力用戶更好的處理就近轉

238、碼、彈幕分發、實時渲染、內容審核等核心業務。華為云IEC邊緣站點CDN內容中心智能手機OBS直通訪問視頻流視頻存儲視頻智能攝像頭OBS網關視頻接入按需查看三線接入IEC邊緣站點智能手機攝像頭OBS網關視頻接入按需查看三線接入IEC邊緣站點直播轉碼內容渲染主播音視頻流彈幕流CDN分發流主播觀眾觀眾彈幕分發內容審核IEC邊緣站點直播轉碼內容渲染彈幕分發內容審核華為云CDN網絡直播中心視頻存儲視頻智能視頻存儲視頻智能079云原生 2.0 架構白皮書 基于邊緣 IEF 的視頻 AI 及流處理，云端 ModelArts 訓練，模型推送到 IEF，兼容非 AI 傳統終端上圖表示了一個用該模式實現的智慧工業

239、場景，根據對從產線上采集到的信息進行推理分析來不斷優化產線參數，達到最優化生產的目的。在該系統中，部署于云上的 ModelArts 服務利用云上的資源完成海量數據預處理及半自動化標注、大規模分布式訓練、自動化模型生成，而后通過 IEF（智能邊緣平臺）將模型部署到邊緣。IEF 服務將云上訓練好的 AI 應用以容器形式推送到指定的邊緣節點，提供邊云傳輸通道，聯動邊緣和云端的數據，支撐 AI 應用實現邊云智能協同。同時提供升級、監控、日志等運維能力。邊緣 AI 容器加載模型，實時從設備獲取數據，通過推理進行瑕疵檢測，根據結果調整生產設備的參數，提升良品率。邊緣產生的數據和推理結果周期上傳到云上的 M

240、odelArts 服務，用于持續模型訓練和生產分析。通過華為云 IEF 服務管理基于開源云原生邊緣計算項目 KubeEdge 定制的邊緣一體化系統KubeEdge 是 CNCF 中的首個云原生邊緣計算框架。該項目面向邊緣計算場景，專為邊云協同設計，旨在提供應用協同、資源協同、數據協同和設備協同的統一標準。IEF 是華為云中提供的KubeEdge 商用版服務，與 KubeEdge 生態完全兼容，可對用戶使用 KubeEdge 為自己特殊的邊緣形態深度定制化的系統提供統一的云上管理能力。數據集管理產線維護生產計劃良品率分析EI服務模型部署數據集管理模型訓練IEF接入服務應用管理邊緣運維資源調度產線

241、通信容器管理EdgeAgent函數管理1.發放/更新邊緣應用5.持續訓練4.傳遞數據邊云通道3.周期上傳檢測數據和結果2.啟動邊緣容器1.讀取視頻流2.調整參數工業平臺-AI應用視頻接入瑕疵檢測任務管理邊緣AI容器/函數產線調節數據管理圖 3-8 IEF 用于智慧工業場景第三章|華為云云原生 2.0 架構設計模式080上圖展示了該模式在云原生衛星場景中的使用。在該場景中，使用邊云協同的模式從地面對衛星上的 AI 遙感模型進行管理，并且通過 KubeEdge-Sedna 的能力使衛星具備了與大云進行協同推理、增量訓練的能力，讓衛星越來越聰明。在衛星中，對設備功耗要求嚴苛，從星載設備到操作系統再到

242、上面運行的軟件都有嚴格的要求。為了滿足衛星上的使用，需要對 KubeEdge 進行兼容性、輕量化等方面的深度定制。只需保證定制后的系統滿足社區的“平臺一致性認證”，即可保證該邊緣可以連接至華為公有云，利用公有云的海量算力支持業務運行。2.公有云跨 Region1)多云容器場景：互聯網 App 的跨 Region/跨云統一彈性伸縮，跨 Region/跨云統一微服務治理圖 3-10 多云容器場景系統管理員MCP集群聯邦管理ASM網絡數據面資源利用率低中心云專屬Region全局容器網絡邊緣站點A邊緣站點B推理中間件推薦數據庫網站ASM網絡數據面資源利用率高ASM網絡數據面ASM網絡數據面資源利用率高

243、彈性流量治理數據庫廣告用戶LBLB視頻轉碼視頻資源利用率高LB視頻視頻視頻數據廣告網站數據數據數據ASM全局服務治理中心圖 3-9 IEF 用于遙感衛星場景遙感衛星華為云星載邊緣一體化遙感設備EdgeCloud遙感目標檢測（小模型）衛星地面信號站KubeEdoe-Sedna遙感目標檢測（大模型）IEF服務081云原生 2.0 架構白皮書上圖是抽象了互聯網客戶的場景，用戶的業務分別部署在中心云和專屬 region 上以及多個邊緣站點上，這樣用戶希望多地集群資源能夠進行統一的管控，從而提升資源的利用率。在此基礎上希望將多集群間服務就行統一治理，降低服務延遲和提升服務的流量分發效率。通過 MCP 集

244、群管理能力，可以把這些分布式集群統一就行管控，這樣當流量高峰時候，單一便于站點的資源利用率持續升高，提高了業務由于資源不足的故障可能性，這時候就可以通過識別其他資源利用率低的站點，彈性擴容服務，將流量一部分導入到其他站點上來緩解業務高峰時故障發生，完成跨云跨地域的彈性擴容，保證業務可用性，提供資源利用率。而通過 ASM 的全局服務治理，可以使得用戶的訪問流量能夠就近訪問對應集群，降低訪問的端到端時延，提升用戶使用體驗，同時服務在集群間的流量可以識別不同流量就行分發訪問，例如實際訪問流量可以導向邊緣站點，而溢出流量等可以導向其他集群。2)跨國企業用戶跨華為云、伙伴云開通賬號，并使用消費云服務企業

245、在華為云（歸屬云）上完成開戶，申請開通巴黎Reigon、莫斯科Region的“漫游”訪問權限。歸屬云會自動在漫游 Region 所屬的伙伴云創建“漫游”賬號，賦予訪問權限。然后，企業就如使用歸屬云自有 Region 一樣，以統一的賬號、統一 Console、統一 API 網關使用漫游 Region，費用統一結算、統一出賬。圖 3-11 跨國企業用戶跨華為云、伙伴云開通賬號租戶統一入口伙伴云歸屬云歸屬賬號租戶Console華北Region華東Region新加坡Region莫斯科Region巴黎Region河姆斯特丹Region.RegionAPIConsoleAPIConsoleAPI漫游賬號伙

246、伴云漫游賬號3.公有云+本地專屬 region該模式基于專屬云技術，可提供對計算資源、存儲資源、網絡、數據庫等資源的專屬使用，第三章|華為云云原生 2.0 架構設計模式082華為云通過 HCSO 解決方案為政企客戶提供專屬云技術，該解決方案的技術優勢包括：專享合規、安全隔離：用戶獨享隔離的物理資源，滿足業務性能和安全合規要求；就近部署、極致體驗：就近部署在用戶機房，滿足數據不出省或不出機房，高速本地接入，節省跨省鏈路成本，云服務使用時延小于 50ms；穩定可靠、精簡敏捷：繼承云大規模商用成熟架構，代碼相同，體驗一致，業務可用性高；云服務模塊化解耦，可快速同步華為云服務，按需搭配云服務組合，精簡

247、管理和網絡占比，自動化部署快速上線，統一運維，業務平滑遷移和擴展；同構混合、開放生態：基于與華為云統一的擎天架構，構建云上云下無縫協同的混合云架構，共享華為云 MarketPlace 生態，方便直接復用云上豐富的第三方軟件生態。圖 3-12 公有云+本地專屬 region3.3.2 極致性價比驅動的軟硬協同架構設計模式 1.基于擎天/SDI 卡的無 IO 損耗虛擬化/容器化華為云的擎天/SDI 卡通過 SRIOV 獲得 VF 形式的 SCSI Controller，這些 VF 通過 VFIO 直通到容器中。容器內的 IO 讀寫請求將直接發送到運行在擎天卡上的 SPDK 進程，SDPK 進程通過

248、 DMA直接訪問需要讀寫的數據，并進行本地或遠程的 IO 持久化操作，全過程都在 SDI 上運行，不會因HCS Online云服務華為云機房本地機房華為云統一運維華為云機房云服務共享資源池.資源專屬HCS Online云服務全棧專屬云服務同時提供高安全的網絡隔離環境滿足網絡隔離要求，資源獨享可以避免業務高發期資源被搶占造成的業務卡頓情況，從而滿足性能、安全、可靠性、可擴展性等關鍵業務訴求。083云原生 2.0 架構白皮書此占用物理機上的 CPU 和 memory 資源。同時由于采用的是物理設備直通的方式，最大限度地消除了虛擬化帶來的 IO 時延和帶寬的影響。2.基于昇騰卡替代 GPU/CPU

249、的 AI 訓練及推理服務面向 AI 場景，華為云提供昇騰系列云服務器。該服務支持 Mind Studio、自定義編排 AI 業務流，以及 Caffe/Tensorflow 等推理模型，非常適合人臉識別、內容審核等視覺計算類業務，性價比相比業界主流GPU系列推理型實例性價比提升75%。同時，基于華為自研的鯤鵬+昇騰處理器，華為云打造了兩款鯤鵬系列 AI 實例，鯤鵬 AI 推理型實例 KAi1s 和鯤鵬 AI 訓練型實例 KAt1。華為云昇騰 AI 計算解決方案基于昇騰全棧創新的能力，構建開放的開發和服務框架，提供快速被集成，共享標準化組件。昇騰 AI 計算解決方案由推理加速型云服務器 Ai1 提

250、供 AI 算力，其單實例性能半精度 FP16 計算高達 128 TeraFLOPS，整型 INT8 計算高達 256 TeraOPS；其中，單芯片可提供 8GB 顯存，內存帶寬 50GB/s，功耗低至 8w，構建高性價比算力。解決方案中Ascend Serving 層支持 RESTFul 和 gRPC 接口，兼容 FFmpeg 框架，與主流生態無縫對接，無需額外編碼。解決方案的 AI 容器層借助容器的輕量靈活的優勢，可實現 30 秒擴容 1000 容器，為海量的任務快速補充算力，再結合智能任務調度，實現任務與資源的最佳匹配。其以高性價比、高性能、生態兼容為互聯網、智慧園城市、智慧零售、泛金融認

251、證等行業提供全棧賦能。3.應用感知智能自治的云原生 OS云原生下的操作系統變更應滿足以下的特征要求：感知云上資源與負載：云化基礎設施可以看做是一種新型的硬件形態，當前操作系統在溝通協調應用與底層資源匹配上仍存在一定的隔閡，尤其當云上硬件環境發生變化，如多種異構設備下的混合算力模式的時候。因此，云原生下的操作系統應能精確感知底層資源狀況，觀測并收集分析信息給平臺層進行調度決策；對上需要感知具體應用運行負載，根據負載特征進行相關調整。協同全棧的敏捷：前文表述過當前基礎設施與應用開發部署態復雜度進行了置換，在云原生進入深水區后，操作系統自身應和全技術棧一道進行敏捷化，其重要表現為系統的自治，實現系統

252、的自治依賴于對應用、負載、資源及自身運行狀態的感知，可以說上文中特征要求是實現自治的基礎。智能化 AI Native 可定義的操作系統：利用人工智能機器學習等智能化方式結合啟發式經驗化的自動化能力，實現將智能化融入操作系統本身，這里應該包括兩個部分，一方面是利用智能化對整個系統的自治，另一方面是利用智能化手段對操作系統本身進行改造，更適配當前應用所需的運行環境，也是以應用為中心的體現之一。第三章|華為云云原生 2.0 架構設計模式084針對上述技術特征，云原生操作系統包括但不限于以下的技術能力：數據觀測引擎：提供低負載的數據觀測能力，包括對黑盒的觀測與微架構層級的觀測等，形成統一的結構化數據，

253、為數據分析提供基礎能力?？梢宰⒁獾降氖?，觀測能力是基礎能力，但資源消耗是當前觀測能力局限的一個很大的制約?？尚械募夹g手段包括利用 eBPF 輕量化的觀測探針、與硬件結合的細粒度 PMU 觀測手段等。在云原生環境下，數據觀測應該內化為操作系統的基礎能力之一。OS 數據服務：清洗處理數據觀測引擎提供的數據，提供數據分析與數據關系處理。這里的數據服務指操作系統本身產生的數據。在實際的使用過程中，云平臺、框架本身也會提供一定的數據服務，這部分能力應可以結合協同使用。如在華為云平臺中，瑤光提供了一定的數據處理能力，此時這部分數據服務可以進行相應的結合。OS智能自治引擎：包括運行態的自治，即應用運行態性能

254、的自調節，保障應用運行最優環境；運維態的自治，即智能化自動進行操作系統運維操作，包括但不限于系統的升級、故障定位定界與排除等；安全自治，即自動化安全漏洞推送、修復等。當然，除了以上列出的可能的探索點，在云原生下操作系統本身還有諸多可探索的方面。華為云平臺也針對云原生推出了 Huawei Cloud EulerOS 操作系統發行版，上述的這些技術能力也會逐步在該發行版內進行實踐。3.3.3 多元算力統一資源池架構設計模式華為云瑤光云腦支持多異構資源統一調度。云計算規模發展和計算資源多元化趨勢，在資源有效利用、資源成本控制等方面對云提供商的資源供應提出了更高的要求，華為云瑤光統一調度通過算力池化、

255、技術棧統一、數據自驅等技術打造了統一資源管控平臺?，幑饨y一資源管控平臺具有以下特點：1.統一資源調度過去的資源調度中，常常針對不同的硬件資源、不同的器件代系、不同的產品形態獨立建立多個資源池，資源池獨立調度。這主要存在兩方面問題，首先是資源池調度沒有有效實現資源池化，精細程度不足，第二是調度局限在資源池內部，資源池間存在空氣墻。統一資源調度需要統一的計算節點技術?；A，并在調度方面實現資源分層、協同調度。資源池調度系統需要屏蔽多元化算力資源差異，在資源池化基礎上完成在線資源調度、離線資源整理、資源自適應調整等功能，通過精細化調度實現資源利用率的有效提升。資源池間調度系統需要處理多資源池之間的聯

256、系，協調多資源池有序供給，協同應用層進行削峰填谷，實現資源的極致復用。除此之外，統一資源調度還需要完善的配套基礎設施，例如計算熱點最終系統，調度仿真及算法迭代系統，資源供需畫像及預測系統等。085云原生 2.0 架構白皮書2.統一問題建模、求解云計算資源管理領域中存在諸多復雜、多目標、大規模的博弈、優化問題，問題之間相互影響且多屬于 NP 難。建模與求解此類工業級復雜約束的問題一直是學術界和工業界的共同挑戰，針對獨立問題逐個突破幾乎注定無法成功。因此，使用統一的問題建模語言，應用統一的問題求解框架，解耦問題建模與算法求解過程，成為了一個趨勢。3.數據自驅演進超大規模資源的管理和高效利用，高度依

257、賴實時、自動化、智能化的數字化管理能力，平臺需要具有資源、服務、系統等多維度指標數據的實時采集能力，選用合適的存儲系統累計數據資源，支持流、批等多種數據分析及可視化供給，同時與調度、運維等系統聯動、協同，一方面實現資源交付使用全鏈路看護，另一方面為系統架構、功能的長期演進提供數據支撐。3.3.4 無服務器化（Serverless）架構設計模式華為云 Serverless 函數工作流 FunctionGraph2.0 是新一代函數計算與編排服務，聯合華為2012 實驗室傾力打造。圖 3-13 華為云 Serverless 架構大數據&AI端側應用物聯網數據處理音視頻函數開發工具監控調用鏈日志函數

258、可觀測條件分支并行分支循環處理時間等待DDSAPIGLTSOBSSMNKafka觸發器函數編排Fn 1Fn 2Fn n云基礎設施（計算、存儲、網絡、容器）數據庫消息認證存儲BaaS元戎內核CLI CI/CDCloudIDE第三章|華為云云原生 2.0 架構設計模式0861.豐富的函數開發語言及觸發方式讓設計更靈活支持常見的編程語言 python、java、nodejs、go，也支持容器鏡像和自定義運行時。函數調用支持同步和異步兩種方式，最長支持 12 小時，可滿足長時間任務的需求，大大突破傳統serverless 的適用場景。圖 3-14 華為云 Serverless 支持的函數開發語言和函數

259、觸發方式圖 3-15 華為云 Serverless 支持圖形化拖拽方式進行函數編排2.可視化拖拽式函數流支持編排復雜業務場景支持通過圖形化拖拽方式進行函數編排，支持并行分支、條件分支、子流程、循環、異常處理等，可以滿足多函數場景下的快速編排需求。函數開發語言（6大類）函數觸發方式（10+）自定義運行時Shell腳本 orLinux可執行文件容器鏡像版本：6.10、8.10、12.13、14編程語言版本：2.7、3.6、3.9版本：8、11版本：1.xGaussDB(for Mongo)云數據庫Kafka分布式消息服務DDS文檔數據庫服務APIGAPI網關同步 最大運行時長15分鐘DBCTS云審

260、計服務LTS云日志服務DIS數據接入服務OBS對象存儲服務DMS分布式消息服務SMN消息通知服務Timer定時器異步 最大運行時長12小時087云原生 2.0 架構白皮書3.統一插件支持云上和云下的開發與調試serverless 場景下如何對函數進行調試是個難點，我們針對云上云下兩個場景都提供了解決方案，值得一提的是支持了多函數調試能力，目前業界首家。4.HTTP 函數讓 WEB 服務近乎 0 成本改造，享受 Serverless 優勢能力圖 3-16 云上云下兩個場景數支持多函數調試能力業界首個支持集群函數調測VSCode 本地開發測試（云上）CloudIDE 支持：1.通過模板創建函數2.

261、云端函數的查看，下載到云 IDE 在線調試3.函數推送到云端4.當前支持 Java，Node.js 語言（云下）VSCode 插件支持：1.通過模板創建函數2.云端函數的查看，下載到本地調試3.本地函數推送到云端4.當前支持 Node.js，Python 語言圖 3-17 WEB 服務 serverless 化改造方案RDS云數據庫ECS云服務器ECS云服務器ELB典型的WEB服務部署架構RDS云數據庫Client客戶端Client客戶端FunctionGraphWeb ServerWeb ServerWeb ServerAPIServerless化改造方案Server代碼0修改，僅需修改服務

262、端口等少量配置自動創建API網關服務，僅需創建函數第三章|華為云云原生 2.0 架構設計模式088微服務和函數在未來幾年會是一個共存的形態，當前存在著大量微服務應用，如何高效的支撐其 Serverless 化，讓現有微服務快速享用到 Serverless 的優勢能力，是一個待解決的問題。針對 Web 服務，推出 API 網關加 FunctionGraph 的 HTTP 函數方案，用戶只需把原有的 Web Server代碼打包為一個HTTP函數，即可完成Serverless化改造。價值體現在多語言WEB框架支持，例如：Java-Spring Boot，Nodejs-Express 等框架開發的應

263、用極小修改就是能完成 Serverless 函數化改造。開發人員可以繼續使用熟悉的開發框架和測試工具，API 網關服務隨函數自動化創建，降低開發人員學習負擔。改造后無需運維資源，簡單配置即可實現 100ms 級自動彈性和灰度升級。5.函數支持在運行時動態指定資源，靈活調度節省成本圖片壓縮、水印處理、文檔轉換、視頻轉碼是典型的事件觸發，波峰波谷明顯的場景，越來越多地使用 Serverless 函數來開發業務，以視頻轉碼為例，典型的處理流程：圖 3-18 Serverless 函數用于視頻轉碼的處理流程視頻文件的大小從 MB 到 GB，不同編碼格式和分辨率對轉碼需要的計算資源要求差別很大，為保證轉

264、碼函數的性能，通常配置一個很大的資源規格，但是在低分辨率的（例如短視頻）場景下，會造成資源浪費。FunctionGraph 提供了一種方案支持函數執行時可根據業務需要動態指定資源規格，最小化資源占用，可以給用戶帶來更精細的資源控制，更低的成本開銷。用戶OBS存儲視頻上傳視頻FunctionGraph獲取元數據FunctionGraph轉碼VOD視頻點播轉碼工作流089云原生 2.0 架構白皮書圖 3-19 華為云方案在視頻轉碼場景的優勢圖 3-20 有狀態函數支持更多復雜應用6.有狀態函數支持更多復雜應用 當前的 Serverless 方興未艾，為了能夠支撐更廣泛應用的開發和運行，還需要解決一

265、系列挑戰。函數生命周期有限，已加載的狀態無法復用。當前主流的 Serverless 平臺對于函數的生命周期都有時間限制，函數不能長時間運行，只能在有限的時間執行，如 900s（15min）。當函數沒有新的請求時，函數所在的執行環境被銷毀，函數執行的中間狀態、緩存等會被刪除。當新的函數調用發起時，不能直接利用上次計算的緩存狀態。獲取元數據轉碼8CPU分辨率：4K轉碼2CPU分辨率：480P轉碼2CPU6CPU分辨率：480P業界方案，默認配置滿足極限轉碼性能低分辨率時產生資源浪費華為方案，用戶可動態指定資源規格節點節點外部存儲/緩存服務有狀態應用無狀態函數有狀態函數節點Function代碼Fun

266、ction代碼狀態遠程讀寫序列化/通信開銷狀態本地讀寫應用代碼堆/棧/寄存器Global數據系統Local數據系統狀態內存狀態本地讀寫第三章|華為云云原生 2.0 架構設計模式090 數據搬移成本高，影響運行效率。承載業務邏輯的函數在 FaaS 的容器上加載，獨立于數據側（BaaS）運行，函數執行時需要把數據運送到代碼處，而不是把代碼放在數據所在的計算節點運行。對于大數據、分布式機器學習等場景，數據的搬移開銷會影響這些工作負載的運行效率，同時也會給數據中心網絡造成負擔，這大大限制了 Serverless 的應用范疇。借助于類似 OBS 的對象存儲服務，要比點對點通信慢、成本高。為了解決這些挑戰

267、，FunctionGraph 推出有狀態函數，有狀態函數編程模型提供了方便的函數定義方式，以及語言無關的狀態定義方式。由于不需要頻繁地和外部存儲進行交互，減少了網絡訪問的次數，從而能夠獲得更低的時延。數據不需要分發到外部存儲中，也不需要緩存到其它節點上，在可用性和一致性方面得到提升。由于用戶請求與節點存在粘性連接，用戶只需和一個函數實例發生交互，存取狀態數據更為容易，通常只需要對函數中的一個簡單結構體進行操作即可。另外，由于 FunctionGraph 服務接管了狀態的管理，可以為用戶提供多種數據一致性模型，以及處理并發場景下死鎖的問題，從而使得編程模型更加容易理解、用戶程序更加簡潔。7.對應

268、用無感知的倒換支撐數據庫 Serverless傳統的數據庫部署模式，用戶需要先從應用視角規劃數據庫容量，再根據實際運行情況調整規格，而調整規格往往意味著數據庫需要重啟甚至倒換，引起應用連接的中斷，影響用戶體驗。而 Serverless 的部署模式只需要用戶給定資源的上限下限，讓云平臺自動根據運行的負載調整實例規格，利用華為云數據庫的應用無損透明倒換技術(ALT)，規格變更可以實現應用基本無感知。讓開發者專注于應用開發，無需關注資源。圖 3-21 從“以資源為中心”到“以應用為中心”的部署模式以資源為中心以應用為中心Serverless部署傳統部署評估應用訪問壓力，得出性能評估模型最低規格規劃應

269、用容量評估數據庫資源購買匹配規格調整規格最高規格升級規格1升級規格n.負載下降負載上升根據性能評估模型檢測出數據庫資源需求根據數據庫資源需求購買響應規格的數據庫資源根據應用現網運行情況重新調整規格匹配資源091云原生 2.0 架構白皮書3.3.5 存算分離架構設計模式華為云基于云原生數據湖+云原生數據庫底座提供存算分離的一站式數據處理方案。1.計算和存儲資源解耦，各自彈性伸縮華為云存算分離方案的實施，計算和存儲資源的解耦，可以實現：存儲和計算各自按需彈性擴展，通過容器化技術實現計算彈性伸縮，徹底釋放算力的流動，實現了資源價值的最大化，更為靈活和可靠的一站式數據處理整體方案，性能超過存算合一方案

270、 20%，整體成本降低 30%。2.云原生云存儲能力升級，支撐大數據計算云原生數據湖云存儲，基于對象語義能力升級，通過擴展 Posix 文件語義，實現了：高性能 Rename 原子操作，滿足 MapReduce 過程中性能訴求。Append、hflush&hsync 支持，完善 HDFS 語義支持，滿足流計算場景的接口語義兼容性。圖 3-22 華為云存算分離架構HDFSPOSIX數據湖云存儲Data Multi-Protocol云容器彈性云服務器裸金屬服務器兼容S3第三方大數據AI訓練平臺華為云大數據MRSDLIModelArtsTensorFlow圖 3-23 云原生數據湖云存儲對象語義能力

271、升級新增API接口PUT(Modify)POST(Append)POST(Rename)并行文件桶（Posix文件語義）標準對象存儲桶OBSFilesystem(HDFS FileSystem語義實現)云存儲OBS API(兼容S3)COPYDeletePUTGETPOST第三章|華為云云原生 2.0 架構設計模式0923.數據全生命周期 PipeLine 計算，多協議數據共享采用數據湖底座云存儲，支撐 Pipeline 多種計算場景。一份數據多協議共享訪問（S3/HDFS/Posix 協議），數據免拷貝，提高了計算分析效率，節省了數據保存成本。圖 3-24 PileLine 多集群計算，數據

272、多協議共享訪問4.云原生近計算緩存，實現高性能數據計算 IO 加速存算分離后，計算集群從云存儲拉取數據進行計算，針對高性能計算場景需要更高性能的存儲介質，提升 IO 效率。大數據和 AI 計算場景，通過計算引擎內置分布式緩存，基于內存和 SSD存儲介質提升 IO 效率。云原生的近計算緩存，定位于近計算、輕量化、任務感知的高性能智能緩存服務層，通過數據湖 IO 加速，實現大數據&AI 計算場景 1.5 倍的性能提升。關鍵特性包括：基于內存+SSD 池化，無 NameNode 分布式緩存；利用 RACE Hashing 索引，數據分片多節點并發預??；計算任務感知、文件格式感知等智能數據預取手段；數

273、據預取流量 Qos 控制能力等。圖 3-25 云原生近計算緩存SparkSQLFlink流計算數據湖云存儲數據入池離線分析計算即席查詢計算數倉計算AI計算 KafkaMR任務SparkStreamingHivePrestoImpalaDWSTensorflowCDMOMS本地盤本地盤HDFS協議HDFS協議S3協議S3協議HDFS協議S3/Posix 協議 數據全生命周期3rdPartyMRS/DLIDWSModelArtsOne CatalogCompute Pod云原生近計算緩存數據湖云存儲數據預取作業DAG感知File FormatMem/SSD 池化093云原生 2.0 架構白皮書5.

274、近數據計算存儲卸載技術，實現數據計算加速存算分離后，計算集群到云存儲之間，網絡帶寬需求膨脹，如：中等規模的計算集群（如：5萬計算核）需要 Tbps 級網絡帶寬供給，網絡成本增加。采用 OBSSelect 存儲卸載技術，大數據服務和云存儲通過云原生的垂直優化，實現網絡帶寬消減 30%，計算性能提升 20%。關鍵特性包括：文件 schema 感知（Json、CSV、Parquet）、Projection/Filter/Aggregation 的類 SQL 算子卸載云存儲近數據計算。圖 3-26 OBSSelect 存儲卸載技術利用云原生數據庫云存儲 DFV 基于存儲算子語義下推能力，支撐事務處理算

275、子的并行下推。計算層可以通過并行處理分片下推數據庫要處理的語義到存儲層，存儲層也能夠理解數據庫語義，進而在存儲層并行地預處理數據庫的算子。比如范圍查詢，存儲層可以在確保事務隔離性、數據一致性的前提下過濾掉不需要的數據，直接把命中的行返回到計算層，避免計算層和存儲層無意義的數據交互。存儲層支持日志回放能力，數據庫寫節點無需把數據頁面寫到存儲層，只需要把日志寫到存儲層，存儲層可以將日志回放為數據頁面，并在多副本上提供一致性版本給其他節點訪問，進而節省計算層和存儲層的高速網絡帶寬。圖 3-27 GaussDB 存算分離+數據庫邏輯下推架構NetworkObjectSelect firstName,l

276、astNameFrom tablePeopleWhere country=“China”;BaselineNetworkObjectOBSSelectData movementData movementEntireObjectObjectSubsetSelect firstName,lastNameFrom tablePeopleWhere country=“China”;架構更優SQLNodesStorageNoder簡單的計算存儲分離ReplicaDataServerA b cDataServera B cDataServera b CMasterRDMA（Storage Network）

277、ReplicaStorageNoderGaussDB計算存儲分離+數據庫邏輯下推RDMA（Storage Network）SQLNodes內置深度整合DB插件ReplicaSALModuleSALModuleSALModuleMaster分布式存儲池Replica第三章|華為云云原生 2.0 架構設計模式0946.云原生統一元數據，實現多計算引擎共用一份數據存算分離后，當大量業務訪問一份數據使用時，常常遇到并發寫入、并發查詢、修改Schema 等并發需求。由于不同業務使用的計算引擎不同，也帶來了跨引擎使用一份數據的需求。而基于傳統存算合一的 Hadoop 生態組件，其創建之初并沒有考慮眾多引擎

278、的并發訪問，所以為大數據和 AI 計算引擎統一元數據，并支持并發事務型操作，變得越來越急迫。采用云原生統一元數據方案，實現了多個計算引擎并發共用一份數據。其具備如下特點：兼容 Hive Meta Store，計算組件可無縫對接統一元數據，可按需將原有表格遷移新的元數據管理系統。對已有的 Hadoop 生態組件無侵入式修改，通過配置即可支持使用新的統一元數據?；诳蓴U展的 KV 存儲實現大規模元數據存儲和并發訪問，訪問性能與表格個數、分區個數、數據量大小無關。支持結構化表格、半結構化數據、非結構化數據、AI模型等多種數據實體的元數據存儲和處理。所有元數據操作都支持事務和版本管理，對表格數據可實現

279、任意版本恢復、回退。支持插件式擴展元數據功能，例如通過插件可增加數據鑒權、數據共享、數據畫像、數據脫敏等功能。3.3.6 數據治理自動化架構設計模式進入 AI 時代后，數據類型越來越多，業務要求越來越實時化，傳統 Hadoop 生態組件做數據管理有較高的門檻，基于人工管理的成本越來越高，越來越難以適應業務的要求。企業迫切需要一種新的方式來管理海量數據，將數據從“資源”變為“資產”，真正幫助業務實現以實時數據驅動的智能決策。數據智能基礎設施 Data Intelligence Infrastructure（DII）是華為云面向云原生 2.0 自動數據治理平臺打造的全新平臺，其基于華為云智能數據

280、AI for Data 引擎，構筑覆蓋數據入湖、數據準備、數據目錄管理和數據洞察的全流程自動化能力，極大提升企業數據治理效率，幫助企業快速洞察數據價值。095云原生 2.0 架構白皮書1.數據集成服務DII 全新構建的數據集成服務支持一鍵式數據入湖能力，無需過多的手工配置，自動完成數據的入湖存儲，滿足全量遷移，定時增量遷移，實時遷移等多個場景?；谌A為云 AI for Data Engine 智能數據引擎，支持在數據遷移入湖過程中，自動進行隱私數據發現和標注，自動脫敏和水印。并且還具備數據爬蟲功能，自動發現半結構化數據的元數據 schema 信息，并統一存入Data Catalog 中。入湖數

281、據統一存儲在華為云 OBS 對象存儲服務中，支持 parquet、hudi、ORC CarbonData 等多種開源格式，方便多種數據分析引擎使用。圖 3-28 數據智能基礎設施 Data Intelligence Infrastructure（DII）圖 3-29 DII 數據集成服務一鍵入湖2.0數據目錄2.0依賴的云服務Auto ML權限管理實時同步入湖爬蟲數據圖譜元數據存儲搜索引擎AI引擎特征工程模型訓練模型評估模型服務聯邦認證數據權限資源權限全量增量入湖自動擴縮容數據準備2.0數據理解數據轉換數據質量數據洞察2.0Daas engineML insight智能分析No code工作臺

282、智能ETL推薦自動ETL流水線特征提取實體合并智能打標脫敏OBSMRS元數據存儲DLIDAYU-DGCIAM.數據湖存儲OBS業務數據庫文檔上傳VPC增量遷移CC實時遷移公有網絡VPCEP一鍵遷移Data CatalogAI for Data Engine消息第三章|華為云云原生 2.0 架構設計模式0962.數據準備服務 AutoETLDII 的 AutoETL 服務為數據科學家、業務分析師提供 no code 的可視化數據準備能力。AutoETL 提供數據流推薦交互界面、托拉拽可視化交互、運維管理頁面、調度引導配置、資產發布與可視化呈現界面。類 Excel 的數據準備智能交互方式，基于 A

283、I for data module 的數據預覽、數據剖析、schema mapping、算子推薦等能力實現數據準備引導式交互界面。數據質量評估：支持常規數據質量檢測，支持基于質量異常檢測算法，自動展示質量評分、修復建議。智能數據清洗：基于 AI for data module 的算子推薦實現轉換與清洗。數據豐富：基于湖內外標準數據集，通過關系挖掘實現對數據內容的豐富以及數據schema的補充。數據發布：支持新建 Schema，自動實現 Schema 關聯，字段信息推薦，比如業務名稱、標準、密級、分類、標簽等內容的推薦。AutoETL Studio：提供托拉拽可視化交互界面，支持表關系推薦，轉換

284、算子推薦，數據準備pipeline 自動生成與運維管理，支持版本管理，數據血緣生成，支持數據流推薦。圖 3-30 AutoETL Studio3.數據目錄服務 Data Catalog基于華為云在線元數據管理引擎，為企業構建統一的元數據管理中心，統一管理數據湖元數據、業務元數據、dashboard 元數據、ML 數據特征、sample data 等各類數據資產。數據湖 Catalog：數據湖的元數據統一采集，支持 Schema 自動解析，支持注冊 DWS、Mysql、ES 等外部數據源，提供兼容 Hivemetastore 的查詢接口；數據湖元數據和計算引擎元數據支持秒級同步。數據理解遷移數據

285、洞察2.0Data samplingData previewData profilingFeature extractSchema buildingMetric building數據發布數據轉換數據質量數據豐富AutoETLpipeline097云原生 2.0 架構白皮書 元模型管理：支持用戶自定義元模型，自定義采集適配器，支持內置元模型擴展屬性。數據關系圖譜：自動解析發現元數據之間的深度關系，包括血緣、主外鍵、logical-physical、parent-child、數據標準、分級、分類、主題目錄等，以知識圖譜的形式呈現。數據湖庫表統一權限管理：支持庫級、表級、列級、行級權限管控，支持權限

286、有效期。數據目錄權限管理：通過 access control 控制元數據和數據的訪問權限。智能數據搜索：所有資產均可搜索，支持搜索+過濾，自然語言搜索，相關度機器學習排序，基于用戶特征的資產推薦等。圖3-31 數據目錄服務Data Catalog4.智能數據洞察引擎服務 DaaS Query Engine基于華為云智能數據 AI for data 引擎而構建的 Data as a Service 能力，提供搜索體驗的數據洞察能力，通過簡單的搜索輸入，系統即可提供可視化的數據洞察、根因分析、數據預測、圖表推薦、自動數據故事生成等，幫助用戶發現數據中隱藏的價值。自然語言交互式分析：用戶通過自然語言

287、輸入查詢或所需報表內容，基于規則化或模型完成到 SQL 語義轉化。通過轉化后的語義查找 DII 數據目錄元數據生成 Query SQL，并基于用戶的語義理解從 Data Lake 中發現所需數據。報表智能分析、設計和應用發布：支持數據片段和數據點的智能根因分析，關聯指標及圖表推薦，多維下鉆。支持不同粒度下手動托拉拽+提醒引導式的數據智能洞察和報表智能設計。提供全局（數據集）的報表內容洞察和單一圖形的智能分析、圖表推薦，設計完成的報表形成儀表盤發布。針對某些業務場景的工作區可以整體打包成應用發布。智能洞察（ML Insights）：支持從單維到多維的數據洞察，提供時序智能異常檢測、預測、告警能力

288、；支持數據根因探索，例如異常點貢獻因素分析、預測值特征重要度分析等。元數據采集權限管理數據特征解析元模型管理數據圖譜元數據目錄HMS API搜索API圖分析API權限APIConsole數據目錄HMSElasticsearchGraphDB第三章|華為云云原生 2.0 架構設計模式098 智能圖表設計：基于用戶數據配置或者自然語言提問方式，自動推薦包括：最適合的圖形組件，多視圖下報表整體布局，配色一致性，基于見解的自動故事生成。圖 3-31 智能數據洞察引擎服務 DaaS Query Engine5.智能數據增強管理技術輔助數據洞察，提升 BI 分析效率基于智能數據增強管理技術的 Data a

289、s a Service 能力，提供搜索體驗的數據洞察能力，通過簡單的搜索輸入，系統即可提供可視化的數據洞察、根因分析、數據預測、圖表推薦、自動數據故事生成等，幫助用戶發現數據中隱藏的價值。關鍵特性包括：自然語言交互式分析：用戶通過自然語言輸入查詢或所需報表內容，基于規則化或模型完成到 SQL 語義轉化，并基于用戶的語義理解從 Data Lake 中發現所需數據。智能洞察（ML Insights）：基于智能增強管理技術，自動數據歸類統計和洞察，支持數據根因探索和數據預測。6.數據生命周期管理自動化，自動入庫、自動合并、自動清理云原生數據湖采用數據生命周期管理自動化技術，降低數據管理的門檻，無需編

290、程，使用純SQL 方式使企業數據管理員輕松管理數據，實現如下能力：對如 App 埋點日志、IoT 數據等實時流數據，實現無間斷的自動入湖。對于 JSON 數據，在入湖期間支持自動 Schema 推斷和自動 Schema 變更?；跀祿y計，可自動觸發 Compaction 任務合并小文件?；谑褂媒y計，可自動觸發建索引任務，加速業務查詢。根據用戶配置的數據老化規則，可自動觸發數據清理任務，節省存儲空間。數據集報表智能分析&設計儀表盤(ML)InsightsLineage發布圖表設計引導式拖拉拽1.通用分析模塊2.智能見解模塊TS,Geo3.根因探索模塊4.關聯指標聯系模塊1.智能圖表推薦模塊2

291、.智能布局配色模塊3.見解自動故事生成參數設置自然語言輸入語義轉化Query SQL獲得數據DaaS Query EngineApps數據資產發現工作區/應用業務099云原生 2.0 架構白皮書在統一元數據的基礎上，根據用戶配置的數據生命周期管理規則，云原生數據湖會自動觸發一系列的數據管理任務，以Serverless的方式自動執行，將用戶從繁重的數據管理任務中釋放出來，用戶只需聚焦自己的數據分析業務。3.3.7 基于軟總線異構集成的架構設計模式1.融合集成平臺 ROMA Connect 功能架構 FDI：支持多種異構數據源靈活轉換，入湖，入庫能力集成 DRS 和 CDM；APIC：實現 API

292、 全生命周期管理；MQS：支持消息中間件接入，前后端應用無感知；設備集成：支持標準 MQTT、MQTT Client SDK、軟/硬網關、OPCUA、Modbus 等各種協議與設備數據接入；FDI、APIC、MQS 和設備集成之間也可以自由組合形成多種集成解決方案；ABM：構建業務元數據模型；Compose：基于業務模型，通過業務規則，構建業務過程，實現應用聚合；圖形化業務流編排：代碼可視化集成，快速完成端邊云應用集成。圖 3-32 華為云融合集成平臺 ROMA Connect數倉/數據湖企業SaaS應用設備消息服務MDMDWIEFIESHCS 8.0公有云HCHCSO財務營銷PLMERPME

293、S企業應用大屏應用視頻應用移動應用GIS應用SaaS服務合作伙伴業務倉庫物流供應商ROMA connect（混合云）ROMA Site（邊緣）企業資產匯聚、沉淀集成應用 Cloud應用、Legacy系統連接器 協議對接插件API、MQ 各類標準化接口業務流 集成關系業務編排（Compose）集成流（Flow）業務對象模型構建模型映射模型管理應用業務對象（ABM）應用與數據聯接數據集成(FDI)消息集成(MQS)服務集成(APIC)設備集成業務聯接ROMA Connect（融合集成平臺）任務監控數據轉換任務管理讀寫插件任務調度多通道消息軌跡運維可視Topic管理消息延時發布訂閱消息重發多語言SD

294、K多協議轉換策略路由秒級流控環境管理服務編排協議轉換設備狀態報警信息規則引擎TLS加密傳輸多IoT對接模型聯接函數計算編排引擎規則引擎第三章|華為云云原生 2.0 架構設計模式1002.基于 ROMA Connect 將傳統非云原生應用封裝為 REST 接口與云原生應用對接如圖展示了融合集成平臺的設備集成、消息集成、數據集成、API 集成等能力，將設備、傳統非云原生應用、第三方應用的數據集成至數據庫、EI 平臺、數倉等系統，最終通過融合集成平臺的統一接口服務層 APIC 進行開放，業務云原生應用通過標準接口即可獲取老系統的信息。圖 3-33 融合集成平臺架構3.傳統 Oracle/Sybase

295、 等數據接入上云傳統數據一般在云下，與云上網絡不互通，此時通過融合集成云邊協同完成數據上云。云上云原生應用通過云上標準 API 調用、數據庫訪問、消息訂閱等方式即可獲取傳統數據。(注：如果云下通過專線、VPN 等方式與云上網絡互通，則融合集成平臺邊緣形態不是必選項。)圖 3-34 傳統 Oracle/Sybase 等數據接入上云應用層融合集成平臺統一接口服務層APIC數據運營平臺（DAYU）數據集成數據規范數據開發數據質量數據資產數據服務匯聚層明細層貼源層三維組態系統多維分析系統AI創新業務云原生應用傳統非云原生應用數據倉庫DWS第三方應用設備1工業網關EI平臺ModelArts設備NEMQ（

296、MQTT 消息服務器）MQTTKAFKA（分布式消息隊列）Jstorm（流處理引擎）OBS（數據歸檔3個月）RDS(mysql)內部外部API（服務接口層)數據歸檔Stream/Flink融合集成平臺歷史OT數據備份OBS(IT)OBS(OT)以外表關聯查詢OT歸檔OT查詢消息集成MQSERP財務系統CRM資金系統eHROA數據集成FDIAPI集成Spark消息集成MQS融合集成平臺-lOTOT實時OT實時工業網關(IIG500/1000/3000)設備1DCS/PLC/上位機設備NDCS/PLC/上位機數據集成與計算平臺（MRS）云原生應用方式二：數據庫訪問方式三：訂閱子消息云上數據庫API

297、CAPI托管數據定時或實時集成數據集成FDI消息集成MQS傳統數據APICOracleSAPMysqlRedisSQL Server消息集成MQS數據集成FDI路徑1方式一：標準API調用云上內部數據ROMA Connect邊緣形態ROMA Connect101云原生 2.0 架構白皮書4.企業多分支集成大型政府機構和企業的復雜網絡環境，要求能夠跨云、跨網的方案應用、數據和服務；政企需要一種安全、可靠、高效的連接方案，在不打破組織安全邊界的前提下，進行跨組織的API、數據、消息協同；在跨網過程中，不同業務方無需進行定制化對接適配工作，全程無感知。即可實現協議的轉換和數據的可控性交換。融合集成平

298、臺通過公有云、混合云、邊云多種部署形態協同，跨云跨域集成，構建應用一張網，全網級聯，多種能力組合完成企業多地數據共享數據交換。圖 3-35 企業多分支集成一級中心（集團）ROMA ExchangeROMA Connect應用資產(軟件包/鏡像)服務資產(App API)運營中心(IOC)定價管理集成資產(南向集成)數據資產(LiveData API)服務質量客戶分析二級分支1（省網1）數據源 庫表消息文件數據湖MRSDWS接入FDI+MQSROMA Factory應用開發應用開發應用托管應用運維應用APP微服務APIROMA Connect 數據FDI 消息MQS省級應用1省級應用2API(A

299、PIC)集團應用系統1系統N消息MQS管理面MGR數據FDI管理面MGRAPI（APIC）三級分支1（市/縣/邊緣）ROMA Site本地數據應用數據庫容器IEF底座消息MQS數據FDI設備MQTTAPI(APIC)二級分支2（省網2）融合集成平臺級聯數據源 庫表消息文件數據湖MRSDWS接入FDI+MQSROMA Factory應用開發應用開發應用托管應用運維應用APP微服務APIROMA Connect 數據FDI 消息MQS省級應用API(APIC)管理面MGR三級分支N（市/縣/邊緣）ROMA Site本地數據應用數據庫容器IEF底座消息MQS數據FDI設備MQTTAPI(APIC)3

300、.3.8 可信、平民化 DevOps 架構設計模式 1.合開發能力、運維能力與安全能力的 DevSecOps 平臺DevCloud：DevOps 工具鏈，包括 CloudIDE、項目管理服務、代碼托管服務、流水線服務、代碼檢查服務、編譯構建服務、云測服務、移動應用測試服務、部署服務、發布服務；第三章|華為云云原生 2.0 架構設計模式102圖 3-36 華為云 DevCloud2.基于 AppCube 的界面定制1)多種頁面類型支持標準頁面：標準頁面是一種將一個或多個組件拖進畫布，進行低代碼甚至無代碼的配置，即可快速完成業務功能的前端頁面。對于一般的業務應用系統，例如績效管理、請假電子流、出差

301、報銷、在線投票等企業常見業務場景，其功能主要是針對業務數據的增、刪、改、查，且前端界面的樣式相對簡單的頁面。標準頁面提供了豐富的組件，組件包含了預置的樣式，并封裝了基礎事件代碼，實現了開箱即用，避免重復寫樣式和事件代碼，陷入代碼細節，使開發人員更好的專注于業務場景的挖掘。高級頁面：對于一些樣式比較復雜的頁面，例如網站、電商、園區大屏等，您可以使用平臺提供的“高級頁面”。業務大屏頁面：業務大屏頁面即 DMAX 大屏頁面，業務大屏頁面可以幫助開發者快速構建和發布專業水準的實時可視化大屏頁面?？蓮V泛應用于政府、商業、金融、制造等行業的業務場景中。CICD流水線DevOps工具鏈（DevCloud/A

302、OM）安全工程能力服務化安全技術服務化（SecDev/AAD/SA）DevSecOps開發階段安全度量/安全看板安全設計服務隱私合規服務代碼安全服務安全測試服務安全運維服務運行階段安全度量及生態感知安全標準、規范、最佳實踐需求計劃安全設計與合規協同編碼構建部署發布托管治理編碼安全檢查日志監控攻擊發現響應運維壓測、接口測試安全測試漏洞掃描安全應用開發框架API安全開發框架安全開發組件IDE檢查門禁檢查源碼已知漏洞檢查.API安全測試Web漏洞掃描安卓應用掃描系統漏洞掃描.隱私分析隱私聲明隱私設計方案庫.威脅建模威脅庫安全設計.態勢感知DDoS高防主機安全安全響應.AOM：運維平臺，包括 LTS

303、日志服務、AOM 監控告警服務、APM 應用性能服務；SecDev：安全開發服務，包括安全設計服務 SecDesign、隱私合規服務 SecPCP、代碼安全服務 SecSolar 以及安全測試服務 SecScan；同時也集成了安全運維服務態勢感知服務 SA、DDos 高防AAD 等。103云原生 2.0 架構白皮書2)豐富的組件能力AppCube 基礎組件覆蓋了全部的標準 W3C HTML5 表單組件，包含：文字組件：單行文本域、多行文本域、密碼域、日期域、數字域、范圍域、顏色域、搜索域。列表組件：Select 組件、DataList 組件。選擇組件：Radio、Checkbox。按鈕組件：提

304、交按鈕(submit)、重置按鈕(reset)、普通按鈕(button)。AppCube 具備適配企業業務的高級組件，包含：高級控件：函數公式、自動編號、身份證件、手機號碼、地理定位、手寫簽名、文本識別。關聯控件：關聯記錄、子表、他表字段、級聯選擇、匯總。企業相關：部門選擇、角色選擇、人員選擇、群聊選擇、云盤附件。AppCube 提供自定義組件和組件屬性的能力 平臺內置常用的 JS 庫，開發者可以基于 JS 庫開發組件上傳到平臺。平臺同事支持開發者通過引用第三方庫的方式在降低組件開發的復雜度的同時豐富組件的功能。平臺支持自定義組件的一些屬性，可以在用到該組件的頁面中根據具體的場景配置這些屬性值

305、。3)強大的布局能力，支持常見的 Web 頁面布局，適配多終端展示 支持靜態布局，常用于 IOC 大屏頁面開發。支持流式布局，流式布局為 12 列柵格布局，可拖動組件右側邊界按柵格進行組件寬度調整，組件高度將根據組件內容進行自適應，頁面中組件將按照從左到右、從上到下的順序依次排列。支持響應式布局，組件的響應式設計是頁面適配多終端的重要前提。多種布局組件：包含柵格、分欄、容器、表格、彈層、IFrame、JSX 等多種組件。3.基于 AppCube 的服務能力編排的業務流程無代碼定制1)靈活的流程觸發方式 表單實例創建、修改、刪除觸發 API 調用觸發 用戶手動觸發 定時觸發 自定義事件觸發第三章

306、|華為云云原生 2.0 架構設計模式1042)基于BPMN2.0規范的流程節點，可以設計出多分支、多規則、多權限、多處理的復雜業務流程，滿足企業業務的全流程閉環 活動：用戶任務、調用腳本、調用服務編排、規則決策表、郵件發送、數據映射、子流程/活動。事件：開始、拋出信號、捕獲信號/時間、結束/終止。網關：排他網關、并行網關、事件網關。3)多種權限配置方式 支持部門、角色、人員、自定義分組等維度來劃分權限。支持數據創建、修改、刪除、查看、列表、打印、分享等多種操作權限賦予。支持數據集、數據行、數據列、自定義規則等途徑對數據進行敏感保護。4)自定義的業務編排 托拉拽式編排流程：以往的傳統編程，需要進

307、行變量的聲明并編寫相應邏輯代碼進行服務的開發。使用服務編排進行服務開發，能夠通過托拉拽的方式，將配置項創建的變量以及服務編排中提供的各種功能進行編排，并以流程的方式將服務所要實現的功能展現出來。整個開發過程中無需進行代碼的編寫，簡單快捷，并能夠圖形化展示服務的邏輯。邏輯處理：服務編排中提供了邏輯處理的圖形化元件，包括賦值、循環、跳出循環、決策和等待。通過這些圖元能夠實現基本的邏輯處理，并圖形化展示，便于開發者理解。5)對象處理服務編排中提供了對象處理的圖形化元件，包括記錄創建、記錄查詢、記錄更新和記錄刪除。通過這些圖元能夠對通過平臺創建的自定義對象或標準對象進行相應的增、刪、改、查操作，簡化處

308、理對象數據的流程，提高開發效率。6)服務單元組合腳本、原生服務、BO、第三方服務服務編排中提供了服務單元組合的圖形化元件，包括腳本、子服務編排、原生服務、BO 和連接器。通過這些圖元能夠將平臺中已開發完成的服務集成到服務編排中，并重新進行組合，快速擴展出更豐富的業務功能。105云原生 2.0 架構白皮書3.3.9 多模態可迭代行業 AI 架構設計模式華為云面向 AI 主要提供底層的 AI 訓練平臺以及上層的面向各行各業的 AI 應用。底層 AI 平臺是華為云 ModelArts 服務，上層 AI 應用是華為云知識計算服務。3.3.9.1 華為云普惠 AI 開發平臺：ModelArts 1)面向

309、 AI 開發的 ModelArts IDE軟件開發的歷史，就是一部降低開發者成本，提升開發體驗的歷史。在 AI 開發過程中，ModelArts 也致力于提升 AI 開發體驗，降低行業 AI 開發門檻。ModelArts IDE，為不同類型的AI 開發、探索、教學用戶，提供更好的云化 AI 開發體驗；更近一步接入優質 AI 開發內容，提供基于算法外殼+套件的算法開發方式和基于 ModelBox 的應用開發能力。將 On Cloud AI 開發演進為 In Cloud AI 開發。ModelArts IDE作為統一的AI開發解決方案，是由多個工具和服務組成，面向不同開發者場景，提供不同的解決方案。

310、1.ModelArts Studio 一站式 AI 開發線上(Web)入口針對于 AI 數據、算法探索、特征分析、模型訓練評估等場景，提供一站式的 AI 實驗開發與管理的能力。ModelArts Studio 基于 JupyterLab 底座，通過豐富功能擴展插件來打造，延續了類似 Notebook 的交互習慣，增加了額外的云上 AI 開發能力與管理功能。利用云上 AI 計算資源完成算法代碼的交互式調測，迎合 Notebook 生態，便捷的運行和管理Notebook；云上開發主入口，方便的上傳數據，模型訓練、調優、評估、轉化以及搜索等步驟的執行、管理與可視化；集成 ModelArts 基于算法

311、套件的算法開發能力，接入官方以及開源算法套件內容，高效的完成算法探索。2.ModelArts CodeLab 云原生 Notebook 服務針對 AI 探索、教學、快速實驗場景，提供云上 serverless 化的云原生 Notebook 服務。免費算力：包含 CPU、GPU 和 Ascend。開發者可以使用免費規格，按需進行使用規格切換，端到端體驗 ModelArts Notebook 能力。也可使用此免費算力，在線完成您的算法開發。即開即用：serverless 化資源管理，無需創建 Notebook 實例，打開即可編碼，自用自動釋放。高效分享與協作：ModelArts 官方提供的 Not

312、ebook 樣例，一鍵即可打開 CodeLab 學習樣例第三章|華為云云原生 2.0 架構設計模式106代碼，也提供 Notebook 分享的功能，方便的講自己的 notebook 分享給其他開發者完成實驗內容復現。3.ModelArts Studio extension for PyCharm and VSCode 本地 IDE 遠程開發能力針對 AI 算法或者 AI 應用中，需要進行深度代碼開發與調測的場景，例如工程化代碼開發與調測、算子開發與調測等，提供 PyCharm 和 VScode 插件，直接連接云上 AI 開發容器實例，完成遠程代碼開發與調測。高效代碼調測：延續深度代碼開發用戶的

313、開發使用習慣，利用本地 IDE 代碼開發、工程管理的能力，更高效的完成代碼開發與調測。云上云下協同：本地 IDE 插件與云上資源進行聯動，在 Web 入口無法高效完成工程化代碼調測功能時，能夠低成本的進行使用方式切換，開發內容一致。AI 算法開發能力：在 IDE 中集成 ModelArts 算法外殼，利用 ModelArts 提供的算法套件，以及接入定向適配的開源套件，完成工程化算法開發與探索。AI 應用開發能力：在 VScode 通過插件提供基于 ModelBox 的 AI 應用開發能力，包含 AI 應用開發工程，結合 ModelBox 提供的預置流單元完成 AI 應用開發與調測。圖 3-3

314、7 ModelArts Studio extension for PyCharm and VSCode2)面向 AI 項目管理與迭代的 ModelArts Workflow在云原生 2.0 時代，如何實現普惠 AI，需要解決迭代效率的問題。AI 項目在落地過程中，端到端的流程包括項目設計、數據工程、模型構建、模型訓練、模型評估和部署落地。傳統交付一ModelArts插件ModelArts IDE插件管理底座ModelArts-SDK本地IDE底座（VSCode、PyCharm）本地IDE+插件開發環境管理面邊側設備、一體化大數據資源DLI、MRSMA資源池第三方資源納管K8s operator

315、遠程開發（ssh）httpsHilens.定制化插件2定制化插件n社區商業化插件工具ModelArts插件ModelArts Notebook插件管理底座ModelArts-SDK線上IDE底座（JupyterLab）ModelArts-StudioMLStudio.AIFlow定制化插件n社區商業化插件工具ModelArts-IDE（IDE底座+ModelArts插件）Integrated development environment（IDE）for MLModelArts-Fundamental107云原生 2.0 架構白皮書個 AI 項目，都是直接交付一個 AI 應用。當出現數據漂移的

316、情況時，需要相對應的算法人員、測試人員等重新介入迭代模型。這種流程非常消耗人力。MLOps 是一種機器學習工程文化和做法，其統一了機器學習系統開發和系統運營。參照DevOps 的概念，DevOps 使軟件的維護工程化、例行化、專業化。AI 應用的維護也需要工程化、例行化和專業化。在迭代過程中，通過固化已有的流程構造工作流，針對場景中的數據樣本增加數據量，提高數據標注的一致性，輸入到工作流中迭代訓練定期調整模型。ModelArts Workflow 是專為 MLOps 功能提供的工具。借助 Workflow 和賬號管理體系，用戶可以在 ModelArts 上開發基于實際場景的 MLOps 工作流

317、。workflow 就是針對某個 AI 項目的解決方案。在 AI 項目中會有不同角色的參與，基本角色有項目 PO、數據科學家、算法人員、集成&驗證和運維人員等；相對應的 workflow 也有開發態和運行態。圖 3-38 AI 項目的端到端流程項目設計數據工程模型構建部署落地需求收集場景設計明確問題邊界定義數據收集數據數據標注數據可用性檢查數據工程算法開發模型訓練模型評估迭代優化應用集成應用部署模型監控系統運維圖 3-39 ModelArts Workflow 數據AI 應用數據處理模型開發模型訓練模型評估應用開發應用評估AI開發數據處理模型訓練應用構建應用部署迭代優化第三章|華為云云原生 2

318、.0 架構設計模式108用戶可以基于 ModelArts 提供的 Workflow SDK 和低代碼的開發工具 Studio，開發相應的Workflow?；诓煌膶嶋H場景，開發者可以自己定義每一個步驟的實際業務屬性和操作。實際業務屬性包括步驟的輸入輸出、依賴的步驟、需要用戶操作的參數等。通過 ModelArts Studio 的低代碼可視化開發工具，讓用戶更輕松地進行模型和流程開發。在 Workflow 運行時提供可視化的操作界面，提供給使用者一個只需要關注迭代優化的工具。開發者完成工作流的定義后，發布到項目中，即可提供給使用者進行使用。使用者無須關注每個步驟是如何實現的，背后使用了什么算法

319、邏輯，只需要關注開發者定義的評估指標是否符合當前業務上線標準，當不符合標準的時候，更新數據進行應用模型迭代。針對整個開發的流程，通過定義步驟的屬性來定義 AI 項目工程的流程。結合 ModelArts 賬號體系，實現基于單/多項目場景多人開發&迭代，不同步驟多人開發&管理功能。3)面向 AI 生態社區培育與建設的 AI GalleryAI Gallery 是為 AI 初學者，算法工程師，數據科學家量身打造的 AI 開發生態社區。圍繞著 AI學習、AI 開發、AI 落地三大環節，構建“學徒專家”“資產建?！薄敖Ｍ评怼钡墓┬铇蛄?，通過體系化的 AI 內容、多樣化的 AI 資產和場景化的 AI 方

320、案，實現 AI 學習有指導，AI 開發更高效，AI 落地零門檻。圖 3-40 AI Gallery AI 學習：主要是面向 AI 學徒，AI 專家兩類用戶。AI 學徒能夠在 AI Gallery 上獲取圍繞 AI 相關的課程、論文、文章等內容知識，并從中學習成長；AI 專家能夠在 AI Gallery 上貢獻各種優質內容，并得到相應的榮譽和收益。區別于其他的社區內容，AI Gallery 的課程、論文等內容體系，關聯嵌入可基于實際環境動手實踐的AI資產，例如數據集、Notebook代碼樣例等。AI企業，高階開發者企業/個人開發者AI專家，AI教育培訓機構行業客戶企業/個人開發者AI學徒供需AI

321、 Gallery提供AI內容，獲取收益、榮譽。使用AI內容，獲取能力進階提供AI資產，獲取收益、榮譽。使用AI資產，提高AI開發效率提供AI案例，獲取收益、榮譽。使用AI案例，解決業務問題AI學習AI開發AI落地AI方案（面向場景化交付的AI解決方案）AI內容（圍繞AI相關的課程，論文，文章等）AI資產（AI開發到落地過程中的成果物，如數據集，算法，模型等）109云原生 2.0 架構白皮書 AI 開發：主要是面向具備一定 AI 開發能力，能夠基于數據集，算法、模型、工具等 AI 資產完成 AI 建模的各類開發者。AI 開發者們可以分享和復用 AI 開發過程中的各類 AI 資產，例如數據集、算法

322、代碼、預訓練模型、鏡像，工具等，來提升自身的 AI 開發能力和效率。各類AI 資產，可基于業務場景，通過組合、集成等方式構建覆蓋端到端環節的 AI 解決方案。AI 落地：主要是為對 AI 應用落地有訴求，但自身 AI 開發能力相對薄弱的各類行業客戶提供其所需的 AI 方案。具備 AI 能力的企業、高階開發者等，可以作為 AI 能力的供應方，提供基于場景化交付的AI方案，幫助AI能力的需求方，實現AI應用的快速落地，解決實際業務問題。圍繞場景化的方案，通過不同行業、不同領域的打磨，可以沉淀為豐富的案例庫，實現 AI 經驗和知識在不同業務場景下的復用。AI 資產是 AI Gallery 的核心。A

323、I 平臺 ModelArts 的數據管理、訓練管理、模型管理等模塊類似于“生產線”，AI 開發者們在這里生產出數據集、算法、模型等各類 AI 資產；然后可以將自己生產出來的資產發布到 AI Gallery 的“資產集市”進行免費分享或者商業售賣。其他的開發者們可以來到資產集市搜索查找自己想用的 AI 資產，找到后，可以便捷獲取并一鍵運行在 ModelArts等底座平臺上。圖 3-41 AI Gallery 與 ModelArts 協同當前 AI Gallery 已支持數據集、Notebook 代碼樣例，算法、模型、Workflow 工作流、套件等多種類型的 AI 資產，積累沉淀 6W+資產。通

324、過構建 AI 生態鏈上的供需橋梁，未來將吸引更多伙伴和開發者共建共享一個繁榮的 AI 生態社區。發布訂閱數據準備代碼調測實驗管理模型評估模型注冊部署管理ModelArts發布者訂閱者AI資產數據算法模型Notebook工作流AI學習AI落地AI開發AI Gallery創建AI資產使用AI資產第三章|華為云云原生 2.0 架構設計模式1103.3.9.2 華為云知識計算與多模態 AI1)知識計算架構當前，AI 主要基于海量數據完成建模、求解與應用。然而現實中，人類在解決各類問題時，通常會基于對數據的觀察，結合所學知識進行思考，進而做出決策。在此過程中，知識是人在解決復雜問題時，做出判斷、推測的重

325、要依據?；谶@一特點，很多學者提出 AI 系統需要結合知識來解決復雜的問題。在數字化轉型過程中，企業積累了大量的知識，比如專家經驗、生產系統中的機理模型、行業標準、技術文獻等，這些知識以多種形態存在于各行各業，承載了諸如場景屬性、業務流程、數據特征等信息，蘊含著寶貴的價值。將行業知識與 AI 有效的結合，可以解決 AI行業應用過程中的諸多問題，幫助 AI 以更高效的方式落地。當前人工智能正在向第三代邁進。相比數據驅動的人工智能，第三代人工智能試圖將人類對世界的認知轉換為知識這一要素，參與到人工智能模型的計算中，幫助模型提升魯棒性和可解釋性。知識與人工智能的結合，為 AI 行業落地提供了新的思路

326、，也為加速行業智能化指明了潛在的方向。知識和 AI 的結合主要體現在三個方面：行業知識賦能 AI 建模、行業知識幫助 AI 模型高效求解、行業知識保證 AI 應用持續可靠。圖 3-42 華為云云原生知識計算框架111云原生 2.0 架構白皮書如上圖所示，華為云知識計算框架主要包括知識層、模型層和算子層。知識是知識參與計算的底層基礎，是人類在實踐中認識客觀世界（包括人類自身）的成果。參考哲學、心理學對知識的分類，通常以事實性知識、概念性知識、程序性知識以及元認知知識等形式呈現。行業生產活動所沉淀的知識可被歸于其中，包括生產日志、手冊、經驗、流程等。例如，生產中的基本元素屬于事實性知識、生產流程屬

327、于程序性知識、機理模型屬于概念性知識。模型是知識參與計算的載體，刻畫行業知識并有效參與計算。由數學模型刻畫的知識，可以通過數值計算、符號計算等方式來求解，是可以有效參與計算的知識。常用的數學模型包括代數方程模型、微分方程模型、統計模型、圖模型等，例如知識圖譜可以通過圖模型來構建，石油勘探的測井環節中的伽馬射線通量計算模型屬于一種微分方程模型。算子是知識參與計算的手段，是一種機器對知識進行建模和求解的操作。讓知識參與建模和求解的過程中，機器進行的操作即為知識計算算子。算子可以規范化為兩類：建模算子和求解算子。建模算子聚焦在將數據轉換成可計算的模型，求解算子聚焦在利用 AI 技術對模型進行高效、精

328、準求解。通過對知識計算框架中算子的使用，可形成搜索、推薦、預測、優化、正演、反演等行業應用。例如，知識可以提升預測準確率，實現更智能的行業應用：在政務“一網統管”中，構建工單多維度分析知識圖譜，落地智能工單智能分撥、疑難工單識別、敏感事件預警應用；在交通調度場景中，落地實時路況分析、公交調度等應用。知識在正演、反演中同樣起著重要作用，例如在能源行業，通過數據正演解決小樣本問題，通過反演解決測井油氣層識別、地震層位解釋等問題，實現“提質增效”和“增儲上產”。2)多模態 AI 架構傳統的 AI 主要側重某種特定信號的處理，比如計算機視覺領域的視覺信號、語音信號處理領域的語音信號、自然語言處理領域的

329、文本信息等。但是現實生活中人所接觸的信號是各種各樣的，不僅僅限于某一個種類的信號，如在城市治理工作中，涉及數據種類多：位置、社會關系、網絡行為，以及大量非結構化數據如語音通信、視頻人臉、案件存檔等。運用 AI 技術可以對非結構化數據挖掘，自動建立非結構化數據與結構化記錄關聯。如在視頻分析中會涉及語音、文本、圖像信息。多模態分析設計多模態識別和多模態生成。多模態 AI 主要涉及的技術點包括表示、映射、對齊、融合以及協同學習。表示是指如何表示各個模態的特征，比如語言是符號表示，而音頻和視頻是連續的信號表示。這兩類表示如何統一的有效表示為計算機可以理解的表示信息是一個關鍵技術。映射是指不同的模態之間

330、如何從一個模態映射到另外一個模態。不同模態之間的關系往往是開放的或主觀的。比如針對一張圖片，有很多種文字描述方法來描述這張圖像。同一段文字描述，不同人聯想到的圖像也是不一樣的。這種模態之間的映射可能是一個多對多的映射關系，不存在一個完美的映射。第三章|華為云云原生 2.0 架構設計模式112 對齊是指兩種或三種模態之間的信息如何精準對齊，比如我們希望視頻中語音、文本和視頻畫面信號之間進行對齊；人的說話內容和其表情、肢體動作對齊等。融合是指有了多種模態信息之后，如何綜合有效利用這些模態的信息進行 AI 模型的訓練，起到 1+1 大于 2 的作用。如在視聽語音識別中，將唇動的視覺描述信息與語音信號

331、融合，預測語音對應的文本信息。不同模態之間的信息所具備的信息量、噪聲、分布不相同，模態之間可以互補，甚至可能會出現模態缺失的問題。協同學習是指如何實現不同模態之間的知識遷移，比如在某一個模態 A 上訓練的模型，如何有效的遷移到另外一個模態 B，實現在 B 模態上的零樣本學習。這種在某個模態缺失數據的情況下非常關鍵。如語音情感分析領域，語音對應的情感標注數據非常少，而人臉的情感標注會容易很多，所以可以基于人臉的情感識別知識遷移到語音的情感語料標注中。華為云提供了基于知識計算引擎的云原生多模態分析工作流內置了多模態表示學習、映射、對齊、融合、遷移、補全等功能。結合知識計算引擎，為用戶提供一站式的多

332、模態應用開發工作流。具體應用案例如 OCR 文字識別、視頻分析、多模態內容審核等。圖 3-43 多模態分析流程華為云提供了基于知識計算引擎的云原生多模態分析工作流內置了多模態表示學習、映射、對齊、融合、遷移、補全等功能。多模態輸入多模態輸出多模態表示多模態映射多模態對齊多模態融合多模態遷移113云原生 2.0 架構白皮書3.3.10 全方位立體式安全防護架構設計模式3.3.10.1 統一權限管理1）細粒度授權模式訪問控制，是指對受保護的資源進行選擇性的限制訪問，防止未授權的操作。任何訪問控制模型都離不開兩個關鍵要素：主體（Subject）和對象（Object），主體指系統中發起訪問操作的實體，

333、不僅指人，也包括應用程序和服務，對象指需要進行訪問控制的資源。目前最流行的訪問控制模型是 RBAC（Role-Based Access Control），也就是基于角色的訪問控制。RBAC 模型在主體和對象之間抽象出角色的概念，將主體和權限的關聯進行解耦。角色是一組權限的集合，主體只需要擔任角色，即自動擁有該角色中包含的權限。圖 3-44 RBAC 訪問控制模型RBAC 的權限設置是基于組織內的職責劃分來定義，容易理解和管理，且實現成本低，所以RBAC 得到了非常廣泛的采用。例如 Kubernetes 主流的訪問控制機制就是 RBAC。但 RBAC 的授權策略必須是基于授權這一時刻下主體和對象的靜止狀態來預先定義，對于主體和對象變化的響應是滯后的。RBAC 一般定義一套資源組，資源需要放到不同的資源組里，并根據組織內人員的職責設置角色及其權限，建立人員-資源組-角色的關聯。如果資源的分組維