微服务【SpringCloud】成长之路（二）【Eureka】_eureka 实现流量染色

微服务【SpringCloud】成长之路（二）【Eureka】

官网地址：https://docs.spring.io/spring-cloud-netflix/docs/current/reference/html/#configuration-properties

• Eureka包含两个组件：Eureka Server和Eureka Client。
• Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
• Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
• 在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
• Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

自我保护机制

自我保护模式是一种应对网络异常的安全保护措施，健康的微服务和不健康的微服务都会保留，也不注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定

默认情况下，如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，以上行为可能变得非常危险了。微服务本身其实是健康的，此时本不应该注销这个微服务。

自我保护模式：当Eureka Server节点在短时间内丢失过多客户端时可能发生了网络故障，进入自我保护模式。一旦该模式启动，Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据不会注销任何微服务。网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

Eureka’s Health Checks 健康检查

默认情况下，Eureka 使用客户端心跳来确定客户端是否已启动。除非另有说明，否则 Discovery Client 不会根据 Spring Boot Actuator 传播应用程序的当前健康检查状态。因此，在成功注册后，Eureka 总是宣布应用程序处于“UP”状态。这种行为可以通过启用 Eureka 健康检查来改变，这会导致将应用程序状态传播到 Eureka。因此，其他所有应用程序都不会向处于“UP”以外的状态的应用程序发送流量。以下示例显示了如何为客户端启用健康检查：
application.yml

eureka:
  client:
    healthcheck:
      enabled: true
1
2
3
4

application.yml

eureka:
  instance:
    statusPageUrl: https://${eureka.hostname}/info
    healthCheckUrl: https://${eureka.hostname}/health
    homePageUrl: https://${eureka.hostname}/
1
2
3
4
5

Eureka Metadata for Instances and Clients 元数据

对于主机名、IP 地址、端口号、状态页面和健康检查等信息，有标准的元数据。这些在服务注册表中发布，并由客户端用于以直接的方式联系服务。可以将其他元数据添加到 中的实例注册中eureka.instance.metadataMap，并且可以在远程客户端中访问此元数据。通常，附加元数据不会改变客户端的行为，除非客户端知道元数据的含义。
application.yml

eureka:
  instance:
    hostname:  
    nonSecurePort:  
1
2
3
4

Using the EurekaClient 使用客户端

一旦您拥有作为发现客户端的应用程序，您就可以使用它从Eureka Server发现服务实例。一种方法是使用本机com.netflix.discovery.EurekaClient（而不是 Spring Cloud DiscoveryClient）

@Autowired
private EurekaClient discoveryClient;

public String serviceUrl() {
    InstanceInfo instance = discoveryClient.getNextServerFromEureka("STORES", false);
    return instance.getHomePageUrl();
}
1
2
3
4
5
6
7

可以使用org.springframework.cloud.client.discovery.DiscoveryClient，它为发现客户端提供了一个简单的 API（并非特定于 Netflix）

@Autowired
private DiscoveryClient discoveryClient;

public String serviceUrl() {
    List<ServiceInstance> list = discoveryClient.getInstances("STORES");
    if (list != null && list.size() > 0 ) {
        return list.get(0).getUri();
    }
    return null;
}
1
2
3
4
5
6
7
8
9
10

注册服务为啥这么慢

作为一个实例还涉及到注册表的周期性心跳（通过客户端的serviceUrl），默认持续时间为 30 秒。在实例、服务器和客户端在其本地缓存中都具有相同的元数据之前，客户端无法发现服务（因此可能需要 3 个心跳）。您可以通过设置更改周期eureka.instance.leaseRenewalIntervalInSeconds。将其设置为小于 30 的值可加快使客户端连接到其他服务的过程。在生产中，最好坚持使用默认值，因为服务器中的内部计算会对租约续订期做出假设。

Refreshing Eureka Clients 刷新Eureka客户端

默认情况下，EurekaClientbean 是可刷新的，这意味着 Eureka 客户端属性可以更改和刷新。当刷新发生时，客户端将从 Eureka 服务器注销，并且可能有一小段时间给定服务的所有实例都不可用。避免这种情况发生的一种方法是禁用刷新 Eureka 客户端的功能。eureka.client.refresh.enable=false

Eureka Server

High Availability, Zones and Regions 高可用

Eureka 服务器没有后端存储，但注册中心中的服务实例都必须发送心跳以保持其注册最新（因此这可以在内存中完成）。客户端还有一个 Eureka 注册的内存缓存（因此他们不必为每个服务请求都去注册中心）。

默认情况下，每个 Eureka 服务器也是 Eureka 客户端，并且需要（至少一个）服务 URL 来定位对等方。

application.yml (Two Peer Aware Eureka Servers)

---
spring:
  profiles: peer1
eureka:
  instance:
    hostname: peer1
  client:
    serviceUrl:
      defaultZone: https://peer2/eureka/

---
spring:
  profiles: peer2
eureka:
  instance:
    hostname: peer2
  client:
    serviceUrl:
      defaultZone: https://peer1/eureka/
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

在前面的示例中，我们有一个 YAML 文件，可用于通过在不同的 Spring 配置文件中运行它来在两个主机（peer1和peer2）上运行相同的服务器。您可以使用此配置通过操作/etc/hosts解析主机名来测试单个主机上的对等感知（在生产中这样做没有太大价值）。事实上，eureka.instance.hostname如果您在知道自己主机名的机器上运行，则不需要 。默认情况下，使用 查找它java.net.InetAddress。

您可以将多个对等点添加到系统中，并且只要它们都通过至少一个边缘相互连接，它们就会在它们之间同步注册。您可以将多个对等点添加到系统中，只要它们都直接相互连接，它们就会在它们之间同步注册。

application.yml (Three Peer Aware Eureka Servers)

eureka:
  client:
    serviceUrl:
      defaultZone: https://peer1/eureka/,http://peer2/eureka/,http://peer3/eureka/

---
spring:
  profiles: peer1
eureka:
  instance:
    hostname: peer1

---
spring:
  profiles: peer2
eureka:
  instance:
    hostname: peer2

---
spring:
  profiles: peer3
eureka:
  instance:
    hostname: peer3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

在某些情况下，Eureka 更喜欢通告服务的 IP 地址而不是主机名。
设置主机名的唯一显式方法是设置eureka.instance.hostname属性。您可以在运行时使用环境变量设置您的主机名 - 例如，eureka.instance.hostname=${HOST_NAME}.

拓展

CAP

CAP原则又称CAP定理:
指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：保证每个请求不管成功或者失败都有响应。
分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
*BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
例如：
ZooKeeper 基于 CP，不能保证高可用，Eureka 基于AP，能保证高可用。
待续