*作者：揚少*

歷史上 90%的故障源於業務新版本上線，如何最大化保障功能迭代過程中業務流量無損一直是開發者比較關心的問題。尤其對於分散式架構的微服務應用而言，服務之間的依賴關係錯綜複雜，一個業務功能需要多個微服務共同提供能力，一次業務請求需要經過多個微服務才能完成處理，牽一髮而動全身。業務的發展需要應用系統不斷的迭代，我們無法避免應用頻繁變更發版，但是我們可以提升應用升級過程中的穩定性和高可用。

## 場景分析

首先，我們來看一個真實的業務場景。如下是某電商公司的業務架構，包含使用者中心（User）、購物車（Chart）和訂單中心（Order），後端微服務統一透過閘道器對外提供服務，其中開發框架採用 Spring Boot 和 Dubbo，註冊中心使用的 Nacos。其中下單請求的呼叫鏈路為：閘道器->User->Chart->Order。

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

隨著使用者群體和業務規模不斷擴大，原有的下單功能逐漸暴露出了很多設計和程式上的缺陷。業務開發者針對這些亟待解決的問題進行了重新設計和最佳化，需要對線上的使用者中心和訂單中心同時釋出新版本進行修復。在對系統中已有服務進行版本升級過程中，開發者的操作步驟一般為：

1.  在正式上線之前，小流量驗證新版本是否符合預期
1.  驗證符合預期之後，開始逐步下線服務的老版本
1.  同時逐步上線服務的新版本，直到所有的流量切到新版本為止

這種釋出的處理方式是正確的，但是這些步驟中仍然有非常多的細節要考慮，遺漏或未處理好任何一個細節，都有可能影響線上流量，甚至引發故障，進而造成業務有損，使用者體驗下降。接下來會對每一個環節進行詳細分析其中的痛點和挑戰。

### 灰度驗證

對於傳統的單體應用來說，所有的服務模組耦合在一個應用程式中，灰度驗證的實現相對簡單。如果採用的是基於流量比權重的方式進行灰度引流，那麼只需要在前面四層代理對應用新老版本的 IP 進行權重分配即可；如果採用的是基於請求內容的方式進行小流量驗證，比如基於請求的 Header、路徑引數或者 Cookie 的灰度方式，那麼需要在應用前面的七層代理閘道器上配置對應的灰度路由。

在分散式微服務架構中，應用中被拆分出來的子服務都是獨立部署、執行和迭代的，服務之間的依賴關係錯綜複雜，有時某個功能發版依賴多個服務同時升級上線。這時，對新功能驗證時就涉及到了對多個服務同時灰度的問題，透過構建從閘道器到整個後端服務的環境隔離來對多個不同版本的服務進行灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，如圖所示：

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

針對剛剛提到的業務場景，需要在叢集中部署使用者中心和訂單中心的新版本，然後需要配置合適的灰度策略，確保灰度流量能夠正確的流經這些服務的新版本。這裡，有幾個核心問題要解決：

1.  端到端的灰度策略如何實現
1.  每一跳的灰度節點如何識別
1.  每一跳的流量容災如何實現

### 正式上線—老版本下線

在小流量灰度驗證環節，我們透過真實的線上業務流量和人工模擬的各種業務極端 case 的灰度請求，已經充分驗證了新版本的正確性，現在開始對服務的老版本進行下線操作。

看似簡單的下線操作，其實暗藏玄機。由於微服務應用自身呼叫特點，在高併發下，服務提供端應用例項的直接下線，會導致服務消費端應用例項無法實時感知下游例項的實時狀態，因而出現繼續將請求轉發到已下線的例項從而出現請求報錯，流量有損。

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

為什麼會出現上述問題呢？我們從客戶端視角和服務端視角分別來分析。

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

當服務端應用的某個節點下線時，由於註冊中心的心跳保活機制存在時間視窗範圍內的延遲，導致註冊中心感知服務端下線的事件滯後，進一步延遲了客戶端感知服務端下線的時間。在客戶端收到下線事件之前，線上的流量仍然會被負載到已下線的節點，導致業務流量有損。

整個過程不僅依賴註冊中心感知節點變更的時效性，還嚴重依賴客戶端訂閱的實現邏輯。比如，Spring Cloud 框架為了在可用性和效能方面做平衡，消費者預設是 30s 去註冊中心拉取最新的服務列表，因此服務端例項的下線事件被客戶端感知的時間存在較大的時間差，進一步擴大了呼叫已下線節點的持續時間。

如何確保服務老版本下線過程中流量無損呢？

### 正式上線—新版本上線

