[[409674]]

本文轉(zhuǎn)載自微信公眾號「程序新視界」，作者二師兄。轉(zhuǎn)載本文請聯(lián)系程序新視界公眾號。

前言

在上篇文章《微服務(wù)：剖析一下源碼，Nacos的健康檢查竟如此簡單》中講了當(dāng)微服務(wù)突然掛掉的解放方案：調(diào)整健康檢查周期和故障請求重試。朋友看了文章，建議再聊聊正常關(guān)閉服務(wù)時如何讓微服務(wù)優(yōu)雅下線。

為什么說是優(yōu)雅下線?我們知道在分布式應(yīng)用中為了滿足CAP原則中的A(可用性)，像Nacos、Eureka等注冊中心的客戶端都會進行實例列表的緩存。當(dāng)正常關(guān)閉應(yīng)用時，雖然可以主動調(diào)用注冊中心進行注銷，但這些客戶端緩存的實例列表還是要等一段時間才會失效。

上述情況就有可能導(dǎo)致服務(wù)請求到已經(jīng)被關(guān)閉的實例上，雖然通過重試機制可以解決掉這個問題，但這種解決方案會出現(xiàn)重試，在一定程度上會導(dǎo)致用戶側(cè)請求變慢。這時就需要進行優(yōu)雅的下線操作了。

下面我們先從通常關(guān)閉進程的幾種方式聊起。

方式一：基于kill命令

Spring Cloud本身對關(guān)閉服務(wù)是有支持的，當(dāng)通過kill命令關(guān)閉進程時會主動調(diào)用Shutdown hook來進行當(dāng)前實例的注銷。使用方式：

kill Java進程ID

這種方式是借助Spring Cloud的Shutdown hook機制(本質(zhì)是Spring Boot提供，Spring Cloud服務(wù)發(fā)現(xiàn)功能進行具體注銷實現(xiàn))，在關(guān)閉服務(wù)之前會對Nacos、Eureka等服務(wù)進行注銷。但這個注銷只是告訴了注冊中心，客戶端的緩存可能需要等幾秒(Nacos默認(rèn)為5秒)之后才能感知到。

這種Shutdown hook機制不僅適用于kill命令，還適用于程序正常退出、使用System.exit()、終端使用Ctrl + C等。但不適用于kill -9 這樣強制關(guān)閉或服務(wù)器宕機等場景。

這種方案雖然比直接掛掉要等15秒縮短了時間，相對好一些，但本質(zhì)上并沒有解決客戶端緩存的問題，不建議使用。

方式二：基于/shutdown端點

在Spring Boot中，提供了/shutdown端點，基于此也可以實現(xiàn)優(yōu)雅停機，但本質(zhì)上與第一種方式相同，都是基于Shutdown hook來實現(xiàn)的。在處理完基于Shutdown hook的邏輯之后，也會進行服務(wù)的關(guān)閉，但同樣面臨客戶端緩存的問題，因此，也不推薦使用。

這種方式首先需要在項目中引入對應(yīng)的依賴：

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-actuator</artifactId> 
</dependency> 

然后在項目中配置開啟/shutdown端點：

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

然后停服時請求對應(yīng)的端點，這里采用curl命令示例：

curl -X http://實例服務(wù)地址/actuator/shutdown

方式三：基于/pause端點

Spring Boot同樣提供了/pause端點(Spring Boot Actuator提供)，通過/pause端點，可以將/health為UP狀態(tài)的實例修改為Down狀態(tài)。

基本操作就是在配置文件中進行pause端點的開啟：

management: 
  endpoint: 
    # 啟用pause端點 
    pause: 
      enabled: true 
    # pause端點在某些版本下依賴restart端點 
    restart: 
      enabled: true 
  endpoints: 
    web: 
      exposure: 
        include: pause,restart 

然后發(fā)送curl命令，即可進行服務(wù)的終止。注意這里需要采用POST請求。

關(guān)于/pause端點的使用，不同的版本差異很大。筆者在使用Spring Boot 2.4.2.RELEASE版本時發(fā)現(xiàn)根本無法生效，查了Spring Boot和Spring Cloud項目的Issues發(fā)現(xiàn)，這個問題從2.3.1.RELEASE就存在。目前看應(yīng)該是在最新版本中Web Server的管理改為SmartLifecycle的原因，而Spring Cloud對此貌似放棄了支持(有待考察)，最新的版本調(diào)用/pause端點無任何反應(yīng)。

鑒于上述版本變動過大的原因，不建議使用/pause端點進行微服務(wù)的下線操作，但使用/pause端點的整個思路還是值得借鑒的。

