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

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

　　圖 1 云原生融合架構(gòu)實施步驟

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

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

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

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

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

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

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

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

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

2. 步驟二：服務(wù)管理和治理

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

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

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

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

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

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

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

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

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

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

4. 步驟四：自服務(wù)敏捷響應(yīng)基礎(chǔ)設(shè)施

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

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

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

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

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

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

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

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

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

總結(jié)

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