云原生架構(gòu)實(shí)施路線圖

【導(dǎo)讀】云原生架構(gòu)體系內(nèi)容眾多，建設(shè)做不到一步到位，彼此之間也存在著先后次序相關(guān)性，需要通過一系列項(xiàng)目持續(xù)完成相關(guān)的能力，從而實(shí)現(xiàn)云原生融合架構(gòu)。本文分享了根據(jù)云原生架構(gòu)體系中技術(shù)之間的關(guān)系和實(shí)際經(jīng)驗(yàn)，基于“頂層規(guī)劃+分步實(shí)施”的原則，定義為5個步驟的云原生架構(gòu)實(shí)施路線圖。通過本文能夠相對深入的理解云原生架構(gòu)體系，并為企業(yè)實(shí)際做出頂層規(guī)劃提供啟發(fā)。云原生架構(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ū)動設(shè)計(jì)DDD方法等。云原生這么多的內(nèi)容做不到一步到位，而且彼此之間也存在著先后次序相關(guān)性，它需要通過一系列的項(xiàng)目持續(xù)完成相關(guān)的能力，從而實(shí)現(xiàn)云原生融合架構(gòu)。由于云原生架構(gòu)體系內(nèi)容眾多，需要對其有相對深入的理解并能根據(jù)企業(yè)實(shí)際做出實(shí)施頂層規(guī)劃，然后以分步實(shí)施的方法邊建設(shè)邊交付價值，使整個體系建設(shè)具備可持續(xù)性。圖1云原生融合架構(gòu)實(shí)施步驟根據(jù)云原生架構(gòu)體系中技術(shù)之間的關(guān)系和實(shí)際經(jīng)驗(yàn)，基于“頂層規(guī)劃+分步實(shí)施”的原則，云原生架構(gòu)實(shí)施路線圖我們定義為5個步驟：1.微服務(wù)采用及運(yùn)行環(huán)境容器云平臺構(gòu)建；2.服務(wù)管理和治理；3.持續(xù)交付及安全；4.自服務(wù)敏捷向基礎(chǔ)設(shè)施建設(shè)；5.增強(qiáng)生產(chǎn)環(huán)境韌性和安全性。每個實(shí)施步驟又可以根據(jù)實(shí)際建設(shè)需要分為若干個子項(xiàng)目，并可能需要多次迭代。比如說，步驟一微服務(wù)采用及運(yùn)行環(huán)境構(gòu)建，容器云平臺建設(shè)和系統(tǒng)微服務(wù)架構(gòu)采用可能需要分別以不同的項(xiàng)目立項(xiàng)。容器云平臺作為基礎(chǔ)設(shè)施平臺，可能還需要規(guī)劃采購服務(wù)器、存儲、網(wǎng)絡(luò)設(shè)備等，也可能需要根據(jù)微服務(wù)系統(tǒng)改造進(jìn)度持續(xù)進(jìn)行采購。微服務(wù)的設(shè)計(jì)開發(fā)就是個持續(xù)的過程，可能涉及不同系統(tǒng)的新建或改造重構(gòu)。同時呢，也可能需要前期的咨詢、規(guī)劃指導(dǎo)和培訓(xùn)等。不同的單位實(shí)際情況不同，所采取的步驟和方式也會不同。1.步驟一：微服務(wù)采用及運(yùn)行環(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ù)運(yùn)行在容器中。所以第一步在采用微服務(wù)的同時需要構(gòu)建容器環(huán)境支撐微服務(wù)的運(yùn)行。基于容器技術(shù)和容器調(diào)度管理技術(shù)如Kubernetes構(gòu)建企業(yè)內(nèi)私有容器云平臺支撐微服務(wù)應(yīng)用系統(tǒng)的部署、運(yùn)行和管理，實(shí)現(xiàn)微服務(wù)運(yùn)行時環(huán)境支持，基于容器云平臺可以實(shí)現(xiàn)相關(guān)的自服務(wù)敏捷能力，比如彈性擴(kuò)展、服務(wù)路由、分發(fā)限流、健康檢查、錯誤隔離、故障恢復(fù)、資源調(diào)度等。以云應(yīng)用12或15要素為指導(dǎo)設(shè)計(jì)微服務(wù)。當(dāng)前微服務(wù)分拆的方式通常是基于領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）方法。不過DDD對業(yè)務(wù)領(lǐng)域的劃分往往難以清晰定義領(lǐng)域邊界，存在著領(lǐng)域劃分不合理、數(shù)據(jù)同時存在于不同領(lǐng)域的問題，為每個服務(wù)選擇合適的責(zé)任級別及其范圍是困難的，需要極深的經(jīng)驗(yàn)和對業(yè)務(wù)的理解。因此MartinFlowler建議可以先建一個傳統(tǒng)的大一統(tǒng)系統(tǒng)，在對領(lǐng)域知識有更好的了解以后，再通過重構(gòu)將其改造成微服務(wù)。筆者覺得DDD通過領(lǐng)域劃分可以在一定程度上簡化業(yè)務(wù)關(guān)系，從而簡化微服務(wù)設(shè)計(jì)，但領(lǐng)域劃分也使每個領(lǐng)域缺乏全局認(rèn)識，所以DDD更像是一種分類簡化的設(shè)計(jì)方法，這會造成多次的重復(fù)迭代，造成浪費(fèi)。而MartinFlowler的建議則使DDD有了全局的視角，能夠從上到下，全局來看到領(lǐng)域劃分和設(shè)計(jì)，但這個大一統(tǒng)系統(tǒng)并不容易建設(shè)。筆者基于實(shí)踐提出了“主數(shù)據(jù)驅(qū)動設(shè)計(jì)”的微服務(wù)設(shè)計(jì)方法，主數(shù)據(jù)本來就是系統(tǒng)間共享的高價值數(shù)據(jù)，基于企業(yè)主數(shù)據(jù)設(shè)計(jì)的微服務(wù)天然具備系統(tǒng)間的可重用性。而且基于行業(yè)通用數(shù)據(jù)模型(CommonDataModel，CDM)則很容易定義并完善主數(shù)據(jù)微服務(wù)，減少重復(fù)的迭代設(shè)計(jì)和實(shí)現(xiàn)。2.步驟二：服務(wù)管理和治理微服務(wù)架構(gòu)在分解應(yīng)用的同時也帶來了微服務(wù)數(shù)量的成倍增長，使服務(wù)的管理和治理難以通過人工完成。隨著微服務(wù)量的增加，需要完善服務(wù)的管理和治理能力。在完成容器云平臺運(yùn)行時支撐建設(shè)之后，可以側(cè)重實(shí)現(xiàn)服務(wù)的治理和API的定義，以支持高效的管理和敏捷的服務(wù)編排響應(yīng)，同時實(shí)現(xiàn)基于API的協(xié)同。微服務(wù)治理有多種實(shí)現(xiàn)的方法。基于容器云平臺可以直接利用k8s的能力實(shí)現(xiàn)服務(wù)的注冊發(fā)現(xiàn)、配置、路由分發(fā)、負(fù)載均衡、彈性擴(kuò)容等，不過容器云平臺要作為企業(yè)級應(yīng)用支撐平臺，需要在Kubernetes之上擴(kuò)展實(shí)現(xiàn)服務(wù)的管理和治理能力。CNCF推薦用ServiceMesh，代理東西向流量，支持跨語言。Porvital的SpringCloud框架提供了相對完整的服務(wù)治理實(shí)現(xiàn)，比如服務(wù)的注冊發(fā)現(xiàn)、配置、熔斷、客戶端負(fù)載均衡等，但僅支持Java；等等有眾多的框架和技術(shù)。微服務(wù)架構(gòu)提出的一個主要目的就是通過API來屏蔽開發(fā)語言，無論用什么開發(fā)語言，只要遵循同樣的API，都可以進(jìn)行協(xié)同。其實(shí)這類似于地球上不同國家之間的交流，通過相互可以理解的公共語言就可以對話。因此在實(shí)現(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)部可以實(shí)現(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ù)運(yùn)行運(yùn)營的基礎(chǔ)能力，具備了支撐微服務(wù)彈性擴(kuò)展、協(xié)同交互的能力。有了部署運(yùn)維平臺和服務(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)隊(duì)的持續(xù)交付要求。這也是我們一直提倡先著力構(gòu)建微服務(wù)運(yùn)行支撐環(huán)境的重要原因。DevOps一種思想和方法論，其核心是協(xié)作反饋，只有及時的反饋才能反思和改進(jìn)。利用DevOps思想構(gòu)建持續(xù)交付能力的過程中，會涉及組織架構(gòu)的優(yōu)化，這可能是一個難點(diǎn)。首先組織領(lǐng)導(dǎo)要能夠理解DevOps思想和理念，知道組織的弱點(diǎn)并愿意嘗試改進(jìn)；其次，DevOps體系（DevOps體系可能不僅僅是一個平臺）可能涉及眾多的組件和工具，或者需要一體化的設(shè)計(jì)研發(fā)，每種方式都會花費(fèi)大量人力和時間。比如說用開源工具，持續(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工具鏈和流水線實(shí)施和使用過程中逐步完善，以提升云原生的整體安全性。4.步驟四：自服務(wù)敏捷響應(yīng)基礎(chǔ)設(shè)施基礎(chǔ)設(shè)施在第一步搭建容器云平臺和微服務(wù)的時候就會用到，只不過這個階段微服務(wù)量相對較少，對自服務(wù)敏捷響應(yīng)基礎(chǔ)設(shè)施沒有迫切需求。隨著持續(xù)交付能力的提升，微服務(wù)量的增長，運(yùn)維能力需要從量變演化到質(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ā)、運(yùn)行、運(yùn)維的平臺，例如持續(xù)交付平臺、容器云平臺等。純技術(shù)工具指的是和業(yè)務(wù)無關(guān)、圍繞支撐平臺周邊的工具，比如消息平臺（RabbitMQ、Kafka）、監(jiān)控平臺、權(quán)限管理平臺、認(rèn)證平臺、人臉識別平臺等等。這些平臺可以提取構(gòu)建技術(shù)中臺能力，各業(yè)務(wù)應(yīng)用都可以復(fù)用這些能力。在實(shí)施持續(xù)交付的同時，也是在部分構(gòu)建自服務(wù)敏捷響應(yīng)基礎(chǔ)設(shè)施能力，比如持續(xù)集成、持續(xù)交付流水線等。在這個步驟，需要重點(diǎn)構(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ù)等。實(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è)施資源多種多樣，可能來自不同的廠商品牌、不同的型號、不同的架構(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)隊(duì)來運(yùn)維運(yùn)營基礎(chǔ)設(shè)施資源，為平臺和工具提供資源服務(wù)；平臺團(tuán)隊(duì)來運(yùn)維運(yùn)營平臺，工具團(tuán)隊(duì)來持續(xù)研發(fā)工具和技術(shù)中臺服務(wù)，支撐以應(yīng)用管理為中心的架構(gòu)；應(yīng)用研發(fā)團(tuán)隊(duì)專注于業(yè)務(wù)應(yīng)用微服務(wù)的研發(fā)，使用自服務(wù)的資源、平臺、工具實(shí)現(xiàn)服務(wù)的研發(fā)、測試、部署、運(yùn)行、運(yùn)維等全生命周期管理。5.步驟五：增強(qiáng)生產(chǎn)環(huán)境韌性和安全性脆弱性的反面是健壯性、韌性。抗脆弱性（或反脆弱性，Antifragility）的目的就是持續(xù)定時或不定時通過在運(yùn)行環(huán)境中注入故障的方式來主動的找到弱點(diǎn)，并強(qiáng)制修復(fù)這些弱點(diǎn)，從而提升環(huán)境的健壯性和韌性。以人類免疫系統(tǒng)為例，當(dāng)受到病毒侵害時，人體的免疫系統(tǒng)就會自動做出反應(yīng)，會變得更強(qiáng)；而當(dāng)人被隔離時，免疫系統(tǒng)會變得更弱。用人類免疫系統(tǒng)的思想來構(gòu)建云原生架構(gòu)的韌性，以抵御不同場景下的故障。NetflixSimianArmy項(xiàng)目有個著名的子模塊“混沌猴（ChaosMonkey）”，它將隨機(jī)故障注入生產(chǎn)組件，目的是識別和消除體系結(jié)構(gòu)中的弱點(diǎn)。通過明確查找應(yīng)用程序體系結(jié)構(gòu)中的弱點(diǎn)、注入故障并強(qiáng)制進(jìn)行補(bǔ)救，體系結(jié)構(gòu)自然會隨著時間的推移收斂到更高的安全程度。因此可以在完成前幾個步驟之后，或者在條件允許的情況下，也可伴隨著前述步驟過程