文章目錄
前言
在生產(chǎn)環(huán)境中，如何保證在服務(wù)升級的時候，不影響用戶的體驗，這個是一個非常重要的問題。如果在我們升級服務(wù)的時候，會造成一段時間內(nèi)的服務(wù)不可用，這就是不夠優(yōu)雅的。那什么是優(yōu)雅的呢？主要就是指在服務(wù)升級的時候，不中斷整個服務(wù)，讓用戶無感知，進(jìn)而不會影響用戶的體驗，這就是優(yōu)雅的。
實際上，優(yōu)雅下線是目標(biāo)，而不是手段，它是一個相對的概念，例如kill PID和kill -9 PID都是暴力殺死服務(wù)，相對于kill -9 PID來說，kill PID就是優(yōu)雅的。但如果單獨拿kill PID出來說，我們能說它是優(yōu)雅的下線策略嗎？肯定不是啊，就是這個道理。
因此，本文講述的優(yōu)雅下線僅能稱之為“相對的優(yōu)雅下線”，但相對于暴力的殺死服務(wù)，已經(jīng)足夠優(yōu)雅了。常見的優(yōu)雅解決方案，主要包括優(yōu)雅下線和灰度發(fā)布。而實際上，灰度發(fā)布的范圍就已經(jīng)包含優(yōu)雅下線了。
最后，在本文中，我們主要講述基于 Spring Cloud 和 Euraka 的優(yōu)雅下線以及灰度發(fā)布。
優(yōu)雅下線
常見的下線方式
方式一：kill PID
使用方式：kill java進(jìn)程ID
該方式借助的是 Spring Boot 應(yīng)用的 Shutdown hook，應(yīng)用本身的下線也是優(yōu)雅的，但如果你的服務(wù)發(fā)現(xiàn)組件使用的是 Eureka，那么默認(rèn)最長會有 90 秒的延遲，其他應(yīng)用才會感知到該服務(wù)下線，這意味著：該實例下線后的 90 秒內(nèi)，其他服務(wù)仍然可能調(diào)用到這個已下線的實例。因此，該方式是不夠優(yōu)雅的 。
方式二：/shutdown端點
Spring Boot 提供了/shutdown端點，可以借助它實現(xiàn)優(yōu)雅停機(jī)。
使用方式：在想下線應(yīng)用的application.yml中添加如下配置，從而啟用并暴露/shutdown端點：
management:
endpoint:
shutdown:
enabled: true
endpoints:
web:
exposure:
include: shutdown
發(fā)送 POST 請求到/shutdown端點
curl -X http://你想停止的服務(wù)地址/actuator/shutdown
該方式本質(zhì)和方式一是一樣的，也是借助 Spring Boot 應(yīng)用的 Shutdown hook 去實現(xiàn)的。
方式三：/pause端點
Spring Boot 應(yīng)用提供了/pause端點，利用該端點可實現(xiàn)優(yōu)雅下線。
使用方式：在想下線應(yīng)用的application.yml中添加配置，從而啟用并暴露/pause端點：
management:
endpoint:
# 啟用pause端點
pause:
enabled: true
# 啟用restart端點，之所以要啟用restart端點，是因為pause端點的啟用依賴restart端點的啟用
restart:
enabled: true
endpoints:
web:
exposure:
include: pause,restart
發(fā)送 POST 請求到/actuator/pause端點：
curl -X POST http://你想停止的服務(wù)實例地址/actuator/pause
執(zhí)行后的效果類似下圖：
如圖所示，該應(yīng)用在 Eureka Server 上的狀已被標(biāo)記為DOWN，但是應(yīng)用本身其實依然是可以正常對外服務(wù)的。在 Spring Cloud 中，Ribbon 做負(fù)載均衡時，只會負(fù)載到標(biāo)記為UP的實例上。
利用這兩點，你可以：先用/pause端點，將要下線的應(yīng)用標(biāo)記為DOWN，但不去真正停止應(yīng)用；然后過一定的時間（例如 90 秒，或者自己做個監(jiān)控，看當(dāng)前實例的流量變成 0 后）再去停止應(yīng)用，例如kill應(yīng)用。
缺點 & 局限
方式四：/service-registry端點
使用方式：在想下線應(yīng)用的application.yml中添加配置，從而暴露/service-registry端點：
management:
endpoints:
web:
exposure:
include: service-registry
發(fā)送 POST 請求到/actuator/service-registry端點：
curl -X "POST" "http://localhost:8000/actuator/service-registry?status=DOWN" \
-H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8"
實行后的效果類似如下圖：
優(yōu)雅的下線方式
在上文中，我們講述了四種常見的下線方式，對比來看，方式四 是一種比較優(yōu)雅的下線方式。
在實際項目中，我們可以先使用/service-registry端點，將服務(wù)標(biāo)記為DOWN，然后監(jiān)控服務(wù)的流量，當(dāng)流量為 0 時，即可升級該服務(wù)。當(dāng)然，這里假設(shè)我們部署了多個服務(wù)實例，當(dāng)一個服務(wù)實例DOWN掉之后，其他服務(wù)實例仍然是可以提供服務(wù)的，如果就部署一臺服務(wù)的話，那么討論優(yōu)不優(yōu)雅就沒那么重要了。
除了上述的下線方式之外，還有一種利用EurekaAutoServiceRegistration對象達(dá)到優(yōu)雅下線的目標(biāo)。
- 執(zhí)行
eurekaAutoServiceRegistration.start()方法時，當(dāng)前服務(wù)向 Eureka 注冊中心注冊服務(wù)； - 執(zhí)行
eurekaAutoServiceRegistration.stop()方法時，當(dāng)前服務(wù)會向 Eureka 注冊中心進(jìn)行反注冊，注冊中心收到請求后，會將此服務(wù)從注冊列表中刪除。
示例代碼如下：
@RestController
@RequestMapping(value = "/graceful/registry-service")
public class GracefulOffline {
@Autowired
private EurekaAutoServiceRegistration eurekaAutoServiceRegistration;
@RequestMapping("/online")
public String online() {
this.eurekaAutoServiceRegistration.start();
return "execute online method, online success.";
}
@RequestMapping("/offline")
public String offline() {
this.eurekaAutoServiceRegistration.stop();
return "execute offline method, offline success.";
}
}
到這里，我們已經(jīng)介紹了兩種相對優(yōu)雅的下線方式了。具體如何操作，我們可以根據(jù)實際上情況進(jìn)行包裝，或者利用自動化的腳本來實現(xiàn)更加優(yōu)雅的下線方式。
灰度發(fā)布
藍(lán)綠部署
藍(lán)綠部署，英文名為 Blue Green Deployment，是一種可以保證系統(tǒng)在不間斷提供服務(wù)的情況下上線的部署方式。
如何保證系統(tǒng)不間斷提供服務(wù)呢？那就是同時部署兩個集群，但僅對外提供一個集群的服務(wù)，當(dāng)需要升級時，切換集群進(jìn)行升級。藍(lán)綠部署無需停機(jī)，并且風(fēng)險較小。其大致步驟為：
- 部署集群 1 的應(yīng)用（初始狀態(tài)），將所有外部請求的流量都打到這個集群上
- 部署集群 2 的應(yīng)用，集群 2 的代碼與集群 1 不同，如新功能或者 Bug 修復(fù)等
- 如集群 2 測試正常，就刪除集群 1 正在使用的資源（例如實例），使用集群 2 對外提供服務(wù)
因為在使用藍(lán)綠部署的方式時，我們需要控制流量，所以我們需要借助路由服務(wù)，如 Nginx 等。
滾動部署
滾動部署，英文名為 Rolling Update，同樣是一種可以保證系統(tǒng)在不間斷提供服務(wù)的情況下上線的部署方式。和藍(lán)綠部署不同的是，滾動部署對外提供服務(wù)的版本并不是非此即彼，而是在更細(xì)的粒度下平滑完成版本的升級。
如何做到細(xì)粒度平滑升級版本呢？滾動部署只需要一個集群，集群下的不同節(jié)點可以獨立進(jìn)行版本升級。比如在一個 12 節(jié)點的集群中，我們每次升級 4 個節(jié)點，并將升級后的節(jié)點重新投入使用，周而復(fù)始，直到集群中所有的節(jié)點都更新為新版本。
這種部署方式相對于藍(lán)綠部署，更加節(jié)約資源，因為它不需要運行兩個集群。但這種方式也有很多缺點，例如：
- 沒有一個確定 OK 的環(huán)境。使用藍(lán)綠部署，我們能夠清晰地知道老版本是 OK 的，而使用滾動發(fā)布，我們無法確定。
- 如果需要回滾，很困難。舉個例子，在某一次發(fā)布中，我們需要更新 100 個實例，每次更新 10 個實例，每次部署需要 5 分鐘。當(dāng)滾動發(fā)布到第 80 個實例時，發(fā)現(xiàn)了問題，需要回滾。這時，我們估計就要瘋了。
- 有的時候，我們還可能對系統(tǒng)進(jìn)行動態(tài)伸縮，如果部署期間，系統(tǒng)自動擴(kuò)容/縮容了，我們還需判斷到底哪個節(jié)點使用的是哪個代碼。盡管有一些自動化的運維工具，但是依然令人心驚膽戰(zhàn)。
并不是說滾動發(fā)布不好，滾動發(fā)布也有它非常合適的場景。
金絲雀部署
金絲雀部署又稱灰度部署（或者，灰度發(fā)布），英文名為 Canary Deployment，是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。
金絲雀的名稱來源于「礦井中的金絲雀」，早在 17 世紀(jì)，英國礦井工人發(fā)現(xiàn)，金絲雀對瓦斯這種氣體十分敏感，空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當(dāng)瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發(fā)身亡。當(dāng)時在采礦設(shè)備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標(biāo)”，以便在危險狀況下緊急撤離。
我們來看一下金絲雀部署的步驟：
- 準(zhǔn)備好部署各個階段的工件，包括：構(gòu)建工件，測試腳本，配置文件和部署清單文件
- 從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器
- 升級“金絲雀”應(yīng)用（切斷原有流量并進(jìn)行部署）
- 將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）
- 如果“金絲雀”在線使用測試成功，升級剩余的其他服務(wù)器（否則就回滾）
在金絲雀部署中，常常按照用戶量設(shè)置路由權(quán)重，例如 90% 的用戶維持使用老版本，10% 的用戶嘗鮮新版本。不同版本應(yīng)用共存，經(jīng)常與 A/B 測試一起使用，用于測試選擇多種方案。
金絲雀部署比較典型的例子，就是我們在使用某個應(yīng)用的時候，該應(yīng)用邀請我們進(jìn)行“內(nèi)測”或者“新版本體驗”，如果我們同意了，那么我們就成了金絲雀。