在服務老版本的下線過程中，我們需要逐步完成新版本上線，確保機器的容量滿足線上流量規模。

同樣，新版本上線過程中也是危機重重。當服務的新節點啟動之後，註冊中心會感知服務新節點上線事件並通知客戶端拉取服務的最新節點資訊列表，客戶端更新連線池資訊並加入新節點，新的訪問請求會被負載到新節點上。由於新節點啟動之後，需要進行一些資源初始化和預熱操作。這時，如果大量的請求在資源初始化完畢之前到來，會導致請求出現超時或出錯，甚至直接導致新節點當機不可用。

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

以下舉例是 Java 服務新節點啟動之後一般涉及到的操作：

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

1.  應用初始化：載入必須的類，裝配處理器，監聽連線
1.  服務註冊：向註冊中心登記服務以及對應的節點資訊
1.  節點就緒：容器化應用上設定的就緒探針檢查透過
1.  流量進入：延遲載入所需的類，熱點程式碼 JIT，快取需要回源，資料庫需要建鏈

只有流量進入以後，服務所需的資源才被動載入。在大規模流量場景下，因資源載入消耗一定的硬體資源，此時大量請求得不到及時的響應，出現短暫的超時或錯誤，甚至拖垮其他上下游的服務，造成嚴重的業務不可用的後果。

如何確保服務新版本上線過程中流量無損呢？

## 解決方案

在上一節我們針對應用釋出新版本過程中涉及到痛點進行了詳細分析，這一節會給出一些比較好的解決方案供開發者參考。

### 全鏈路灰度

如何在實際業務場景中去快速落地全鏈路灰度呢？目前，主要有兩種解決思路，基於物理環境隔離和基於邏輯環境隔離。

-   **物理環境隔離**

物理環境隔離，顧名思義，透過增加機器的方式來搭建真正意義上的流量隔離。

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

這種方案需要為要灰度的服務搭建一套網路隔離、資源獨立的環境，在其中部署服務的灰度版本。這個方案一般用於企業的測試、預發開發環境的搭建，對於線上灰度釋出引流的場景來說其靈活性不夠。況且，微服務多版本的存在在微服務架構中是家常便飯，需要為這些業務場景採用堆機器的方式來維護多套灰度環境。如果您的應用數目過多的情況下，會造成運維、機器成本過大，成本和代價遠超收益；如果應用數目很小，就兩三個應用，這個方式還是很方便的，可以接受的。

-   **邏輯環境隔離**

另一種方案是構建邏輯上的環境隔離，我們只需部署服務的灰度版本，流量在呼叫鏈路上流轉時，由流經的閘道器、各個中介軟體以及各個微服務來識別灰度流量，並動態轉發至對應服務的灰度版本。如下圖：

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

上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務閘道器還是微服務本身都需要識別流量，根據治理規則做出動態決策。當服務版本發生變化時，這個呼叫鏈路的轉發也會實時改變。相比於利用機器搭建的灰度環境，這種方案不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精細化的全鏈路控制。

那麼全鏈路灰度具體是如何實現呢？透過上面的討論，我們需要解決以下問題：

1.  鏈路上各個元件和服務能夠根據請求流量特徵進行動態路由 —— 標籤路由
1.  需要對服務下的所有節點進行分組，能夠區分版本 ——  節點打標
1.  需要對流量進行灰度標識、版本標識 —— 流量染色、分散式鏈路追蹤

如果想為現有的業務接入全鏈路灰度能力，不可避免的需要為業務使用的閘道器以及後端服務開發框架 SDK 進行改造。首先，需要支援動態路由功能，對於 Spring Cloud、Dubbo 開發框架，可以對出口流量實現自定義 Filter，在該 Filter 中完成流量識別以及標籤路由。同時需要藉助分散式鏈路追蹤技術完成流量標識鏈路傳遞以及流量自動染色。此外，需要引入一箇中心化的流量治理平臺，方便各個業務線的開發者定義自己的全鏈路灰度規則。

### 無損下線

下線過程中出現流量有損的根本原因，在於應用提供者節點在停止服務前沒有確保已經通知到所有消費者不再呼叫自己，也無法確保在處理完所有請求之後再停止應用。所以新發版的應用，即使業務程式碼沒有任何問題，也可能在釋出過程影響使用者的體驗。

要想達到無損下線的效果，就要依次解決上面的問題。

1.  服務提供者待下線節點在主動從註冊中心登出之後，並持續執行一小段時間之後，再退出並停止執行
1.  服務提供者待下線節點主動告知客戶端下線事件，避免後續新請求訪問

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

