雲原生DevOps的5步升級路徑

簡介： 究竟什麼是雲原生DevOps呢？咱們認爲：雲原生DevOps是充分利用雲原生基礎設施，基於微服務/無服務架構體系和開源標準，語言和框架無關，具有持續交付和智能自運維能力，從而作到比傳統DevOps更高的服務質量、更低的開發運維成本，讓研發專一於業務的快速迭代。

一、什麼是雲原生DevOps

咱們先經過一個簡單的例子來了解什麼是雲原生DevOps，它和DevOps有什麼不一樣。

上圖是一個大排檔，圖中的大廚在很是努力的去切、炒、製做各類美食，並將它賣出去。從原材料的採購到加工到銷售到售後，都是一兩我的完成。這是很是典型的DevOps場景，團隊搞定端到端的全部的事情。這種狀況，當廚師水平比較高、銷售能力比較強的時候，能夠作到高效率、低浪費。但存在的問題是，想要規模化會很難。由於它的流程都是非標準的，須要廚師有很強的我的能力。

咱們再看這張南京大排檔的圖，雖然名字裏有大排檔，但它顯然不是咱們上面說的大排檔。咱們隨便走進任何一家南京大排檔，均可以發現，南京大排檔的廚師，能夠專一在爲客戶提供更好的菜品上，研發試驗新菜品，並經過小批量的用戶來嘗試和推廣。不管是用戶量增長或減小，都能很快的去適應。店鋪擴張也能夠很快。這種咱們能夠理解爲雲原生DevOps。

那究竟什麼是雲原生DevOps呢？咱們認爲：雲原生DevOps是充分利用雲原生基礎設施，基於微服務/無服務架構體系和開源標準，語言和框架無關，具有持續交付和智能自運維能力，從而作到比傳統DevOps更高的服務質量、更低的開發運維成本，讓研發專一於業務的快速迭代。

如上圖所示，雲原生DevOps基於2個原則：符合開放標準、語言和框架無關，有2個基礎：微服務/無服務架構、Serverless基礎設施 BaaS/FaaS，提供2個能力：智能自運維、持續交付。

符合開放標準、語言和框架無關，相比於針對某個特定語言、特定框架，在技術升級或迭代時能夠有更高的彈性、更好的發展和生命力，造成更好的生態。
2個基礎：基於微服務和無服務架構，可讓DevOps成爲可能；基於Serverless的基礎設施，是面向資源和需求，以達到更好的彈性。
在這2個原則和2個基礎之上，作到2個能力：持續交付和智能自運維。

二、阿里巴巴雲原生DevOps升級案例

咱們先來看一個阿里某團隊雲原生DevOps轉型的案例。

案例背景：阿里某海外電商團隊面臨海外市場站點多、建站成本高、需求變化快、交付慢、運維成本高等挑戰，如何平滑地升級到雲原生DevOps 來解決這些問題，以提高業務交付效率呢？咱們是這麼作的。
（1）架構升級 - 服務治理sidecar和mesh化

第一步是架構升級，首先將服務治理的代碼下沉到應用以外的sidecar部分，同時用服務網格來承載瞭如環境路由之類的能力。如上圖所示，每一個綠點表明一個服務應用代碼，每個橘點表明一個服務治理代碼，這些代碼以二方包的形式存在這個容器中。隨着服務治理體系的建設，這裏面就包含了很是多的東西，如日誌採集、監控埋點、運維干預等等，咱們把這種容器稱之爲富容器。它的問題很明顯：即使是日誌採集的升級或調整，咱們都須要把應用從新升級、構建和部署一遍。然而這個其實與應用自己是沒有任何關係的。同時，由於關注點不分離，日誌採集的一個bug，都會影響到應用自己。

本着讓應用能更專一於應用自己的目的，咱們作的第一件事就是把全部服務治理的代碼從應用容器中剝離出來，放到了sidecar裏面，這樣服務治理和應用的代碼就存在兩個容器裏了。同時咱們又把原來服務治理的一些事情，好比測試路由、鏈路追蹤等交給了Mesh sidecar 。這樣應用就瘦身了，應用只須要關心應用代碼的自己。

這樣作的好處是，業務能夠專一於業務相關的應用代碼，而無需依賴於服務治理了。

這是第一步，這一步是平滑的，由於咱們能夠逐步把服務治理遷移到sidecar裏面，不用擔憂一次遷移成本過大。
（2）架構升級 - 從構建解耦、發佈解耦到運維解耦
第二步，咱們作了三個層面的解耦：構建解耦、發佈解耦、運維解耦。

瞭解微服務和無服務架構的人應該清楚，只有當一個業務可以獨立去開發、測試、發佈、運維的時候，業務才能跑得更快、更好。由於這樣跟其餘人的耦合性降到最低。

