Eureka和Consul的区别

Eureka

1. client默认每隔30s发送请求给server，拉取最新的注册表
2. client默认每隔30s发送心跳给server，证明自己还活着
3. server定时检测默认超过90s，client没有发送心跳更新时间，则认为client挂了

拉取注册表：

1. 维护和拉取注册表、更新心跳时间，都是发生在内存里
2. 具体拉取时基于多级缓存来拿数据，这样可以减少并发读写冲突，且进一步提高服务响应
3. 先从 ReadOnlyCacheMap 查缓存的注册表；若没有，就找ReadWriteCacheMap 缓存的注册表；若没有，就从内存中获取当前注册表数据
4. 在注册表发生变更时，先更新内存中的注册表数据，同时过期掉ReadWriteCacheMap 的数据。此过程不会影响ReadOnlyCacheMap提供数据，过程默认持续30s。之后后台线程发现ReadWriteCacheMap 已清空，也会清空ReadOnlyCacheMap的缓存数据。下次获取则从内存中拿，同时填充到2个缓存中

Consul

1. 基于Consul作为服务注册中心，需要在每个服务器部署一个Consul Agent，作为一个服务所在机器的代理
2. 在多台机器上部署Consul Server，作为核心的服务注册中心
3. 由Consul Agent收集服务信息发送给Consul Server进行注册，同时由Consul Agent转发请求给Consul Server获取其他服务信息
4. Consul Server之间会自动实现数据同步，而且Consul Server集群会自动选举一个为Leader
5. 各个服务发送的注册请求都会落地给 Leader，由 Leader 同步给其他 Follower
6. 各个服务之间的查询也会通过Leader获取，这样就保持了数据的强一致性
7. Consul 会基于 Raft 协议来解决Leader数据与Follower之间的可能发生的数据不一致。Raft 协议要求服务注册到Leader上时，Leader把这条注册信息复制给大部分的Follower才算成功。这样只要注册成功，即使当前Leader宕机，新选举出的Leader上也会有这个注册信息
8. Eureka的心跳机制会给Server造成很大的压力。Consul Agent会不断发送请求检查服务器的健康情况，若服务宕机则通知Consul Server，这种方式大幅度减轻了Server的压力