云原生架構體系內(nèi)容眾多，如果深入到微服務、容器、 DevOps、服務網(wǎng)格ServiceMesh、自服務敏捷基礎設施、混沌工程、安全等任何一項內(nèi)容都有很多的工作需要做。比如說微服務，一套SpringCloud開發(fā)框架就需要很多的學習成本，更別說還有很多其他的框架、方法和思想，比如微服務的拆分領域驅(qū)動設計DDD方法等。

云原生這么多的內(nèi)容做不到一步到位，而且彼此之間也存在著先后次序相關性，它需要通過一系列的項目持續(xù)完成相關的能力，從而實現(xiàn)云原生融合架構。由于云原生架構體系內(nèi)容眾多，需要對其有相對深入的理解并能根據(jù)企業(yè)實際做出實施頂層規(guī)劃，然后以分步實施的方法邊建設邊交付價值，使整個體系建設具備可持續(xù)性。

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

根據(jù)云原生架構體系中技術之間的關系和實際經(jīng)驗，基于“頂層規(guī)劃+分步實施”的原則，云原生架構實施路線圖我們定義為5個步驟：

1. 微服務采用及運行環(huán)境容器云平臺構建；
2. 服務管理和治理；
3. 持續(xù)交付及安全；
4. 自服務敏捷向基礎設施建設；
5. 增強生產(chǎn)環(huán)境韌性和安全性。

每個實施步驟又可以根據(jù)實際建設需要分為若干個子項目，并可能需要多次迭代。比如說，步驟一微服務采用及運行環(huán)境構建，容器云平臺建設和系統(tǒng)微服務架構采用可能需要分別以不同的項目立項。容器云平臺作為基礎設施平臺，可能還需要規(guī)劃采購服務器、存儲、網(wǎng)絡設備等，也可能需要根據(jù)微服務系統(tǒng)改造進度持續(xù)進行采購。微服務的設計開發(fā)就是個持續(xù)的過程，可能涉及不同系統(tǒng)的新建或改造重構。同時呢，也可能需要前期的咨詢、規(guī)劃指導和培訓等 。不同的單位實際情況不同，所采取的步驟和方式也會不同。

1. 步驟一：微服務采用及運行環(huán)境構建

云原生架構體系中，應用是交付業(yè)務價值的載體，而微服務是構建業(yè)務應用的技術。經(jīng)微服務架構分解的應用服務運行在容器中。所以第一步在采用微服務的同時需要構建容器環(huán)境支撐微服務的運行。

基于容器技術和容器調(diào)度管理技術如Kubernetes構建企業(yè)內(nèi)私有容器云平臺支撐微服務應用系統(tǒng)的部署、運行和管理，實現(xiàn)微服務運行時環(huán)境支持，基于容器云平臺可以實現(xiàn)相關的自服務敏捷能力，比如彈性擴展、服務路由、分發(fā)限流、健康檢查、錯誤隔離、故障恢復、資源調(diào)度等。

以云應用12或15要素為指導設計微服務。當前微服務分拆的方式通常是基于 領域驅(qū)動設計（DDD）方法。不過DDD 對業(yè)務領域的劃分往往難以清晰定義領域邊界，存在著領域劃分不合理、數(shù)據(jù)同時存在于不同領域的問題，為每個服務選擇合適的責任級別及其范圍是困難的，需要極深的經(jīng)驗和對業(yè)務的理解。

因此Martin Flowler建議可以先建一個傳統(tǒng)的大一統(tǒng)系統(tǒng)，在對領域知識有更好的了解以后，再通過重構將其改造成微服務。筆者覺得DDD通過領域劃分可以在一定程度上簡化業(yè)務關系，從而簡化微服務設計，但 領域劃分也使每個領域缺乏全局認識，所以DDD更像是一種分類簡化的設計方法， 這會造成多次的重復迭代，造成浪費。而Martin Flowler的建議則使DDD有了全局的視角，能夠從上到下，全局來看到領域劃分和設計，但這個大一統(tǒng)系統(tǒng)并不容易建設。

