【導讀】雲原生架構體系內容眾多，建設做不到一步到位，彼此之間也存在著先後次序相關性，需要透過一系列專案持續完成相關的能力，從而實現雲原生融合架構。本文分享了根據雲原生架構體系中技術之間的關係和實際經驗，基於“頂層規劃+分步實施”的原則，定義為5個步驟的雲原生架構實施路線圖。透過本文能夠相對深入的理解雲原生架構體系，併為企業實際做出頂層規劃提供啟發。

【作者】汪照輝，中國銀河證券架構師，專注於容器雲、微服務、DevOps、資料治理、數字化轉型等領域，對相關技術有獨特的理解和見解。擅長於軟體規劃和設計，提出的“平臺融合”的觀點越來越得到認同和事實證明。發表了眾多技術文章探討容器平臺建設、微服務技術、DevOps、數字化轉型、資料治理、中臺建設等內容，受到了廣泛關注和肯定。個人公眾號：技術思維創新

上篇《 你需要知道的雲原生架構體系內容 》（點選標題可閱讀）中對雲原生架構體系內容進行了介紹，雲原生架構體系內容眾多，如果深入到微服務、容器、 DevOps、服務網格ServiceMesh、自服務敏捷基礎設施、混沌工程、安全等任何一項內容都有很多的工作需要做。比如說微服務，一套SpringCloud開發框架就需要很多的學習成本，更別說還有很多其他的框架、方法和思想，比如微服務的拆分領域驅動設計DDD方法等。

雲原生這麼多的內容做不到一步到位，而且彼此之間也存在著先後次序相關性，它需要透過一系列的專案持續完成相關的能力，從而實現雲原生融合架構。由於雲原生架構體系內容眾多，需要對其有相對深入的理解並能根據企業實際做出實施頂層規劃，然後以分步實施的方法邊建設邊交付價值，使整個體系建設具備可持續性。

圖 1 雲原生融合架構實施步驟

根據雲原生架構體系中技術之間的關係和實際經驗，基於“頂層規劃+分步實施”的原則，雲原生架構實施路線圖我們定義為5個步驟：

1 . 微服務採用及執行環境容器雲平臺構建；

2 . 服務管理和治理；

3 . 持續交付及安全；

4 . 自服務敏捷向基礎設施建設；

5 . 增強生產環境韌性和安全性。

每個實施步驟又可以根據實際建設需要分為若干個子專案，並可能需要多次迭代。比如說，步驟一微服務採用及執行環境構建，容器雲平臺建設和系統微服務架構採用可能需要分別以不同的專案立項。容器雲平臺作為基礎設施平臺，可能還需要規劃採購伺服器、儲存、網路裝置等，也可能需要根據微服務系統改造進度持續進行採購。微服務的設計開發就是個持續的過程，可能涉及不同系統的新建或改造重構。同時呢，也可能需要前期的諮詢、規劃指導和培訓等 。不同的單位實際情況不同，所採取的步驟和方式也會不同。

1. 步驟一：微服務採用及執行環境構建

雲原生架構體系中，應用是交付業務價值的載體，而微服務是構建業務應用的技術。經微服務架構分解的應用服務執行在容器中。所以第一步在採用微服務的同時需要構建容器環境支撐微服務的執行。

基於容器技術和容器排程管理技術如Kubernetes構建企業內私有容器雲平臺支撐微服務應用系統的部署、執行和管理，實現微服務執行時環境支援，基於容器雲平臺可以實現相關的自服務敏捷能力，比如彈性擴充套件、服務路由、分發限流、健康檢查、錯誤隔離、故障恢復、資源排程等。

以雲應用12或15要素為指導設計微服務。當前微服務分拆的方式通常是基於 領域驅動設計（DDD）方法。不過DDD 對業務領域的劃分往往難以清晰定義領域邊界，存在著領域劃分不合理、資料同時存在於不同領域的問題，為每個服務選擇合適的責任級別及其範圍是困難的，需要極深的經驗和對業務的理解。因此Martin Flowler建議可以先建一個傳統的大一統系統，在對領域知識有更好的瞭解以後，再透過重構將其改造成微服務。筆者覺得DDD透過領域劃分可以在一定程度上簡化業務關係，從而簡化微服務設計，但 領域劃分也使每個領域缺乏全域性認識，所以DDD更像是一種分類簡化的設計方法， 這會造成多次的重複迭代，造成浪費。而Martin Flowler的建議則使DDD有了全域性的視角，能夠從上到下，全域性來看到領域劃分和設計，但這個大一統系統並不容易建設。

