eureka架构设计

1. 服务注册中心

1.1 服务注册中心的概念

image.png

微服务服务注册中心核心功能就是存储各个服务和节点的元数据信息,同时对外提供服务数据的访问,同时提供给其他微服务核心组件使用, 并保证自身数据的高可用性和数据的一致性

1.2 AP和CP的模型选择

1.2.1 当服务注册中心故障时AP与CP模型的处理机制

image.png

当serviceA需要从服务注册中心拉取调用服务serviceB的服务信息时,如果当前服务注册中心发生故障,则AP和CP模型的处理方案如下:

AP模型: 返回当前的服务注册信息

CP模型: 拒绝返回任何数据,断开链接,等待集群恢复

1.2.2 微服务中client端的容错机制

image.png

在微服务中通常在我们的client端都会拥有一些容错机制,以应对分布式环境下服务调用失败的情况,所以这种环境下,如果我们本地的服务节点包含失效的节点,也可以在客户端自动进行重试来完成服务的成功调用

1.3 Eureka的架构概览

image.png

从eureka官方的架构图中我们可以看出,eureka的核心架构主要分为两部分:

eureka-server: 提供服务的注册、心跳管理、服务注册信息的获取,同时在集群内部进行数据的同步

eureka-client: 提供给应用服务,想eureka server进行服务信息的注册和拉取

2. Eureka的核心设计

2.1 eureka的数据复制架构

2.1.1 常见的数据复制架构

image.png

比较经典的数据架构是Master-slave架构,由一个主节点进行数据的接收用户请求,并且将数据复制给slave节点, slave节点可以提供数据的读服务,数据库就是经典的Master/slave架构

Peer to Peer(对等模式)架构,每个节点都是都是一个数据的服务端,可以独立的对外提供数据的读写服务,同时在集群内部节点之间相互传递自己接收到的数据,最终整个集群内部的所有节点数据达到一个最终的一致性

2.1.2 架构模式的对比


Master/SlavePeer to Peer
性能
扩展性写低读高
一致性
容错性
健壮性

上面指标的高低,主要是相对于在注册中心整个场景下,并非适用于所有场景

P2P模式因为集群内部所有节点均可写入,所以在性能、扩展性、容错性、健壮性几个角度相对于Master/slave架构比较高,但是在数据的一致性上相对较低, Master/slave架构只需要由Master将数据传递给slave即可,而P2P模式下,则需要双向同步,所以相对低一些

2.1.3 Eureka的数据复制模式

image.png

eureka采用P2P模式进行服务注册信息的复制,eureka client可以向集群内部的任意一个节点进行自身服务信息的注册,同时通过建立的链接来进行服务注册信息的拉取,如果eureka server节点发生故障, 则eureka client可以从集群剩余节点选择一个eureka server节点进行服务的注册和拉取

image.png

eureka server集群之间通过将向自己注册的服务节点请求同步给集群中的其他节点,同时接受集群中其他节点的同步信息,来进行数据的复制

2.2 数据一致性

2.2.1 Eureka server集群的数据一致性

image.png

eureka采用P2P的数据复制模式,每个节点都接受请求同时将数据分发给集群的其他节点,从而达到集群数据的最终一致性

为了达到最终一致性eureka server主要采用心跳和过期同步机制实现

心跳机制:eureka client不断向eureka server发送自己的注册信息,从而最终可以达到一致性

过期同步:eureka server如果发现集群中其他节点发送的信息过期,则就拒绝对应的修改,同时要求对应的eureka server节点来拉取自己的最新信息,从而达到最终一致性

2.2.2 eureka client与server的一致性

image.png

eureka server和client之间的数据一致性主要考全量和增量拉取来进行保证

增量拉取:

1.eureka client定期从eureka server进行数据的拉取

2.在拉取的过程中eureka server会返回当前注册信息的一个hash值, client应用差异信息

3.eureka client通过计算hash值进行对比,如果发现hash值与eureka server的服务注册信息的hash值不同, 则进行全量拉取

全量拉取: eureka server返回全量的服务注册信息

2.3 基于云化的设计

2.3.1 region和zone的设计

image.png

在架构设计中大部分人都听过一个词叫做容灾,但是在云下环境下,由于IDC和硬件的成本,通常也没多少公司做的起,而在云的环境中按需付费的特点,则天然适合这种场景

eureka则基于aws云的环境设计了region和zone两个概念

region:区域,通常比作北京或者上海某个区域的数据中心

zone: zone则是对应数据中心下的一个具体的机房

image.png

基于这种特点,我们可以按照region和zone进行服务注册的划分,eureka会优先链接自己最适配的,比如位于zone1区域的client就链接zone1下的eureka server, 只有当整个zone下的eureka server不可用时,才链接其他的zone

我们可以基于这种分层设计, 来进行服务注册中心的分级设计,按照数据中心,机房来进行eureka server集群节点的部署

2.4 服务节点注册与发现

2.4.1 通信机制 

image.png

eureka的client与server之间直接通过http进行通信, 同时eureka server自身也相当于一个client端,通过这个client端进行集群其他节点服务注册信息的拉取

2.4.2 服务节点注册

image.png

服务节点的注册主要由eureka client完成, 主要分为两部分:

1.eureka client通过向eureka server发送服务信息(http请求)来完成节点的注册

2.eureka cleint定期向eurkea server发送心跳信息(http请求)来完成心跳的续约

eureka server则后台会启动一个定时任务,定期检测自己维护的服务的注册信息,如果未能接收到client发送到心跳信息, 则进行对应节点的摘除操作

2.5 自我保护

image.png

如果当eureka server和client之间发生网络分区的情况下,则eureka server无法接收到eureka client的信息,就会将对应的节点从注册表中删除,这会严重影响eureka server的Availability,eureka设计了一种一种保护的机制来应对这种情况

image.png

eureka server会定时计算接收到的心跳信息和服务注册信息,计算百分比,同时与设定阈值进行对比,如果超过阈值,则关闭定时检测,不再进行注册表的删除,等待系统恢复

原创文章,作者:baxiaoshi,如若转载,请注明出处:http://www.sreguide.com/%e5%88%86%e5%b8%83%e5%bc%8f/eureka%e6%9e%b6%e6%9e%84%e8%ae%be%e8%ae%a1.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

QQ: 52866169