筆者基于實踐提出了“主數(shù)據(jù)驅(qū)動設計”的微服務設計方法，主數(shù)據(jù)本來就是系統(tǒng)間共享的高價值數(shù)據(jù)，基于企業(yè)主數(shù)據(jù)設計的微服務天然具備系統(tǒng)間的可重用性。而且基于行業(yè)通用數(shù)據(jù)模型(Comm on Data Model，CDM)則很容易定義并完善主數(shù)據(jù)微服務，減少重復的迭代設計和實現(xiàn)。

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

微服務架構在分解應用的同時也帶來了微服務數(shù)量的成倍增長，使服務的管理和治理難以通過人工完成。隨著微服務量的增加，需要完善服務的管理和治理能力。在完成容器云平臺運行時支撐建設之后，可以側(cè)重實現(xiàn)服務的治理和 API的定義，以支持高效的管理和敏捷的服務編排響應，同時實現(xiàn)基于 API的協(xié)同。

微服務治理有多種實現(xiàn)的方法。基于容器云平臺可以直接利用k 8s的能力實現(xiàn)服務的注冊發(fā)現(xiàn)、配置、路由分發(fā)、負載均衡、彈性擴容等，不過容器云平臺要作為企業(yè)級應用支撐平臺，需要在Kubernetes之上擴展實現(xiàn)服務的管理和治理能力。CNCF推薦用 ServiceMesh，代理東西向流量，支持跨語言。Porvital的 SpringClou d框架提供了相對完整的服務治理實現(xiàn)，比如服務的注冊發(fā)現(xiàn)、配置、熔斷、客戶端負載均衡等，但僅支持Java；等等有眾多的框架和技術 。

微服務架構提出的一個主要目的就是通過API來屏蔽開發(fā)語言，無論用什么開發(fā)語言，只要遵循同樣的 API，都可以進行協(xié)同。其實這類似于地球上不同國家之間的交流，通過相互可以理解的公共語言就可以對話。因此在實現(xiàn)服務治理時需要考慮跨平臺能力以及對內(nèi)和對外 API服務能力。這里要區(qū)分下微服務的 API和對外的 OpenAPI ，可以看作是兩個層次 。OpenAPI通常是跨平臺、跨企業(yè)的，用于構建生態(tài)系統(tǒng)，不過企業(yè)內(nèi)部也可以用于構建企業(yè)內(nèi)部生態(tài)。思想都是一樣。

云原生以API為協(xié)同方式，因此在公司內(nèi)部可以實現(xiàn)容器云平臺和 API網(wǎng)關兩層的服務治理能力。同一個微服務可以通過 API網(wǎng)關暴露為不同的 API，或者也可以多個微服務暴露為一個 API。API既可以面向企業(yè)內(nèi)部，也可以面向外部生態(tài)伙伴。

3. 步驟三：持續(xù)交付及安全

前兩個步驟完成了微服務運行運營的基礎能力，具備了支撐微服務彈性擴展、協(xié)同交互的能力。有了部署運維平臺和服務管理治理能力，則就可以側(cè)重提升研發(fā)端的持續(xù)交付能力。這樣，無論開發(fā)多少微服務，在服務管理和治理方面也就沒有了后顧之憂。以DevOps理論為指導，構建持續(xù)集成、持續(xù)部署、持續(xù)交付、持續(xù)監(jiān)控、持續(xù)反饋的閉環(huán)流程。

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

DevOps一種思想和方法論，其核心是協(xié)作反饋，只有及時的反饋才能反思和改進。利用 DevOps思想構建持續(xù)交付能力的過程中，會涉及組織架構的優(yōu)化，這可能是一個難點。首先組織領導要能夠理解 DevOps思想和理念，知道組織的弱點并愿意嘗試改進；其次， DevOps 體系（DevOps體系可能不僅僅是一個平臺 ） 可能涉及眾多的組件和工具，或者需要一體化的設計研發(fā)，每種方式都會花費大量人力和時間。

