遷移 Eureka 到 Nacos 之雙注冊雙訂閱模式

作者：Java4ye 2022-05-02 22:01:49

Eureka 1.x 的架構有些地方可以改進，比如在客戶端的 pull 模式下，增加這個消息推送模式，增加實時性;還有集群，Eureka 只支持 AP ，各個客戶端都能進行寫請求，沒有主從節點之分，各個節點之間通過相互復制來同步數據，無法保證一致性。Nacos 則有 AP 和 CP 兩種選擇，更靈活。

這里面涉及到這個雙注冊雙訂閱模式，下面讓我們一起看看吧！

內容概覽

首先，為啥要遷移呢?

主要是它對比其他注冊中心，已經落后太多了。

就拿 Nacos 來說吧，不僅有配置中心，管理界面，還能手動上下線，而且支持服務列表變更的消息推送模式(實時性高)。
Eureka 1.x 的架構有些地方可以改進，比如在客戶端的 pull 模式下，增加這個消息推送模式，增加實時性;還有集群，Eureka 只支持 AP ，各個客戶端都能進行寫請求，沒有主從節點之分，各個節點之間通過相互復制來同步數據，無法保證一致性。Nacos 則有 AP 和 CP 兩種選擇，更靈活。
2019年的某個會上，Spring 團隊提出如何解決 Netflix 進入維護模式后的 SpringCLoud 組件選擇問題。
就是 Eureka 早已進入維護模式啦!而且 long long ago ，官方就放棄了這個 Eureka2.X 版本的開發(看了下分支，6，7年前的代碼了)，而且官方還說了不能用在生產上，后果自負(咱也不知道它有啥新特點，反正 SpringCloud 一直用的 1.x 版本。現在更新到1.10 了)。

官方Wiki

Eureka 最新版本

簡單了解了這個背景后，咱們再來看看 4ye 搭建的這個 demo 。

Eureka 注冊中心

比如老項目中，使用的注冊中心是 Eureka 。架構如下：

代碼也很簡單，有三個模塊。分別是

注冊中心：搭建時選擇 Eureka Server 即可。
服務提供者(provider)：搭建時選擇 Eureka Discovery Client 和 Spring Web 即可。
服務消費者(consumer)：搭建時選擇 Eureka Discovery Client 和 Spring Web 即可。

然后依次啟動注冊中心，provider，consumer 即可。

訪問 http://localhost:8772/hello/Java4ye 可以看到下面的內容。

雙注冊雙訂閱模式

接著，我們克隆上面的 provider 和 consumer 模塊。

在 pom 文件中直接加入 Nacos 和 Eureka 。

啟動時會拋出下面的異常信息。(引入 Actuator 時會出現另一個，同樣排除掉即可)

Description:

Field autoServiceRegistration in org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration required a single bean, but 2 were found:
  - nacosAutoServiceRegistration: defined by method 'nacosAutoServiceRegistration' in class path resource [com/alibaba/cloud/nacos/registry/NacosServiceRegistryAutoConfiguration.class]
  - eurekaAutoServiceRegistration: defined by method 'eurekaAutoServiceRegistration' in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.class]

可以看到是自動裝配時，不知道用哪個導致的異常。但是我們兩個都要。

這里只要在 application.properties 中把這個自動裝配移除掉即可。

# 雙注冊模式下關閉
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration

當然，秉著嚴謹的態度，我們在這兩個類中打入相應的斷點，可以看到他們都被創建了。

同時，也成功注冊到這兩個注冊中心去了。

Eureka

Nacos

這個時候，再次訪問舊的客戶端 8772 端口的，可以發現如下效果。

但是要注意，此時項目的架構變成這樣，consumer 中只有 Eureka 的客戶端，所以調用到的都是 Eureka 中心中的服務。此時流量不會走到 Nacos 這邊

接著便是看客戶端 consumer 正不正常，比如跑個一天看看。

穩定后，下一步就是下線這個 provider ，然后看看正不正常了。同樣穩定后，便是準備啟動這個雙訂閱的客戶端了。

小實驗

但是我這里做了一個小實驗哈哈想看看不下線的情況，我這個新客戶端上線后是使用哪個注冊中心的服務多點。

所以，接著，我們就啟動這個新的 consumer，一個雙訂閱的客戶端。

同樣修改下配置文件即可。

spring.cloud.nacos.discovery.username=nacos
spring.cloud.nacos.discovery.password=nacos
# Nacos 服務發現與注冊配置，其中子屬性 server-addr 指定 Nacos 服務器主機和端口
spring.cloud.nacos.discovery.server-addr=192.168.175.128:8848
# 注冊到 nacos 的指定 namespace，默認為 public
spring.cloud.nacos.discovery.namespace=public

# 雙注冊模式下關閉
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration

這個時候，我們訪問新的客戶端。8872 端口的：http://localhost:8872/hello/Java4ye

發現無論怎么刷新，接口的返回值都是下面這個，無法達到負載均衡的效果。(⊙o⊙)?

簡單翻看了下源碼，可以發現系統創建了三個 discoveryClient ，最后一個是兜底用的。

而且 nacos 排在第一個，這意味著從 nacos 的注冊中心中找到服務的話，就不會調用到 Eureka 中的了。

了解了這個原理后，將 nacos 中的服務進行下線。

然后去刷新新的客戶端，8872 端口的，可以發現，又出現了負載均衡的效果了。

而且得益于 Nacos 的服務列表變更推送機制，我們客戶端可以實時感知到服務列表的變化，這個時候直接去刷新新客戶端的接口，可以發現它已經切換到 Eureka 中了，沒有延遲感!

所以當我們在遷移的過程中，如果發現 Nacso 上新的 provider 有什么異常時，可以將其下線先?? 輕輕一點真的太方便了。

優雅下線

結束上面的小實驗，回到正常流程中，我們要來下線這個 provider 了。

階段目標

這里就得考慮這個優雅下線的問題了。

網上的方案很多，這里用 Springboot 的 actuator 來實現。

這個 graceful 配置是 Springboot2.3 之后才有的，會讓內嵌服務器拒絕外部請求，然后處理完已經在內部的請求后，進入關閉狀態。

通過這個暴露的 api，去修改 eureka 中 service 的狀態。

# 優雅下線
server.shutdown=graceful
# 關閉超時
spring.lifecycle.timeout-per-shutdown-phase=20s

#
management.endpoints.web.exposure.include= service-registry

這里直接訪問 curl "localhost:8771/actuator" 來獲取我們注冊的這個 API (可以看到我們 - 符號被吃掉了坑??)

接著，我們通過這串請求，改變 Eureka 中服務的狀態：DOWN。

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