-
注册中心是 CP 还是 AP 系统 Eureka作为AP更适合服务注册中心;当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪; Eureka 如果有节点挂掉, 剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中 -
当下,云部署服务越来越流行,出现网络分隔的情况变多(不同子网的网络互相不通信);但是Eureka可以在自己独自子网继续提供服务
-
注册中心不能因为自身的任何原因破坏服务之间本身的可连通性,这是注册中心设计应该遵循的铁律
-
当数据中心服务规模超过一定数量 (服务规模=F{服务pub数,服务sub数}),作为注册中心的 ZooKeeper 很快就会像下图的驴子一样不堪重负
-
注册中心需要持久存储和事务日志 服务调用并不关注注册中心的本身节点的变化情况;只想关注提供服务的节点的一些元数据(比如中心标识、路由等)
-
健康检查,并不只是tcp链接的互通检查,真正关注的是服务的有效性
-
注册中心的容灾考虑 服务调用(请求响应流)链路应该是弱依赖注册中心,必须仅在服务发布,机器上下线,服务扩缩容等必要时才依赖注册中心
-
zookeeper种种坑 难以掌握的Client/Session状态机
Eureka 比 zookeeper 更适合服务注册中心
最新推荐文章于 2021-07-24 22:04:40 发布