開源的微服務框架本身是不具備這些能力，開發者需要深入瞭解各個微服務框架的實現細節，需要設計好 PreStop 指令碼，需要修改底層通訊框架來做主動通知機制，並要確保在途的請求都處理完畢才能下線。此外，還需要修改現有的服務訂閱 SDK，配合主動通知機制觸發客戶端主動重新整理。

### 無損上線

上線過程中出現流量有損的根本原因，是因為在某些場景下，服務提供者需要經過一段時間資源預熱才能正常地接收大流量的請求併成功返回。同時在 K8s 場景下，還需要和 K8s 中的 readiness 、滾動釋出等生命週期緊密結合，才能確保應用釋出過程中能不出現業務報錯。

一般場景下，剛釋出的微服務應用例項跟其他正常例項一樣一起平攤線上總 QPS。要想達到無損上線的效果，就是控制負載到新節點上流量是漸進式遞增的，給予新節點充足的時間進行資源預熱。

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

目前， 開源 Dubbo 所實現的小流量服務預熱過程原理如下：

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

服務提供端在向註冊中心註冊服務的過程中，將自身的預熱時⻓ WarmupTime、服務啟動時間 StartTime 透過後設資料的形式註冊到註冊中心中，服務消費端在註冊中心訂閱相關服務例項列 表，呼叫過程中根據 WarmupTime、StartTime 計算個例項所分批的呼叫權重。剛啟動 StartTime 距離呼叫時刻差值較小的例項權重下，從而實現對剛啟動應用分配更少流量實現對其進行小流量預熱。

Dubbo 提供的方案是線性增長的，那麼如何做到剛開始慢，後面越來越快呢？如何建設無損上線的可觀測體系呢？這樣可以更方便的瞭解應用上線過程中各個環節的狀況。

### 無侵入式解決方案

上面我們分析了問題並給出了對應的解決方案，無外乎都需要開發者對現有的閘道器和微服務框架進行改造，存在一定的開發成本和維護成本，也給業務發展帶來了不穩定的因素。目前，我們結合阿里巴巴十幾年雙十一大促經驗總結做成雲產品，對外輸出這些能力。使用者可以以低成本、無侵入的方式接入，享受沉澱多年的微服務治理能力。

-   **單體應用的灰度釋出**

對於業務規模比較小的企業，可能更傾向於選擇單體應用。對於單體應用的灰度釋出來說，可以直接利用雲原生閘道器支援的基於權重或者基於請求內容的灰度路由即可完成灰度釋出。

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

-   **微服務應用的灰度釋出**

對於採用微服務架構且業務規模較大的企業，一次新功能上線可能要涉及到多個微服務同時發版上線，這時具備端到端的環境隔離特性的全鏈路灰度可以非常方便助力業務快速迭代。針對微服務應用場景，使用者可以參考以下兩種方案來助力業務快速迭代發展。

#### **1. 雲原生閘道器 + MSE 微服務治理**

-   雲原生閘道器將流量閘道器、微服務閘道器和安全閘道器三合一，支援標準 K8s Ingress，相容 Nginx Ingress Annotaition，支援標籤路由、流量染色、路由 Fallback，支援多種服務發現方式。
-   MSE 微服務治理提供一站式微服務治理解決方案，無侵入增強主流 Spring Cloud, Apache Dubbo 等開源微服務框架

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

#### **2. 雲原生閘道器 + EDAS**

企業級分散式應用服務 EDAS 是一個應用託管和微服務管理的雲原生 PaaS 平臺，提供應用開發、部署、監控、運維等全棧式解決方案。目前，雲原生閘道器與 EDAS 完成了整合。容器使用者習慣使用標準 Ingress 資源定義路由規則來對外提供服務，可以在 EDAS 平臺選擇 MSE Ingress 輕鬆完成服務對外暴露。

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

## 動手實踐

目前，我們針對微服務場景和 K8s 服務場景下的灰度釋出，分別建立了免費的實驗室，歡迎感興趣的讀者前來體驗。

1. 基於雲原生閘道器實現微服務的多版本線上灰度*<https:>*

2. 基於 MSE 實現 K8s 叢集內多服務的灰度釋出*<https:>*

## 總結

本文詳細分析了應用釋出新版本過程中遇到的問題以及應對方法，最後給出了低成本、無侵入式的 MSE 雲原生閘道器+MSE 微服務治理、MSE 雲原生閘道器+EDAS 的解決方案。

MSE 雲原生閘道器、註冊配置中心**首購 8 折優惠，首購 1 年及以上 7 折優惠**。

掃碼瞭解更多產品資訊~

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

應用釋出新版本如何保障流量無損

相關文章