作者 | 行鬆 阿里巴巴雲原生團隊
應用發佈、服務升級一直是一個讓開發和運維同學既興奮又擔心的事情。
興奮的是有新功能上線，自己的產品可以對用戶提供更多的能力和價值；擔心的是上線的過程會不會出現意外情況影響業務的穩定性。確實，在應用發佈和服務升級時，線上問題出現的可能性更高，本文我們將結合 Serverless 應用引擎（以下簡稱 SAE）就 Serverless 架構下，討論如何保障上線過程中服務的優雅下線。
在平時的發佈過程中，我們是否遇到過以下問題：
- 發佈過程中，出現正在執行的請求被中斷？
- 下游服務節點已經下線，上游依然繼續調用已經下線的節點導致請求報錯，進而導致業務異常？
- 發佈過程造成數據不一致，需要對髒數據進行修復。
有時候，我們把發版安排在凌晨兩三點，趕在業務流量比較小的時候，心驚膽顫、睡眠不足、苦不堪言。那如何解決上面的問題，如何保證應用發佈過程穩定、高效，保證業務無損呢？首先，我們來梳理下造成這些問題的原因。
場景分析
上圖描述了我們使用微服務架構開發應用的一個常見場景，我們先看下這個場景的服務調用關係：
- 服務 B、C 把服務註冊到註冊中心，服務 A、B 從註冊中心發現需要調用的服務；
- 業務流量從負載均衡打到服務 A，在 SLB 上配置服務 A 實例的健康檢查，當服務 A 有實例停機的時候，相應的實例從 SLB 摘掉；服務 A 調用服務 B，服務 B 再調用服務 C；
圖中有兩類流量，南北向流量（即通過 SLB 轉發到後端服務器的業務流量，如業務流量 -> SLB -> A 的調用路徑）和東西向流量（通過註冊中心服務中心服務發現來調用的流量，如 A -> B 的調用路徑），下面針對這兩類流量分別進行分析。
南北向流量
南北向流量存在問題
當服務 A 發佈的時候，服務 A1 實例停機後，SLB 根據健康檢查探測到服務 A1 下線，然後把實例從 SLB 摘掉。實例 A1 依賴 SLB 的健康檢查從 SLB 上摘掉，一般需要幾秒到十幾秒的時間，在這個過程中，如果 SLB 有持續的流量打入，就會造成一些請求繼續路由到實例 A1，導致請求失敗；
服務 A 在發佈的過程中，如何保證經過 SLB 的流量不報錯？我們接著看下 SAE 是如何做的。
南北向流量優雅升級方案
如上文所提，請求失敗的原因在於後端服務實例先停止掉，然後才從 SLB 摘掉，那我們是不是可以先從 SLB 摘掉服務實例，然後再對實例進行升級呢？
按照這個思路，SAE 基於 K8S service 的能力給出了一種方案，當用戶在通過 SAE 為應用綁定 SLB 時，SAE 會在集群中創建一個 service 資源，並把應用的實例和 service 關聯，CCM 組件會負責 SLB 的購買、SLB 虛擬服務器組的創建，並且把應用實例關聯的 ENI 網卡添加到虛擬服務器組中，用戶可以通過 SLB 來訪問應用實例；當應用發佈時，CCM 會先把實例對應的 ENI 從虛擬服務器組中摘除，然後再對實例進行升級，從而保證流量不丟失。
這就是 SAE 對於應用升級過程中關於南北向流量的保障方案。
東西向流量
東西向流量存在問題
在討論完南北向流量的解決方案後，我們再看下東西向流量，傳統的發佈流程中，服務提供者停止再啟動，服務消費者感知到服務提供者節點停止的流程如下：
- 1.服務發佈前，消費者根據負載均衡規則調用服務提供者，業務正常。
- 2.服務提供者 B 需要發佈新版本，先對其中的一個節點進行操作，首先是停止 java 進程。
-
3.服務停止過程，又分為主動註銷和被動註銷，主動註銷是準實時的，被動註銷的時間由不同的註冊中心決定，最差的情況會需要 1 分鐘。
- 1）如果應用是正常停止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被執行，這一步的耗時可以忽略不計。
- 2）如果應用是非正常停止，比如直接使用
kill -9停止，或者 Docker 鏡像構建的時候 java 應用不是 1 號進程且沒有把 kill 信號傳遞給應用。那麼服務提供者不會主動去註銷服務節點，而是在超過一段時間後由於心跳超時而被動地被註冊中心摘除。
- 4.服務註冊中心通知消費者，其中的一個服務提供者節點已下線。包含推送和輪詢兩種方式，推送可以認為是準實時的，輪詢的耗時由服務消費者輪詢間隔決定，最差的情況下需要 1 分鐘。
- 5.服務消費者刷新服務列表，感知到服務提供者已經下線了一個節點，這一步對於 Dubbo 框架來說不存在，但是 Spring Cloud 的負載均衡組件 Ribbon 默認的刷新時間是 30 秒 ，最差情況下需要耗時 30 秒。
- 6.服務消費者不再調用已經下線的節點。
從第 2 步到第 6 步的過程中，Eureka 在最差的情況下需要耗時 2 分鐘，Nacos 在最差的情況下需要耗時 50 秒。在這段時間內，請求都有可能出現問題，所以發佈時會出現各種報錯，同時還影響用戶的體驗，發佈後又需要修復執行到一半的髒數據。最後不得不每次發版都安排在凌晨兩三點發布，心驚膽顫，睡眠不足，苦不堪言。
東西向流量優雅升級方案
經過上文的分析，我們看，在傳統發佈流程中，客戶端有一個服務調用報錯期，原因就是客戶端沒有及時感知到服務端下線的實例。在傳統發佈流程中，主要是藉助註冊中心通知消費者來更新服務提供者列表，那能不能繞過註冊中心，服務提供者直接通知服務消費者呢？答案是肯定的，我們主要做了兩件事情：
- 服務提供者應用在發佈前後主動向註冊中心註銷應用，並將應用標記為已下線的狀態；將原來的停止進程階段註銷服務變成了 prestop 階段註銷服務。
- 在接收到服務消費者請求時，首先會正常處理本次調用，並通知服務消費者此節點已下線，服務消費者會立即從調用列表刪除此節點；在這之後，服務消費者不再調用已經下線的節點。這是將原來的依賴於 註冊中心推送，做到了服務提供者直接通知消費者從調用列表中摘除自己。
通過上面這個方案，就使得下線感知的時間大大減短，從原來的分鐘級別做到準實時，確保應用在下線時能做到業務無損。
分批發布和灰度發佈
上文介紹的是 SAE 在處理優雅下線方面的一些能力，在應用升級的過程中，只有實例的優雅下線是不夠的，還需要有一套配套的發佈策略，保證我們新業務是可用的，SAE 提供分批發布和灰度發佈的能力，可以使得應用的發佈過程更加省心省力；
我們先介紹下灰度發佈，某應用包含 10 個應用實例，每個應用實例的部署版本為 Ver.1 版本，現需將每個應用實例升級為 Ver.2 版本。
從圖中可以看出，在發佈的過程中先灰度 2 臺實例，在確認業務正常後，再分批發布剩餘的實例，發佈的過程中始終有實例處於運行狀態，實例升級過程中依照上面的方案，每個實例都有優雅下線的過程，這就保證了業務無損。
再來看下分批發布，分批發布支持手動、自動分批；還是上面的 10 個應用實例，假設將所有應用實例分 3 批進行部署，根據分批發布策略，該發佈流程如圖所示，就不再具體介紹了。
最後針對在 SAE 上應用灰度發佈的過程進行演示，點擊即可觀看演示過程：https://developer.aliyun.com/lesson_2026_19009
課程推薦
為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless
Serverless 公眾號，發佈 Serverless 技術最新資訊，彙集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。