云原生架構體系內容眾多，如果深入到微服務、容器、 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 ）”，它將隨機故障注入生產組件，目的是識別和消除體系結構中的弱點。通過明確查找應用程序體系結構中的弱點、注入故障并強制進行補救，體系結構自然會隨著時間的推移收斂到更高的安全程度。因此可以在完成前幾個步驟之后，或者在條件允許的情況下，也可伴隨著前述步驟過程通過抗脆弱性試驗持續增強環境的韌性。

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

總結

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