这里就涉及到了这个双注册双订阅模式，一起来看看吧！内容概述首先，为什么要迁移？主要原因是它已经远远落后于其他注册管理机构。以Nacos为例。不仅有配置中心和管理界面，还可以手动上下线，支持服务列表变化的消息推送方式（实时性高）。Eureka1.x的架构在某些地方可以改进。比如在客户端的pull模式下，增加这个消息push模式，增加实时性；还有一个集群。Eureka只支持AP，每??个client都可以写请求，没有master-slave节点，每个节点通过相互复制来同步数据，不能保证一致性。Nacos有AP和CP两种选择，更加灵活。在2019年的一次会议上，Spring团队提出了在Netflix进入维护模式后如何解决SpringCLoud组件选择问题。也就是说，Eureka已经进入维护模式了！而且很久很久以前，官方就放弃了这个Eureka2.X版本的开发（看了下分支，6、7年前的代码），官方也说不能用于生产，后果自负（不知道有什么新特性，反正SpringCloud一直在用1.x版本，现在更新到1.10了）。在官方最新版的WikiEureka中简单了解了这个背景之后，我们来看看4ye搭建的demo。Eureka注册中心例如，在老项目中，使用的注册中心是Eureka。架构如下：代码也很简单，一共有三个模块。它们是注册中心：构建时选择EurekaServer。服务提供者（provider）：构建时选择EurekaDiscoveryClient和SpringWeb。服务消费者（consumer）：构建时选择EurekaDiscoveryClient和SpringWeb即可。然后依次启动注册中心、提供者、消费者。访问http://localhost:8772/hello/Java4ye可以看到如下内容。双注册双订阅模式接下来，我们克隆上面的提供者和消费者模块。直接在pom文件中添加Nacos和Eureka。启动时会抛出如下异常信息。（引入Actuator时会出现另一个，排除即可）说明：org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration中的字段autoServiceRegistrationrequiredasinglebean,but2werefound:-nacosAutoServiceRegistration:definedbymethod'nacosAutoServiceRegistration'in类路径资源[com/alibaba/cloud/nacos/registry/NacosServiceRegistryAutoConfiguration.class]-eurekaAutoServiceRegistration:类路径资源[org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.class]中的方法'eurekaAutoServiceRegistration'定义时可以看到是自动组装的，不知道用哪个导致异常。但我们两者都想要。这里只需要去掉application.properties中的这个自动组装即可。#关闭双注册模式下的spring.autoconfigure.exclude=org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration,org.springframework.cloud.client.serviceregistry.ServiceRegistryAutoConfiguration当然，本着严谨的态度，我们在这两个类中回车对应的断点，可以看到都创建好了。同时在这两个注册中心注册成功。此时EurekaNacos再次访问老客户端8772端口，可以发现如下效果。但是需要注意的是，这个时候项目的结构变成了这个样子。consumer中只有Eurekaclients，所以调用了Eurekacenter中的所有服务。这时候流量就不会去Nacos了，再看看客户端消费是否正常，比如跑一天看看。稳定之后，下一步就是让这个provider下线，然后检查是否正常。同样稳定后，准备启动双订阅客户端。小实验不过我这里做了个小实验哈哈想看看不下线的情况，我新客户端上线后哪个注册中心使用的服务更多。所以，接下来，我们启动这个新的消费者，一个双订阅客户端。您也可以修改配置文件。spring.cloud.nacos.discovery.username=nacosspring.cloud.nacos.discovery.password=nacos#Nacos服务发现和注册配置，其中子属性server-addr指定Nacos服务器主机和spring.cloud.nacos端口。discovery.server-addr=192.168.175.128:8848#注册到nacos的指定命名空间，默认是publicspring.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⊙)？简单看一下源码，我们可以发现系统创建了三个discoveryClients，最后一个是做底线的。而nacos是排在第一位的，也就是说如果从nacos注册中心找到服务，是不会调用到Eureka中的。理解了这个原理之后，就把nacos中的服务取下来。然后去刷新新客户端，8872端口，可以发现负载均衡效果又出现了。并且得益于Nacos的服务列表变更推送机制，我们的客户端可以实时感知到服务列表的变化。这时候我们可以直接刷新新客户端的界面，可以发现已经切换到了Eureka，没有任何延迟感！所以当迁移过程中，如果我们在Nacso上发现新的provider有异常，我们可以先下线
