應(yīng)用不停機(jī)發(fā)布的思考與初識(shí) | IDCF

• 傳統(tǒng)行業(yè)的業(yè)務(wù)一般都集中的日間，也就是說(shuō)凌晨基本沒(méi)有業(yè)務(wù)，或者非重要業(yè)務(wù)。

• 就算凌晨無(wú)法使用這些功能，覺(jué)得也沒(méi)關(guān)系，第二天再來(lái)就是了，客戶又不會(huì)跑了。

• “全天”代表著任何時(shí)間

• “優(yōu)質(zhì)”代表著客戶體驗(yàn)

• “線上”代表著線上自助

? Part 1

應(yīng)用不停機(jī)發(fā)布，從字面上很好理解，就是應(yīng)用發(fā)布過(guò)程中服務(wù)不中斷。

但仔細(xì)回想一下，原先應(yīng)用發(fā)布過(guò)程中，反正服務(wù)會(huì)中斷，那就在應(yīng)用發(fā)布完成后，通過(guò)網(wǎng)絡(luò)屏蔽外部流量的方式，先進(jìn)行核心或常用功能的內(nèi)部驗(yàn)證，在確保沒(méi)有問(wèn)題后，再解除網(wǎng)絡(luò)屏蔽，并對(duì)外提供服務(wù)。

那現(xiàn)在呢？應(yīng)用發(fā)布后直接對(duì)外？不需要進(jìn)行內(nèi)部或小流量驗(yàn)證？想必每個(gè)人的答案都有所不同。對(duì)此，可以對(duì)應(yīng)用不停機(jī)發(fā)布能力，簡(jiǎn)單定義三個(gè)成熟度。

注：不同的成熟度對(duì)技術(shù)能力的要求會(huì)有所不同，建議通過(guò)逐步演進(jìn)的方式來(lái)提升成熟度，并在演進(jìn)過(guò)程中對(duì)不同的技術(shù)能力進(jìn)行驗(yàn)證，從而不斷完善。

有人會(huì)說(shuō)藍(lán)綠發(fā)布，或有人會(huì)說(shuō)滾動(dòng)發(fā)布，灰度發(fā)布就可以實(shí)現(xiàn)以上能力。但其實(shí)，這些答案并不準(zhǔn)確，或者說(shuō)并不全面，它們雖有交集，但無(wú)法涵蓋。

既然提到發(fā)布模式，那我們先來(lái)簡(jiǎn)單比較一下幾種發(fā)布模式的優(yōu)缺點(diǎn)。

注：大部分的技術(shù)文章里都會(huì)提到，可通過(guò)以上任何一種發(fā)布模式，做到用戶無(wú)感知的應(yīng)用發(fā)布，但在實(shí)際情況下，并不完全足夠，還需要通過(guò)一些輔助手段組合在一起才能實(shí)現(xiàn)。

結(jié)合以上發(fā)布模式的優(yōu)缺點(diǎn)，如果你的組織在基礎(chǔ)架構(gòu)技術(shù)能力上已經(jīng)非常成熟，那么灰度發(fā)布一定是最佳之選，但如果還處于初級(jí)階段，那可能并不是，而藍(lán)綠發(fā)布的資源投入較高，也不是一種非常好的選擇。

剩下的只有滾動(dòng)發(fā)布，但滾動(dòng)發(fā)布的發(fā)布策略會(huì)比較復(fù)雜，特別在容器環(huán)境下，同一應(yīng)用多個(gè)服務(wù)實(shí)例的滾動(dòng)策略還需要單獨(dú)來(lái)實(shí)現(xiàn)。

所以，前期可以選擇一種折中的方式，即：單獨(dú)搭建一套預(yù)發(fā)驗(yàn)證環(huán)境，應(yīng)用架構(gòu)需對(duì)齊生產(chǎn)環(huán)境，但容量方面可以最小化，一般一個(gè)應(yīng)用至少2個(gè)服務(wù)實(shí)例。

這樣，我們就可以在對(duì)生產(chǎn)環(huán)境做應(yīng)用發(fā)布前，事先對(duì)生產(chǎn)預(yù)驗(yàn)證環(huán)境進(jìn)行應(yīng)用發(fā)布，發(fā)布后僅對(duì)內(nèi)部用戶可見(jiàn)，驗(yàn)證通過(guò)后，再對(duì)生產(chǎn)環(huán)境采用全量應(yīng)用發(fā)布。

