迁移 Eureka 到 Nacos 之双注册双订阅模式

2023-02-28

模式客户端中心

这里面涉及到这个双注册双订阅模式，下面让我们一起看看吧！内容概览首先，为啥要迁移呢?主要是它对比其他注册中心，已经落后太多了。就拿Nacos来说吧，不仅有配置中心，管理界面，还能手动上下线，而且支持服务列表变更的消息推送模式(实时性高)。Eureka1.x的架构有些地方可以改进，比如在客户端的pul

这里面涉及到这个双注册双订阅模式，下面让我们一起看看吧！

内容概览

首先，为啥要迁移呢?

主要是它对比其他注册中心，已经落后太多了。

就拿 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]
1.
2.
3.
4.
5.

可以看到是自动装配时，不知道用哪个导致的异常。但是我们两个都要。

这里只要在 application.properties 中把这个自动装配移除掉即可。

# 双注册模式下关闭
spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration1.
2.

当然，秉着严谨的态度，我们在这两个类中打入相应的断点，可以看到他们都被创建了。

同时，也成功注册到这两个注册中心去了。

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
1.
2.
3.
4.
5.
6.
7.
8.
9.

这个时候，我们访问新的客户端。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-registry1.
2.
3.
4.
5.
6.
7.

这里直接访问 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"1.