Spring Cloud Eureka(全面解析) 大白话

Eureka大白话解析

笔记补录：

1.Eureka 介绍

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件的一部分，基于 Netflix Eureka 做了二次封装，主要负责实现微服务架构中的服务治理功能。

服务治理是微服务架构中必不可少的一部分，阿里开源的 Dubbo 框架就是针对服务治理的。服务治理必须要有一个注册中心，除了用 Eureka 作为注册中心外，我们还可以使用 Consul、Etcd、Zookeeper 等来作为服务的注册中心。

Eureka 由两部分组成：服务端和客户端，服务端就是注册中心，用来接收其它的服务注册，客户端是一个java客户端，用来注册，并可以实现负载均衡等功能。 Eureka 的搭建和集群请点击查看这篇文章。

Eureka图解如下：

Spring Cloud Eureka(全面解析) 大白话

从图中可以看出Eureka有三个角色：

Eureka Server：注册中心
Eureka Provider：服务提供者
Eureka Consumer：服务消费者

注册中心就是管理所有服务的信息和状态，12306 就好比一个注册中心，顾客就好比调用的客户端，当他们需要坐火车时，就会在 12306 网站上查询余票，有票就可以购买，然后获取火车的车次、时间等，最后出发。程序也是一样，当你需要调用某一个服务的时候，你会先去 Eureka 中去拉取服务列表，查看你调用的服务在不在其中，在的话就拿到服务地址、端口等信息，然后调用。

注册中心带来的好处就是，不需要知道有多少提供方，你只需要关注注册中心即可，就像顾客不必关心有多少火车在开行，只需要去 12306 网站上看有没有票就可以了。

为什么 Eureka 比 Zookeeper 更适合作为注册中心呢？主要是因为 Eureka 是基于 AP 原则构建的，而 ZooKeeper 是基于 CP 原则构建的。在分布式系统领域有个著名的 CAP 定理，即 C 为数据一致性；A 为服务可用性；P 为服务对网络分区故障的容错性。这三个特性在任何分布式系统中都不能同时满足，最多同时满足两个。Zookeeper 有一个 Leader，而且在这个 Leader 无法使用的时候通过 Paxos（ZAB）算法选举出一个新的 Leader。这个 Leader 的任务就是保证写数据的时候只向这个 Leader 写入，Leader 会同步信息到其他节点。通过这个操作就可以保证数据的一致性。

想要保证 AP 就要用 Eureka，想要保证 CP 就要用 Zookeeper。

Dubbo 中大部分都是基于 Zookeeper 作为注册中心的。Spring Cloud 中当然首选 Eureka。

2. Eureka 的工作细节

2.1 Eureka Server

Eureka Server主要对外提供了三个功能：

服务注册，所有的服务都注册到Eureka Server上面来
提供注册表，注册表就是所有注册上来服务的一个列表，Eureka Client在调用服务时，需要获取这个注册表，一般来说，这个注册表会缓存下来，如果缓存失效，则直接获取最新的注册表
同步状态，Eureka Client 通过注册、心跳等机制，和Eureka Server同步当前客户端的状态

2.2 Eureka Client

Eureka Client 主要是来简化每一个服务和Eureka Server 之间的交互。Eureka Client 会自动拉取、更新以及缓存Eureka Server 中的信息，这样，即便Eureka Server 所有节点都宕机，Eureka Client 依然能够获取到想要调服务的地址（但是地址可能不准确）。

2.2.1 服务注册

服务提供者将自己注册到服务注册中心(Eureka Server)，需要注意，所渭的服务提供者，只是一个业务上的划分，本质上他就是一个 Eureka Client 。当 Eureka Client 向 Eureka Server 注册时，他需要提供自身的一些元数据信息，例如IP地址、端囗、名称、运行状态等等。

2.2.2 服务续约

Eureka Client 注册到 Eureka Server 上之后，事情还没有结束，刚刚开始而已。注册成功后，默认情况下，Eureka Client 每隔30秒就要向 Eureka Server 发送一条心跳消息，来告诉Eureka Server 我还在运行。如果 Eureka Server 连续90秒有沿有收到Eureka Client 的续约消息（连续三次没发送），它会认为Eureka Client已经线了，会将掉线的Eureka Client从当前的服务注册列表中剔除。

服务续约，有两个相关的属性（一般不建议修改）：

				?

									# 表示服务的续约时间，默认是30秒

									eureka.instance.lease-renewal-intetval-in-seconds=30 

									# 服务失效时间，默认是90秒

									eureka.instance.lease-expiration-duration-in-seconds=90

