eureka需要部署服务,服务自身需要做集群,增加了系统部署的复杂性。
各服务之间数据同步是异步的,定时的,这会导致节点间一定时间内,数据不一致;并且,在数据复制的过程中,如果持有新实例注册信息的注册中心自身挂掉了,这个实例就无法得到注册;
注册中心自身如果监测到某个实例的心跳成功比例一定时间内小于一定的阈值,这个实例注册信息会被保护起来,不会注销掉,等到这个心跳成功比例大于阈值时,退出自我保护机制。在这个保护期内,如果服务挂了,那这个实例信息其实时有问题的,应该被剔除。
如果注册中心注册的实例过多,比如500个,每个间隔30s发出一次续约心跳,那30s内,就是15000个心跳连接,这个心跳的请求可能大于实际业务发出的请求。
健康检查比较单一,仅仅检查心跳是不够的,心跳还在,说明服务进程没死,那服务所在的硬件问题如内存满载,关联的db挂了等,这些都无法得到反应,所以服务可能并不能提供服务了,但是服务还在注册中心的列表中。
官方宣布2.0的开源工作停止了,继续使用的责任自负。
java开发,引入依赖多,对于服务器而言太重,部署复杂,不支持多数据中心。对服务侵入大。
检查方式单一,需要消费者自己实现,也是靠心跳连接保活,连接断开,就是服务挂了,服务就会被剔除。
非常稳定,更新少,微服务架构下,对于做专业的注册中心而言,功能匮乏,丧失了快速迭代的能力,不够与时俱进,不够灵活。
paxos算法,复杂难懂。
未使用过,资料了解,其本质上是一个比zk轻量的分布式键值对存储系统,但是需要搭配其他小工具才能较好较易用的实现注册中心功能。但是,为了实现A功能,又额外引入了B和C工具,不是一个优雅的实现方案,而且不支持多数据中心,无web管理页面。
raft算法,实现思路从源头上避免了数据不一致性。注册时,超过半数没有拿到信息,那就注册失败。
集成简单,不依赖其他工具,使用也简单,支持2种服务注册方式:配置文件,http api。
支持和zk和etcd一样的kv存储,可做配置中心。
健康检查支持好,提供多种健康检查功能,比如服务返回的状态码,内存利用率等。
服务状态的检查,不是直接向注册中心发心跳,而是agent向服务发出健康监测。
官方提供良好的web管理页面。
社区很活跃,更新频繁。
这个最近也挺火,待了解。
consul中有个问题,服务异常退出时的服务剔除,这个待研究,还没看到原理讲解。