? Part 2

應(yīng)用不停機(jī)發(fā)布是一項(xiàng)綜合性能力，當(dāng)明確好一種發(fā)布模式后，就需要逐步識(shí)別會(huì)涉及到哪些技術(shù)組件，以及明確技術(shù)組件在整個(gè)解決方案中所擔(dān)任的職責(zé)邊界，從而使它們能夠相互協(xié)同工作。

如下列舉了一些主要的技術(shù)組件：

在明確技術(shù)組件后，還需要對(duì)技術(shù)組件進(jìn)行合理的架構(gòu)規(guī)劃，以適配不同的網(wǎng)絡(luò)架構(gòu)要求。

本次主要將對(duì)負(fù)載均衡進(jìn)行特別說(shuō)明，一方面它是負(fù)責(zé)處理流量的核心技術(shù)組件，另一方面網(wǎng)絡(luò)架構(gòu)的不同，對(duì)它的部署架構(gòu)影響可能也是最大的。

在傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)環(huán)境中，出于對(duì)網(wǎng)絡(luò)安全或其他考慮因素，通常會(huì)劃分出多個(gè)不同的網(wǎng)絡(luò)區(qū)域，網(wǎng)絡(luò)區(qū)域間的訪問(wèn)需要通過(guò)開(kāi)設(shè)防火墻訪問(wèn)策略才可以進(jìn)行互通。

但這種方式必然會(huì)對(duì)應(yīng)用服務(wù)間直接進(jìn)行點(diǎn)對(duì)點(diǎn)訪問(wèn)的方式造成影響，主要原因是虛擬機(jī)或容器環(huán)境中，應(yīng)用的IP地址可能會(huì)發(fā)生變化，導(dǎo)致無(wú)法提前明確防火墻訪問(wèn)策略。

所以，一般都會(huì)考慮使用負(fù)載均衡（代理模式）來(lái)解決這個(gè)問(wèn)題。

建議前期優(yōu)先選擇方案三，雖然鏈路較長(zhǎng)會(huì)小幅影響性能，但此部署方案相對(duì)較為成熟，一方面可以避免流量負(fù)載不均的問(wèn)題，另一方面對(duì)于應(yīng)用的改造成本也會(huì)相對(duì)較低。

注：除網(wǎng)絡(luò)區(qū)域隔離會(huì)遇到這種情況外，在某些網(wǎng)絡(luò)架構(gòu)中，不同的容器集群間也同樣無(wú)法訪問(wèn)，所以也同樣適用。

另外，除必要情況下，也應(yīng)盡量減少跨網(wǎng)絡(luò)區(qū)域或跨容器集群間的訪問(wèn)，例如：優(yōu)先容器集群內(nèi)路由訪問(wèn)，跨網(wǎng)絡(luò)區(qū)域頻繁交互的應(yīng)用服務(wù)建議遷移至同一網(wǎng)絡(luò)區(qū)域等。

負(fù)載均衡通常可以分為4層模式和7層模式，其中4層更關(guān)注流量負(fù)載，而7層更關(guān)注流量路由。

一般建議將負(fù)載均衡（4層）和負(fù)載均衡（7層）進(jìn)行分層部署，以充分發(fā)揮它們的強(qiáng)項(xiàng)。

建議前期優(yōu)先選擇方案二，雖然無(wú)法實(shí)現(xiàn)多容器集群間的全局流量調(diào)度，但對(duì)于當(dāng)前可觀測(cè)性和排障能力還不夠健全的組織，通過(guò)物理隔離降低運(yùn)維難度也是一種不錯(cuò)的選擇。

綜上架構(gòu)決策，最終的全局流量鏈路大致如下，默認(rèn)情況下，數(shù)據(jù)中心間流量隔離，即：?jiǎn)螖?shù)據(jù)中心流量收斂，但可根據(jù)實(shí)際情況進(jìn)行選擇性放行。

Part 3

應(yīng)用不停機(jī)發(fā)布的基礎(chǔ)是服務(wù)路由，在這里，我們可以把應(yīng)用服務(wù)分為兩種角色，服務(wù)請(qǐng)求方或服務(wù)提供方，而服務(wù)請(qǐng)求方通過(guò)不同的尋址方式，最終訪問(wèn)到服務(wù)提供方的形式，可以稱之為服務(wù)路由。