筆者基於實踐提出了“主資料驅動設計”的微服務設計方法，主資料本來就是系統間共享的高價值資料，基於企業主資料設計的微服務天然具備系統間的可重用性。而且基於行業通用資料模型(Comm on Data Model，CDM)則很容易定義並完善主資料微服務，減少重複的迭代設計和實現。

2. 步驟二：服務管理和治理

微服務架構在分解應用的同時也帶來了微服務數量的成倍增長，使服務的管理和治理難以透過人工完成。隨著微服務量的增加，需要完善服務的管理和治理能力。在完成容器雲平臺執行時支撐建設之後，可以側重實現服務的治理和 API的定義，以支援高效的管理和敏捷的服務編排響應，同時實現基於 API的協同。

微服務治理有多種實現的方法。基於容器雲平臺可以直接利用k 8s的能力實現服務的註冊發現、配置、路由分發、負載均衡、彈性擴容等，不過容器雲平臺要作為企業級應用支撐平臺，需要在Kubernetes之上擴充套件實現服務的管理和治理能力。CNCF推薦用 ServiceMesh，代理東西向流量，支援跨語言。Porvital的 SpringClou d框架提供了相對完整的服務治理實現，比如服務的註冊發現、配置、熔斷、客戶端負載均衡等，但僅支援Java；等等有眾多的框架和技術 。微服務架構提出的一個主要目的就是透過API來遮蔽開發語言，無論用什麼開發語言，只要遵循同樣的 API，都可以進行協同。其實這類似於地球上不同國家之間的交流，透過相互可以理解的公共語言就可以對話。因此在實現服務治理時需要考慮跨平臺能力以及對內和對外 API服務能力。這裡要區分下微服務的 API和對外的 OpenAPI ，可以看作是兩個層次 。OpenAPI通常是跨平臺、跨企業的，用於構建生態系統，不過企業內部也可以用於構建企業內部生態。思想都是一樣。

雲原生以API為協同方式，因此在公司內部可以實現容器雲平臺和 API閘道器兩層的服務治理能力。同一個微服務可以透過 API閘道器暴露為不同的 API，或者也可以多個微服務暴露為一個 API。API既可以面向企業內部，也可以面向外部生態夥伴。

3. 步驟三：持續交付及安全

前兩個步驟完成了微服務執行運營的基礎能力，具備了支撐微服務彈性擴充套件、協同互動的能力。有了部署運維平臺和服務管理治理能力，則就可以側重提升研發端的持續交付能力。這樣，無論開發多少微服務，在服務管理和治理方面也就沒有了後顧之憂。以DevOps理論為指導，構建持續整合、持續部署、持續交付、持續監控、持續反饋的閉環流程。

兵馬未動，糧草先行，之所以要先建設容器雲平臺和服務管理治理能力，就是要提前準備好在應用微服務化、分散式微服務量的爆炸增長，具備支撐彈性伸縮、視覺化、可觀察性、故障隔離、容錯、故障自恢復等能力。這樣才能支援各個團隊的持續交付要求。這也是我們一直提倡先著力構建微服務執行支撐環境的重要原因。

DevOps一種思想和方法論，其核心是協作反饋，只有及時的反饋才能反思和改進。利用 DevOps思想構建持續交付能力的過程中，會涉及組織架構的最佳化，這可能是一個難點。首先組織領導要能夠理解 DevOps思想和理念，知道組織的弱點並願意嘗試改進；其次， DevOps 體系（DevOps體系可能不僅僅是一個平臺 ） 可能涉及眾多的元件和工具，或者需要一體化的設計研發，每種方式都會花費大量人力和時間。比如說用開源工具，持續整合和持續交付流程涉及開發、原始碼管理、原始碼檢查、單元測試、用例管理、構建、安全測試、交付管理等眾多的工具，僅考慮打通這些工具的認證許可權管理，就不是一件容易的事。因此有些DevOps廠商直接自研持續整合、持續交付等流水線。如果具備這樣的研發能力，筆者建議儘可能自研或者合作研發，這也是為系統融合打好基礎，避免眾多的開源第三方工具帶來眾多的整合問題，難以有效融合在一起。

認證和許可權是DevOps體系中的基礎安全措施。程式碼安全檢查、映象安全檢查、系統安全、應用安全、介面安全、容器安全等等都需要在 DevOps工具鏈和流水線實施和使用過程中逐步完善，以提升雲原生的整體安全性。

