![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/abd49dbcf990480387169f74e0b9e2df.png)

作者 | 張裕
編輯 | 雅純
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/WUVXXKd_GpHBoBGEgTEjzw)

# 什麼是雲原生 DevOps

點選檢視影片：[https://v.qq.com/x/page/u3220cutt7v.html](https://v.qq.com/x/page/u3220cutt7v.html)

我們先透過上面一個簡短影片和下面兩張圖，來了解什麼是雲原生 DevOps，它和 DevOps 有什麼不同。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/441ecd00c2054a90b572e8e3765f76fc.png)

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/fa07dce1701a4b74b67138d1d30cc8cd.png)

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

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8e3b4a671a774369abccd219af921c88.png)

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

- 2 個原則：符合開放標準、語言和框架無關。相比於針對某個特定語言、特定框架，在技術升級或迭代時可以有更高的彈性、更好的發展和生命力，形成更好的生態。

- 2 個基礎：基於微服務和無服務架構，可以讓 DevOps 成為可能；基於 Serverless 的基礎設施，是面向資源和需求，以達到更好的彈性。

- 在這 2 個原則和 2 個基礎之上，做到 2 個能力：持續交付和智慧自運維。

# 阿里巴巴雲原生 DevOps 升級案例

我們先來看一個阿里某團隊雲原生 DevOps 轉型的案例。 案例背景：阿里某海外電商團隊面臨海外市場站點多、建站成本高、需求變化快、交付慢、運維成本高等挑戰，如何平滑地升級到雲原生 DevOps 來解決這些問題，以提升業務交付效率呢？我們是這麼做的。

## 1. 架構升級 - 服務治理 sidecar 和 mesh 化

![4.png](https://ucc.alicdn.com/pic/developer-ecology/c322b687aaa741dd919a3d063a9b3b3b.png)

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/6b01cacb7c5b4d9588ccec60a1f0ff79.png)

本著讓應用能更專注於應用本身的目的，我們做的第一件事就是把所有服務治理的程式碼從應用容器中剝離出來，放到了 sidecar 裡面，這樣服務治理和應用的程式碼就存在兩個容器裡了。同時我們又把原來服務治理的一些事情，比如測試路由、鏈路追蹤等交給了 Mesh sidecar 。這樣應用就瘦身了，應用只需要關心應用程式碼的本身。

這樣做的好處是，業務可以專注於業務相關的應用程式碼，而無需依賴於服務治理了。

這是第一步，這一步是平滑的，因為我們可以逐步把服務治理遷移到 sidecar 裡面，不用擔心一次遷移成本過大。

## 2. 架構升級 - 從構建解耦、釋出解耦到運維解耦

第二步，我們做了三個層面的解耦：構建解耦、釋出解耦、運維解耦。

瞭解微服務和無服務架構的人應該清楚，只有當一個業務能夠獨立去開發、測試、釋出、運維的時候，業務才能跑得更快、更好。因為這樣跟其他人的耦合性降到最低。但是我們也知道，隨著業務越來越複雜和應用的持續演進，應用裡會包含越來越多的業務程式碼。比如下圖中這個應用，它裡面有一些程式碼是針對某個特定業務的，比如作為一個支付應用，有的是針對盒馬的特定需求的，有的是針對天貓的特定需求的，還有一些是通用程式碼，或者叫平臺程式碼，是針對所有業務場景的。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/7b61397bfa9a4959aeaf9e1d9d89ed44.png)

顯然，從提高開發效率的角度講，業務方改自己相關的業務程式碼，可以減少溝通成本，提高研發效率。但這帶來了一個新的問題：如果某一個業務有需求改動，但並不涉及通用的業務邏輯時，也需要對整個應用的所有業務進行全面迴歸，如果這個時間段還有其他業務改動，他們需要一起整合並進行釋出。如果改動的業務多，大家就需要排隊整合。這種情況下，整合測試和溝通協調的成本非常高。

我們的目標是每個業務都能獨立的開發、釋出和運維。為了平滑地達到這個目標，我們首先要做的是讓它們在構建階段能夠解耦。比如，對一個相對獨立的業務，我們將其單獨構建為一個容器映象，並透過編排把它放到 Pod 的 init Container 中，Pod 啟動的時候，再將其掛載到主應用容器的儲存空間。

