Eureka 服务注册与发现

什么是服务注册与发现

Eureka采用了CS的设计架构，Eureka Server作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行。

在服务注册与发现中，有一个注册中心。当服务启动的时候，会把当前自己服务器的信息，比如服务地址通讯地址等以别名方式注册到注册中心上。另一方(消费者|服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用RPC远程电泳框架核心思想；在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系（服务治理概念）。在任何RPC远程框架中，都会有一个注册中心（存放服务地址相关信息【接口地址】）

Eureka两个组件

EurekaServer

提供服务注册服务，各个微服务节点通过配置启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看见。

EurekaClient

通过注册中心访问，是一个JAVA客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期30秒）。如果EurekaServer在多个心跳周期内没有收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）。

Eureka集群原理

Remote CallGet RegistryRegister/Renew/CancelServiceProviders服务提供者1服务提供者2服务提供者3EurekaServerCluster节点1节点2节点3消费者

Q:微服务RPC远程服务调用最核心的是什么？

A:高可用，试想注册中心只有一个，一旦它出故障会导致整个服务环境不可用，所以解决办法是：搭建Eureka注册中心集群，实现负载均衡+故障容错。

所以Eureka集群原理一句话说就是互相注册，相互守望。

自我保护模式

主要用于一组客户端和EurekaServer之间存在网络分区场景下的保护。

一旦进入保护模式，EurekaServer将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。

如果在EurekaServer的首页看到以下提示则说明Eureka进入了保护模式：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认时间是90秒）。但是当网络分区发生故障（延迟，卡顿，拥挤）时，微服务与EurekaServer之间无法发送正常的心跳包，以上行为可能变的危险了【因为微服务本身是健康的，此时本不应该注销这个服务。】Eureka通过“自我保护模式”来解决这个问题。（当EurekaServer节点在短时间内丢失过多客户端时【可能时网络问题导致】），那么就会进入自我保护模式。
自我保护机制：默认情况下EurekaClient定时向EurekaServer端发送心跳包，如果Eureka在servert端在一定时间内（默认90秒）没有收到EurekaClient发送心跳包，便会直接从服务注册列表中剔除该服务，但是在短时间(90秒中)内丢失了大量的服务实例心跳，这时候EurekaServer会开启自我保护机制，不会剔除该服务（该现象可能出现在如果网络不通但是EurekaClient为出现宕机，此时如果换做别的注册中心如果一定时间内没有收到心跳会将剔除该服务，这样就出现了严重失误，因为客户端还能正常发送心跳，只是网络延迟问题，而保护机制是为了解决此问题而产生的)

在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。

它的设计理念就是宁可保留错误的注册信息，也不盲目注销任何可能健康的服务实例。

总结：自我保护模式是一种应对网络异常的安全保护措施。它的设计理念就是宁可同时保留所有微服务（包括健康以及不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以使得Eureka集群更加的健壮、稳定。

为什么会产生Eureka自我保护机制

为了当EurekaClient可以正常运行，但是与EurekaServer网络暂时不通的情况下，EurekaServer不会立刻将EurekaClient服务剔除。

怎么禁止自我保护模式

eureka:
  server:
    enable-self-preservation: false               #关闭自我保护模式
    eviction-interval-timer-in-ms: 2000           #没有收到心跳后删除注册信息的时间，单位是毫秒（默认是90秒）
  instance:
    lease-expiration-duration-in-seconds: 1       #Eureka客户端向服务端发送心跳的时间间隔,单位是秒(默认是30秒)
    lease-expiration-duration-in-seconds: 2       #EurekaServer在收到最后一次心跳后的等待时间的上限,单位是秒(默认是90秒),超时将剔除服务

CAP

  • C：Consistency（强一致性）
  • A：Availability（可用性）
  • P：Partition（分区容错性）

经典CAP图

CAP最好能同时较好的满足两个。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，因此，根据CAP原理将NOSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三个大类：

  1. CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
  2. CP：满足一致性，分区容错性的系统，通常性能不是特别高。
  3. AP：满足可用性，分区容错性的系统，通常对一致性要求低一些。

CAP

Eureka,Zookeeper,Consul的异同点

名称 语言 CAP 服务健康检查 对外暴露接口 SpringCloud集成
Eureka JAVA AP 可配支持 HTTP 已集成
Consul GO CP 支持 HTTP/DNS 已集成
Zookeeper JAVA CP 支持 客户端 已集成

AP【Eureka】

AP架构

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

结论：违背了一致性C的要求，只满足可用性和分区容错，即AP。

cluster数据同步失败请求返回x=1系统B/x=1系统A/x=2用户
  1. 当没有出网络分区时，系统A与系统B的数据一致，X=1。
  2. 将系统A的X修改为2，X=2。
  3. 当出现网络分区后，系统A与系统B之间的数据同步数据失败，系统B的X=1。
  4. 当客户端请求系统B时，为了保证可用性，此时系统B应返回旧值，X=1。

CP【Consul/Zookeeper】

CP架构

当网络分区出现后，为了保证一致性，系统B就必须拒绝请求，否则就无法保证一致性

结论：违背了可用性A的要求，只满足一致性和分区容错，即CP。

Clusters数据同步失败请求error系统B/x=1系统A/x=2用户
  1. 当没有出网络分区时，系统A与系统B的数据一致，X=1。
  2. 将系统A的X修改为2，X=2。
  3. 当出现网络分区后，系统A与系统B之间的数据同步数据失败，系统B的X=1。
  4. 当客户端请求系统B时，为了保证一致性，此时系统B应拒绝服务请求，返回错误码或错误信息。