wangjie_fourth

may the force be with you

0%

Eureka的使用与总结

发表于 更新于 分类于
本文字数： 4.3k 阅读时长 ≈ 4 分钟

背景

什么是Eureka

Eureka是Netflix使用java语言开发、最初基于AWS的一款客户端服务发现框架，后来被SpringCloud将其作为自己的子项目spring-cloud-netflix。
Eureka是属于系统架构的中间层部分，它目的是解决微服务中服务发现、负载均衡等问题。它通过引入心跳检查、客户端缓存、自我保护等机制，确保了系统的高可用性、可伸缩性和灵活性。

为什么需要Eureka

服务多实例

后端服务通常要保证高可用性，一个服务可能会有多个实例。很难通过传统的根据ip + 端口号这种方式来完成方法调用。

弹性要求

假设某个服务功能只在特定时刻流量才会特别大，这时候只想在那个时刻加大这个服务的实例，过了这个时刻就削减这个服务的实例。此时，这个服务的实例是动态变化的。同上，很难通过传统的根据ip + 端口号这种方式来完成方法调用。

服务所在容器动态变化

假设你在的公司足够大，想用一些ip动态匹配自己的某些服务器。也就是说这些服务所在的服务器的ip可能是动态变化的。同上，很难通过传统的根据ip + 端口号这种方式来完成方法调用。

开发困难

其实如果你公司研发比较小的话，完全不用服务发现组件也是能完成日常开发的。比如说我现在所在的公司，每个服务的实例数量都是固定的，其实例所在的服务器也是不变的。这样的话，你完全可以借助nginx来完成。但是麻烦的是，你每套环境的nginx都需要单独配置，其配置文件还需要特殊维护。

Eureka

Region、Availability Zone

背景

Region、Availability Zone是AWS提出的俩个概念。

  • Region: 不同的地理位置，如：华东地区、华北地区；
  • Availability Zone: 可用空间，可以理解成某个地区的某个机房；

这俩个概念是针对应用发布时，新请求如何转发的问题。比如说像amazon这样全世界范围的电商网站，如果它需要进行服务发版时，希望外部请求旧系统的请求落到旧系统上，外部请求新系统的请求落到新系统上，以保证请求的准确性。

Eureka的实现

Eureka内部也实现了Region、Availability Zone概念，并做了以下规定：

  • 每个Region有一个Eureka Server集群，每一个Availability Zone至少要有一个Eureka Server；
  • 各个Region彼此完全隔离，彼此内网不通，即：每个Region只能知道自己Region内部的所有服务实例，不知道其他Region服务实例；
  • 每个Region内部的所有Availability Zone之间是可以相互通信的

自我保护机制

背景

Eureka作为服务注册发现组件，很核心的一点就是要保证高可用性。因为一旦服务注册发现组件挂了，整个后端基本上就全挂了。
自我保护机制正是一种针对网络异常波动的安全保护措施，使用自我保护模式可以使得Eureka集群更加的健壮、稳定的运行。当一个EurekaServer监测到大于预期数量的已注册客户端以非正常方式终止其连接，并且同时正在等待在服务注册表中删除时，该Eureka Server将进入自我保护机制，以确保灾难性网络事件不会消除eureka注册表数据，并将其传播到下游所有客户端中。

具体过程

自我保护机制的工作机制是如果在15分钟内超过15%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况：

  • Eureka Server不再从注册表中移除因为长时间没有收到心跳而应该过期的服务；
  • Eureka Server仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上，保证当前节点依然可用
  • 当网络稳定时，当前Eureka Server新的注册信息会被同步到其他节点中

因为Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况就会导致整个集群不可用而变成瘫痪。
Eureka自我保护机制，通过配置eureka.server.enable-self-preservation控制自我保护机制，默认打开状态，建议生产环境打开此配置。启动自我保留的默认阙值是当前服务注册表大小的15%

举个例子

1、正常情况下
假设你部署了一个Eureka Server双节点集群，并且有5个服务实例都向Eureka Server1注册，并且向同等peer节点Eureka Server2复制当前注册信息。

2、触发自我保护机制
由于网络问题，实例4、5发送的续租renew请求无法正常发送到Eureka Server1节点。Eureka Server1认为这俩个服务下线了，并向peer节点和下面的实例同步了这一消息。
Eureka Server1又发现，此时下线实例数高于15%的客户端，此时Eureka Server1将进入自我保护机制。也就是后面再有服务接收不到心跳时，它也不从服务注册表删除该服务。

