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