2.2.3 服务下线

当 Eureka Client 下线时，它会主动发送一条消息，告诉Eureka Server，我下线了。

2.2.4 获取注册表信息

Eureka Client 从Eureka Server 上获取服务的注册信息，将其缓存在本地。本地客户端在需要调用远程服务时，会从该信息中查找远程服务所对应的IP地址、端囗等信息。Eureka Client 上缓存的服务注册信息会定期更新（30秒)，如果 Eureka Server 返回的注册表信息与本地缓存的注册表信息不同的话，Eureka Client 会自动处理。

这里，也涉及至两个属性，一个是是否允许获取注册表信息：

				?

									eureka.client.fetch-registry=true

Eureka Client 上缓存的服务注册信息，定期更新的时间间隔，默认30秒：

				?

									eureka.client.registry-fetch-interval-seconds=30

Eureka分区策略

第一步：背景和概念介绍

背景：用户量比较大或者用户地理位置分布范围很广的项目，一般都会有多个机房。这个时候如果上线springCloud服务的话，我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用的时候，再去调用其它机房的服务，以达到减少延时的作用。

概念：region：能够简单理解为地理上的分区。好比亚洲地区，或者华北地区，再或者北京地区等等，没有具体大小的限制，根据项目具体的状况，能够自行划分region。 zone：能够简单理解为 region 内的具体机房，好比说 region 划分为华北地区，而后华北地区有两个机房，就能够在此 region 之下划分出 zone1、zone2 两个 zone eureka 也借用了 region 和 zone 的概念架构

Spring Cloud Eureka(全面解析) 大白话

如图所示，有一个 region:华北地区，下面有两个机房，机房A 和机房Burl

每一个机房内有一个 Eureka Server 集群和两个服务提供者 ServiceA 和 ServerB
如今假设 serverA 须要调用 ServerB 服务，按照就近原则，serverA 会优先调用同一个 zone 内的 ServiceB，当 ServiceB 不可用时，才会去调用另外一个 zone 内的 ServiceBcode

第二步：相关参数介绍

服务注册相关:

eureka: client: # 尽可能向同一区域的 eureka 注册,默认为true prefer-same-zone-eureka: true #地区 region: huabei availability-zones: huabei: zone-1,zone-2 service-url: zone-1: http://Eureka的Ip地址:8761/eureka/ zone-2: http://Eureka的Ip地址:8761/eureka/

当存在多个注册中心时，选择逻辑为cdn

若是 prefer-same-zone-eureka 为 false，按照 service-url 下的 list 取第一个注册中心来注册，并和其维持心跳检测，再也不向list内的其它的注册中心注册和维持心跳。server只有在第一个注册失败的状况下，才会依次向其它的注册中心注册，总共重试3次，若是3个service-url都没有注册成功，则注册失败。blog

注册失败后每隔一个心跳时间，会再次尝试。it

若是 prefer-same-zone-eureka 为true，先经过 region 取 availability-zones 内的第一个zone，而后经过这个zone取 service-url 下的list，并向list内的第一个注册中心进行注册和维持心跳，再也不向list内的其它的注册中心注册和维持心跳。只有在第一个注册失败的状况下，才会依次向其它的注册中心注册，总共重试3次，若是3个service-url都没有注册成功，则注册失败。注册失败后每隔一个心跳时间，会再次尝试。

为了保证服务注册到同一个 zone 的注册中心，必定要注意 availability-zones 的顺序，必须把同一 zone 写在最前面

eureka: instance: # 服务和注册中心的心跳间隔时间，默认为30s lease-renewal-interval-in-seconds: 30 # 服务和注册中心的心跳超时时间，默认为90s lease-expiration-duration-in-seconds: 90 metadata-map: # 当前服务所属的 zone zone: zone1

服务消费者和服务提供者分别属于哪一个zone，均是经过 eureka.instance.metadata-map.zone 来断定的。
服务消费者会先经过 ribbon 去注册中心拉取一份服务提供者的列表，而后经过 eureka.instance.metadata-map.zone 指定的 zone 进行过滤，过滤以后若是同一个 zone 内的服务提供者有多个实例，则会轮流调用。
只有在同一个 zone 内的全部服务提供者都不可用时，才会调用其它zone内的服务提供者。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。

原文链接：https://blog.csdn.net/ourstronger/article/details/108721497