SpringCloud入门教程 (二) 服务治理Eureka简述

前言

什么是Eureka

需要对服务治理的核心概念有一定的了解，参考：SpringCloud入门教程 (一) 服务治理核心组件介绍

1. 基于CS的设计架构
2. 具有独特的自我保护模式
3. 基于CAP理论中的AP实现高可用
4. Spring Cloud Eureka使用的是Netflix Eureka来实现服务的注册与发现，它既包含了服务端组件又包含了客户端组件。
5. 服务端组件和客户端组件均由Java编写，故Eureka主要适用于通过Java编写的分布式系统或是与JVM兼容构建的系统。

一、EureKa组件介绍

1.1 Eureka Server 服务端

Eureka Server服务端：也称为服务注册中心，同其他注册中心一样支持高可用配置，不同可用区域的服务注册中心可以通过异步模式相互复制各自的状态，这意味着在给定的时间点每个实例关于所有服务的状态是有细微差别的。

1.2 Eureka Client 客户端

1. 主要处理服务的注册与发现
2. 客户端通过注解和参数配置的形式嵌入进客户端代码中，当程序启动时，Eureka客户端向注册中心注册自身的服务并周期性的向服务端发送心跳来更新其的服务租约（默认周期30s）。如果Eureka Server在多个心跳周期内（默认90s）都没有收到某个节点的心跳，在关闭自保护模式的情况下，Eureka将会从服务注册列表中移除这个节点。如果开启了自我保护模式需要根据短时间的瘫痪率选择是否保留还是剔除。
3. 对于Eureka Client端也能从服务端查询当前服务中心已经注册的信息，并缓存在本地，周期性的进行刷新服务状态信息。通过@EnableDiscoveryClient注解激活Eureka中的DiscoveryClient实现（自动化配置，创建DiscoveryClient接口针对Eureka客户端的EurekaDiscoveryClient实例），实现服务发现功能。
4. 从Spring Cloud Edgware开始，@EnableDiscoveryClient 或@EnableEurekaClient 可省略。只需加上相关依赖，并进行相应配置，即可将微服务注册到服务发现组件上。
5. TIPS：上述图示的消费端也是客户端的一种

二、Eureka Server的高可用实现

原因：防止服务端单点故障
思想：将自己作为服务向其他服务注册中心注册自己，实现相互注册的注册中心，实现服务清单列表的相互同步，达到高可用的效果。

eureka:
  client:         
    service-url:
      # 注册中心Server将自身注入到另一个Server中
      defaultZone: http://address:${port}/eureka/

三、服务治理机制（细分）

简述：上述图示的消费端和服务提供者都是客户端的表现形式，以下将从服务注册到开始服务调用涉及的三端进行详解，并阐述其调用的通信行为。

3.1服务提供者Service Provider

3.1.1 服务注册

前提：该服务位于Eureka Client端，需要开启register-with-eureka: true，否则不会启动注册操作，默认集成SpringBoot配置为true，可写可不写。

1. 服务提供者在启动的时候会通过Rest请求的方式将自己注册到EurekaServer上，同时携带自身服务的一些元数据信息。
2. Eureka Server在接收到这个Rest请求之后，将元数据信息存储在Map集合中，其中key是对应的服务名称spring.application.name（故，不同的服务需要以别名区分不能重复），Ribbon实现负载均衡就是通过这么实现的，以服务名称调用该服务下的多个实例。

3.1.2 服务同步

场景：假设服务名称为A，其有两个服务实例A1和A2，Eureka Server也已集群的方式部署分别为B1和B2，B1和B2之间相互注册，相互守望。A1和A2分别注册到了不同的服务注册中心上B1和B2，即被不同的注册中心所维护。

问题：如何保证两个服务提供者A1和A2分服务信息通过两台服务注册中心中的任意一台获取到？
答：由于服务注册中心之间相互注册为服务，当服务提供者发送请求到一个服务注册中心时，其会将请求转发到给集群中的相连的其他注册中心，从而实现服务注册中心之间的服务同步。

3.1.3 服务续约

概念：在完成服务注册进入Eureka Server之后，服务提供者会维持一个心跳用来告知EurekaServer“当前服务还活着”，以防止Eureka Server将该服务实例从服务列表中剔除。

配置：

properties	说明
lease-expiration-duration-in-seconds：90	定义服务失效时间，默认90s
lease-renewal-interval-in-seconds: 30	定义服务续约任务的调用间隔时间，默认30s

Tips：注意Eureka的自我保护机制，
当关闭时，90s内未收到服务续约的信息将会剔除该服务。
当开启时：只有短时间内大面积XXX

eureka:
  instance:
    instance-id: payment8001
    prefer-ip-address: true
    lease-renewal-interval-in-seconds: 30
    lease-expiration-duration-in-seconds: 90

3.2 服务消费者 Service Consumer

3.2.1获取服务

