从 2018 年 Nacos 开源说起

@ 2018年夏天 

 文  | 望陶

2018 年夏天

---

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

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

为什么要开源 Nacos ？

---

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

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

除此之外，Nacos 支持多种启动模式，用户可以根据业务场景自由选择，将各个功能模块，如注册中心和配置中心，分开部署或者合并部署，从而能够完整支持小型创业公司成长到大型企业，微服务全生命周期的演进。

在 “Who is using Nacos” 的社区调研中，有 140 条留言，留言企业包括工商银行、爱奇艺、海康威视、APUS、上海识装等，而实际使用 Nacos 来构建注册和配置中心的企业数量远不止于此，虎牙直播是最早一批将 Nacos 大规模引入到生产环境的典型用户：

Who is using Nacos：

https://github.com/alibaba/nacos/issues/273

“虎牙关注 Nacos 是从v0.2 开始的，我们也参与了社区的建设，可以说是比较早期的企业用户。引入Nacos前，我们也对比了Spring Cloud Config Server、ZooKeeper 和 ectd ，总体评估下来，基于我们微服务体系现状以及业务场景，决定使用 Nacos 作为服务化改造中服务注册和服务发现的方案。使用过程中，我们发现，随着社区版本的不断更新和虎牙的深入实践，Nacos 的优势远比调研过程中发现的多。” #虎牙 基础保障部中间件团队负责人张波在一次开发者活动上分享道。

从开源到商业增值

---

似乎从开源软件诞生的第一天起，商业增值就出现了，它为那些基于开源来构建业务，但苦于效率、时间成本和稳定性问题的企业，提供了更多、更契合的选项，而这一魅力使得开源生态的发展越发健康。

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

产品官网：

https://www.aliyun.com/product/mse

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

从了解到实践

---

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

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

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

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

  com.alibaba.edas  edas-dubbo-migration-bom  2.6.5.1  pom

其中 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 依赖。

     org.springframework.cloud     spring-cloud-starter-alibaba-nacos-discovery     {相应的版本} 

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

     com.alibaba.edas
     edas-sc-migration-starter
     1.0.2
 

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 技术使得您的应用无需修改任何代码和配置，即可享有阿里云提供的微服务治理能力，已经上线的功能包含服务查询、无损下线、服务鉴权、离群实例摘除、标签路由。

[1 ]https://yq.aliyun.com/articles/698930

作者信息：

望陶，GitHub ID @ralf0131，Apache Dubbo PPMC Member，Apache Tomcat PMCMember，阿里巴巴高级技术专家。

点击文末“阅读原文”，了解更多详情~

Tips：

# 点下“在看”❤️

# 然后，公众号对话框内发送“Nacos”，试试手气？????

# 本期奖品是超级受欢迎的《码出高效》一本 。