Serverless架構(gòu)下的服務(wù)優(yōu)雅下線的示例分析

本篇文章給大家分享的是有關(guān)Serverless架構(gòu)下的服務(wù)優(yōu)雅下線的示例分析，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

應(yīng)用發(fā)布、服務(wù)升級(jí)一直是一個(gè)讓開發(fā)和運(yùn)維同學(xué)既興奮又擔(dān)心的事情。

興奮的是有新功能上線，自己的產(chǎn)品可以對(duì)用戶提供更多的能力和價(jià)值；擔(dān)心的是上線的過程會(huì)不會(huì)出現(xiàn)意外情況影響業(yè)務(wù)的穩(wěn)定性。確實(shí)，在應(yīng)用發(fā)布和服務(wù)升級(jí)時(shí)，線上問題出現(xiàn)的可能性更高，本文我們將結(jié)合 Serverless 應(yīng)用引擎（以下簡(jiǎn)稱 SAE）就 Serverless 架構(gòu)下，討論如何保障上線過程中服務(wù)的優(yōu)雅下線。

在平時(shí)的發(fā)布過程中，我們是否遇到過以下問題：

• 發(fā)布過程中，出現(xiàn)正在執(zhí)行的請(qǐng)求被中斷？

• 下游服務(wù)節(jié)點(diǎn)已經(jīng)下線，上游依然繼續(xù)調(diào)用已經(jīng)下線的節(jié)點(diǎn)導(dǎo)致請(qǐng)求報(bào)錯(cuò)，進(jìn)而導(dǎo)致業(yè)務(wù)異常？

• 發(fā)布過程造成數(shù)據(jù)不一致，需要對(duì)臟數(shù)據(jù)進(jìn)行修復(fù)。

有時(shí)候，我們把發(fā)版安排在凌晨?jī)扇c(diǎn)，趕在業(yè)務(wù)流量比較小的時(shí)候，心驚膽顫、睡眠不足、苦不堪言。那如何解決上面的問題，如何保證應(yīng)用發(fā)布過程穩(wěn)定、高效，保證業(yè)務(wù)無損呢？首先，我們來梳理下造成這些問題的原因。

場(chǎng)景分析

上圖描述了我們使用微服務(wù)架構(gòu)開發(fā)應(yīng)用的一個(gè)常見場(chǎng)景，我們先看下這個(gè)場(chǎng)景的服務(wù)調(diào)用關(guān)系：

• 服務(wù) B、C 把服務(wù)注冊(cè)到注冊(cè)中心，服務(wù) A、B 從注冊(cè)中心發(fā)現(xiàn)需要調(diào)用的服務(wù)；

• 業(yè)務(wù)流量從負(fù)載均衡打到服務(wù) A，在 SLB 上配置服務(wù) A 實(shí)例的健康檢查，當(dāng)服務(wù) A 有實(shí)例停機(jī)的時(shí)候，相應(yīng)的實(shí)例從 SLB 摘掉；服務(wù) A 調(diào)用服務(wù) B，服務(wù) B 再調(diào)用服務(wù) C；

圖中有兩類流量，南北向流量（即通過 SLB 轉(zhuǎn)發(fā)到后端服務(wù)器的業(yè)務(wù)流量，如業(yè)務(wù)流量 -> SLB -> A 的調(diào)用路徑）和東西向流量（通過注冊(cè)中心服務(wù)中心服務(wù)發(fā)現(xiàn)來調(diào)用的流量，如 A -> B 的調(diào)用路徑），下面針對(duì)這兩類流量分別進(jìn)行分析。

南北向流量

南北向流量存在問題

當(dāng)服務(wù) A 發(fā)布的時(shí)候，服務(wù) A1 實(shí)例停機(jī)后，SLB 根據(jù)健康檢查探測(cè)到服務(wù) A1 下線，然后把實(shí)例從 SLB 摘掉。實(shí)例 A1 依賴 SLB 的健康檢查從 SLB 上摘掉，一般需要幾秒到十幾秒的時(shí)間，在這個(gè)過程中，如果 SLB 有持續(xù)的流量打入，就會(huì)造成一些請(qǐng)求繼續(xù)路由到實(shí)例 A1，導(dǎo)致請(qǐng)求失敗；

