Consule作为注册中心配置实例
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Consule作为注册中心配置实例相关的知识,希望对你有一定的参考价值。
参考技术A 上一篇 <<< Eureka的自我保护机制下一篇 >>> Zookeeper作为注册中心配置实例
推荐阅读:
<<< 服务注册、服务发现和服务治理
<<< 服务治理的方式和原理
<<< Nacos的服务手动注册与发现
<<< Nacos整合到SpringCloud中
<<< Eureca作为注册中心配置实例
<<< Eureka的自我保护机制
<<< Zookeeper作为注册中心配置实例
<<< @EnableDiscoveryClient与@EnableEurekaClient区别
<<< Nacos单机环境安装
<<< Nacos集群环境安装
nacos简介以及作为注册/配置中心与Eurekaapollo的选型比较
一、Nacos简介
Nacos是以服务为主要服务对象的中间件,Nacos支持所有主流的服务发现、配置和管理。
Nacos主要提供以下四大功能:
服务发现与服务健康检查
Nacos使服务更容易注册自己并通过DNS或HTTP接口发现其他服务。Nacos还提供服务的实时健康检查,以防止向不健康的主机或服务实例发送请求。
动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序和服务的需要,这使配置更改更加高效和灵活。
动态DNS服务
Nacos支持加权路由,使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡,灵活的路由策略,流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现,并防止应用程序耦合到特定于供应商的服务发现API。
服务和元数据管理
Nacos提供易于使用的服务仪表板,可帮助您管理服务元数据,配置,kubernetes DNS,服务运行状况和指标统计。
1.1 Nacos总体概况
image.png
1.2 Nacos架构
image.png
二、注册中心与配置中心横向对比
2.1 Nacos与eureka注册中心对比
对比项目注册中心 | Spring Cloud Nacos | Spring Cloud Eureka |
---|---|---|
CAP模型 | 支持AP和CP模型 | AP模型 |
客户端更新服务信息 | 使用注册+DNS-f+健康检查模式。DNS-F客户端使用监听模式push/pull拉取更新信息 | 客户端定时轮询服务端获取其他服务ip信息并对比,相比之下服务端压力较大、延迟较大 |
伸缩性 | 使用Raft选举算法性能、可用性、容错性均比较好,新加入节点无需与所有节点互相广播同步信息 | 由于使用广播同步信息,集群超过1000台机器后对eureka集群压力很大 |
健康检查模式/方式 | 支持服务端/客户端/关闭检查模式,检查方式有tcp、http、sql。支持自己构建健康检查器 | 客户端向服务端发送http心跳 |
负载均衡 | 支持 | 支持 |
手动上下线服务方式 | 通过控制台页面和API | 通过调用API |
跨中心同步 | 支持 | 不支持 |
k8s集成 | 支持 | 不支持 |
分组 | Nacos可用根据业务和环境进行分组管理 | 不支持 |
权重 | Nacos默认提供权重设置功能,调整承载流量压力 | 不支持 |
厂商 | 阿里巴巴 | Netflix |
2.2服务配置中心对比
对比项目/配置中心 | apollo | nacos |
---|---|---|
开源时间 | 2016.5 | 2018.6 |
配置实时推送 | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
版本管理 | 自动管理 | 自动管理 |
配置回滚 | 支持 | 支持 |
权限管理 | 支持 | 待支持 |
多集群多环境 | 支持 | 支持 |
监听查询 | 支持 | 支持 |
多语言 | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI |
分布式高可用最小集群数量 | Config2+Admin3+Portal*2+Mysql=8 | Nacos*3+MySql=4 |
配置格式校验 | 支持 | 支持 |
通信协议 | HTTP | HTTP |
数据一致性 | 数据库模拟消息队列,Apollo定时读消息 | HTTP异步通知 |
单机读(tps) | 9000 | 15000 |
单机写(tps) | 1100 | 1800 |
nacos具有Apollo大部分功能,最重要的是配置中心与注册中心打通,可以省去我们在微服务治理方面 的一些投入(比如通过动态配置来启停线程池等操作)。
2.3 初步选型结论
初步结论为:使用Nacos代替Eureka和apollo,主要理由为:
相比与Eureka:
(1)Nacos具备服务优雅上下线和流量管理(API+后台管理页面),而Eureka的后台页面仅供展示,需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看,Nacos整合了注册中心、配置中心功能,把原来两套集群整合成一套,简化了部署维护
(3)从长远来看,Eureka开源工作已停止,后续不再有更新和维护,而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合,填补 2 者的鸿沟,在两套体系下可以采用同一套服务发现和配置管理的解决方案,这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh,是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步,而Eureka不支持,且在伸缩扩容方面,Nacos比Eureka更优(nacos支持大数量级的集群)。
(5)Nacos具有分组隔离功能,一套Nacos集群可以支撑多项目、多环境。
相比于apollo
(1) Nacos部署简化,Nacos整合了注册中心、配置中心功能,且部署相比apollo简单,方便管理和监控。
(2) apollo容器化较困难,Nacos有官网的镜像可以直接部署,总体来说,Nacos比apollo更符合KISS原则
(3)性能方面,Nacos读写tps比apollo稍强一些
结论:使用Nacos代替Eureka和apollo
三、Nacos其他特性
3.1 Nacos Sync的价值
NacosSync是一个支持多种注册中心的同步组件,基于Spring boot开发框架,数据层采用Spring Data JPA,遵循了标准的JPA访问规范,支持多种数据源存储,默认使用Hibernate实现,更加方便的支持表的自动创建更新
使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在3s,8C16G的单机能够支持6K的同步任务
NacosSync除了单机部署,也提供了高可用的集群部署模式,NacosSync是无状态设计,将任务等状态数据迁移到了数据库,使得集群扩展非常方便
抽象出了Sync组件核心接口,通过注解对同步类型进行区分,使得开发者可以很容易的根据自己需求,去扩展不同注册中心,目前已支持的同步类型:
Nacos数据同步到Nacos
Zookeeper数据同步到Nacos
Nacos数据同步到Zookeeper
Eureka数据同步到Nacos
Consul数据同步到Nacos
系统模块架构
image.png
使用场景
多个网络互通的Region之间服务共享,打破Region之间的服务调用限制
image.png
3.2 DNS - F 的技术价值
Nacos提供DNS-F功能
DNS-F落地的技术价值
填补了内部微服务业务没有全局动态调度能力的空白
解决了服务端棉铃挑战:时延大、解析不准、故障牵引慢
支持服务端多种调度需要
加速外部域名解析
服务故障牵引秒级生效
image.png
3.3 目前使用Nacos的公司
阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等
完整列表:https://github.com/alibaba/nacos/issues/273
以上是关于Consule作为注册中心配置实例的主要内容,如果未能解决你的问题,请参考以下文章