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

內(nèi)容概覽

首先，為啥要遷移呢?

主要是它對(duì)比其他注冊(cè)中心，已經(jīng)落后太多了。

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

官方Wiki

Eureka 最新版本

簡單了解了這個(gè)背景后，咱們?cè)賮砜纯?4ye 搭建的這個(gè) demo 。

Eureka 注冊(cè)中心

比如 老項(xiàng)目中，使用的注冊(cè)中心是 Eureka 。架構(gòu)如下：

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

• 注冊(cè)中心 ：搭建時(shí)選擇 Eureka Server 即可。
• 服務(wù)提供者(provider)：搭建時(shí)選擇 Eureka Discovery Client 和 Spring Web 即可。
• 服務(wù)消費(fèi)者(consumer)：搭建時(shí)選擇 Eureka Discovery Client 和 Spring Web 即可。

然后依次啟動(dòng)注冊(cè)中心，provider，consumer 即可。

訪問 http://localhost:8772/hello/Java4ye 可以看到下面的內(nèi)容。

雙注冊(cè)雙訂閱模式

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

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

啟動(dòng)時(shí)會(huì)拋出下面的異常信息 。(引入 Actuator 時(shí)會(huì)出現(xiàn)另一個(gè)，同樣排除掉即可)

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]

可以看到是自動(dòng)裝配時(shí)，不知道用哪個(gè)導(dǎo)致的異常。但是我們兩個(gè)都要。

這里只要在 application.properties 中把這個(gè)自動(dòng)裝配移除掉即可。

# 雙注冊(cè)模式下關(guān)閉
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration

當(dāng)然，秉著嚴(yán)謹(jǐn)?shù)膽B(tài)度，我們?cè)谶@兩個(gè)類中打入相應(yīng)的斷點(diǎn)，可以看到他們都被創(chuàng)建了。

同時(shí)，也成功注冊(cè)到這兩個(gè)注冊(cè)中心去了。

Eureka

Nacos

這個(gè)時(shí)候，再次訪問舊的客戶端 8772 端口的，可以發(fā)現(xiàn)如下效果。

但是要注意，此時(shí)項(xiàng)目的架構(gòu)變成這樣，consumer 中只有 Eureka 的客戶端，所以調(diào)用到的都是 Eureka 中心中的服務(wù)。此時(shí)流量不會(huì)走到 Nacos 這邊

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

穩(wěn)定后，下一步就是 下線這個(gè) provider ，然后看看正不正常了。同樣穩(wěn)定后，便是準(zhǔn)備啟動(dòng)這個(gè) 雙訂閱的客戶端了。

小實(shí)驗(yàn)

但是我這里做了一個(gè)小實(shí)驗(yàn) 哈哈 想看看不下線的情況，我這個(gè) 新客戶端 上線后是使用哪個(gè)注冊(cè)中心的服務(wù)多點(diǎn)。

所以，接著，我們就啟動(dòng)這個(gè)新的 consumer，一個(gè)雙訂閱的客戶端。

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

spring.cloud.nacos.discovery.username=nacos
spring.cloud.nacos.discovery.password=nacos
# Nacos 服務(wù)發(fā)現(xiàn)與注冊(cè)配置，其中子屬性 server-addr 指定 Nacos 服務(wù)器主機(jī)和端口
spring.cloud.nacos.discovery.server-addr=192.168.175.128:8848
# 注冊(cè)到 nacos 的指定 namespace，默認(rèn)為 public
spring.cloud.nacos.discovery.namespace=public

# 雙注冊(cè)模式下關(guān)閉
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration

這個(gè)時(shí)候，我們?cè)L問新的客戶端。8872 端口的：http://localhost:8872/hello/Java4ye

發(fā)現(xiàn)無論怎么刷新，接口的返回值都是下面這個(gè)，無法達(dá)到負(fù)載均衡的效果 。(⊙o⊙)?

簡單翻看了下源碼，可以發(fā)現(xiàn)系統(tǒng)創(chuàng)建了三個(gè) discoveryClient ，最后一個(gè)是兜底用的。

而且 nacos 排在第一個(gè)，這意味著從 nacos 的注冊(cè)中心中找到服務(wù)的話，就不會(huì)調(diào)用到 Eureka 中的了。

了解了這個(gè)原理后，將 nacos 中的服務(wù)進(jìn)行下線。

然后去刷新新的客戶端，8872 端口的，可以發(fā)現(xiàn)，又出現(xiàn)了負(fù)載均衡的效果了。

而且得益于 Nacos 的服務(wù)列表變更推送機(jī)制，我們客戶端可以實(shí)時(shí)感知到 服務(wù)列表的 變化，這個(gè)時(shí)候直接去刷新新客戶端的接口，可以發(fā)現(xiàn)它已經(jīng)切換到 Eureka 中了，沒有延遲感!

所以當(dāng)我們?cè)谶w移的過程中，如果發(fā)現(xiàn) Nacso 上新的 provider 有什么異常時(shí)，可以將其下線先?? 輕輕一點(diǎn)真的太方便了。

