简洁 网站模板,wordpress ddns,厦门一个平台做网站啥的,福建祥盛建设有限公司网站2018 年夏天
国内微服务开源 领域#xff0c;迎来了一位新成员。此后#xff0c;在构建微服务注册中心和配置中心的过程中#xff0c;国内开发者多了一个可信赖的选项。
Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台(官方网站)…
2018 年夏天
国内微服务开源 领域迎来了一位新成员。此后在构建微服务注册中心和配置中心的过程中国内开发者多了一个可信赖的选项。
Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台(官方网站)它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践可以用在微服务场景作为服务注册中心、配置中心等核心场景中和阿里的其他微服务开源项目一样Nacos 也是始于阿里成长于社区的典型。
为什么要开源 Nacos
在大规模服务发现和服务治理领域现有的开源解决方案并非已经非常完美阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中积累了大量有关服务注册和服务配置的实践经验而这些经验是可以在各个行业大规模复用。除此之外更重要的是希望和社区开发者共同发展让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。
相比其他服务注册和配置中心开源方案Nacos 的起步虽然晚了点但除了注册和配置中心的功能外他还提供了动态服务发现、服务共享与管理的功能在大规模场景下具备更优秀的性能在易用性上更便捷分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比内容摘自《主流微服务注册中心浅析和对比》 NacosConsulEurekaZookeeper一致性协议CPAPCPAPCP健康检查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统计不支持提供TPSQPS监控视图运维集群观测无页面可视化查看节点健康状态角色 监控图表无提供多种指标如Znode链接数图形化视图 配置运维手动修改手动重启页面修改一键重启生效 节点伸缩手动扩缩容手动重启页面选择一键扩缩容 性能伸缩不支持页面选择一键伸缩
从了解到实践
Dubbo 应用如何保证业务不停机的情况下无缝迁移到MSE 下面以基于 SpringBoot 构建的 Dubbo 应用为例介绍如何进行迁移
第一步引入用于迁移的定制化注册中心依赖
虽然 Dubbo 本身提供了配置多注册中心的能力但其存在比较大的局限性当消费者配置多注册中心时Dubbo 原有的策略为优先选取第一个注册中心的地址若其地址为空再读取第二个依次类推选取地址。理想的模型应当是多个注册中心的地址合并后随机选取为此MSE 提供了专门的注册中心扩展解决该问题
dependencygroupIdcom.alibaba.edas/groupIdartifactIdedas-dubbo-migration-bom/artifactIdversion2.6.5.1/versiontypepom/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-registryconsul://${consulAddress}:8500,nacos://${nacosAddress}:8848reference-registryconsul://${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 依赖。
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactIdversion{相应的版本}/version/dependency默认情况下 Spring Cloud 只支持在依赖中引入一个注册中心当存在多个注册中心时启动会报错。所以这里需要添加一个依赖 edas-sc-migration-starter使 Spring Cloud 应用支持多注册。
dependencygroupIdcom.alibaba.edas/groupIdartifactIdedas-sc-migration-starter/artifactIdversion1.0.2/version/dependencyRibbon 是实现负载均衡的组件为了使应用可以支持从多个注册中心订阅服务需要修改 Ribbon 配置。在应用启动的主类中将 RibbonClients 默认配置为 MigrationRibbonConfiguration 。假设原有的应用主类启动代码如下
SpringBootApplicationpublic class ConsumerApplication {public static void main(String[] args) {SpringApplication.run(ConsumerApplication.class, args);}}那么修改后的应用主类启动代码如下
SpringBootApplicationRibbonClients(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.subscribesnacos,consul # 同时从 Consul 和 Nacos 订阅服务
spring.cloud.edas.migration.subscribesnacos # 只从 Nacos 订阅服务动态变更服务注册默认的注册策略是注册到所有注册中心。您可以通过在您的配置中心的 spring.cloud.edas.migration.registry.excludes 属性来选择关闭指定的注册中心。
spring.cloud.edas.migration.registry.excludes #默认值为空注册到所有的服务注册中心
spring.cloud.edas.migration.registry.excludesconsul #关闭 Consul 的注册
spring.cloud.edas.migration.registry.excludesnacos,consul #关闭 Nacos 和 Consul 的注册阿里云微服务引擎 MSE 重磅升级发布会即将开启
抛开担忧迎接确性。
从配置中心到微服务全面治理MSE 正在迎接他的第一个成人礼在原有配置中心托管的基础上全面升级引入微服务治理能力并通过 Java Agent 技术使得您的应用无需修改任何代码和配置即可享有阿里云提供的微服务治理能力已经上线的功能包含服务查询、无损下线、服务鉴权、离群实例摘除、标签路由。
原文链接 本文为云栖社区原创内容未经允许不得转载。
