問題
互聯(lián)網(wǎng)產(chǎn)品高速迭代,通常伴隨著高頻次的版本發(fā)布。部署新版上線需要重啟服務(wù),直接 kill 服務(wù)進(jìn)程可能會造成服務(wù)短暫不可用,從而影響到正在使用的用戶。
Spring Cloud 項目中一般會用到 Ribbon 作為負(fù)載均衡,那么是不是只要保證每個服務(wù)部署多臺服務(wù)器,發(fā)布時采用 Rolling Update 分批次部署,保證一部分服務(wù)器正常提供服務(wù)的同時發(fā)布另一部分服務(wù)器,Ribbon 就能自動切換,保證服務(wù)的不間斷?然而并不是。
產(chǎn)生原因
所有服務(wù)的狀態(tài)保存在注冊中心,即 Eureka Server。一個服務(wù)要想獲取其他服務(wù)的實例列表和狀態(tài),需要通過 Eureka Client 定時從 Eureka Server 中獲取并緩存下來,默認(rèn)時間間隔是30秒。Eureka Client 和 Eureka Server 是通過 HTTP 協(xié)議通信,請求由 Eureka Client 發(fā)起,而不是基于長連接或者 Eureka Server 主動推送,所以無法立即知道其他服務(wù)狀態(tài)變更。
即使同一個服務(wù)部署多臺機(jī)器,每臺機(jī)器依次發(fā)布,當(dāng)其中一個服務(wù)實例重啟時,服務(wù)調(diào)用方是無法第一時間知道的,所以還是會調(diào)用到這臺暫時無法提供服務(wù)的實例上。這樣會造成短暫的訪問失敗,這段時間也會對正在使用產(chǎn)品的用戶造成一定的影響。
解決方案
基于以上的原因,在部署應(yīng)用時應(yīng)該按照以下步驟進(jìn)行(為了簡單起見,假設(shè)一個應(yīng)用部署兩個實例):
- 將服務(wù)的一個實例在注冊中心的狀態(tài)設(shè)置為 DOWN
- 等待一段時間,直到其他服務(wù)緩存刷新,不再調(diào)用到這臺服務(wù)器上
- 停止服務(wù),更新代碼,重新啟動,等待,直到啟動成功
完成后,再重復(fù)以上步驟部署另一個實例。
第一步:修改服務(wù)實例狀態(tài)為 DOWN
有兩種方案可以修改實例的狀態(tài),選擇其一即可:
- 直接調(diào)用 Eureka Server API 修改:PUT /eureka/apps/{appID}/{instanceID}/status?value=DOWN
- 調(diào)用服務(wù)實例對應(yīng)的 actuator endpoint:
/service-registry
我更偏向使用方法二,對應(yīng)的命令:
1
| curl -H "Content-Type:application/json" -X POST http://{host:port}/actuator/service-registry?status=DOWN
|
如果 actuator endpoint 加了 Spring Security Basic 認(rèn)證,則還需要加上用戶名和密碼:
1
| curl -H "Content-Type:application/json" -X POST -u {username}:{password} http://{host:port}/actuator/service-registry?status=DOWN
|
第二步:等待其他服務(wù)緩存刷新
具體要等多久,其他調(diào)用者的請求才會不再訪問到這臺狀態(tài)為 DOWN 的實例?這里涉及到三個配置項:
eureka.client.registryFetchIntervalSeconds Eureka 客戶端每隔多久去 Eureka 服務(wù)器拉取最新的注冊信息,默認(rèn)值 30(秒)。ribbon.ServerListRefreshInterval Ribbon 的緩存刷新間隔時間,默認(rèn) 30000(毫秒)。Eureka 客戶端拉取到最新注冊信息后,Ribbon、Feign 等組件不會立即生效,是因為 Ribbon 還有一層緩存。eureka.server.responseCacheUpdateIntervalMs Eureka Server 返回最新的注冊信息的接口緩存刷新時間間隔,默認(rèn) 30000(毫秒)。有時候會看到 Eureka 頁面和 /eureka/apps 接口的服務(wù)狀態(tài)不一致,就是因為 /eureka/apps 接口默認(rèn)會有 30 秒緩存。
在默認(rèn)情況下,當(dāng)一個服務(wù)狀態(tài)改為 DOWN,最長可能需要 30+30+30 秒,所有的緩存才會刷新,其他調(diào)用者才不會調(diào)用到這個狀態(tài)為 DOWN 的實例。這就意味著修改服務(wù)實例狀態(tài)為 DOWN 后需要等待 90 秒,才能進(jìn)行下一步操作。
為了讓部署時間縮短,可以將以上三個配置項都修改為5秒:
Eureka Server:
1
2
3
| eureka:
server:
responseCacheUpdateIntervalMs: 5000
|
Eureka Client(即各個服務(wù)):
1
2
3
4
5
| ribbon:
ServerListRefreshInterval: 5000
eureka:
client:
registryFetchIntervalSeconds: 5
|
完成以上配置,部署時將實例狀態(tài)設(shè)為 DOWN 后,只需要等待 15 秒即可停止進(jìn)程:
第三步:實例部署
這一步主要需要注意
- 盡量不要使用
kill -9 pid 強(qiáng)制殺掉進(jìn)程,而應(yīng)該使用 kill pid 或者 kill -15 pid 關(guān)閉進(jìn)程。使用 kill pid 或者 kill -15 pid 關(guān)閉進(jìn)程之前,Eureka Client 會給 Eureka Server 請求刪除自己,后續(xù)服務(wù)再次啟動后會重新注冊為 UP 狀態(tài)。如果使用 kill -9 pid 強(qiáng)制殺掉進(jìn)程,Eureka Client 沒有辦法注銷自己,Eureka Server 就不知道該實例已下線,直到長時間收不到心跳才會刪除該實例。如果在 Eureka Server 刪除實例之前實例啟動了,那么它的狀態(tài)還是會保持 DOWN 狀態(tài)。如果確實需要用到 kill -9 pid 強(qiáng)制殺掉進(jìn)程,那么服務(wù)重啟后需要再通過第一步的方式將實例狀態(tài)設(shè)為 UP。 - 服務(wù)啟動后,需要等待并確認(rèn)啟動成功后,才可以開始部署下一臺服務(wù)器。這里我們可以定時去請求 Spring Boot 提供的 actuator endpoint
/health 接口,例如每隔 1 秒請求一次,直到接口可以正常訪問,即可認(rèn)為服務(wù)啟動成功。
本文基于 Spring Boot 2.1.x 及 Spring Cloud Greenwich 版本 問題
互聯(lián)網(wǎng)產(chǎn)品高速迭代,通常伴隨著高頻次的版本發(fā)布。部署新版上線需要重啟服務(wù),直接 kill 服務(wù)進(jìn)程可能會造成服務(wù)短暫不可用,從而影響到正在使用的用戶。
Spring Cloud 項目中一般會用到 Ribbon 作為負(fù)載均衡,那么是不是只要保證每個服務(wù)部署多臺服務(wù)器,發(fā)布時采用 Rolling Update 分批次部署,保證一部分服務(wù)器正常提供服務(wù)的同時發(fā)布另一部分服務(wù)器,Ribbon 就能自動切換,保證服務(wù)的不間斷?然而并不是。
產(chǎn)生原因
所有服務(wù)的狀態(tài)保存在注冊中心,即 Eureka Server。一個服務(wù)要想獲取其他服務(wù)的實例列表和狀態(tài),需要通過 Eureka Client 定時從 Eureka Server 中獲取并緩存下來,默認(rèn)時間間隔是30秒。Eureka Client 和 Eureka Server 是通過 HTTP 協(xié)議通信,請求由 Eureka Client 發(fā)起,而不是基于長連接或者 Eureka Server 主動推送,所以無法立即知道其他服務(wù)狀態(tài)變更。
即使同一個服務(wù)部署多臺機(jī)器,每臺機(jī)器依次發(fā)布,當(dāng)其中一個服務(wù)實例重啟時,服務(wù)調(diào)用方是無法第一時間知道的,所以還是會調(diào)用到這臺暫時無法提供服務(wù)的實例上。這樣會造成短暫的訪問失敗,這段時間也會對正在使用產(chǎn)品的用戶造成一定的影響。
解決方案
基于以上的原因,在部署應(yīng)用時應(yīng)該按照以下步驟進(jìn)行(為了簡單起見,假設(shè)一個應(yīng)用部署兩個實例):
- 將服務(wù)的一個實例在注冊中心的狀態(tài)設(shè)置為 DOWN
- 等待一段時間,直到其他服務(wù)緩存刷新,不再調(diào)用到這臺服務(wù)器上
- 停止服務(wù),更新代碼,重新啟動,等待,直到啟動成功
完成后,再重復(fù)以上步驟部署另一個實例。
第一步:修改服務(wù)實例狀態(tài)為 DOWN
有兩種方案可以修改實例的狀態(tài),選擇其一即可:
- 直接調(diào)用 Eureka Server API 修改:PUT /eureka/apps/{appID}/{instanceID}/status?value=DOWN
- 調(diào)用服務(wù)實例對應(yīng)的 actuator endpoint:
/service-registry
我更偏向使用方法二,對應(yīng)的命令:
1
| curl -H "Content-Type:application/json" -X POST http://{host:port}/actuator/service-registry?status=DOWN
|
如果 actuator endpoint 加了 Spring Security Basic 認(rèn)證,則還需要加上用戶名和密碼:
1
| curl -H "Content-Type:application/json" -X POST -u {username}:{password} http://{host:port}/actuator/service-registry?status=DOWN
|
第二步:等待其他服務(wù)緩存刷新
具體要等多久,其他調(diào)用者的請求才會不再訪問到這臺狀態(tài)為 DOWN 的實例?這里涉及到三個配置項:
eureka.client.registryFetchIntervalSeconds Eureka 客戶端每隔多久去 Eureka 服務(wù)器拉取最新的注冊信息,默認(rèn)值 30(秒)。ribbon.ServerListRefreshInterval Ribbon 的緩存刷新間隔時間,默認(rèn) 30000(毫秒)。Eureka 客戶端拉取到最新注冊信息后,Ribbon、Feign 等組件不會立即生效,是因為 Ribbon 還有一層緩存。eureka.server.responseCacheUpdateIntervalMs Eureka Server 返回最新的注冊信息的接口緩存刷新時間間隔,默認(rèn) 30000(毫秒)。有時候會看到 Eureka 頁面和 /eureka/apps 接口的服務(wù)狀態(tài)不一致,就是因為 /eureka/apps 接口默認(rèn)會有 30 秒緩存。
在默認(rèn)情況下,當(dāng)一個服務(wù)狀態(tài)改為 DOWN,最長可能需要 30+30+30 秒,所有的緩存才會刷新,其他調(diào)用者才不會調(diào)用到這個狀態(tài)為 DOWN 的實例。這就意味著修改服務(wù)實例狀態(tài)為 DOWN 后需要等待 90 秒,才能進(jìn)行下一步操作。
為了讓部署時間縮短,可以將以上三個配置項都修改為5秒:
Eureka Server:
1
2
3
| eureka:
server:
responseCacheUpdateIntervalMs: 5000
|
Eureka Client(即各個服務(wù)):
1
2
3
4
5
| ribbon:
ServerListRefreshInterval: 5000
eureka:
client:
registryFetchIntervalSeconds: 5
|
完成以上配置,部署時將實例狀態(tài)設(shè)為 DOWN 后,只需要等待 15 秒即可停止進(jìn)程:
第三步:實例部署
這一步主要需要注意
- 盡量不要使用
kill -9 pid 強(qiáng)制殺掉進(jìn)程,而應(yīng)該使用 kill pid 或者 kill -15 pid 關(guān)閉進(jìn)程。使用 kill pid 或者 kill -15 pid 關(guān)閉進(jìn)程之前,Eureka Client 會給 Eureka Server 請求刪除自己,后續(xù)服務(wù)再次啟動后會重新注冊為 UP 狀態(tài)。如果使用 kill -9 pid 強(qiáng)制殺掉進(jìn)程,Eureka Client 沒有辦法注銷自己,Eureka Server 就不知道該實例已下線,直到長時間收不到心跳才會刪除該實例。如果在 Eureka Server 刪除實例之前實例啟動了,那么它的狀態(tài)還是會保持 DOWN 狀態(tài)。如果確實需要用到 kill -9 pid 強(qiáng)制殺掉進(jìn)程,那么服務(wù)重啟后需要再通過第一步的方式將實例狀態(tài)設(shè)為 UP。 - 服務(wù)啟動后,需要等待并確認(rèn)啟動成功后,才可以開始部署下一臺服務(wù)器。這里我們可以定時去請求 Spring Boot 提供的 actuator endpoint
/health 接口,例如每隔 1 秒請求一次,直到接口可以正常訪問,即可認(rèn)為服務(wù)啟動成功。
本文基于 Spring Boot 2.1.x 及 Spring Cloud Greenwich 版本
|