1. 前言
服务发现就是服务提供者将自己提供的地址post或者update到服务中介，服务消费者从服务中介那里get自己想要的服务的地址。
但是有两个问题：
第一个问题：如果有一个服务提供者宕机，那么中介的key/value中会有一个不能访问的地址，该怎么办？
心跳机制： 服务提供者需要每隔5秒左右向服务中介汇报存活，服务中介将服务地址和汇报时间记录在zset数据结构的value和score中。服务中介需要每隔10秒左右检查zset数据结构，踢掉汇报时间严重落后的地址。这样就可以保证服务列表中地址的有效性。
第二个问题是服务地址变动时如何通知消费者。有两种解决方案。
第一种是轮询，消费者每隔几秒查询服务列表是否有改变。如果服务地址很多，查询会很慢。这时候可以引入服务版本号机制，给每个服务提供一个版本号，在服务变动时，递增这个版本号。消费者只需要轮询这个版本号的变动即可知道服务列表是否发生了变化。
第二种是采用pubsub。这种方式及时性要明显好于轮询。缺点是每个pubsub都会占用消费者一个线程和一个额外的连接。为了减少对线程和连接的浪费，我们使用单个pubsub广播全局版本号的变动。所谓全局版本号就是任意服务列表发生了变动，这个版本号都会递增。接收到版本变动的消费者再去检查各自的依赖服务列表的版本号是否发生了变动。这种全局版本号也可以用于第一种轮询方案。
CAP理论
CAP理论是分布式架构中重要理论
- 一致性(Consistency) (所有节点在同一时间具有相同的数据)
- 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
- 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
关于P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都取，只能取其中2个。原因是
（1）如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。
（2）如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。
（3）再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了。
2.Consul、zookeeper、etcd、eureka对比结论
平时经常用到的服务发现的产品进行下特性的对比，首先看下结论：
| Feature | Consul | Zookeeper | Etcd | Eureka |
|---|---|---|---|---|
| 服务健康检查 | 服务状态，内存，硬盘等 | (弱)长连接，keepalive | 连接心跳 | 可配支持 |
| 多数据中心 | 支持 | — | — | — |
| kv存储服务 | 支持 | 支持 | 支持 | — |
| 一致性 | raft | paxos | raft | — |
| CAP定理 | CA | CP | CP | AP |
| 使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http（sidecar） |
| watch支持 | 全量/支持long polling | 支持 | 支持 long polling | 支持 long polling/大部分增量 |
| 自身监控 | metrics | — | metrics | metrics |
| 安全 | acl /https | acl | https支持（弱） | — |
| Spring Cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
补充：
（1）运维和开发如果是 Java 更熟，也更多 Java 的应用，那毫无疑问应该用 ZK；如果是搞 Go 的，那么还是 etcd 吧，毕竟有时候遇到问题还是要看源码的。
（2）在创建一百万个或更多键时，etcd可以比Zookeeper或Consul稳定地提供更好的吞吐量和延迟。此外，它实现了这一目标，只有一半的内存，显示出更高的效率。但是，还有一些改进的余地，Zookeeper设法通过etcd提供更好的最小延迟，代价是不可预测的平均延迟。
（3）
一致性协议： etcd 使用 Raft 协议，Zookeeper 使用 ZAB（类PAXOS协议），前者容易理解，方便工程实现；
运维方面：etcd 方便运维，Zookeeper 难以运维；
数据存储：etcd 多版本并发控制（MVCC）数据模型 ， 支持查询先前版本的键值对
项目活跃度：etcd 社区与开发活跃，Zookeeper 感觉已经快死了；
API：etcd 提供 HTTP+JSON, gRPC 接口，跨平台跨语言，Zookeeper 需要使用其客户端；
访问安全方面：etcd 支持 HTTPS 访问，Zookeeper 在这方面缺失；
3. 主流注册中心产品
3.1 Apache Zookeeper -> CP
与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。
从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。
当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。
但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。
因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。
当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。
3.2 Spring Cloud Eureka -> AP
Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则。Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。
Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。
在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。
当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。
默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。
当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。
Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。
3.3 Consul
Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。
Consul采用主从模式的设计，使得集群的数量可以大规模扩展，集群间通过RPC的方式调用(HTTP和DNS)。
Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。
Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
默认依赖于SDK
Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。
Consul Template
Consul，默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零侵入性。
所幸通过Consul Template，可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。
Consul强一致性(C)带来的是：
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性：
服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。
3.4 etcd
etcd是一个采用http协议的分布式键值对存储系统，因其易用，简单。很多系统都采用或支持etcd作为服务发现的一部分，比如kubernetes。但正事因为其只是一个存储系统，如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。
比如配合etcd、Registrator、confd组合，就能搭建一个非常简单而强大的服务发现框架。但这种搭建操作就稍微麻烦了点，尤其是相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。
etcd 比较多的应用场景是用于服务发现，服务发现 (Service Discovery) 要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。和 Zookeeper 类似，etcd 有很多使用场景，包括：
配置管理
服务注册发现
选主
应用调度
分布式队列
分布式锁
按照官网给出的数据， 在 2CPU，1.8G 内存，SSD 磁盘这样的配置下，单节点的写性能可以达到 16K QPS, 而先写后读也能达到12K QPS。这个性能还是相当可观。
etcd 提供了 etcdctl 命令行工具 和 HTTP API 两种交互方法。etcdctl命令行工具用 go 语言编写，也是对 HTTP API 的封装，日常使用起来也更容易。所以这里我们主要使用 etcdctl 命令行工具演示。
4. 参考
（1）注册中心ZooKeeper、Eureka、Consul 、Nacos对比
https://zhuanlan.zhihu.com/p/165217227?utm_source=wechat_session
（2）常用的服务发现对比（Consul、zookeeper、etcd、eureka）
https://blog.csdn.net/gaohe7091/article/details/101197107