*作者：竹達 趙宇*

## 背景

CPaaS（cainiao platform as a service）是以公有云為基座，結合先進的雲原生理建設的企業級 DevOps 的 PaaS 平臺，CPaaS 主要目前主要支援的場景：菜鳥生態的雲上研發運維、菜鳥公有云 SaaS 化的能力透出、菜鳥商業化輸出支撐，部署到客戶的公有云、專有云環境。

在服務了菜鳥多家生態公司及部分商業化輸出的產品過程中，深入客戶業務場景，解決業務研發及部署痛點的過程中，積累了一些寶貴的經驗。這裡我們主要對規範雲上研發流程，提升研發效率為目標建設的環境治理（雲上專案環境）及減少線上版本釋出風而險建設的灰度平臺的實現過程進行展開介紹。

## 目標

1、透過專案環境，為多分支並行開發場景提供流量隔離及快速聯調的能力。

2、生產環境實現服務灰度釋出（金絲雀釋出），降低變更風險。

3、微服務應用具備優雅上下線能力，避免啟停過程中帶來的服務呼叫出錯問題。

## 調研階段

### 微服務流量管控

我們首先調研了開源自建的方案。在調研時我們發現，開發和維護開源 SDK 方案的成本非常大。需要對 Spring Cloud 和 Dubbo 這些微服務框架以及 RockeMQ 這類訊息中介軟體非常瞭解，才能準確地找到各個框架的增強點進行定製化開發。

除此之外，業務方使用的微服務框架版本也是跨度很大，維護這些不同版本的微服務框架適配，也需要投入大量的精力。

最重要的一點是，使用開源 SDK 自建的方案，開發業務的同事，需要在應用的開發和部署運維的流程都感知到 SDK 的存在，對開發、構建、運維的侵入性很大，很難進行推廣。

後來我們也找到了阿里集團負責中介軟體的同事尋求支援，瞭解到中介軟體團隊已經推出了一款面向公有云的微服務治理產品 MSE，於是我們進行了調研。

MSE 作為公有云的微服務治理產品，具備雲上的服務管控、微服務測試、標籤路由、離群摘除、優雅上下線等能力，與我們的訴求完全吻合，並且透過 agent 方式實現，對應用程式碼無侵入，更適合 PaaS 平臺對業務應用增加擴充套件。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/35b39ae02c9b43bca6d63b5f1dfc80c1~tplv-k3u1fbpfcp-zoom-1.image "1.png")

圖 1.1

經過與 MSE 團隊同時的幾次電話和會議溝通之後，逐漸對 MSE 產品有了一些功能上的認知。其中在微服務治理中，我們結合實際的業務需求，落地實現了下面 MSE 的部分能力。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f0b5a11017a4314b4d3ac3af5b7b96e~tplv-k3u1fbpfcp-zoom-1.image "2.png")

圖 1.2

## 落地場景

### 專案環境

在多分支開發的場景下，我們通常需要同時部署多個分支。但是多個分支同時部署之後，如何將開發自測流量與日常環境的測試流量分開，以及如何讓各個分支擁有自己獨立的流量，都是需要解決的問題。

-   **流量隔離**

調研和驗證 MSE 的標籤路由的能力之後，實現思路：透過標籤路由能力，將流量進行隔離。

相同應用的不同分支，使用不同的 deployment 實現對版本和容器標籤的管理。圖 2.1 中 core 應用專案環境 c1 和專案環境 c2 均使用獨立於日常環境的容器單獨部署，各自的路由標籤為 joint1 和 joint2。透過對流量攜帶流量標記的方式，完成專案環境流量的控制。

接入層應用則透過 K8s-Ingress  實現流量路由，只需要在請求流量的請求頭中攜帶 x-mse-tag的標籤，則可以將流量路由到對應標籤的入口層應用。入口應用設定標籤傳遞的開發，可將流經此容器的流量打標傳遞到上有服務。如此反覆，則實現流量在整個呼叫鏈路的封閉。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d5d41f02af6b4f4c9c804df2c7406e26~tplv-k3u1fbpfcp-zoom-1.image "3.png")

圖 2.1

-   **服務測試**

在研發過程中，除了分支之間的相互干擾需要隔離之外，還需要從業務側研發的角度解決服務測試的效率問題。MSE 平臺提供了微服務測試平臺，可以快速的幫助開發者實現服務自測，並且我們透過整合方式整合到自身的 PaaS 平臺中，免去自身重建的痛苦。

測試平臺支援按照服務提供者 IP 的維度進行服務測試，剛好與流量隔離相互契合，可以對自身關注的專案環 境的應用容器發起服務測試完成服務自測。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/758dbf4d5ca345739622a92ad52c4868~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖 2.2

### 灰度環境

灰度環境的目的是為了降低線上應用版本釋出的風險，減小問題爆炸半徑。同樣可以透過 MSE 提供的標籤路由功能基礎上完成對流量灰度的實現。

![5.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/88389a50fb794bcb9a75513b05528e72~tplv-k3u1fbpfcp-zoom-1.image "5.jpeg")

圖 2.3

想要流量實現灰度，那麼需要對流量的所有入口實現流量路由。通常我們所感知的流量入口包括：HTTP 接入層、RPC 下游呼叫、MQ 服務消費、Task 任務排程。當前在 MSE 的灰度能力支援範圍內，微服務雲閘道器、金絲雀釋出、MQ 灰度均可以組合實現。

當然，這裡我們只實現了 HTTP 接入層+RPC 的灰度能力，因為歷史的原因，在接入層使用了另一個接入層（MSHA 的 MSFE，本質上是一個 tengine）實現接入層的灰度。但這裡絲毫不影響與 MSE 的灰度能力完成流量的串聯，這得益於 MSE 產品自身擁有良好的對其他產品的相容性。我們只需要在入口層的應用上設定流量經過此容器時帶標，即可完成灰度流量的傳遞。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/89eac1593e49415ba768375af5cd64fe~tplv-k3u1fbpfcp-zoom-1.image "6.png")

圖 2.4

在實際的業務灰度場景中，我們總結了常見的四種灰度場景，均透過 MSE 完成並實現。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52a2abea0df647e9904e6f0e84354fc0~tplv-k3u1fbpfcp-zoom-1.image "7.png")

圖 2.5

## 未來規劃

在使用 MSE 的雲產品之後，對 PaaS 平臺層來說，避免很多重複功能的建設。在我們業務側實際落地的遠不止如上列舉的場景，比如：服務優雅停機、註冊中心等能力，均解決了業務側的微服務治理上的難點問題。

在實現了對專案環境及灰度釋出的能力開發之後，我們接下來對服務離群摘除、應用服務列表透出、服務鑑權、本地聯調部署等能力做重點關注，在降低業務側服務運維成本、微服務可觀測、服務可用性方面與 MSE 團隊加強合作，幫助業務側解決微服務治理中的痛點。

MSE 註冊配置中心專業版首購享 9 折優惠，MSE 雲原生閘道器預付費全規格享 9 折優惠。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠！

菜鳥 CPaaS 平臺微服務治理實踐

相關文章