服務(wù)路由可以分為南北向和東西向。

• 南北向：服務(wù)請(qǐng)求方—>負(fù)載均衡（4層）—>負(fù)載均衡（7層）—>服務(wù)提供方
• 東西向：服務(wù)請(qǐng)求方—>服務(wù)提供方

Part 4

應(yīng)用不停機(jī)發(fā)布的核心是應(yīng)用如何優(yōu)雅停止，光有服務(wù)路由可能還不夠，它雖然已經(jīng)解決了大部分問(wèn)題，但離成功還差最后一步。

前面我們提到過(guò)應(yīng)用發(fā)布要做到用戶無(wú)感知，那如果應(yīng)用發(fā)布過(guò)程中出現(xiàn)瞬斷或短時(shí)間中斷，而用戶又正好在使用，那算不算用戶就感知到了呢？

不過(guò)，如果你覺(jué)得線上服務(wù)中斷5分鐘也可以忍受，那我只能呵呵了。但我相信大部分具備互聯(lián)網(wǎng)服務(wù)模式的頭部公司，別說(shuō)發(fā)布一次服務(wù)停止5分鐘，可能就連5秒鐘也無(wú)法忍受。

那我們先來(lái)分析一下為什么會(huì)出現(xiàn)瞬斷或短時(shí)間中斷：

• 服務(wù)請(qǐng)求處理還沒(méi)完成，應(yīng)用就被強(qiáng)行停止（例如：運(yùn)維必備大招之kill -9 進(jìn)程），導(dǎo)致處理中的請(qǐng)求無(wú)法正常返回。
• 服務(wù)提供方雖然已停止，但未通知服務(wù)請(qǐng)求方，服務(wù)請(qǐng)求方仍然繼續(xù)訪問(wèn)已停止的服務(wù)提供方，導(dǎo)致出現(xiàn)異常。

• 容器：銷毀服務(wù)實(shí)例，創(chuàng)建新版本服務(wù)實(shí)例。
• 虛擬機(jī)：更新服務(wù)實(shí)例，更新后解除屏蔽。

1. 在服務(wù)提供方上實(shí)現(xiàn)Shutdown hook，即：等待服務(wù)請(qǐng)求處理完成后，再進(jìn)行應(yīng)用停止。
2. 在服務(wù)提供方停止前，需通知所有服務(wù)請(qǐng)求方，并在完成通知后再進(jìn)行應(yīng)用停止。

方式一：最多中斷5秒

step1：依賴spring-boot-starter-actuator組件，暴露/shutdown端點(diǎn)。

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown

step2：調(diào)整Eureka配置參數(shù)，該調(diào)整會(huì)分別增加Eureka客戶端和服務(wù)端性能壓力。

step3：容器銷毀服務(wù)實(shí)例或虛擬機(jī)更新服務(wù)實(shí)例前，請(qǐng)求如下地址進(jìn)行應(yīng)用服務(wù)實(shí)例停止。

curl -X http://應(yīng)用服務(wù)地址/actuator/shutdown

方式二：不中斷（不通知）

step1：依賴spring-boot-starter-actuator組件，暴露/shutdown和/service- registry端點(diǎn)。

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown,service-registry

step2：調(diào)整Eureka配置參數(shù)，該調(diào)整會(huì)分別增加Eureka客戶端和服務(wù)端性能壓力。

step3：容器銷毀服務(wù)實(shí)例或虛擬機(jī)更新服務(wù)實(shí)例前，請(qǐng)求如下地址進(jìn)行應(yīng)用服務(wù)實(shí)例下線。

curl -X http://應(yīng)用服務(wù)地址/actuator/service-registry?status=DOWN

注：此時(shí)，服務(wù)提供方仍然可以提供服務(wù)，但再次獲取服務(wù)實(shí)例的服務(wù)請(qǐng)求方不會(huì)再獲取該服務(wù)實(shí)例。

step4：服務(wù)請(qǐng)求方最多等待5秒后會(huì)更新服務(wù)列表，所以，在完成以上操作后，可以休眠5秒鐘，再請(qǐng)求如下地址停止應(yīng)用服務(wù)實(shí)例。

curl -X http://應(yīng)用服務(wù)地址/actuator/shutdown

注：eureka.client.registry-fetch-interval-seconds+ribbon.ServerListRefreshInterval=5秒。

方式三：不中斷（通知）

