从 2018 年 Nacos 开源说起

2018 年夏天

国内微服务开源 领域，迎来了一位新成员。此后，在构建微服务注册中心和配置中心的过程中，国内开发者多了一个可信赖的选项。

Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台(官方网站)，它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践，可以用在微服务场景作为服务注册中心、配置中心等核心场景中，和阿里的其他微服务开源项目一样，Nacos 也是始于阿里，成长于社区的典型。

为什么要开源 Nacos ？

在大规模服务发现和服务治理领域，现有的开源解决方案并非已经非常完美，阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中，积累了大量有关服务注册和服务配置的实践经验，而这些经验是可以在各个行业大规模复用。除此之外，更重要的是，希望和社区开发者共同发展，让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。

相比其他服务注册和配置中心开源方案，Nacos 的起步虽然晚了点，但除了注册和配置中心的功能外，他还提供了动态服务发现、服务共享与管理的功能，在大规模场景下具备更优秀的性能，在易用性上更便捷，分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比：（内容摘自《主流微服务注册中心浅析和对比》）

不想自己运维Nacos? 阿里云微服务引擎MSE提供Nacos托管服务

阿里云微服务引擎 ( MSE ) 是开源注册、配置中心的全托管平台，提供高可用、免运维的 ZooKeeper、Nacos 注册中心 和 Eureka 等集群，完全兼容开源产品标准接口，无需修改代码、开箱即用，并为客户提供相应的监控和运维工具。产品官网：https://www.aliyun.com/product/mse


那么，MSE托管的注册中心，和开源自建注册中心究竟有什么区别？可以通过下面这张表来进行对比。

从了解到实践

Dubbo 应用如何保证业务不停机的情况下无缝迁移到MSE？

下面以基于 SpringBoot 构建的 Dubbo 应用为例介绍如何进行迁移

第一步：引入用于迁移的定制化注册中心依赖

虽然 Dubbo 本身提供了配置多注册中心的能力，但其存在比较大的局限性，当消费者配置多注册中心时，Dubbo 原有的策略为优先选取第一个注册中心的地址，若其地址为空，再读取第二个，依次类推选取地址。理想的模型应当是多个注册中心的地址合并后随机选取，为此，MSE 提供了专门的注册中心扩展，解决该问题：

<dependency>
  <groupId>com.alibaba.edas</groupId>
  <artifactId>edas-dubbo-migration-bom</artifactId>
  <version>2.6.5.1</version>
  <type>pom</type>
</dependency>

其中 edas-dubbo-migration-bom 有 2.6.5.1 和 2.7.5 两个版本，分别对应 Dubbo 2.6.x 和 Dubbo 2.7.x 两个大版本。

第二步：购买 MSE Nacos 实例，并配置对应 nacos server address

在 MSE 控制台购买相同 VPC 内的 Nacos 实例，并在应用的 application.properties 配置文件增加：

dubbo.registry.address = edas-migration://30.5.124.15:9999?service-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848&reference-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848

说明：

edas-migration://30.5.124.15:9999

多注册中心的头部信息。可以不做更改，ip 和 port 可以任意填写，主要是为了兼容 Dubbo 对 ip 和 port 的校验。启动时，如果日志级别是 WARN 及以下，可能会抛一个 WARN 的日志，可以忽略。

service-registry

服务注册的注册中心地址。写入多个注册中心地址。每个注册中心都是标准的 Dubbo 注册中心格式；多个用 , 分隔。

reference-registry

服务订阅的注册中心地址。每个注册中心都是标准的 Dubbo 注册中心格式；多个用,分隔。

第三步：确认双注册方案成功

启动应用，并观察到 MSE 实例的服务管理页面中注册上了提供者和消费者的信息。

同时在 Consul 的控制台中也能看相应的信息：

并且确认应用可以正常访问，到目前为止我们第一个应用迁移完毕。

第四步：依照迁移第一个应用的迁移步骤，逐步迁移全量应用

第五步 清理迁移配置

迁移完成后，删除原注册中心的配置和迁移过程专用的依赖 edas-dubbo-migration-bom，在业务量较小的时间分批重启应用。edas-dubbo-migration-bom 是一个迁移专用的 starter，虽然长期使用对您业务的稳定性没有影响，但其并不会跟随 Dubbo 的版本进行升级，为避免今后框架升级过程中出现兼容问题，推荐您在迁移完毕后清理掉，然后在业务量较小的时间分批重启应用。