基本思路就是：當(dāng)調(diào)用/pause端點之后，微服務(wù)的狀態(tài)會從UP變?yōu)镈OWN，而服務(wù)本身還是可以正常提供服務(wù)。當(dāng)微服務(wù)被標(biāo)記為DOWN狀態(tài)之后，會從注冊中心摘除，等待一段時間(比如5秒)，當(dāng)Nacos客戶端緩存的實例列表更新了，再進行停服處理。

這個思路的核心就是：先將微服務(wù)的流量切換掉，然后再關(guān)閉或重新發(fā)布。這就解決了正常發(fā)布時客戶端緩存實例列表的問題。

基于上述思路，其實自己也可以實現(xiàn)相應(yīng)的功能，比如提供一個Controller，先調(diào)用該Controller中的方法將當(dāng)前實例從Nacos中注銷，然后等待5秒，再通過腳本或其他方式將服務(wù)關(guān)閉掉。

方式四：基于/service-registry端點

方式三中提到的方案如果Spring Cloud能夠直接支持，那就更好了。這不，Spring Cloud提供了/service-registry端點。但從名字就可以知道專門針對服務(wù)注冊實現(xiàn)的一個端點。

在配置文件中開啟/service-registry端點：

management: 
  endpoints: 
    web: 
      exposure: 
        include: service-registry 
      base-path: /actuator 
  endpoint: 
    serviceregistry: 
      enabled: true 

訪問http://localhost:8081/actuator 端點可以查看到開啟了如下端點：

{ 
    "_links": { 
        "self": { 
            "href": "http://localhost:8081/actuator", 
            "templated": false 
        }, 
        "serviceregistry": { 
            "href": "http://localhost:8081/actuator/serviceregistry", 
            "templated": false 
        } 
    } 
} 

通過curl命令來進行服務(wù)狀態(tài)的修改：

curl -X "POST" "http://localhost:8081/actuator/serviceregistry?status=DOWN" -H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8" 

執(zhí)行上述命令之前，查看Nacos對應(yīng)實例狀態(tài)為：

可以看到實例詳情中的按鈕為“下線”也就是說目前處于UP狀態(tài)。當(dāng)執(zhí)行完上述curl命令之后，實例詳情中的按鈕為“上線”，說明實例已經(jīng)下線了。

上述命令就相當(dāng)于我們在Nacos管理后臺手動的操作了實例的上下線。

當(dāng)然，上述情況是基于Spring Cloud和Nacos的模式實現(xiàn)的，本質(zhì)上Spring Cloud是定義了一個規(guī)范，比如所有的注冊中心都需要實現(xiàn)ServiceRegistry接口，同時基于ServiceRegistry這個抽象還定義了通用的Endpoint：

@Endpoint(id = "serviceregistry") 
public class ServiceRegistryEndpoint { 
 
   private final ServiceRegistry serviceRegistry; 
 
   private Registration registration; 
 
   public ServiceRegistryEndpoint(ServiceRegistry<?> serviceRegistry) { 
      this.serviceRegistry = serviceRegistry; 
   } 
 
   public void setRegistration(Registration registration) { 
      this.registration = registration; 
   } 
 
   @WriteOperation 
   public ResponseEntity<?> setStatus(String status) { 
      Assert.notNull(status, "status may not by null"); 
 
      if (this.registration == null) { 
         return ResponseEntity.status(HttpStatus.NOT_FOUND).body("no registration found"); 
      } 
 
      this.serviceRegistry.setStatus(this.registration, status); 
      return ResponseEntity.ok().build(); 
   } 
 
   @ReadOperation 
   public ResponseEntity getStatus() { 
      if (this.registration == null) { 
         return ResponseEntity.status(HttpStatus.NOT_FOUND).body("no registration found"); 
      } 
 
      return ResponseEntity.ok().body(this.serviceRegistry.getStatus(this.registration)); 
   } 
 
} 

我們上面調(diào)用的Endpoint便是通過上面代碼實現(xiàn)的。所以不僅Nacos，只要基于Spring Cloud集成的注冊中心，本質(zhì)上都是支持這種方式的服務(wù)下線的。

小結(jié)

很多項目都逐步在進行微服務(wù)化改造，但一旦因為微服務(wù)系統(tǒng)，將面臨著更復(fù)雜的情況。本篇文章重點基于Nacos在Spring Cloud體系中優(yōu)雅下線來為大家剖析了一個微服務(wù)實戰(zhàn)中常見的問題及解決方案。你是否在使用微服務(wù)，你又是否注意到這一點了?