服務(wù) A 在發(fā)布的過程中，如何保證經(jīng)過 SLB 的流量不報(bào)錯(cuò)？我們接著看下 SAE 是如何做的。

南北向流量?jī)?yōu)雅升級(jí)方案

如上文所提，請(qǐng)求失敗的原因在于后端服務(wù)實(shí)例先停止掉，然后才從 SLB 摘掉，那我們是不是可以先從 SLB 摘掉服務(wù)實(shí)例，然后再對(duì)實(shí)例進(jìn)行升級(jí)呢？

按照這個(gè)思路，SAE 基于 K8S service 的能力給出了一種方案，當(dāng)用戶在通過 SAE 為應(yīng)用綁定 SLB 時(shí)，SAE 會(huì)在集群中創(chuàng)建一個(gè) service 資源，并把應(yīng)用的實(shí)例和 service 關(guān)聯(lián)，CCM 組件會(huì)負(fù)責(zé) SLB 的購(gòu)買、SLB 虛擬服務(wù)器組的創(chuàng)建，并且把應(yīng)用實(shí)例關(guān)聯(lián)的 ENI 網(wǎng)卡添加到虛擬服務(wù)器組中，用戶可以通過 SLB 來訪問應(yīng)用實(shí)例；當(dāng)應(yīng)用發(fā)布時(shí)，CCM 會(huì)先把實(shí)例對(duì)應(yīng)的 ENI 從虛擬服務(wù)器組中摘除，然后再對(duì)實(shí)例進(jìn)行升級(jí)，從而保證流量不丟失。

這就是 SAE 對(duì)于應(yīng)用升級(jí)過程中關(guān)于南北向流量的保障方案。

東西向流量

東西向流量存在問題

在討論完南北向流量的解決方案后，我們?cè)倏聪聳|西向流量，傳統(tǒng)的發(fā)布流程中，服務(wù)提供者停止再啟動(dòng)，服務(wù)消費(fèi)者感知到服務(wù)提供者節(jié)點(diǎn)停止的流程如下：

• 1.服務(wù)發(fā)布前，消費(fèi)者根據(jù)負(fù)載均衡規(guī)則調(diào)用服務(wù)提供者，業(yè)務(wù)正常。

• 2.服務(wù)提供者 B 需要發(fā)布新版本，先對(duì)其中的一個(gè)節(jié)點(diǎn)進(jìn)行操作，首先是停止 java 進(jìn)程。

• 3.服務(wù)停止過程，又分為主動(dòng)注銷和被動(dòng)注銷，主動(dòng)注銷是準(zhǔn)實(shí)時(shí)的，被動(dòng)注銷的時(shí)間由不同的注冊(cè)中心決定，最差的情況會(huì)需要 1 分鐘。

• 1）如果應(yīng)用是正常停止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被執(zhí)行，這一步的耗時(shí)可以忽略不計(jì)。

• 2）如果應(yīng)用是非正常停止，比如直接使用 kill -9 停止，或者 Docker 鏡像構(gòu)建的時(shí)候 java 應(yīng)用不是 1 號(hào)進(jìn)程且沒有把 kill 信號(hào)傳遞給應(yīng)用。那么服務(wù)提供者不會(huì)主動(dòng)去注銷服務(wù)節(jié)點(diǎn)，而是在超過一段時(shí)間后由于心跳超時(shí)而被動(dòng)地被注冊(cè)中心摘除。

• 4.服務(wù)注冊(cè)中心通知消費(fèi)者，其中的一個(gè)服務(wù)提供者節(jié)點(diǎn)已下線。包含推送和輪詢兩種方式，推送可以認(rèn)為是準(zhǔn)實(shí)時(shí)的，輪詢的耗時(shí)由服務(wù)消費(fèi)者輪詢間隔決定，最差的情況下需要 1 分鐘。

• 5.服務(wù)消費(fèi)者刷新服務(wù)列表，感知到服務(wù)提供者已經(jīng)下線了一個(gè)節(jié)點(diǎn)，這一步對(duì)于 Dubbo 框架來說不存在，但是 Spring Cloud 的負(fù)載均衡組件 Ribbon 默認(rèn)的刷新時(shí)間是 30 秒 ，最差情況下需要耗時(shí) 30 秒。

