赞
踩
在微服务架构中,服务与服务之间存在着相互调用,比如A服务要调用B服务,但是如何拿到B服务的入口呢?这就用到注册中心了,B服务将自己的实例信息注册到注册中心上,然后服务A就去注册中心上获取服务B的信息,就可以调用了。
Zookeeper、Eureka、Consul和 Nacos是常用的管理服务的注册中心,下面我们从CAP角度分别讲一下它们的区别和应用场景。
Consistency(一致性):所有节点同一时间具有相同的数据,对某个客户端而言,读操作能返回最新的写操作。
强一致性:某个节点更新数据,其他节点能够立即读取最新数据。
弱一致性(最终一致性):过一段时间才读取到最新数据。
Availability(可用性):非故障节点在合理的时间返回合理响应。
Partition tolerance(分区容错性):网络分区后,系统可继续工作;
分布式系统中,网络无法保证100%可靠,分区是必然(P)
CP:放弃可用性,追求一致性和分区容错性。因为数据同步会消耗时间,性能就会降低。
AP:放弃强一致性,追求可用性和分区容错性。有一个服务在,就能够正常接收请求,因为在分布式系统中,
支持CP(强一致性和分区容错性);
使用zk获取服务列表时,如果zk集群中的leader宕机(或者半数以上的服务器节点挂掉),就要进行leader的选举,选举期间服务集群瘫痪,所以不能保证服务的可用性;
对于数据存储的场景,数据一致性是首先要保证。
对于服务发现来说,即使注册中心保存的服务提供者的信息不同,也不会有太大问题。
对于服务消费者来说,即使拿到的数据不一定正确,也可以尝试一下,也比无法获取实例信息,系统异常要好(比如淘宝双十一)。
支持AP(可用性和分区容错性);
本质是Servlet程序,跑在Servlet容器中
是一个去中心化的架构,Eureka Server可以运行多个节点来构建集群,解决单点问题,每一个节点都是对等的,节点通过相互注册提高可用性,每个节点需要添加一个或多个有效的serviceUrl指向其他节点,每个节点都可以看作其他节点的副本。
如果Eureka Server宕机,Eureka Client的请求会自动切换到新的Server节点上,宕机的服务器重新恢复后,Eureka会再次将其纳入服务器集群管理中。当节点开始接收客户端请求时,所有的操作都会在每个节点间复制。
当一个新的Eureka Server启动后,首先会从邻近节点获取注册列表信息(getEurekaServiceUrls()方法获取所有节点),并完成初始化,通过心跳机制定期更新数据(默认接收不到节点的心跳超过30s,Server会将该节点注销)。
Eureka集群中,只要有一台节点在,就能保证注册服务可用(保证可用性),但是查到的信息可能不是最新(不保证强一致性)
自我保护机制:15分钟内超过85%的节点都没有正常的心跳,Eureka认为客户端与注册中心出现了网络故障,会出现以下情况:
1.Eureka不再从服务注册表中移除因长时间没有收到心跳而过期的服务;
2.Eureka仍能够新服务的注册和查询请求,但是不会同步到其他节点(即保证当前节点依然可用);
3.当网络稳定时,当前实例新注册的信息会被同步到其他节点;
Eureka可以很好应对网络故障导致部分节点失去联系的情况,不会像Zookeeper一样使整个服务注册瘫痪;
支持CP(强一致性和分区容错性);
是HashiCorp公司推出的开源工具,Go语言编写,用于实现分布式系统的服务发现与配置,具有天然可移植性(支持Windows,Linux,Mac)
内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key-Value存储、多数据中心方案,不需要依赖其他工具,使用方便。
可用性下降:Consul的raft协议要求必须过半数的节点都写入成功才算注册成功,leader挂掉之后,重新选举leader之前,服务不可用。
Consul本质属于应用外的注册方式,但是可以通过SDK简化注册流程,而服务发现默认依赖SDK,但是可以通过Consul Template去除SDK。
Consul Template:
默认服务调用者需要依赖SDK发现服务,这就无法保证对应用的零入侵性。通过Consul Template,可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置,对于服务调用者而言,只需要配置一个统一的服务地址。
阿里开源的,支持基于DNS和RPC的服务发现。
Nacos注册中心支持CP和AP。
支持动态配置服务。
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。