0代碼實現滾動升級不斷服

升級不斷服存在的問題

要實現升級不斷服，通常需要解決如下問題：

停止服務的時候，可能引起業務中斷。在停止服務的過程中，可能服務正在處理請求，新的請求可能持續的發送到該服務。

在微服務架構下，一般都會通過注冊中心進行服務發現，客戶端會緩存實例地址。停止服務的時候，使用者可能無法及時感知實例下線，并繼續使用錯誤的實例進行訪問，導致失敗。

新服務啟動起來后，會存在灰度狀態，出現多個版本并存，如果新服務新增加了接口，新升級的服務需要正確的將流量發送到包含新接口的服務。

成本：實現升級不斷服，可以先準備大量的備份機器，將新服務啟動起來。然后對用戶的請求進行引流，待老服務沒有流量后，停止老服務。這需要運維人員準備額外的集群資源并開發強大的運維監控系統來完成。

使用CSE框架，可以以極低的成本，不借助運維工具，就能夠輕松的實現升級不斷服

使用CSE進行滾動升級的實踐和評估

在討論不斷服的時候，需要先設計一個測試評估模型。為了簡單，采用下面測試場景來進行評估。調用者通過網關來訪問應用實例1和應用實例2，現在要對應用實例進行升級。升級的過程中，調用者會啟動N個線程，以Mtps的流量來請求。我們可以以整個升級過程出現的失敗次數來評估系統對于不斷服升級的支持好壞。為了節省資源，我們采用先停止1.0版本的實例1，然后部署2.0版本的實例1；再停止1.0版本的實例2，最后部署2.0版本的實例2。另外，我們還需要構造服務端處理時延T，模擬請求正在處理的情況。

在這個過程中，使用CSE測試的數據如下：

調用者線程數N 調用者流量M 處理時延T 失敗次數

     10                      20tps                   無                    0

     10                      80tps                   無                    0

     10                      600tps                   無                  0

     10                      80tps                   100ms             0

實現原理

實現不斷服的核心機制包括如下幾個：

優雅停機：服務停止的時候，需要等待請求完成，并拒絕新請求；

重試：客戶端對于網絡連接錯誤，以及拒絕請求錯誤，需要選擇新服務器進行重試。

隔離：對于失敗超過一定次數的服務實例，進行隔離。

在上面的測試數據中，重試策略配置為：

servicecomb:

loadbalance:

retryEnabled: true

retryOnNext: 1

retryOnSame: 0

隔離策略配置為：

servicecomb:

loadbalance:

myservice:

  isolation:

    enabled: true

    enableRequestThreshold: 5

    singleTestTime: 10000

    continuousFailureThreshold: 2

測試過程中，在停止1.0版本實例2的時候，需要確保2.0版本實例1已經正確處理請求，否則可能出現無實例可用，出現升級中斷。

商業工具

上面描述了僅僅借助SDK就實現升級不斷服。通過配合CSE的灰度發布、部署工具等，可以實現更加可靠的升級不斷服和更好的體驗。

更多精彩文章，盡在微服務蜂巢公眾號，快來關注我們吧~