比如說用開源工具，持續(xù)集成和持續(xù)交付流程涉及開發(fā)、源碼管理、源碼檢查、單元測試、用例管理、構建、安全測試、交付管理等眾多的工具，僅考慮打通這些工具的認證權限管理，就不是一件容易的事。因此有些DevOps廠商直接自研持續(xù)集成、持續(xù)交付等流水線。如果具備這樣的研發(fā)能力，筆者建議盡可能自研或者合作研發(fā)，這也是為系統(tǒng)融合打好基礎，避免眾多的開源第三方工具帶來眾多的集成問題，難以有效融合在一起。

認證和權限是DevOps體系中的基礎安全措施。代碼安全檢查、鏡像安全檢查、系統(tǒng)安全、應用安全、接口安全、容器安全等等都需要在 DevOps工具鏈和流水線實施和使用過程中逐步完善，以提升云原生的整體安全性。

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

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

基礎設施大致可以劃分為三個部分：基礎設施資源、支撐平臺和純技術工具。基礎設施資源可能有很多種異構資源和云平臺，需要通過統(tǒng)一的層次（比如多云管理平臺）來封裝，提供統(tǒng)一的基礎設施資源服務，隔離底層異構資源細節(jié)，簡化應用資源調(diào)度。支撐平臺主要是微服務開發(fā)、運行、運維的平臺，例如 持續(xù)交付平臺、容器云平臺等。純技術工具指的是和業(yè)務無關、圍繞支撐平臺周邊的工具，比如消息平臺（ RabbitMQ、Kafka ）、監(jiān)控平臺、權限管理平臺、認證平臺、人臉識別平臺等等。這些平臺可以提取構建技術中臺能力，各業(yè)務應用都可以復用這些能力。

在實施持續(xù)交付的同時，也是在部分構建自服務敏捷響應基礎設施能力，比如持續(xù)集成、持續(xù)交付流水線等。在這個步驟，需要重點構建和完善自動化、自服務的基礎設施能力，包括統(tǒng)一身份認證和權限服務、日志服務、配置服務、監(jiān)控服務、告警服務、安全服務、AI服務（人臉識別、文字識別、圖像識別、語音識別、自然語言處理、知識圖譜、算法等）、消息服務、調(diào)度服務等基礎服務和CICD研發(fā)流程服務等 。實現(xiàn)這些服務的自服務能力是構建應用敏捷響應的關鍵。

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

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

5. 步驟五：增強生產(chǎn)環(huán)境韌性和安全性

脆弱性的反面是健壯性、韌性?？勾嗳跣裕ɑ蚍创嗳跣?，Antifragility ）的目的就是持續(xù)定時或不定時通過在運行環(huán)境中注入故障的方式來主動的找到弱點，并強制修復這些弱點，從而提升環(huán)境的健壯性和韌性。以人類免疫系統(tǒng)為例，當受到病毒侵害時，人體的免疫系統(tǒng)就會自動做出反應，會變得更強；而當人被隔離時，免疫系統(tǒng)會變得更弱。用人類免疫系統(tǒng)的思想來構建云原生架構的韌性，以抵御不同場景下的故障。

Netflix Simian Army項目有個著名的子模塊“混沌猴（Chaos Monkey ）”，它將隨機故障注入生產(chǎn)組件，目的是識別和消除體系結(jié)構中的弱點。通過明確查找應用程序體系結(jié)構中的弱點、注入故障并強制進行補救，體系結(jié)構自然會隨著時間的推移收斂到更高的安全程度。因此可以在完成前幾個步驟之后，或者在條件允許的情況下，也可伴隨著前述步驟過程通過抗脆弱性試驗持續(xù)增強環(huán)境的韌性。

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

總結(jié)

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