• 6.服務(wù)消費(fèi)者不再調(diào)用已經(jīng)下線的節(jié)點(diǎn)。

從第 2 步到第 6 步的過程中，Eureka 在最差的情況下需要耗時(shí) 2 分鐘，Nacos 在最差的情況下需要耗時(shí) 50 秒。在這段時(shí)間內(nèi)，請(qǐng)求都有可能出現(xiàn)問題，所以發(fā)布時(shí)會(huì)出現(xiàn)各種報(bào)錯(cuò)，同時(shí)還影響用戶的體驗(yàn)，發(fā)布后又需要修復(fù)執(zhí)行到一半的臟數(shù)據(jù)。最后不得不每次發(fā)版都安排在凌晨?jī)扇c(diǎn)發(fā)布，心驚膽顫，睡眠不足，苦不堪言。

東西向流量?jī)?yōu)雅升級(jí)方案

經(jīng)過上文的分析，我們看，在傳統(tǒng)發(fā)布流程中，客戶端有一個(gè)服務(wù)調(diào)用報(bào)錯(cuò)期，原因就是客戶端沒有及時(shí)感知到服務(wù)端下線的實(shí)例。在傳統(tǒng)發(fā)布流程中，主要是借助注冊(cè)中心通知消費(fèi)者來更新服務(wù)提供者列表，那能不能繞過注冊(cè)中心，服務(wù)提供者直接通知服務(wù)消費(fèi)者呢？答案是肯定的，我們主要做了兩件事情：

1. 服務(wù)提供者應(yīng)用在發(fā)布前后主動(dòng)向注冊(cè)中心注銷應(yīng)用，并將應(yīng)用標(biāo)記為已下線的狀態(tài)；將原來的停止進(jìn)程階段注銷服務(wù)變成了 prestop 階段注銷服務(wù)。

2. 在接收到服務(wù)消費(fèi)者請(qǐng)求時(shí)，首先會(huì)正常處理本次調(diào)用，并通知服務(wù)消費(fèi)者此節(jié)點(diǎn)已下線，服務(wù)消費(fèi)者會(huì)立即從調(diào)用列表刪除此節(jié)點(diǎn)；在這之后，服務(wù)消費(fèi)者不再調(diào)用已經(jīng)下線的節(jié)點(diǎn)。這是將原來的依賴于 注冊(cè)中心推送，做到了服務(wù)提供者直接通知消費(fèi)者從調(diào)用列表中摘除自己。

通過上面這個(gè)方案，就使得下線感知的時(shí)間大大減短，從原來的分鐘級(jí)別做到準(zhǔn)實(shí)時(shí)，確保應(yīng)用在下線時(shí)能做到業(yè)務(wù)無損。

分批發(fā)布和灰度發(fā)布

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

我們先介紹下灰度發(fā)布，某應(yīng)用包含 10 個(gè)應(yīng)用實(shí)例，每個(gè)應(yīng)用實(shí)例的部署版本為 Ver.1 版本，現(xiàn)需將每個(gè)應(yīng)用實(shí)例升級(jí)為 Ver.2 版本。

從圖中可以看出，在發(fā)布的過程中先灰度 2 臺(tái)實(shí)例，在確認(rèn)業(yè)務(wù)正常后，再分批發(fā)布剩余的實(shí)例，發(fā)布的過程中始終有實(shí)例處于運(yùn)行狀態(tài)，實(shí)例升級(jí)過程中依照上面的方案，每個(gè)實(shí)例都有優(yōu)雅下線的過程，這就保證了業(yè)務(wù)無損。

再來看下分批發(fā)布，分批發(fā)布支持手動(dòng)、自動(dòng)分批；還是上面的 10 個(gè)應(yīng)用實(shí)例，假設(shè)將所有應(yīng)用實(shí)例分 3 批進(jìn)行部署，根據(jù)分批發(fā)布策略。

以上就是Serverless架構(gòu)下的服務(wù)優(yōu)雅下線的示例分析，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。