前言

在新版本上線時，無論是從產品穩定性還是使用者對新版本的接受程度上考慮，直接將老應用升級到新版本應用都有很大風險的。我們一般的做法是，保證新老版本同時線上，並且先將少部分流量切換到新版本應用上，同時在此期間對新版本的應用請求進行觀察。在確認新版本沒有問題後，再逐步將更大比例的流量切換到新版本上。這個過程的核心是可以對流量的流入轉發規則進行配置，EDAS 的金絲雀釋出能力，提供了多個版本同時線上的能力，並且提供了靈活的配置規則來給不同的版本進行流量分配。

部署在 EDAS Kubernetes 叢集中的 Spring Cloud 微服務應用，在新版本釋出的時候可以使用金絲雀釋出進行小規模驗證，驗證通過後再全量升級。

金絲雀釋出配置

首先，進入 EDAS 的應用部署頁面，對我們要進行部署升級的應用進行釋出，在這裡我們選擇金絲雀（灰度）釋出。需要注意的是，對灰度釋出的流量控制，當前只對非入口應用的 Dubbo 和 Spring Cloud 應用生效。所謂入口應用，即承接外部流量的第一個應用節點。並且若您的應用使用了 HPA、Rancher、Istio、或者依賴Deployment.Metadata.Name 或 Deployment.Metadata.Uid 的功能與配置等 K8s 原生功能或配置時，請勿使用灰度釋出或分批發布。否則，應用部署之後，這些 K8s 原生功能或配置將出現異常。

在釋出頁面，可以選擇通過上傳 JAR 包或者填入 JAR 包地址的方式選擇要進行釋出的新版本應用部署包。

在選擇好要進行釋出的新版本應用部署包後，接下來進行釋出策略的配置。這裡分為兩個部分：

第一部分可以對釋出批次進行設定，例如設定釋出灰度批次，首批進行灰度的 pod 例項個數，分批間處理方式等；
第二部分可以對流量灰度規則進行配置，我們可以選擇按流量內容進行灰度或者簡單地按照流量比例進行灰度，下面將詳細介紹這兩種釋出策略配置。

設定釋出策略

在批次釋出這裡我們可以進行的配置有：

首批灰度數量：在點選發布後，會首先將首批灰度數量個數的例項進行新版本的釋出，為了保證應用的穩定性，首批灰度的例項數不能超過應用例項總數的 50%。比如當前例項數是 7 臺，那麼最多隻能選擇 3 臺作為首批灰度的例項；
剩餘批次：首批灰度釋出完成後，剩餘的應用例項將按照此處指定的批次釋出完成；
分批間處理方式：剩餘批次間的處理方式可選擇手動或者自動，若選擇自動，則剩餘的幾個批次將在前一批發布完成後進行自動釋出，自動釋出的批次間隔也可進行配置，例如配置每批次在釋出完成後，30 分鐘後自動進行下一批次的釋出；
批次內部署間隔：每一批次內，如果此批次內要釋出的應用例項數大於 1，則要進行此配置指定批次內例項部署間隔。

在下面的例子中，我們現在有 7 個 pod 應用例項，選擇首批對 2 個例項進行灰度升級。在首批 2 個例項的灰度釋出完成後，將剩下的 5 個例項分 3 個批次進行釋出。這3個批次的批次間處理方式選擇自動釋出，在當前批次釋出完成 30 分鐘後自動進行下一批次的釋出。同時，由於第 2 批次和第 2 批次內例項個數為兩臺，因此選擇批次內兩臺例項部署間隔為 60 秒。在釋出頁面右側可以對我們的釋出策略配置資訊進行預覽。

設定灰度規則

目前支援 按內容灰度和 按比例灰度兩種方式設定灰度規則。按請求內容進行灰度支援將請求內容符合指定灰度規則條件的流量作為灰度流量，進入到灰度例項中，例如，選擇使用者 ID 模 100 小於等於 40 的流量作為灰度流量進入灰度例項進行處理，而使用者 ID 模 100 大於 40 的仍然進入非灰度例項進行處理，如圖 1 所示。而按流量比例進行灰度是指，將指定比例的請求流量作為灰度流量進入灰度例項進行處理，例如指定 40% 的流量作為灰度流量，如圖 2 所示。

（圖1）

（圖2）

按請求內容進行灰度

按請求內容進行灰度可以進行下面指定引數的配置，來決定有哪些請求內容特徵的流量將作為灰度流量進入灰度例項中。

協議型別：可選擇 Spring Cloud 和 Dubbo，這裡我們主要介紹 Spring Cloud 協議。在 Spring Cloud 協議下需要對 HTTP 請求路徑進行配置；
條件模式：針對下面配置的的條件列表，可配置條件模式為： 同時滿足下列條件和 滿足下列任一條件。符合條件模式的請求將作為灰度流量；
條件列表：Spring Cloud 協議下可分別對 Cookie、Header 和 Parameter 3 種請求內容進行條件配置。

按比例進行灰度

按比例灰度即設定 流量比例，然後請求流量會按配置的比例被轉發到當前的灰度分組中進行處理。

灰度釋出並驗證新版本應用是否符合預期

配置好釋出配置後，即可開始進行灰度釋出，EDAS 將先在指定的灰度分組中部署新版本應用，可在進入 變更詳情頁面檢視部署進度和狀態。如果在灰度釋出時，發現新版本有問題，還可以終止變更並對應用進行回滾。

在灰度的釋出過程中，可對應用進行監控，以監控灰度流量是否符合預期，同時可以對應用狀態進行新老版本的對比。在當前批次的灰度流量驗證完成後，在變更詳情頁面單擊開始下一批，完成後續分批發布。如果在驗證過程中，發現新版本應用有問題，可以在變更詳情頁面右上角單擊立即回滾。在彈出的立即回滾對話方塊確認回滾的影響，然後單擊回滾。

關於如何監控灰度流量，可以參考 EDAS文件《監控灰度流量》。

灰度釋出後，在基本資訊頁面檢視部署包是否為新部署的應用版本。在例項部署資訊頁面檢視應用例項的執行狀態是否為執行正常。

結語及其後續

本章我們介紹瞭如何對 EDAS Kubernetes 叢集上的 Spring Cloud 應用進行灰度釋出，在灰度釋出過程中，我們可以靈活地配置釋出策略、灰度規則以及在釋出過程中對流量及應用狀態進行監控，並且提供了終止回滾等操作，最大程度地保證應用能夠平滑地進行版本升級。接下來的文章中，我們將詳細介紹在釋出過程中如何對應用進行監控。

“ 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可灰度）

前言