簡介： 究竟什么是云原生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的專家咨詢，可以讓我們少走彎路，更快的實現目標。

作者：小攻云攻略

原文鏈接?

本文為阿里云原創內容，未經允許不得轉載

?

總結

以上是生活随笔為你收集整理的云原生DevOps的5步升级路径的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。