Spring Cloud服务发现几种方案的比较

一、Spring Cloud服务发现存在的方案

Spring Cloud服务发现存在以下几种方案和策略:
Consul
consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。
Eureka
Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。
Zookeeper
Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
etcd
etcd是一个开源的、分布式的键值对数据存储系统，提供共享配置、服务的注册和发现。内部采用raft协议作为一致性算法，基于Go语言实现。

二、几种服务发现的方案对比

特色	Consul	zookeeper	etcd	euerka
服务健康检查	服务状态、内存、硬盘等	(弱)长连接，keepalive	链接心跳	支持可配置
多数据中心	支持	——	——	——
KV存储服务	支持	支持	支持	——
一致性	raft	paxos	raft	——
cap	ca	cp	cp	ap
使用接口(多语言能力)	支持HTTP和https	客户端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持long polling/大部分增量
自身监控	metrics	——	metrics	metrics
安全	acl/https	acl	https支持（弱）	——
spring cloud集成	支持	支持	支持	支持

• 服务的健康检查
  Euraka使用时需要显式的配置健康检查；Zookeeper，Etcd则在失去了和服务进程的连接情况下任务不健康，而Consul相对更为详细点，比如内存是否使用了90%，文件系统的空间是不是快不足了。
• 多数据中心支持
  Consul通过WAN的Gossip协议，完成跨数据中心的同步；而其它策略则需要额外的开发工作来实现。
• KV存储服务
  除了Eureka，其它几种策略都能够对外支持K-V的存储服务，所以其它几种策略追求高一致性。通过提供存储服务，也能够较好的转化动态配置服务。
• 产品设计中CAP理论的取舍
  Eureka典型的AP，作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次CA类型的场景Consul，也能够提供较高的可用性，并能k-v store服务保证一致性。而Zookeeper，Etcd则是CP类型CP类型，牺牲可用性，在服务发现场景并没有太大优势。
• 多语言能力与对外提供服务的接入协议
  Zookeeper的跨语言支持较弱，其他几款支持http11提供接入的可能。Euraka一般通过sidecar的方式提供多语言客户端的接入支持。Etcd还提供Grpc的支持。Consul除了标准的Rest服务API，还提供了DNS的支持。
• Watch的支持（客户端观察到服务提供者变化）
  Zookeeper支持服务器端推送变化，Eureka2.0也计划支持。Eureka1，consul，Etcd则都通过长轮询的方式来实现变化的感知。
• 安全
  Consul，Zookeeper支持ACL，另外Consul，Etcd支持安全通道https。
• Spring Cloud的集成
  目前都有相对应的boot starter，提供了集成能力。

参考博客

1.微服务之consul（一）
2.Eureka(服务发现框架)百度百科
3.SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka