Eureka注册中心简介与详解

Eureka注册中心简介与详解

文章目录

• 前言
• 一、Eureka简介
• 二、Eureka详解
• • • 高可用的Eureka
    • Eureka客户端配置
    • • • 服务注册
        • 服务续约
        • 获取服务列表
    • Eureka服务端配置
    • • • 失效剔除
        • 自我保护
        • 测试：

前言

问题：当一个项目中同时有多个微服务，如果出现微服务的地址变更，删除，那么原本消费者那端写死的服务地址就会失效，如果消费者想找一个服务，也是很难找 ，那么这时候就可以将服务注册到Eureka，并可以监控服务，消费者也是到Eureka找对应的服务，相当于多了一个中间人

一、Eureka简介

举个例子：
这就好比是网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息
（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

结合上一个博客：微服务模拟实例 （这里有Eureka的代码实现）
Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
心跳(续约)：提供者定期通过HTTP方式向Eureka刷新自己的状态 ，看提供者是否有宕机

工作原理图：

二、Eureka详解

高可用的Eureka

多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。

所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务进行注册，这样多个EurekaServer之间就能互相发现对方，从而形成集群。

比如现在又两个个Eureka，端口号分别为10086,10087
1、先在Eureka服务的配置文件 register-with-eureka=true和fetch-registry=true（这两个值默认是true，但是如果刚开始的时候设置为false，就要删掉）
2、把service-url的值改成了另外一台EurekaServer的地址，而不是自己

3、客户端注册到服务到Eureka集群
因为EurekaServer不止一个，因此注册服务的时候，service-url参数需要变化：

eureka:client:service-url: # EurekaServer地址,多个地址以','隔开defaultZone: 127.0.0.1:10086/eureka,127.0.0.1:10087/eureka

Eureka客户端配置

服务注册

默认注册时使用的是主机名或者localhost，如果想用ip进行注册，可以在 user-service 中添加配置如下：

eureka:instance:ip-address: 127.0.0.1 # ip地址prefer-ip-address: true # 更倾向于使用ip，而不是host名

服务续约

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉
EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；

eureka:instance:lease-expiration-duration-in-seconds:  5 #服务的失效时间 默认90秒 即连续90秒没有到心跳，就关掉服务,但是由于自我保护机制，不会关掉lease-renewal-interval-in-seconds:  5 #持续间隔，默认30秒

注：这两个值在生产环境不要修改，默认即可。

获取服务列表

当服务消费者启动时，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会从Eureka Server服务的列表拉取只读备份，然后缓存在本地。并且 每隔30秒 会重新拉取并更新数据。可以在 consumer-demo 项目中通过下面的参数来修改：

eureka:
client:
registry-fetch-interval-seconds: 30
#拉取服务地址列表的间隔时间，默认消费者隔30秒到Eureka服务获取新的注册列表

注：生产环境中，我们不需要修改这个值。

Eureka服务端配置

失效剔除

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下线”的请求。 相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间 （默认为60秒）将当前 清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。 可以通过
eureka.server.eviction-interval-timer-in-ms 参数对其进行修改，单位是毫秒。

自我保护

当有续约超时的，回先看最近15分钟有没有超过85%的服务心跳失败，如果是，就不会将当前实例踢出注册列表，认为这是网络故障问题，不是服务本身不发心跳问题。这就是为什么前面说当服务不往注册中心发心跳，且已经过了服务失效时间，在注册中心的列表还是能看到这个服务，这就是因为有自我保护的机制

我们关停一个服务，就会在Eureka面板看到一条警告：

这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%，当EurekaServer节点在短时间内丢失过多客户端（可能发生了网络分区故障）。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。
但是这给我们的开发带来了麻烦， 因此开发阶段我们都会关闭自我保护模式：

eureka:server:enable-self-preservation: false # 关闭自我保护模式（缺省为打开）eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）

测试：

关闭自我保护，启动Eureka和user服务 会显示红色的这段字体，
然后user-service注册在Eureka

然后关闭user-service服务，因为我们设置了 发心跳的时间为5秒，服务失效时间也是5秒，然后那个轮巡的时间也设置了10秒 ，然后又关闭了自我保护即关闭服务10秒后，这个服务就失效了，然后最多只需等10秒，当那个轮巡的任务看到我这个续约失败的服务，就会
在注册列表中剔除我这个服务

这样那个user服务就会剔除注册列表了