vlambda博客
学习文章列表

从 2018 年 Nacos 开源说起




2018 年夏天



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


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



为什么要开源 Nacos ?



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


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


从 2018 年 Nacos 开源说起



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



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

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


从 2018 年 Nacos 开源说起


从了解到实践



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


从 2018 年 Nacos 开源说起

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



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




<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



reference-registry




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



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


从 2018 年 Nacos 开源说起


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


从 2018 年 Nacos 开源说起


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



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




第五步 清理迁移配置



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



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



从 2018 年 Nacos 开源说起


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 实例的服务管理中注册上我们的服务。


从 2018 年 Nacos 开源说起


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


从 2018 年 Nacos 开源说起


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



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




第五步:清理迁移配置



迁移完成后,删除原有的注册中心的配置和迁移过程专用的依赖 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 技术使得您的应用无需修改任何代码和配置,即可享有阿里云提供的微服务治理能力,已经上线的功能包含服务查询、无损下线、服务鉴权、离群实例摘除、标签路由。



从 2018 年 Nacos 开源说起




 动动小手指 了解更多详情 !