優(yōu)雅下線

結(jié)束上面的小實(shí)驗(yàn)，回到正常流程中，我們要來下線這個(gè) provider 了。

階段目標(biāo)

這里就得考慮這個(gè) 優(yōu)雅下線 的問題了。

網(wǎng)上的方案很多，這里用 Springboot 的 actuator 來實(shí)現(xiàn)。

這個(gè) graceful 配置是 Springboot2.3 之后才有的，會(huì)讓內(nèi)嵌服務(wù)器拒絕外部請(qǐng)求，然后處理完已經(jīng)在內(nèi)部的請(qǐng)求后，進(jìn)入關(guān)閉狀態(tài)。

通過這個(gè)暴露的 api，去修改 eureka 中 service 的狀態(tài)。

# 優(yōu)雅下線
server.shutdown=graceful
# 關(guān)閉超時(shí)
spring.lifecycle.timeout-per-shutdown-phase=20s

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

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

接著，我們通過這串請(qǐng)求，改變 Eureka 中服務(wù)的狀態(tài)：DOWN。

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

然后，在等待若干時(shí)間后，應(yīng)該是客戶端 consumer 重新去拉取服務(wù)列表信息后。(哈哈 我沒數(shù))。

不過我配了 10s ，然后我們不斷刷新請(qǐng)求，會(huì)發(fā)現(xiàn)這個(gè)負(fù)載均衡的效果已經(jīng)消失了。只剩新的 provider 提供的服務(wù)了。

然后在服務(wù)穩(wěn)定一段時(shí)間后，可以通過 Prometheus 來觀察這個(gè)舊的 provider 的 qps 等，當(dāng)它已經(jīng)沒有啥流量進(jìn)入了，便可以直接關(guān)閉下線了。( kill -9)

上線雙訂閱客戶端

接著，上線這個(gè) 新的 consumer ，這里也沒啥特別的了。

同樣等系統(tǒng)穩(wěn)定后，下線這個(gè)舊的客戶端 consumer 了。

而且從上面小實(shí)驗(yàn)環(huán)節(jié)中，我們可以知道流量會(huì)先來到這個(gè) Nacos 中，確認(rèn)里面沒有這個(gè)服務(wù)的話，才去這個(gè) Eureka 中查找。所以到這里，這個(gè) Eureka 中的流量就會(huì)少了大部分了。

再次上線

到了這里，我們還不能直接關(guān)閉這個(gè) Eureka，還得再次上線新版本的只有 Nacos 注冊(cè)中心的 provider 和 consumer 。

這次的新版要注意這個(gè)負(fù)載均衡，我們?nèi)サ袅?Netflix 后，得手動(dòng)引入 SpringCloud 的 loadbalancer 組件。其他也就刪刪配置了。

同樣的，穩(wěn)定后，才去下線雙訂閱客戶端 consumer，再下線雙注冊(cè)服務(wù)端 Provider，最后才下線這個(gè) Eureka。 

這里通過 Nginx 等去控制流量，將他們打到新的只訂閱 Nacos 的 consumer 上，最后等雙訂閱的 consumer 客戶端沒啥流量就給它下線了。

接著，在 Nacos 上 ，下線那個(gè)雙注冊(cè)的服務(wù)，然后再去下線它。

最后就直接關(guān)閉 Eureka 了。

這樣就完成了這個(gè)注冊(cè)中心的遷移了。

整體流程

這里其實(shí)就是上線新版本后，等其穩(wěn)定，下線舊版本的一個(gè)規(guī)則。

看著挺繁瑣的

關(guān)于應(yīng)用的發(fā)布，這里就不多贅述了，網(wǎng)上大把的 藍(lán)綠發(fā)布，灰度發(fā)布，還有 K8s 的 pod 容器，docker 等環(huán)境下的決策。

最后

https://github.com/Java4ye/springcloud-alibaba-demo-4ye

整個(gè)demo 我也弄到 GitHub 上啦，新開的坑， 哈哈，后面也會(huì)逐步完善的。

覺得不錯(cuò)的話，可以 Star 支持一波哦！

總結(jié)

通過本案例，可以快速了解到這個(gè)遷移過程中：

• 這個(gè)代碼基本都沒改!這得益于這個(gè) SpringCloud 的統(tǒng)一服務(wù)注冊(cè)和發(fā)現(xiàn)的編程模型。
• 使用雙注冊(cè)雙訂閱模型時(shí)，要排除掉自動(dòng)裝配的坑，而且在這個(gè)模式下，流量基本都跑到 Nacos 這邊。
• 對(duì)比下兩個(gè)注冊(cè)中心，更能感覺到 Nacos 這么多便利的功能：上下線和服務(wù)列表變化的推送機(jī)制。
• 了解到 Springboot 在優(yōu)雅下線這一塊做的變化，謹(jǐn)記不要輕易 kill -9!