4. 步驟四：自服務敏捷響應基礎設施

基礎設施在第一步搭建容器雲平臺和微服務的時候就會用到，只不過這個階段微服務量相對較少，對自服務敏捷響應基礎設施沒有迫切需求。隨著持續交付能力的提升，微服務量的增長，運維能力需要從量變演化到質變。自動化、自服務敏捷響應能力提上日程。

基礎設施大致可以劃分為三個部分：基礎設施資源、支撐平臺和純技術工具。基礎設施資源可能有很多種異構資源和雲平臺，需要透過統一的層次（比如多雲管理平臺）來封裝，提供統一的基礎設施資源服務，隔離底層異構資源細節，簡化應用資源排程。支撐平臺主要是微服務開發、執行、運維的平臺，例如 持續交付平臺、容器雲平臺等。純技術工具指的是和業務無關、圍繞支撐平臺周邊的工具，比如訊息平臺（ RabbitMQ、Kafka ）、監控平臺、許可權管理平臺、認證平臺、人臉識別平臺等等。這些平臺可以提取構建技術中臺能力，各業務應用都可以複用這些能力。

在實施持續交付的同時，也是在部分構建自服務敏捷響應基礎設施能力，比如持續整合、持續交付流水線等。在這個步驟，需要重點構建和完善自動化、自服務的基礎設施能力，包括統一身份認證和許可權服務、日誌服務、配置服務、監控服務、告警服務、安全服務、AI服務（人臉識別、文字識別、影像識別、語音識別、自然語言處理、知識圖譜、演算法等）、訊息服務、排程服務等基礎服務和CICD研發流程服務等 。實現這些服務的自服務能力是構建應用敏捷響應的關鍵。

基礎設施資源的自服務敏捷響應是所有這些服務的實現敏捷響應的前提。由於基礎設施資源多種多樣，可能來自不同的廠商品牌、不同的型號、不同的架構、不同的協議、不同的雲平臺等等，為基礎設施資源的融合管理和敏捷響應帶來了挑戰。需要考慮構建統一的基礎設施資源管理平臺或多雲管理平臺來提供統一的基礎設施資源服務，封裝底層資源細節，提升資源交付效率。

這個過程中，組織架構可以同步調整，比如基礎設施資源團隊來運維運營基礎設施資源，為平臺和工具提供資源服務；平臺團隊來運維運營平臺，工具團隊來持續研發工具和技術中臺服務，支撐以應用管理為中心的架構；應用研發團隊專注於業務應用微服務的研發，使用自服務的資源、平臺、工具實現服務的研發、測試、部署、執行、運維等全生命週期管理。

5. 步驟五：增強生產環境韌性和安全性

脆弱性的反面是健壯性、韌性。抗脆弱性（或反脆弱性，Antifragility ）的目的就是持續定時或不定時透過在執行環境中注入故障的方式來主動的找到弱點，並強制修復這些弱點，從而提升環境的健壯性和韌性。以人類免疫系統為例，當受到病毒侵害時，人體的免疫系統就會自動做出反應，會變得更強；而當人被隔離時，免疫系統會變得更弱。用人類免疫系統的思想來構建雲原生架構的韌性，以抵禦不同場景下的故障。Netflix Simian Army專案有個著名的子模組“混沌猴（Chaos Monkey ）”，它將隨機故障注入生產元件，目的是識別和消除體系結構中的弱點。透過明確查詢應用程式體系結構中的弱點、注入故障並強制進行補救，體系結構自然會隨著時間的推移收斂到更高的安全程度。因此可以在完成前幾個步驟之後，或者在條件允許的情況下，也可伴隨著前述步驟過程透過抗脆弱性試驗持續增強環境的韌性。

安全措施是防禦性的，而系統是在持續的變化之中，隨時可能會出現不可預知的漏洞，因此除了在開發設計時儘可能消除安全隱患，執行時的安全措施一樣也不能少，而且是持續性的，所以需要不斷地改進安全舉措，持續增強抗擊漏洞攻擊等行為。安全能力建設也是系統抗脆弱性的一部分。

總結

雲原生架構實施路線圖只是基於實踐和思考而提出的一個參考方案，具體的實施過程中還有眾多的細節，以及不同公司有不同的實際情況，可能難以滿足所有的場景需求，因此僅供參考。