可是咱們也知道，隨着業務愈來愈複雜和應用的持續演進，應用裏會包含愈來愈多的業務代碼。好比下圖中這個應用，它裏面有一些代碼是針對某個特定業務的，好比做爲一個支付應用，有的是針對盒馬的特定需求的，有的是針對天貓的特定需求的，還有一些是通用代碼，或者叫平臺代碼，是針對全部業務場景的。

顯然，從提升開發效率的角度講，業務方改本身相關的業務代碼，能夠減小溝通成本，提升研發效率。但這帶來了一個新的問題：若是某一個業務有需求改動，但並不涉及通用的業務邏輯時，也須要對整個應用的全部業務進行全面迴歸，若是這個時間段還有其餘業務改動，他們須要一塊兒集成並進行發佈。若是改動的業務多，你們就須要排隊集成。這種狀況下，集成測試和溝通協調的成本很是高。

咱們的目標是每一個業務都能獨立的開發、發佈和運維。爲了平滑地達到這個目標，咱們首先要作的是讓它們在構建階段可以解耦。好比，對一個相對獨立的業務，咱們將其單獨構建爲一個容器鏡像，並經過編排把它放到Pod的init Container中，Pod啓動的時候，再將其掛載到主應用容器的存儲空間。

可是這時，應用的發佈和運維仍是在一塊兒的，咱們須要將它們分開。

咱們知道，應用的親密性粗略能夠分爲三類：
1、超親密，在同一個進程中，經過函數調用通訊
2、位於同一個Pod的不一樣容器，經過IPC通訊
3、位於同一個網絡中，經過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化的兩大關鍵點是：

• 聲明式地描述資源需求，智能管理，按需使用
• 採用雲上通用資源，對齊標準協議

三、雲效驅動雲原生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標準能力支撐服務發現和治理。

其次，經過雲效流水線實現自動化容器部署，配合灰度部署策略，作到灰度上線，自動擴容，出現故障自動重啓，同時，基於雲效流水線作到零停機快速回滾任意成本，節約機器成本的同時解決了企業無專職運維人員的問題。

第三，經過雲效自動化流水線和分支保護規範研發模式，包括代碼評審、代碼檢測、測試卡點等，提高反饋效率和發佈質量。

下圖爲總體解決方案的架構圖。

四、雲原生DevOps升級路徑

咱們將雲原生DevOps落地分爲5個階段。

第一個階段：全手工交付和運維。它是咱們最初始的階段，應用架構尚未進行服務化改造，也沒有使用雲基礎設施或僅使用IaaS，沒有持續集成、測試自動化，使用手工部署發佈和手工運維。相信不多還有企業停留在這個階段了。

第二個階段：工具化地交付和運維。首先要作的是應用架構的服務化，採用微服務架構改善服務質量；其次是引入一些研發工具，如gitlab、jenkins這類孤島式的工具解決部分問題。同時咱們開始落地單模塊的持續集成，可是通常尚未實現自動化的質量卡點，發佈每每有自動化工具進行輔助。

第三個階段：有限制的持續交付和自動化運維。咱們進一步提高基礎能力，將基礎設施進行容器化改造，基於CaaS建設。另外一方面，開始引入完整的工具鏈，打通研發數據，例如使用雲效DevOps這樣的工具平臺,實現全部數據的完整互通。在發佈能力上能作到持續部署，可是還須要必定的人工干預。這時，自動化測試已經成爲主流了，服務總體能夠觀測，運維可以面向服務，而且是聲明式的。

第四個階段：持續交付和人工輔助自運維。咱們進一步讓開發同窗專一於業務開發，首先在應用架構上開始大量採用無服務架構，並作到無人值守的持續部署；發佈的灰度和回滾，可以在有干預的狀況下儘可能的自動化。觀測能力從應用級別提高到業務級別，實現業務的可觀測性，而且可以在人工輔助的狀況下作到部分的自運維。

第五個階段：全鏈路持續交付和自運維。這是咱們追尋的終極目標。這個階段咱們全部的應用和基礎設施採用的都是無服務架構，並作到端到端的無人值守持續交付，包括髮布的回滾和灰度也是自動化的；技術設施和服務徹底實現自運維。開發者真正只須要關心業務的開發和迭代。

可是，魔鬼都在細節處，固然咱們真正的落地的時候仍有不少的問題須要咱們去解決，藉助雲效這樣的工具平臺和ALPD的專家諮詢，可讓咱們少走彎路，更快的實現目標。

做者：小攻雲攻略

原文連接 

本文爲阿里雲原創內容，未經容許不得轉載