全部產品
Search
文件中心

Microservices Engine:服務發布策略

更新時間:Jul 06, 2024

本文介紹目前被業界廣泛採用的服務發布策略,包括藍綠部署、A/B測試以及金絲雀發布。

藍綠部署

藍綠部署需要對服務的新版本進行冗餘部署,一般新版本的執行個體規格和數量與舊版本保持一致,相當於該服務有兩套完全相同的部署環境,只不過此時只有舊版本在對外提供服務,新版本作為熱備。當服務進行版本升級時,只需將流量全部切換到新版本即可,舊版本作為熱備。由於冗餘部署的緣故,所以不必擔心新版本的資源不夠。如果新版本上線後出現嚴重的問題,那麼只需將流量全部切回至舊版本,大大縮短故障恢複的時間。待新版本完成問題修複並重新部署之後,再將舊版本的流量切換到新版本。

藍綠部署通過使用額外的執行個體資源來解決服務發布期間的不可用問題,當服務新版本出現故障時,也可以快速將流量切回舊版本。

如下圖所示,某服務舊版本為v1,對新版本v2進行冗餘部署。版本升級時,將現有流量全部切換為新版本v2。

藍綠髮布1

當新版本v2存在問題或者發生故障時,可以快速切回舊版本v1。

藍綠髮布2

  • 藍綠部署的優點:

    • 部署結構簡單,營運方便。

    • 服務升級過程操作簡單,周期短。

  • 藍綠部署的缺點:

    • 資源冗餘,需要部署兩套生產環境。

    • 新版本故障影響範圍大。

A/B測試

A/B測試基於使用者請求的元資訊將流量路由到新版本,這是一種基於請求內容匹配的灰階發布策略。只有匹配特定規則的請求才會被引流到新版本,常見的做法包括基於HTTP Header和Cookie。基於HTTP Header方式,例如User-Agent的值為Android的請求 (來自安卓系統的請求)可以訪問新版本,其他系統仍然訪問舊版本。基於Cookie方式,Cookie中通常包含具有業務語義的使用者資訊,例如普通使用者可以訪問新版本,VIP使用者仍然訪問舊版本。

如下圖所示,某服務目前的版本為v1,現在新版本v2要上線。希望安卓使用者可以嘗鮮新功能,其他系統使用者保持不變。

A/B測試1

通過在監控平台觀察舊版本與新版本的成功率、RT對比,當新版本整體服務符合預期後,即可將所有請求切換到新版本v2,最後為了節省資源,可以逐步下線到舊版本v1。

A/B測試2

  • A/B測試的優點:

    • 可以對特定的請求或者使用者提供服務新版本,新版本故障影響範圍小。

    • 需要構建完備的監控平台,用於對比不同版本之間請求狀態的差異。

  • A/B測試的缺點:

    • 仍然存在資源冗餘,因為無法準確評估請求容量。

    • 發布周期長。

金絲雀發布

金絲雀發布是將少量的請求引流到新版本上,因此部署新版本服務只需極小數的執行個體。驗證新版本符合預期後,逐步調整流量權重比例,使得流量慢慢從老版本遷移至新版本,期間可以根據設定的流量比例,對新版本服務進行擴容,同時對老版本服務進行縮容,使得底層資源得到最大化利用。

如下圖所示,某服務目前的版本為v1,現在新版本v2要上線。為確保流量在服務升級過程中平穩無損,採用金絲雀發布方案,逐步將流量從老版本遷移至新版本。

金絲雀發布1

  • 金絲雀發布的優點:

    • 按比例將流量無差別地導向新版本,新版本故障影響範圍小。

    • 發布期間逐步對新版本擴容,同時對老版本縮容,資源使用率高。

  • 金絲雀發布的缺點:

    • 流量無差別地導向新版本,可能會影響重要使用者的體驗。

    • 發布周期長。