JavaEE 框架篇四 SpringCloud_javaee架构集成eureka-CSDN博客

Eureka是Netflix出品的用于实现服务注册和发现的工具。SpringCloud继承了Eureka，并提供了开箱即用的支持。其中Eureka又可细分为EurekaServer和EurekaClient。
Spring Cloud封装了Netiflix公司开发的Eureka模块来实现服务注册和发现（请对比zookeeper：https://blog.csdn.net/qq_40629687/article/details/119799215）。
Eureka采用了C-S的设计架构。EurekaServer作为服务注册功能的服务器，它是服务注册中心。而系统中的其它微服务，使用Eureka的客户端连接到Eureka Server 并维持心跳连接，这样系统的维护人员就可以通过Eureka Server来发现系统中的其它微服务，并执行相关的逻辑

Eureka包含两个组件：Eureka Server 和Eureka Client
- Eureka Server提供服务注册服务，各个节点启动后会在EurekaServer中进行注册，这样EurekaServer中的服务注册中心就会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
- EurekaClient是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内么以偶接收到某个节点的心跳，Eureka Server将会从服务注册中心把这个服务节点移除（默认90秒）

集群基本原理

上图是来自 eureka 的官方架构图，这是基于集群配置的 eureka；
- - 处于不同节点的 eureka 通过 Replicate 进行数据同步
- - Application Service 为服务提供者
- - Application Client 为服务消费者
- - Make Remote Call 完成一次服务调用
服务启动后向 Eureka 注册，Eureka Server 会将注册信息向其他 Eureka Server 进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
当服务注册中心 Eureka Server 检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN 状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。服务提供者在启动后，周期性（默认 30 秒）向 Eureka Server 发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认 90 秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

Eureka 的自我保护机制

在默认配置中，Eureka Server 在默认 90s 没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server 注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。
- 为了解决这个问题，Eureka 有自我保护机制，通过在 Eureka Server 配置如下参数，可启动保护机制 eureka.server.enable-self-preservation=true
  - 它的原理是，当 Eureka Server 节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。自我保护模式的架构哲学是宁可放过一个，决不可错杀一千，好死不如赖活着

Eureka 和 Zookeeper 比较

CAP 理论的核心
- 一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求。因此，根据CAP 原理将 NOSQL 数据分成了 CA 原则、CP 原则、AP 原则三大类：
  - CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不强
  - CP：满足一致性，分区容错性的系统，通常性能不够高
  - AP：满足可用性，分区容错性的系统，通常可能对一致性的要求低一些

CAP 原则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在 A 和 C之间进行权衡。在此 Zookeeper 保证的是 CP（CP：满足一致性，分区容错性的系统，通常性能不够高）, 而 Eureka 则是 AP（AP：满足可用性，分区容错性的系统，通常可能对一致性的要求低一些）。
总体区别
- Zookeeper 保证的是 CP, 而 Eureka 则是 AP Eureka 作为单纯的服务注册中心来说要比zookeeper 更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。不过 Eureka 目前 1.X 版本的实现是基于 servlet 的 Javaweb 应用，它的极限性能肯定会受到影响。期待正在开发之中的 2.X版本能够从 servlet 中独立出来成为单独可部署执行的服务。

Zookeeper 保证 CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
- CP：满足一致性，分区容错性的系统，通常性能不够高

Eureka 保证 AP

Eureka 看明白了这一点，因此在设计时就优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85%的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：1. Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper 那样使整个注册服务瘫痪。
- AP：满足可用性，分区容错性的系统，通常可能对一致性的要求低一些

Ribbon 和 Feign 的区别

Ribbom和Feign都是用于调用其它服务的，不过方式不同
- Ribbon添加maven依赖spring-starter-robbon使用@RibbonClient（value="服务名称"），使用RestTemplate调用远程服务对应的方法
- feign添加maven依赖spring-starter-feign服务提供对外接口调用方在接口上使用@FeignClient("指定服务名")
- 服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法中使用@FeignClient声明

springcloud 断路器的作用

当一个服务调用另一个服务由于网络原因或者自身原因出现问题时调用者就会等待被调用者的响应当更多的服务请求到这些资源时导致更多的请求等待，这样就会发生连锁反应（雪崩效应），短路器就是解决这一问题
- 短路器有完全打开状态
  - 一定时间内，达到一定的次数无法调用，并且多次尖刺没有恢复迹象，断路器完全打开，name下次请求就不会请求到该服务
- 短路器有半开状态
  - 短时间内，有恢复迹象，断路器就会将部分请求发给该服务，当能正常调用时，断路器关闭
- 断路器有关闭状态
  - 当服务一直处于正常状态，能正常调用，断路器关闭

API 网关

API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式【外观模式】很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的 API Gateway。

API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway，然后路由这些，请求到对应的微服务。API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。他可以在web协议与内部使用的非Web友好型协议间进行转换，如HTTP协议、WebSocket协议。
- 响应合并：把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务
- 协议转换：重点是支持SOAP,JMS,Rest间的协议转换
- 数据转换：重点是支持SML和Json之间的报文格式转换能力
- 安全认证：
  - 1.基于Token的客户端访问控制和安全策略
  - 2.传输数据和报文加密，到服务端解密，需要在客户端独立的SDK代理包
  - 3.基于Https的传输加密，客户端和服务端数字证书支持
  - 4.基于OAuth2.0的服务安全认证（授权码，客户端，密码模式等）

配置中心

配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问
zookeeper 配置中心
- 采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。

SpringCloud Config
- SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

服务熔断（Hystrix）

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应，服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用，并将不可用逐渐放大的过程。
熔断器的原理很简单，如同电力过载保护器。他可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作

Hystrix 断路器机制

Hystrix 断路器很好理解，当Hystrix 断路器机制 Command请求后端服务失败数量超过一定比例（默认50%），断路器会切换到开路状态（Open）。这时所有请求会直接失败而不会发送到后端服务，断路器保持在开路状态一段时间后（默认5秒），自动切换到半开路状态（HALF-OPEN）.这时会判断下一次请求的返回情况，如果请求成功，断路器切回闭路状态（CLOSED）.否则重新切换到开路状态（OPEN）.Hystrix 的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求，影响系统吞吐量，并且断路器有自我检测并恢复的能力