从 2018 年 Nacos 开源说起

2018 年夏天 国内微服务开源 领域，迎来了一位新成员。此后，在构建微服务注册中心和配置中心的过程中，国内开发者多了一个可信赖的选项。 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台( 官方网站 )，它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践，可以用在微服务场景作为服务注册中心、配置中心等核心场景中，和阿里的其他微服务开源项目一样，Nacos 也是始于阿里，成长于社区的典型。 为什么要开源 Nacos ？ 在大规模服务发现和服务治理领域，现有的开源解决方案并非已经非常完美，阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中，积累了大量有关服务注册和服务配置的实践经验，而这些经验是可以在各个行业大规模复用。除此之外，更重要的是，希望和社区开发者共同发展，让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。 相比其他服务注册和配置中心开源方案，Nacos 的起步虽然晚了点，但除了注册和配置中心的功能外，他还提供了动态服务发现、服务共享与管理的功能，在大规模场景下具备更优秀的性能，在易用性上更便捷，分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比：（内容摘自 《主流微服务注册中心浅析和对比》 ） NacosConsulEurekaZookeeper一致性协议CP+APCPAPCP健康检查TCP/HTTP/MYSQL/Client BeatTCP/HTTP/gRPC/CmdClient BeatKeep Alive负载均衡策略权重/ metadata/SelectorFabioRibbon—雪崩保护有无有无自动注销实例支持不支持支持支持访问协议HTTP/DNSHTTP/DNSHTTPTCP监听支持支持支持支持支持多数据中心支持支持支持不支持跨注册中心同步支持支持不支持不支持SpringCloud集成支持支持支持支持Dubbo集成支持支持不支持支持K8S集成支持支持不支持不支持 不想自己运维Nacos? 阿里云微服务引擎MSE提供Nacos托管服务 阿里云微服务引擎 ( MSE ) 是开源注册、配置中心的全托管平台，提供高可用、免运维的 ZooKeeper、Nacos 注册中心 和 Eureka 等集群，完全兼容开源产品标准接口，无需修改代码、开箱即用，并为客户提供相应的监控和运维工具。产品官网： https://www.aliyun.com/product/mse 那么，MSE托管的注册中心，和开源自建注册中心究竟有什么区别？可以通过下面这张表来进行对比。 对比项自建注册中心MSE注册中心成本资源成本ECS费用支持按时/包年包月，约等于同等配置ECS费用人力成本需要专人维护运维MSE提供易用自动化能力运维，门槛低高可用容灾能力无支持多机房，多区域容灾宕机处理手动处理自动探测，自动恢复活性探测不支持支持进程活性探测，失败自动恢复功能数据管理命令行页面可视化，支持增删查改访问方式机器IP直连，代码要变域名，换机器，不需要变动业务报警无支持核心业务指标如链接数多维度报警配置网络方式本地网络VPC网络，公网服务管理不支持服务提供者，订阅者页面管理集群权限管理不支持支持子账号管理，可自定义子账号访问权限TPS/QPS统计不支持提供TPS，QPS监控视图运维集群观测无页面可视化，查看节点健康状态，角色监控图表无提供多种指标如Znode，链接数图形化视图配置运维手动修改，手动重启页面修改，一键重启生效节点伸缩手动扩缩容，手动重启页面选择，一键扩缩容性能伸缩不支持页面选择，一键伸缩从了解到实践 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 技术使得您的应用无需修改任何代码和配置，即可享有阿里云提供的微服务治理能力，已经上线的功能包含服务查询、无损下线、服务鉴权、离群实例摘除、标签路由。