Spring Cloud 服务发现模块如何选择？ 原

目前可选择的主要有：Eureka、Zookeeper、Consule、以及Nacos

Eureka:

• 优点:
  1. SpringCloud 官方推荐方案
  2. CAP理论，AP模型，数据最终一致
  3. 使用简单，开箱即用，控制台管理
• 缺点:
  1. 弱一致性，服务不能及时更新
  2. 单一调度更新，客户端的轮询增加服务器压力
  3. 广播式的复制，增加服务器压力
• 试用场景:
  1. 对服务器一致性要求不是特别高，对可用性要求比较高的时候

Zookeeper:

• 优点:
  1. 成熟的协调系统，好多框架经过验证
  2. CAP理论,CP模型，ZAB算法实现强数据一致性
• 缺点:
  1. 维护成本
  2. 伸缩性限制
  3. 强一致带来的可用性问题，leader失效或者半数节点处故障时无法提供服务
• 试用场景:
  1. 感觉可以作为对，Eureka的一种补充方案，规模较小的时候可以单独使用，一般dubbo搭配zookeeper使用

Consule:

• 优点:
  1. 通用方案适用于 Service Mesh、Java 生态，提供服务发现和服务配置等
  2. CAP理论,CP 模型，Raft+Gossip算法
• 缺点:
  1. 可靠性无法保证未经过大规模验证
  2. 非 Java 生态维护和问题排查困难
• 试用场景:
  1. 目前社区较为活跃，如果有CP的需要，可以尝试一下

Nacos:

• 优点:
  1. Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理
• 缺点:
  1. 社区热度不够，依然存在bug
• 试用场景:
  1. 新技术尝鲜挑战

总结： 如果你没有强一致性的需求，比如金融类，在你不知道该怎么选的时候，那别选了就先用，Eureka吧！！原因它够成熟，在你一定规模之前足够了，等你的规模大到不够了的时候，你也该知道选别的开源方案还是自己制造。未来的话，可能看好Consul和Nacos，都属于多功能集成的开源项目。

网络来源对比图：

下图：Consule AP 个人认为是错误的，应该为CP ，参考官方说法的话 https://cloud.spring.io/spring-cloud-consul/reference/html/#spring-cloud-consul-discovery

Service Discovery is one of the key tenets of a microservice based architecture. Trying to hand configure each client or some form of convention can be very difficult to do and can be very brittle. Consul provides Service Discovery services via an HTTP API and DNS. Spring Cloud Consul leverages the HTTP API for service registration and discovery. This does not prevent non-Spring Cloud applications from leveraging the DNS interface. Consul Agents servers are run in a cluster that communicates via a gossip protocol and uses the Raft consensus protocol.