注册中心开源方案选型

谬了个大也

已于 2023-08-10 21:35:12 修改

阅读量3k

点赞数 1

分类专栏：解决方案中间件文章标签：注册中心 k8s

于 2022-03-28 23:12:12 首次发布

本文链接：https://blog.csdn.net/my_miuye/article/details/123809103

版权

解决方案同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

中间件

6 篇文章 0 订阅

订阅专栏

1、服务注册中心分类

应用内：直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka，还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制
应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
DNS：将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表

2、CAP理论

CAP理论是分布式架构中重要理论：

一致性(Consistency)：所有节点在同一时间具有相同的数据；
可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。

在分布式系统内，P 是必然的发生的，不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。所以，对于分布式系统，我们只能能考虑当发生分区错误时，如何选择一致性和可用性。

根据一致性和可用性的选择不同，开源的分布式系统往往又被分为 CP 系统和 AP 系统。

当一套系统在发生分区故障后，客户端的任何请求都被卡死或者超时，但是，系统的每个节点总是会返回一致的数据，则这套系统就是 CP 系统，经典的比如 Zookeeper。
如果一套系统发生分区故障后，客户端依然可以访问系统，但是获取的数据有的是新的数据，有的还是老数据，那么这套系统就是 AP 系统，经典的比如 Eureka。

3、各注册中心特性对比

特性	Nacos	Eureka	Consul	ETCD	Zookeeper	CoreDNS
一致性协议	CP+AP	AP	CP	CP	CP	—
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Client Beat	Keep Alive	—
负载均衡策略	权重/ metadata/Selector	Ribbon	Fabio	轮询	-	RoundRobin
雪崩保护	有	有	无	无	无	无
自动注销实例	支持	支持	支持	支持	支持	不支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	HTTP/GRPC	TCP	DNS
监听支持	支持	支持	支持	支持(3.0)	支持	不支持
安全	acl	-	acl / https	https	acl	-
多数据中心	支持	支持	支持	-	不支持	不支持
作为配置中心	支持	不支持	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	-	不支持	不支持
SpringCloud集成	支持	支持	支持	支持	支持	不支持
Dubbo集成	支持	不支持	支持	支持	支持	不支持
K8S集成	支持	不支持	支持	支持	不支持	不支持

其中，- 表示不确定，不是不支持，有知道的大佬可以告知我补充一下！

实践中，在 CAP 的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性

4、各方案说明

Eureka

Eureka 遵循AP原理中的「AP」原则，Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性），当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。

Eureka2.0已经停止维护.

Consul

Consul 遵循CAP原理中的「CP」原则，保证了强一致性和分区容错性。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

Zookeeper

Zookeeper 遵循CAP原理中的「CP」原则，任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的，不能保证服务可用性。

ETCD

ETCD遵循CAP原理中的「CP」原则，在选主完成前会导致服务不可用。

Nacos

Nacos 的注册中心支持 CP 也支持 AP。

参考链接：
https://blog.miuyun.work/archives/14780627
https://glory.blog.csdn.net/article/details/100023415
https://blog.csdn.net/u012921921/article/details/106521181
https://blog.csdn.net/qq_42046105/article/details/123436832
https://blog.csdn.net/weixin_41605937/article/details/121885248

如有不对，烦请指出，感谢~