在传统应用中,组件之间的调用,通过有规范的约束的接口来实现,从而实现不同模块间良好的协作。但是被拆分成微服务后,每个微服务实例的网络地址都可能动态变化,数量也会变化,使得原来硬编码的地址失去了作用。需要一个中心化的组件来进行服务的登记和管理。
一、eureka
1、本质:存储了每个客户端的注册信息。EurekaClient从EurekaServer同步获取服务注册列表。通过一定的规则选择一个服务进行调用。
2、Eureka构架图
3、详解
服务提供者:是一个Eureka Cient,向Eureka Server注册和更新自己的信息,同时能从Eureka Server注册表中获取到其他服务的信息。
服务注册中心:提供服务注册和发现的功能。每个Eureka Cient向Eureka Server注册自己的信息,也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。
服务消费者:是一个Eureka Client,通过Eureka Server获取注册到其上其他服务的信息,从而根据信息找到所需的服务发起远程调用。
同步复制:Eureka Server之间注册表信息的同步复制,使Eureka Server集群中不同注册表中服务实例信息保持一致。
远程调用:服务客户端之间的远程调用
注册:Client端向Server端注册自身的元数据以供服务发现。
续约:通过发送心跳到Server以维持和更新注册表中服务实例元数据的有效性。当在一定时长内,Server没有收到Client的心跳信息,将默认服务下线,会把服务实例的信息从注册表中删除。
下线:Client在关闭时主动向Server注销服务实例元数据,这时Client的服务实例数据将从Server的注册表中删除。
获取注册表:Client向Server请求注册表信息,用于服务发现,从而发起服务间远程调用。
4、服务注册与发现包括两部分,一个是服务器端,另一个是客户端。
4.1 Server
Server是一个公共服务,为Client提供服务注册和发现的功能,维护注册到自身的Client的相关信息,同时提供接口给Clinet获取注册表中其他服务的信息,使得动态变化的Client能够进行服务间的相互调用。
-
接受服务注册
-
接受服务心跳
-
服务剔除
-
服务下线
-
集群同步(1.启动时从peer拉取信息,2.将注册到自己的服务同步到peer)
4.2 Client
Client将自己的服务信息通过一定的方式登记到Server上,并在正常范围内维护自己信息一致性,分别其他服务发现自己,同时可以通过Server获取到自己依赖的其他服务信息,完成服务调用,还内置了负载均衡器,用来进行基本的负载均衡。
-
拉取server注册表到本地。
-
注册服务。
-
初始化3个定时任务:心跳续约,定时拉取注册表,按需注(InstanceInfoReplicator#run)。
5、Eureka保证AP
可以通过运行多个Eureka server实例并相互注册的方式实现。Server节点之间会彼此增量地同步信息,从而确保节点中数据一致。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩下的节点依然可以提供注册和查询服务。Eureka的客户端在向莫哥Eureka服务注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就会认为客户端与注册中心出现网络故障,此时会出现以下几种情况:
(1)、Eureka不再注册列表中移除因为长时间没收到心跳而应该过期的服务。
(2)、Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(即保证当前节点依然可用)
(3)、当网络稳定时,当前实例信的注册信息会被同步到其他节点中。
6、Eureka优化
server:
# 自我保护,看服务多少。
enable-self-preservation: false
# 自我保护阈值
renewal-percent-threshold: 0.85
# 剔除服务时间间隔
eviction-interval-timer-in-ms: 1000
# 关闭从readOnly读注册表
use-read-only-response-cache: false
# readWrite 和 readOnly 同步时间间隔。
response-cache-update-interval-ms: 1000
7、zookeeper(保证CP)
zookeeper的设计就是保证数据(配置数据、状态数据)在多个服务系统之间保证一致性,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30到120s,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能勾最终恢复,但是漫长的选举时间导致的注册长期不可用事不能容忍的。