Spring Cloud 应用如何保证业务不停机的情况下无缝迁移到MSE？

Spring Cloud 默认只支持 1 个注册中心，所以无法完成不停机的无缝迁移，这里对此作了增强，支持了双注册双订阅的模式，确保业务不停机进行迁移。

迁移方案：选择最先迁移的应用，建议是从最下层 Provider 开始迁移。但如果调用链路太复杂，比较难分析，也可以任意选一个应用进行迁移。选择完成后，即可参考下面的迁移步骤迁移第一个应用。

第一步：购买 MSE Nacos 实例，并配置对应 nacos server address

在 MSE 控制台购买相同 vpc 内的 Nacos 实例，并在应用的 application.properties 配置文件增加：

spring.cloud.nacos.discovery.server-addr={MSE对应Nacos实例的域名}:8848

第二步：在应用程序中添加依赖

在 pom.xml 文件中添加 spring-cloud-starter-alibaba-nacos-discovery 依赖。

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>{相应的版本}</version>
 </dependency>

默认情况下 Spring Cloud 只支持在依赖中引入一个注册中心，当存在多个注册中心时：启动会报错。所以这里需要添加一个依赖 edas-sc-migration-starter，使 Spring Cloud 应用支持多注册。

<dependency>
     <groupId>com.alibaba.edas</groupId>
     <artifactId>edas-sc-migration-starter</artifactId>
     <version>1.0.2</version>
 </dependency>

Ribbon 是实现负载均衡的组件，为了使应用可以支持从多个注册中心订阅服务，需要修改 Ribbon 配置。在应用启动的主类中，将 RibbonClients 默认配置为 MigrationRibbonConfiguration 。假设原有的应用主类启动代码如下：

@SpringBootApplication
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

那么修改后的应用主类启动代码如下：

@SpringBootApplication
 @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

第三步：确认双注册方案成功

启动应用，并观察到 MSE 实例的服务管理中注册上我们的服务。

同时在 Consul 的控制台中也能看到我们的服务。

并且确认应用可以正常访问，到目前为止我们第一个应用迁移完毕。

第四步：依照迁移第一个应用的迁移步骤，逐步迁移全量应用

第五步：清理迁移配置

迁移完成后，删除原有的注册中心的配置和迁移过程专用的依赖 edas-sc-migration-starter ，在业务量较小的时间分批重启应用。edas-sc-migration-starter 是一个迁移专用的 starter，虽然长期使用对您业务的稳定性没有影响，但在 Ribbon 负载均衡实现方面有一定的局限性，推荐您在迁移完毕后清理掉，然后在业务量较小的时间分批重启应用。

关于动态调整服务注册和订阅方式：
依赖 edas-sc-migration-starter 具备配合配置中心达到动态调整服务注册和订阅方式的效果，在完成迁移过程中，您可以通过修改您的配置动态变更服务注册和订阅方式。

动态调整服务订阅默认的订阅策略是从所有注册中心订阅，并对数据做一些简单的聚合。

您可以通过在您的配置中心修改 spring.cloud.edas.migration.subscribes 属性以便选择从哪几个注册中心订阅数据。

spring.cloud.edas.migration.subscribes=nacos,consul # 同时从 Consul 和 Nacos 订阅服务
spring.cloud.edas.migration.subscribes=nacos        # 只从 Nacos 订阅服务

动态变更服务注册默认的注册策略是注册到所有注册中心。您可以通过在您的配置中心的
spring.cloud.edas.migration.registry.excludes 属性来选择关闭指定的注册中心。

spring.cloud.edas.migration.registry.excludes=   #默认值为空，注册到所有的服务注册中心
spring.cloud.edas.migration.registry.excludes=consul   #关闭 Consul 的注册
spring.cloud.edas.migration.registry.excludes=nacos,consul   #关闭 Nacos 和 Consul 的注册

阿里云微服务引擎 MSE 重磅升级发布会即将开启

抛开担忧，迎接确性。

从配置中心，到微服务全面治理，MSE 正在迎接他的第一个成人礼，在原有配置中心托管的基础上，全面升级引入微服务治理能力，并通过 Java Agent 技术使得您的应用无需修改任何代码和配置，即可享有阿里云提供的微服务治理能力，已经上线的功能包含服务查询、无损下线、服务鉴权、离群实例摘除、标签路由。