如何落地云原生DevOps？
什么是云原生DevOps?在阿里內(nèi)部有怎樣的實(shí)踐?企業(yè)又該如何落地?阿里云云效專家團(tuán)隊(duì)提出了下一代精益產(chǎn)品開發(fā)方法體系——ALPD，提供了系統(tǒng)的云原生DevOps落地的方法支撐，幫助企業(yè)漸進(jìn)式地邁入云原生DevOps。本文結(jié)合實(shí)際案例，分享通過阿里云云效落地云原生DevOps的五個(gè)階段。
一 什么是云原生DevOps
我們先通過一個(gè)簡單的例子來了解什么是云原生DevOps，它和DevOps有什么不同。
上圖是一個(gè)大排檔，圖中的大廚在非常努力的去切、炒、制作各種美食，并將它賣出去。從原材料的采購到加工到銷售到售后，都是一兩個(gè)人完成。這是非常典型的DevOps場景，團(tuán)隊(duì)搞定端到端的所有的事情。這種情況，當(dāng)廚師水平比較高、銷售能力比較強(qiáng)的時(shí)候，可以做到高效率、低浪費(fèi)。但存在的問題是，想要規(guī)?；瘯茈y。因?yàn)樗牧鞒潭际欠菢?biāo)準(zhǔn)的，需要廚師有很強(qiáng)的個(gè)人能力。
我們再看這張南京大排檔的圖，雖然名字里有大排檔，但它顯然不是我們上面說的大排檔。我們隨便走進(jìn)任何一家南京大排檔，都可以發(fā)現(xiàn)，南京大排檔的廚師，可以專注在為客戶提供更好的菜品上，研發(fā)試驗(yàn)新菜品，并通過小批量的用戶來嘗試和推廣。無論是用戶量增加或減少，都能很快的去適應(yīng)。店鋪擴(kuò)張也可以很快。這種我們可以理解為云原生DevOps。
為了進(jìn)一步方便大家理解，下面的小視頻里，我們邀請了2位阿里大廚，讓他們告訴你什么是云原生DevOps。
所以，總結(jié)來看，我們認(rèn)為：云原生DevOps是充分利用云原生基礎(chǔ)設(shè)施，基于微服務(wù)/無服務(wù)架構(gòu)體系和開源標(biāo)準(zhǔn)，語言和框架無關(guān)，具備持續(xù)交付和智能自運(yùn)維能力，從而做到比傳統(tǒng)DevOps更高的服務(wù)質(zhì)量、更低的開發(fā)運(yùn)維成本，讓研發(fā)專注于業(yè)務(wù)的快速迭代。
如上圖所示，云原生DevOps基于兩個(gè)原則：符合開放標(biāo)準(zhǔn)、語言和框架無關(guān);有兩個(gè)基礎(chǔ)：微服務(wù)/無服務(wù)架構(gòu)、Serverless基礎(chǔ)設(shè)施 BaaS/FaaS;提供兩個(gè)能力：智能自運(yùn)維、持續(xù)交付。
- 符合開放標(biāo)準(zhǔn)、語言和框架無關(guān)，相比于針對某個(gè)特定語言、特定框架，在技術(shù)升級或迭代時(shí)可以有更高的彈性、更好的發(fā)展和生命力，形成更好的生態(tài)。
- 兩個(gè)基礎(chǔ)：基于微服務(wù)和無服務(wù)架構(gòu)，可以讓DevOps成為可能;基于Serverless的基礎(chǔ)設(shè)施，是面向資源和需求，以達(dá)到更好的彈性。
- 在這兩個(gè)原則和兩個(gè)基礎(chǔ)之上，做到兩個(gè)能力：持續(xù)交付和智能自運(yùn)維。
二 阿里巴巴云原生DevOps升級案例
我們先來看一個(gè)阿里某團(tuán)隊(duì)云原生DevOps轉(zhuǎn)型的案例。
案例背景：阿里某海外電商團(tuán)隊(duì)面臨海外市場站點(diǎn)多、建站成本高、需求變化快、交付慢、運(yùn)維成本高等挑戰(zhàn)，如何平滑地升級到云原生DevOps來解決這些問題，以提升業(yè)務(wù)交付效率呢?我們是這么做的。
1 架構(gòu)升級——服務(wù)治理sidecar和mesh化
第一步是架構(gòu)升級，首先將服務(wù)治理的代碼下沉到應(yīng)用之外的sidecar部分，同時(shí)用服務(wù)網(wǎng)格來承載了如環(huán)境路由之類的能力。如上圖所示，每個(gè)綠點(diǎn)代表一個(gè)服務(wù)應(yīng)用代碼，每一個(gè)橘點(diǎn)代表一個(gè)服務(wù)治理代碼，這些代碼以二方包的形式存在這個(gè)容器中。隨著服務(wù)治理體系的建設(shè)，這里面就包含了非常多的東西，如日志采集、監(jiān)控埋點(diǎn)、運(yùn)維干預(yù)等等，我們把這種容器稱之為富容器。它的問題很明顯：即便是日志采集的升級或調(diào)整，我們都需要把應(yīng)用重新升級、構(gòu)建和部署一遍。然而這個(gè)其實(shí)與應(yīng)用本身是沒有任何關(guān)系的。同時(shí)，因?yàn)殛P(guān)注點(diǎn)不分離，日志采集的一個(gè)bug，都會影響到應(yīng)用本身。
本著讓應(yīng)用能更專注于應(yīng)用本身的目的，我們做的第一件事就是把所有服務(wù)治理的代碼從應(yīng)用容器中剝離出來，放到了sidecar里面，這樣服務(wù)治理和應(yīng)用的代碼就存在兩個(gè)容器里了。同時(shí)我們又把原來服務(wù)治理的一些事情，比如測試路由、鏈路追蹤等交給了Mesh sidecar 。這樣應(yīng)用就瘦身了，應(yīng)用只需要關(guān)心應(yīng)用代碼的本身。
這樣做的好處是，業(yè)務(wù)可以專注于業(yè)務(wù)相關(guān)的應(yīng)用代碼，而無需依賴于服務(wù)治理了。這是第一步，這一步是平滑的，因?yàn)槲覀兛梢灾鸩桨逊?wù)治理遷移到sidecar里面，不用擔(dān)心一次遷移成本過大。
2 架構(gòu)升級——從構(gòu)建解耦、發(fā)布解耦到運(yùn)維解耦
第二步，我們做了三個(gè)層面的解耦：構(gòu)建解耦、發(fā)布解耦、運(yùn)維解耦。
了解微服務(wù)和無服務(wù)架構(gòu)的人應(yīng)該清楚，只有當(dāng)一個(gè)業(yè)務(wù)能夠獨(dú)立去開發(fā)、測試、發(fā)布、運(yùn)維的時(shí)候，業(yè)務(wù)才能跑得更快、更好。因?yàn)檫@樣跟其他人的耦合性降到最低。
但是我們也知道，隨著業(yè)務(wù)越來越復(fù)雜和應(yīng)用的持續(xù)演進(jìn)，應(yīng)用里會包含越來越多的業(yè)務(wù)代碼。比如下圖中這個(gè)應(yīng)用，它里面有一些代碼是針對某個(gè)特定業(yè)務(wù)的，比如作為一個(gè)支付應(yīng)用，有的是針對盒馬的特定需求的，有的是針對天貓的特定需求的，還有一些是通用代碼，或者叫平臺代碼，是針對所有業(yè)務(wù)場景的。
顯然，從提高開發(fā)效率的角度講，業(yè)務(wù)方改自己相關(guān)的業(yè)務(wù)代碼，可以減少溝通成本，提高研發(fā)效率。但這帶來了一個(gè)新的問題：如果某一個(gè)業(yè)務(wù)有需求改動(dòng)，但并不涉及通用的業(yè)務(wù)邏輯時(shí)，也需要對整個(gè)應(yīng)用的所有業(yè)務(wù)進(jìn)行全面回歸，如果這個(gè)時(shí)間段還有其他業(yè)務(wù)改動(dòng)，他們需要一起集成并進(jìn)行發(fā)布。如果改動(dòng)的業(yè)務(wù)多，大家就需要排隊(duì)集成。這種情況下，集成測試和溝通協(xié)調(diào)的成本非常高。
我們的目標(biāo)是每個(gè)業(yè)務(wù)都能獨(dú)立的開發(fā)、發(fā)布和運(yùn)維。為了平滑地達(dá)到這個(gè)目標(biāo)，我們首先要做的是讓它們在構(gòu)建階段能夠解耦。比如，對一個(gè)相對獨(dú)立的業(yè)務(wù)，我們將其單獨(dú)構(gòu)建為一個(gè)容器鏡像，并通過編排把它放到Pod的init Container中，Pod啟動(dòng)的時(shí)候，再將其掛載到主應(yīng)用容器的存儲空間。
但是這時(shí)，應(yīng)用的發(fā)布和運(yùn)維還是在一起的，我們需要將它們分開。
我們知道，應(yīng)用的親密性粗略可以分為三類：
- 超親密，在同一個(gè)進(jìn)程中，通過函數(shù)調(diào)用通信。
- 位于同一個(gè)Pod的不同容器，通過IPC通信。
- 位于同一個(gè)網(wǎng)絡(luò)中，通過RPC通信。
我們可以根據(jù)業(yè)務(wù)的特點(diǎn)，逐步地把一些業(yè)務(wù)代碼拆分成一個(gè)個(gè)RPC或者IPC服務(wù)，這樣它們就可以獨(dú)立的發(fā)布和運(yùn)維了。
至此我們就完成了應(yīng)用容器的構(gòu)建解耦、發(fā)布解耦和運(yùn)維解耦。
3 IaC & GitOps
第三步我們看一下開發(fā)和運(yùn)維態(tài)。在很多研發(fā)場景中，一個(gè)棘手的問題是：不同的環(huán)境和業(yè)務(wù)會有非常多的自己特有的配置，在發(fā)布和運(yùn)維時(shí)經(jīng)常需要根據(jù)情況修改和選擇正確的配置，而這個(gè)配置和應(yīng)用代碼本身其實(shí)就是發(fā)布的一部分，傳統(tǒng)的通過控制臺去維護(hù)的方式成本將會非常高。
在云原生背景下，我們認(rèn)為IaC(Infrastructure as Code)和GitOps是更好的選擇。每個(gè)應(yīng)用除了有一個(gè)代碼庫之外，我們還有一個(gè)IaC 倉庫。這個(gè)倉庫里面會包含應(yīng)用的鏡像版本和所有相關(guān)的配置信息。當(dāng)代碼變更需要發(fā)布或配置有變化時(shí)，都通過代碼push 的形式推送到IaC倉庫。GitOps引擎能自動(dòng)檢測到IaC的變化，并自動(dòng)將其翻譯為符合OAM規(guī)范的配置,然后基于OAM模型把改動(dòng)應(yīng)用到對應(yīng)的環(huán)境上。無論是開發(fā)還是運(yùn)維，都可以通過 IaC 的代碼版本了解到系統(tǒng)發(fā)生了哪些變化，而且每次發(fā)布都是完整的。
4 資源的BaaS化
最后一步是資源的BaaS化。
我們想象一下在應(yīng)用中是怎么去使用資源的。我們一般會先去對應(yīng)的控制臺提交資源申請，描述我們需要的資源規(guī)格和要求，然后通過審批后得到資源的連接串和認(rèn)證信息。在應(yīng)用的配置中加上資源配置，之后如果有改動(dòng)，再到對應(yīng)的控制臺操作，并配合代碼發(fā)布進(jìn)行審批。當(dāng)然，對于這類資源的運(yùn)維和監(jiān)控一般也是在獨(dú)立的控制臺進(jìn)行的。
當(dāng)我們的資源種類越來越多，操作和維護(hù)成本就非常高了，尤其是在新建站點(diǎn)的時(shí)候。
本著用聲明式的方式去描述資源、按需使用的原則，我們通過在IaC 里定義這些資源的方式，去簡化所有應(yīng)用對資源的使用。所有的資源都是聲明式的描述，能夠?qū)崿F(xiàn)資源的智能管理和按需使用。同時(shí)我們所有的資源都采用的是云上通用資源、標(biāo)準(zhǔn)協(xié)議，極大降低了遷移成本。這樣我們就逐步把業(yè)務(wù)團(tuán)隊(duì)遷移到云原生基礎(chǔ)設(shè)施上。
所以，資源BaaS化的兩大關(guān)鍵點(diǎn)是：
- 聲明式地描述資源需求，智能管理，按需使用。
- 采用云上通用資源，對齊標(biāo)準(zhǔn)協(xié)議。
三 云效驅(qū)動(dòng)云原生DevOps高效落地
上面我們分享的是阿里內(nèi)部的實(shí)踐，它依賴于阿里內(nèi)部的研發(fā)協(xié)作平臺Aone。Aone的公有云版本即阿里云云效。我們?nèi)绾瓮ㄟ^阿里云云效去落地云原生DevOps呢?
ALPD——云原生時(shí)代的研發(fā)新范式
從前面的案例我們可以看到，云原生DevOps的落地是一個(gè)系統(tǒng)性的工程，需要有系統(tǒng)的方法和工具體系支撐。上圖是阿里云云效專家團(tuán)隊(duì)提出的下一代精益產(chǎn)品開發(fā)方法體系——ALPD，可以看到，ALPD提供了系統(tǒng)的云原生DevOps落地的方法支撐(圖中籃筐所示)。
上圖是云效云原生DevOps解決方案圖。
這里，我們將用戶分為2種角色：
- 技術(shù)主管或架構(gòu)師。
- 工程師，包括開發(fā)、測試和運(yùn)維等。
作為技術(shù)主管或架構(gòu)師，他需要從整體上去定義和把控企業(yè)的研發(fā)行為。從大的角度講，研發(fā)過程包含四個(gè)方面：可運(yùn)行、可觀測、可治理、可變更。
首先他會去定義企業(yè)的研發(fā)協(xié)作模式，例如是采用敏捷研發(fā)還是精益看板。其次他需要掌握整體的產(chǎn)品架構(gòu)、如需要用到哪些云產(chǎn)品、這些云產(chǎn)品如何協(xié)調(diào)和管理等。然后他會去決定團(tuán)隊(duì)的研發(fā)模式：怎么做好研發(fā)協(xié)作，怎么把控研發(fā)質(zhì)量等。第三步，他需要確定發(fā)布策略，采用灰度發(fā)布還是藍(lán)綠部署，灰度策略是什么等等。最后，就是服務(wù)的監(jiān)控策略，比如服務(wù)需要接入哪些監(jiān)控平臺，怎么探測服務(wù)狀態(tài)，全局監(jiān)控配置等等。
一線開發(fā)、測試、運(yùn)維工程師，關(guān)注的是工作過程的順暢和高效。在云效項(xiàng)目協(xié)作平臺接收到一個(gè)需求或任務(wù)之后，可以通過云效去編碼、提交、構(gòu)建、集成、發(fā)布和測試，并部署到預(yù)發(fā)和生產(chǎn)環(huán)境上，將管理員配置的研發(fā)模式、發(fā)布策略真正落地。同時(shí)，各個(gè)環(huán)境都是自動(dòng)觸發(fā)和流轉(zhuǎn)的，不需要人為地協(xié)調(diào)和拉動(dòng)。
整個(gè)研發(fā)過程中產(chǎn)生的數(shù)據(jù)是一個(gè)有機(jī)的整體，可以產(chǎn)生大量的數(shù)據(jù)洞察，可以驅(qū)動(dòng)團(tuán)隊(duì)進(jìn)行持續(xù)改進(jìn)。當(dāng)團(tuán)隊(duì)在研發(fā)過程中遇到瓶頸或迷茫時(shí)，還可以從云效專家團(tuán)隊(duì)獲得專業(yè)的診斷建議和研發(fā)指導(dǎo)。
總結(jié)一下，云效的云原生DevOps解決方案是在ALPD方法論指導(dǎo)下，基于專家建議的最佳實(shí)踐，深度整合到完整的DevOps工具鏈中，幫助企業(yè)漸進(jìn)式地邁入云原生DevOps。
接下來，我們看一個(gè)具體的案例。
某互聯(lián)網(wǎng)企業(yè)，研發(fā)團(tuán)隊(duì)在30人左右，沒有專職的運(yùn)維人員，產(chǎn)品包括20多個(gè)微服務(wù)以及幾十個(gè)前端應(yīng)用(web、小程序、APP等)。其業(yè)務(wù)增長非?？?，在面對快速增長的客戶和越來越多的需求情況下，原先基于Jenkins+ECS的腳本為主的部署方式漸漸無法滿足訴求，特別是無法解決零停機(jī)部署升級的問題。于是，開始需求云效的幫助，并最終全面遷移到云效云原生DevOps。
這個(gè)研發(fā)團(tuán)隊(duì)主要面臨三大痛點(diǎn)：
- 客戶量大、緊急需求多。
- 無專職運(yùn)維、云原生技術(shù)如K8S的學(xué)習(xí)門檻高。
- IT基礎(chǔ)設(shè)施架構(gòu)復(fù)雜、發(fā)布耗時(shí)耗力。
針對這些問題，云效從基礎(chǔ)能力、發(fā)布能力和運(yùn)維能力三個(gè)方面入手。
首先，引入阿里云ACK在已有ECS資源之上進(jìn)行基礎(chǔ)設(shè)施升級，應(yīng)用進(jìn)行容器化改造。在服務(wù)治理和應(yīng)用架構(gòu)上，從Spring Cloud全家桶簡化為SpringBoot，通過K8S標(biāo)準(zhǔn)能力支撐服務(wù)發(fā)現(xiàn)和治理。
其次，通過云效流水線實(shí)現(xiàn)自動(dòng)化容器部署，配合灰度部署策略，做到灰度上線，自動(dòng)擴(kuò)容，出現(xiàn)故障自動(dòng)重啟，同時(shí)，基于云效流水線做到零停機(jī)快速回滾任意成本，節(jié)約機(jī)器成本的同時(shí)解決了企業(yè)無專職運(yùn)維人員的問題。
第三，通過云效自動(dòng)化流水線和分支保護(hù)規(guī)范研發(fā)模式，包括代碼評審、代碼檢測、測試卡點(diǎn)等，提升反饋效率和發(fā)布質(zhì)量。
下圖為整體解決方案的架構(gòu)圖。
四 云原生DevOps升級路徑
我們將云原生DevOps落地分為5個(gè)階段。
第一個(gè)階段：全手工交付和運(yùn)維
它是我們最初始的階段，應(yīng)用架構(gòu)還沒有進(jìn)行服務(wù)化改造，也沒有使用云基礎(chǔ)設(shè)施或僅使用IaaS，沒有持續(xù)集成、測試自動(dòng)化，使用手工部署發(fā)布和手工運(yùn)維。相信很少還有企業(yè)停留在這個(gè)階段了。
第二個(gè)階段：工具化地交付和運(yùn)維
首先要做的是應(yīng)用架構(gòu)的服務(wù)化，采用微服務(wù)架構(gòu)改善服務(wù)質(zhì)量;其次是引入一些研發(fā)工具，如gitlab、jenkins這類孤島式的工具解決部分問題。同時(shí)我們開始落地單模塊的持續(xù)集成，但是一般還沒有實(shí)現(xiàn)自動(dòng)化的質(zhì)量卡點(diǎn)，發(fā)布往往有自動(dòng)化工具進(jìn)行輔助。
第三個(gè)階段：有限制的持續(xù)交付和自動(dòng)化運(yùn)維
我們進(jìn)一步提升基礎(chǔ)能力，將基礎(chǔ)設(shè)施進(jìn)行容器化改造，基于CaaS建設(shè)。另一方面，開始引入完整的工具鏈，打通研發(fā)數(shù)據(jù)，例如使用云效DevOps這樣的工具平臺,實(shí)現(xiàn)所有數(shù)據(jù)的完整互通。在發(fā)布能力上能做到持續(xù)部署，但是還需要一定的人工干預(yù)。這時(shí)，自動(dòng)化測試已經(jīng)成為主流了，服務(wù)整體可以觀測，運(yùn)維能夠面向服務(wù)，并且是聲明式的。
第四個(gè)階段：持續(xù)交付和人工輔助自運(yùn)維
我們進(jìn)一步讓開發(fā)同學(xué)專注于業(yè)務(wù)開發(fā)，首先在應(yīng)用架構(gòu)上開始大量采用無服務(wù)架構(gòu)，并做到無人值守的持續(xù)部署;發(fā)布的灰度和回滾，能夠在有干預(yù)的情況下盡量的自動(dòng)化。觀測能力從應(yīng)用級別提升到業(yè)務(wù)級別，實(shí)現(xiàn)業(yè)務(wù)的可觀測性，并且能夠在人工輔助的情況下做到部分的自運(yùn)維。
第五個(gè)階段：全鏈路持續(xù)交付和自運(yùn)維
這是我們追尋的終極目標(biāo)。這個(gè)階段我們所有的應(yīng)用和基礎(chǔ)設(shè)施采用的都是無服務(wù)架構(gòu)，并做到端到端的無人值守持續(xù)交付，包括發(fā)布的回滾和灰度也是自動(dòng)化的;技術(shù)設(shè)施和服務(wù)完全實(shí)現(xiàn)自運(yùn)維。開發(fā)者真正只需要關(guān)心業(yè)務(wù)的開發(fā)和迭代。
但是，魔鬼都在細(xì)節(jié)處，當(dāng)然我們真正的落地的時(shí)候仍有很多的問題需要我們?nèi)ソ鉀Q，借助云效這樣的工具平臺和ALPD的專家咨詢，可以讓我們少走彎路，更快的實(shí)現(xiàn)目標(biāo)。
