1.服务发现框架
| 框架 | CAP | 协议 | 语言 | 依赖环境 | 集成方式 |
|---|---|---|---|---|---|
| zk | CP | Paxos(ZAB) | Java | JVM | Clients use language specific bindings |
| Doozer | CP | Paxos | Go | ||
| Etcd | Raft | Go | Clients use language specific bindings/ HTTP | ||
| Eureka | AP | Java | JVM | Java Client，其他语言要SideCar方式或 REST api | |
| Consul | CA | Raft | Go |
2.区别
2.1 zk
通过ZAB选举出一个leader，写信息时只向这个leader写入，leader同步到其他followers，即保证数据的一致性。
Service registration: 通过 watch 机制，client 去写临时节点，client失效或失去连接时，自动删除这个临时节点
Service discovery: client 获取zk上的临时节点，client自己处理 load balance 和 failover
network partition、脑裂等 问题
zk zab协议，解决了分布式系统下数据在多个服务之间保持同步。
CP,没有A，不能保证每次服务请求的可用性，作为分布式协同服务，zk很好，当zk不可用时（网络等原因），做为 Service Discovery不合适
当network partition时，nodes数量没有达到zk规定的leader选举的数量，会从zk中断开，就不能做为提供 Service Discovery功能
2.2 Etcd
Service registration: service 利用 key 的 TTL 及心跳来确认这个 key 仍然可用。
如果 service 更新 key 的 TTL 失败，Etcd 会对它过期处理。service 变的不可用时，client 需要自己处理连接失败和重试其他服务实例
Service discovery: 服务发现涉及一个目录下所有的 keys 列表，等待这个目录下的变动。因为基于 HTTP API，client 应用与 etcd 集群之间保持 long-polling 连接
利用 Raft 选举出一个leader，所有的客户端请求和处理都是靠这个 leader
2.3 Eureka
Service registration: Eureka client注册服务、定期发送心跳去renew租约
Service discovery: Eureka client 从Eureka server获取当前注册的服务信息，并缓存在本地。Eureka client定期刷新这些信息，同时处理 load balance和failover
没有leader选举，节点宕机自动切换到其他eureka节点，宕机的机器恢复后通过同步服务信息的方式加入到eureka集群
network partition时，每个eureka持续对外提供服务（zk不会），在单个partition中照样可以提供 Service Discovery功能
网友评论