注册中心开源方案选型

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、各注册中心特性对比

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

  实践中，在 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://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
 
如有不对，烦请指出，感谢~