但是這時，應用的釋出和運維還是在一起的，我們需要將它們分開。

我們知道，應用的親密性粗略可以分為三類：

- 超親密，在同一個程式中，透過函式呼叫通訊。

- 位於同一個 Pod 的不同容器，透過 IPC 通訊。

- 位於同一個網路中，透過 RPC 通訊。

我們可以根據業務的特點，逐步地把一些業務程式碼拆分成一個個 RPC 或者 IPC 服務，這樣它們就可以獨立的釋出和運維了。

至此我們就完成了應用容器的構建解耦、釋出解耦和運維解耦。

## 3. IaC & GitOps

![7.png](https://ucc.alicdn.com/pic/developer-ecology/161989f33d77482484f3b33df25311f9.png)

第三步我們看一下開發和運維態。在很多研發場景中，一個棘手的問題是：不同的環境和業務會有非常多的自己特有的配置，在釋出和運維時經常需要根據情況修改和選擇正確的配置，而這個配置和應用程式碼本身其實就是釋出的一部分，傳統的透過控制檯去維護的方式成本將會非常高。

在雲原生背景下，我們認為 IaC（Infrastructure as Code）和 GitOps 是更好的選擇。每個應用除了有一個程式碼庫之外，我們還有一個 IaC 倉庫。這個倉庫裡面會包含應用的映象版本和所有相關的配置資訊。當程式碼變更需要釋出或配置有變化時，都透過程式碼 push 的形式推送到 IaC 倉庫。GitOps 引擎能自動檢測到 IaC 的變化，並自動將其翻譯為符合 OAM 規範的配置，然後基於 OAM 模型把改動應用到對應的環境上。無論是開發還是運維，都可以透過 IaC 的程式碼版本瞭解到系統發生了哪些變化，而且每次釋出都是完整的。

## 4. 資源的 BaaS 化

![8.png](https://ucc.alicdn.com/pic/developer-ecology/b295503c070848a9a4107f5c75775d05.png)

最後一步是資源的 BaaS 化。

我們想象一下在應用中是怎麼去使用資源的。我們一般會先去對應的控制檯提交資源申請，描述我們需要的資源規格和要求，然後透過審批後得到資源的連線串和認證資訊。在應用的配置中加上資源配置，之後如果有改動，在到對應的控制檯操作，並配合程式碼釋出進行審批。當然，對於這類資源的運維和監控一般也是在獨立的控制檯進行的。

當我們的資源種類越來越多，操作和維護成本就非常高了，尤其是在新建站點的時候。

本著用宣告式的方式去描述資源、按需使用的原則，我們透過在 IaC 裡定義這些資源的方式，去簡化所有應用對資源的使用。所有的資源都是宣告式的描述，能夠實現資源的智慧管理和按需使用。同時我們所有的資源都採用的是雲上通用資源、標準協議，極大降低了遷移成本。這樣我們就逐步把業務團隊遷移到雲原生基礎設施上。

所以，資源 BaaS 化的兩大關鍵點是：

- 宣告式地描述資源需求，智慧管理，按需使用。

- 採用雲上通用資源，對齊標準協議。

# 雲效驅動雲原生 DevOps 高效落地

上面我們分享的是阿里內部的實踐，它依賴於阿里內部的研發協作平臺 Aone。Aone 的公有云版本即阿里云云效。我們如何透過阿里云云效去落地雲原生 DevOps 呢？

![9.png](https://ucc.alicdn.com/pic/developer-ecology/845ee9eae2e94ccebdfa6e2d1ade293f.png)

從前面的案例我們可以看到，雲原生 DevOps 的落地是一個系統性的工程，包含方法、架構、協作和工程各個方面。其中，雲原生 DevOps 的落地屬於精益交付的範疇。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/ae5261f3dbf94e7bb9b4d3ea1badc783.png)

上圖是雲效雲原生 DevOps 解決方案圖。

這裡，我們將使用者分為 2 種角色：

- 技術主管或架構師。

- 工程師，包括開發、測試和運維等。

作為技術主管或架構師，他需要從整體上去定義和把控企業的研發行為。從大的角度講，研發過程包含四個方面：可執行、可觀測、可治理、可變更。

首先他會去定義企業的研發協作模式，例如是採用敏捷研發還是精益看板。其次他需要掌握整體的產品架構、如需要用到哪些雲產品、這些雲產品如何協調和管理等。然後他會去決定團隊的研發模式：怎麼做好研發協作，怎麼把控研發質量等。第三步，他需要確定釋出策略，採用灰度釋出還是藍綠部署，灰度策略是什麼等等。最後，就是服務的監控策略，比如服務需要接入哪些監控平臺，怎麼探測服務狀態，全域性監控配置等等。

一線開發、測試、運維工程師，關注的是工作過程的順暢和高效。在雲效專案協作平臺接收到一個需求或任務之後，可以透過雲效去編碼、提交、構建、整合、釋出和測試，並部署到預發和生產環境上，將管理員配置的研發模式、釋出策略真正落地。同時，各個環境都是自動觸發和流轉的，不需要人為地協調和拉動。

整個研發過程中產生的資料是一個有機的整體，可以產生大量的資料洞察，可以驅動團隊進行持續改進。當團隊在研發過程中遇到瓶頸或迷茫時，還可以從雲效專家團隊獲得專業的診斷建議和研發指導。

總結一下，雲效的雲原生 DevOps 解決方案是在 ALPD 方法論指導下，基於專家建議的最佳實踐，深度整合到完整的 DevOps 工具鏈中，幫助企業漸進式地邁入雲原生 DevOps。

接下來，我們看一個具體的案例。

某網際網路企業，研發團隊在 30 人左右，沒有專職的運維人員，產品包括 20 多個微服務以及幾十個前端應用（web、小程式、APP 等）。其業務增長非常快，在面對快速增長的客戶和越來越多的需求情況下，原先基於 Jenkins+ECS 的指令碼為主的部署方式漸漸無法滿足訴求，特別是無法解決零停機部署升級的問題。於是，開始需求雲效的幫助，並最終全面遷移到雲效雲原生 DevOps。

這個研發團隊主要面臨三大痛點：

- 客戶量大、緊急需求多。

- 無專職運維、雲原生技術如 K8s 的學習門檻高。

- IT 基礎設施架構複雜、釋出耗時耗力。

針對這些問題，雲效從**基礎能力**、**釋出能力**和**運維能力**三個方面入手。

首先，引入阿里雲 ACK 在已有 ECS 資源之上進行基礎設施升級，應用進行容器化改造。在服務治理和應用架構上，從 Spring Cloud 全家桶簡化為 SpringBoot，透過 K8s 標準能力支撐服務發現和治理。

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

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

下圖為整體解決方案的架構圖。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/5eecafef591a45718269d7b517624fbf.png)

# 雲原生 DevOps 升級路徑

我們將雲原生 DevOps 落地分為 5 個階段。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/aa3dcf1af81e4bb99c97e2b8cca74a7f.png)

第一個階段：**全手工交付和運維**。它是我們最初始的階段，應用架構還沒有進行服務化改造，也沒有使用雲基礎設施或僅使用 IaaS，沒有持續整合、測試自動化，使用手工部署釋出和手工運維。相信很少還有企業停留在這個階段了。

第二個階段：**工具化的交付和運維**。首先要做的是應用架構的服務化，採用微服務架構改善服務質量；其次是引入一些研發工具，如 gitlab、jenkins 這類孤島式的工具解決部分問題。同時我們開始落地單模組的持續整合，但是一般還沒有實現自動化的質量卡點，釋出往往有自動化工具進行輔助。

第三個階段：**有限制的持續交付和自動化運維**。我們進一步提升基礎能力，將基礎設施進行容器化改造，基於 CaaS 建設。另一方面，開始引入完整的工具鏈，打通研發資料，例如使用雲效 DevOps 這樣的工具平臺,實現所有資料的完整互通。在釋出能力上能做到持續部署，但是還需要一定的人工干預。這時，自動化測試已經成為主流了，服務整體可以觀測，運維能夠面向服務，並且是宣告式的。

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

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

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

雲原生 DevOps 的 5 步升級路徑

相關文章