依赖于服务治理框架下运作，此时服务之间的调用不再通过指定具体的实例地址实现，而是通过配置的服务名发起请求调用实现。

服务调用方（消费者）在调用服务（生产者）提供的接口时并不知道具体的服务实例位置。

具体服务治理信息可参考：SpringCloud从入门到精通教程（一）- 服务的注册与发现(Eureka)
前提：获取服务是服务消费者基础，所以必须确保fetch-registry为true，才能从注册中心检索服务，默认值即为true
registry-fetch-interval-seconds: 30 默认值30s，如果希望修改缓存清单更新时间可以设置该参数。

eureka:
  client:
    # 是否从EurekaServer抓取已有的EurekaServer的信息，单节点无所谓，集群必须为true，配合Ribbon负载均衡使用
    fetch-registry: true
    registry-fetch-interval-seconds: 30

流程分析：

1. 当我们启动服务消费者的时候，依托于注册中心配置的server的url信息，会发起一次Rest请求给服务注册中心，获取上面注册的服务清单。出于性能考虑，EurekaServer会维护一份只读的服务清单返回给客户端，同时该缓存清单会每隔30s更新一次。
2. 疑问：调用的时候发起Rest请求还是实际调用的时候才会获取？如果注册进入EurekaServer，但是每隔30s刷新一次会不会存在延迟情况还是请求就会刷新，缓存清单含义？？

3.2.2 服务调用

服务消费者获取清单之后，通过服务名称便可以获取具体的服务实例信息。因为有这些元数据信息，所以客户端可以根据自己的需求去调用哪个实例，具体参考Ribbon。

简述：当Ribbon和Eureka联合使用时，Ribbon的服务实例清单会被重写，扩展成从Eureka注册中心获取服务列表。可以理解为，在Eureka服务发现的基础上实现了一套对服务实例的选择的策略，从而实现服务消费。

服务调用的选择策略（参考Ribbon）
对于访问实例的选择，Eureka默认机架优先，再去选择负载均衡策略，具体信息参考Eureka的Region和Zone设计，优先访问同处一个Zone中的服务提供方。

3.2.3 服务下线

场景：系统运行过程中，当某个服务实例进行了重启或者关闭，我们不希望客户端继续调用已经关闭了的实例。

问题：如何实时更新服务清单列表？
当某个服务实例关闭之后，其会触发一个服务下线的Rest请求给EurekaServer，告知服务注册中心“我要下线了”，服务端接收到请求之后，会将该服务设置为下线状态，并把给事件传播出去。

问题：服务下线和服务续约的关系
参考：https://www.cnblogs.com/yangxiaohui227/p/12604172.html

3.3 服务注册中心 Eureka Server

3.3.1 失效剔除

当服务实例并不是正常下线，可能由于内存溢出或者网络故障等原因导致某些服务实例无法正常工作，而服务注册中心并未收到服务下线的请求。

为了从服务队列中将这些无法提供服务的实例剔除，EurekaServer会在启动的时候创建一个定时任务，默认60s，将当前清单中90s内没有进行服务续约的服务剔除。

注意：服务续约客户端默认30s发送一次心跳，如果客户端发出了心跳，但是由于网络原因，服务端90s内都没收到就会将该服务从可用服务列表中剔除。

3.3.2 自我保护

Eureka Server会在运行期间统计心跳失败比例在15分钟之内是否低于85%，如果出现低于Eureka Server会将这些实例注册信息保护起来，让这些实例不会过期（即使一部分已经不可用），故会造成一种情况，在这段保护期间内如果实例出现问题，那么客户端很容易拿到已经不存在的服务实例，出现调用失败的情况。

问题：如何解决？
客户端需要有服务容错的机制，请求重试或者断路器等机制，参考Hysrix

如何关闭注册中心的保护机制？
答：在Eureka Server端配置 enable-self-preservation: false，默认为true。在开发期间可以关闭保护机制，确保注册中心将不可用的实例剔除。

eureka:
  server:
    enable-self-preservation: false

四、源码分析

4.1 待进行Debug分析

五、总结

• 在Eureka服务治理体系中，主要分为服务端和客户端两个不同的角色，服务端为注册中心，而客户端为各个提供接口的微服务应用。
• 当我们构建了高可用的注册中心时，该集群中所有微服务应用（不仅仅是业务类才可以视为微服务）和一些基础类应用（配置中心、API网关等）都可以视作是该体系下的一个微服务。
• 对于服务端注册中心往往作为一个现成的产品，无需过多配置，例如EurekaServer又或者Nacos等
• 整体来说，我们将SpringBoot应用注册到注册中心，无疑只做了两件事：

1. 配置自身服务信息（元数据信息及服务名称等，实例名称等）
2. 配置注册中心信息（如何将服务入驻注册中心，地址信息等）

• 调用服务信息时也只是基于Ribbon基于Restful风格调用而已
• 待续补充