Serverless架構下的服務優雅下線的示例分析

本篇文章給大家分享的是有關Serverless架構下的服務優雅下線的示例分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

應用發布、服務升級一直是一個讓開發和運維同學既興奮又擔心的事情。

興奮的是有新功能上線，自己的產品可以對用戶提供更多的能力和價值；擔心的是上線的過程會不會出現意外情況影響業務的穩定性。確實，在應用發布和服務升級時，線上問題出現的可能性更高，本文我們將結合 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 秒。在這段時間內，請求都有可能出現問題，所以發布時會出現各種報錯，同時還影響用戶的體驗，發布后又需要修復執行到一半的臟數據。最后不得不每次發版都安排在凌晨兩三點發布，心驚膽顫，睡眠不足，苦不堪言。

東西向流量優雅升級方案

經過上文的分析，我們看，在傳統發布流程中，客戶端有一個服務調用報錯期，原因就是客戶端沒有及時感知到服務端下線的實例。在傳統發布流程中，主要是借助注冊中心通知消費者來更新服務提供者列表，那能不能繞過注冊中心，服務提供者直接通知服務消費者呢？答案是肯定的，我們主要做了兩件事情：

1. 服務提供者應用在發布前后主動向注冊中心注銷應用，并將應用標記為已下線的狀態；將原來的停止進程階段注銷服務變成了 prestop 階段注銷服務。

2. 在接收到服務消費者請求時，首先會正常處理本次調用，并通知服務消費者此節點已下線，服務消費者會立即從調用列表刪除此節點；在這之后，服務消費者不再調用已經下線的節點。這是將原來的依賴于 注冊中心推送，做到了服務提供者直接通知消費者從調用列表中摘除自己。

通過上面這個方案，就使得下線感知的時間大大減短，從原來的分鐘級別做到準實時，確保應用在下線時能做到業務無損。

分批發布和灰度發布

上文介紹的是 SAE 在處理優雅下線方面的一些能力，在應用升級的過程中，只有實例的優雅下線是不夠的，還需要有一套配套的發布策略，保證我們新業務是可用的，SAE 提供分批發布和灰度發布的能力，可以使得應用的發布過程更加省心省力；

我們先介紹下灰度發布，某應用包含 10 個應用實例，每個應用實例的部署版本為 Ver.1 版本，現需將每個應用實例升級為 Ver.2 版本。

從圖中可以看出，在發布的過程中先灰度 2 臺實例，在確認業務正常后，再分批發布剩余的實例，發布的過程中始終有實例處于運行狀態，實例升級過程中依照上面的方案，每個實例都有優雅下線的過程，這就保證了業務無損。

再來看下分批發布，分批發布支持手動、自動分批；還是上面的 10 個應用實例，假設將所有應用實例分 3 批進行部署，根據分批發布策略。

以上就是Serverless架構下的服務優雅下線的示例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。