3、自我保护机制后的运行
此时，实例3即使真正的下线了，Eureka Server1也不会从服务注册表删除该实例。也就是说Eureka Server2和其他实例仍认为该实例3是健康的。

客户端缓存机制

健康检查机制

Eureka服务器不会向其注册的客户端发送保持活动请求，以了解他们是否处于活动状态，而是通过Eureka客户端向Eureka服务器发送心跳以便保持其状态。

工作流程

图中仅表示一个Region，us-east-1c、us-east-1d、us-east-1e表示一个Availability Zone

  • Application Service：服务提供者
  • Application Client：服务消费者
  • Make Remote Call：调用RESTful API

Eureka Server服务启动

Eureka Server可以单节点部署，也可以集群部署。它是用于收集各个服务实例的注册信息（例如：IP、端口、服务名称等），Eureka Server将这些信息存储起来，这些存储的信息就是服务注册表。
需要注意的是，一个AZ内的服务实例只向该AZ内的Eureka Server注册信息。如果Eureka Server是集群部署的话，每个AZ的Eureka Server会将自己的服务注册表信息同步到其他Eureka Server实例上。

replicate: 增量复制服务注册信息；单独Zone的服务只向该Zone的Eureka Server发送注册信息，其他Zone服务想知道服务信息，就得从对应Zone的Eureka Server拷贝数据

Eureka Client客户端注册

一个服务在启动后，会向对应的Eureka Server发送注册请求；随后会周期性(默认30秒)的向Eureka Server发送心跳以续约自己的“租期”。

Eureka Client也会定时从Eureka Sever获取服务注册表信息，并将其缓存。这种机制就是客户端缓存机制。优点在于服务不需要每次向Server获取服务注册表，减轻Server端压力，并且也加快了服务端访问的速度。缺点就是数据一致性得不到保障，但这一点对于服务调用来说并不是非常致命的。

Eureka Server检查服务状态

Eureka Server内部会定时检查服务注册表内的服务有没有发送心跳，如果没有，将会注销该服务实例。（默认90秒）
Eureka Server可以集群部署，默认保证在90秒内，Eureka Server集群内的所有实例中数据达到一致。从这一点看，Eureka Server实例的角色都是一致的，不存在主从关系。这一点，跟Zookeeper就不一样。

Eureka 官方将Eureka Server集群中的所有实例称为peer

Eureka Client下线服务

Eureka协议要求客户端在永久离开时执行显示取消注册操作。例如，在提供的java客户端通过shutdown()方法完成。任何连续3次心跳续订失败的客户端也会被认为是不正当的终止，并将被后台进程从服务注册表中移除。

源码分析

1、服务注册表的实现
PeerAwareInstanceRegistryImpl中的

1
2
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
            = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

2、服务注册流程

  • 客户端：DiscoveryClient#register
  • 服务端：PeerAwareInstanceRegistryImpl#register

3、服务续租流程

  • 客户端：DiscoveryClient#renew
  • 服务端：PeerAwareInstanceRegistryImpl#renew

    客户端心跳线程：DiscoveryClient#initScheduledTasks、HeartbeatThread

4、服务剔除流程
内部检查客户端续约情况的：AbstractInstanceRegistry#evictionTimer、deltaRetentionTimer

5、客户端获取服务端中服务注册表信息
DiscoveryClient#getAndStoreFullRegistry

相面面试题

1、Eureka和Zookeeper比较

https://github.com/Netflix/eureka/
https://juejin.im/post/6844903928178409479
https://nobodyiam.com/2016/06/25/dive-into-eureka/
https://www.fangzhipeng.com/springcloud/2017/08/11/eureka-resources.html
https://blog.csdn.net/u012105931/article/details/104659073
https://www.cnblogs.com/nhdlb/p/12968814.html

  • 背景：
    1、什么是Eureka？
    2、为什么需要Eureka？它解决了什么问题？

  • 具体介绍Eureka
    1、Region、Availability Zone
    2、自我保护机制
    3、健康检查机制
    4、具体工作流程

  • 集群启动

  • 一个小项目的使用
    1、小示例
    2、配置相关参数介绍

  • 源码分析
    1、注册中心的启动
    2、客户端发送心跳、注册、续租

  • 相关面试题