简介
- consul是一个服务发现框架
- 类似的还有zookeeper,eureka,etcd等
作用
- 服务发现(service discovery)
- 健康检查(health checking)
- 配置存储管理(key/value storage)
- 可支持任意数量的区域:multi-datacente
consul与eureka比较
- 最大的区别是Eureka保证AP, Consul为CP
- Consul强一致性(C)带来的是:
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。 - Eureka保证高可用(A)和最终一致性:
服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。 - 服务的健康检查
Euraka 使用时需要显式配置健康检查支持;Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康,而 Consul 相对更为详细点,比如内存是否已使用了90%,文件系统的空间是不是快不足了。 - 多数据中心支持
Consul 通过 WAN 的 Gossip 协议,完成跨数据中心的同步;而且其他的产品则需要额外的开发工作来实现; - KV 存储服务
除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务,所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务,也能够较好的转化为动态配置服务哦。
总结
-
了解有限,笔者想了想连套件eureka都没搞明白呢,而且自觉地分布式服务可靠性比一致性重要点~,虽然Eureka现在还在不断完善中,我还是很看好他的,决定先研究它了
参考博客
https://www.cnblogs.com/xiaohanlin/p/8016803.html
https://blog.csdn.net/ZYC88888/article/details/81453647