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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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