step1：依賴spring-boot-starter-actuator組件，暴露/shutdown和/service-registry端點(diǎn)。

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown,service-registry

step2：調(diào)整Eureka配置參數(shù)，該調(diào)整會(huì)增加Eureka服務(wù)端性能壓力。

step3：容器銷毀服務(wù)實(shí)例或虛擬機(jī)更新服務(wù)實(shí)例前，請(qǐng)求如下地址進(jìn)行應(yīng)用服務(wù)實(shí)例下線。

curl -X http://應(yīng)用服務(wù)地址/actuator/service-registry?status=DOWN

注：此時(shí)，服務(wù)提供方仍然可以提供服務(wù)，但再次獲取服務(wù)實(shí)例的服務(wù)請(qǐng)求方不會(huì)再獲取該服務(wù)實(shí)例。

step4：在注冊(cè)中心上記錄當(dāng)前正訂閱該服務(wù)實(shí)例的服務(wù)請(qǐng)求方列表，并根據(jù)列表通知它們立即重新獲取最新的服務(wù)實(shí)例，通知完成后再請(qǐng)求如下地址停止應(yīng)用服務(wù)實(shí)例。

curl -X http://應(yīng)用服務(wù)地址/actuator/shutdown

以上三種方式，可以結(jié)合價(jià)值收益和改造成本進(jìn)行權(quán)衡，接受瞬斷的可以選擇方式一，而對(duì)技術(shù)有極致追求的可以選擇方式三，如果兩個(gè)都不是，那就選擇方式二吧。

注：每個(gè)應(yīng)用服務(wù)的Eureka配置參數(shù)并不一定能夠完全統(tǒng)一，這樣可能就會(huì)造成大量配置管理成本的增加，但如果可以統(tǒng)一，那方式二還是不錯(cuò)的選擇。

Part 5

在具備以上條件能力后，應(yīng)用發(fā)布不停機(jī)的基本框架已成型，但這樣應(yīng)用發(fā)布就能實(shí)現(xiàn)不停機(jī)了？

那有這么簡(jiǎn)單，我們?cè)陂_(kāi)發(fā)上還需要遵循一些規(guī)范，但符合這些規(guī)范的話，可能會(huì)增加我們的一些開(kāi)發(fā)成本。

因此，并不是說(shuō)每次應(yīng)用發(fā)布都強(qiáng)行需要實(shí)現(xiàn)不停機(jī)發(fā)布，而是應(yīng)該進(jìn)行合理的取舍。不過(guò)，一個(gè)好的系統(tǒng)設(shè)計(jì)必然能做到既能遵循開(kāi)發(fā)規(guī)范，也不會(huì)增加太多開(kāi)發(fā)成本。

如下列舉了一些常用的開(kāi)發(fā)規(guī)范，實(shí)際情況可按需調(diào)整，其目的是為了不管是接口更新還是數(shù)據(jù)庫(kù)更新等，都應(yīng)盡量做到向上兼容。

寫(xiě)在最后

感謝你可以很耐心的讀到這里，整篇文章主要圍繞應(yīng)用不停機(jī)發(fā)布進(jìn)行了思考，從為什么要做，能帶來(lái)什么價(jià)值，一直到應(yīng)該怎么做，要關(guān)心哪些方面，進(jìn)行了簡(jiǎn)要說(shuō)明，主要目的是為了能讓大家，對(duì)應(yīng)用不停機(jī)發(fā)布有一個(gè)大概的框架認(rèn)識(shí)。

實(shí)現(xiàn)應(yīng)用不停機(jī)發(fā)布的手段，也并非僅有文章中說(shuō)的那些方式，涉及到的技術(shù)組件可能也不止這些，但其解決思路基本都差不多，具體的技術(shù)實(shí)現(xiàn)方式，可以結(jié)合自身的架構(gòu)環(huán)境再進(jìn)行適配和調(diào)整。

玩樂(lè)高，學(xué)敏捷，【規(guī)模化敏捷聯(lián)合作戰(zhàn)沙盤(pán)之「烏托邦計(jì)劃」】，12月25-26日登陸深圳，將“多團(tuán)隊(duì)敏捷協(xié)同”基因內(nèi)化在研發(fā)流程中，為規(guī)模化提升研發(fā)效能保駕護(hù)航！!???

企業(yè)組隊(duì)和個(gè)人均可報(bào)名參加，一起挑戰(zhàn)極客烏托邦