## **一、Eureka 详解** **\*\*是什么\*\* ：**         Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。 **\*\*有什么\*\* ：** Eureka 主要包含了 Eureka Server和Eureka Client 两个组件。 **\*\*基本原理\*\* ：** Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。         Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就是一个内置的、使用默认为轮询(round-robin)负载算法的负载均衡器ribon。 在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个服务节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。         Eureka Server集群之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。         综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。 **ps:原理图如下**  针对原理图说明： **1.注册、更新（续约）、取消服务：** 注册： 客户端充当服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表。 更新（续约）： 客户端充当服务提供者默认会每隔 30 秒（可设置）发送一次心跳来续约。 通过续约来告知 服务端注册中心（Eureka Server） 该 客户端（Eureka Client）的服务是否 运行正常。 扩展： 默认情况下，若服务端注册中心（Eureka Server） 在 90 秒内 没有收到 客户端（Eureka Client）的续约，服务端注册中心会将客户端实例从其注册表中删除（服务剔除），此时间可配置，一般情况不建议更改。 Eureka自我保护模式： 为了防止误杀服务，Eureka Server 在运行期间因网络问题或服务状态等原因在统计心跳失败比例在 15 分钟之内低于 85%，即固定时间内大量实例被注销（删除/下线）则会启动自我保护模式，提高微服务架构的高可用性。但自我保护模式开启后会存在以下的问题： (1 Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 (2 Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用 (3 当网络稳定时，当前实例新的注册信息会被同步到其它节点中 如果在保护期内刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，即会调用失败。对于这个问题需要服务消费者端要有一些容错机制，如重试，断路器等。 取消： 客户端（Eureka Client）的服务要关闭时，需通过主动方式向注册中心发送取消注册信息的请求进行服务下线，即需在程序中添加以下代码：DiscoveryManager.getInstance().shutdownComponent()；。 **2.更新非己服务列表信息：** 客户端（Eureka Client）从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 客户端（Eureka Client） 的缓存信息不同， 客户端（Eureka Client）自动处理。 如果由于某种原因导致注册列表信息不能及时匹配， 客户端（Eureka Client）则会重新获取整个注册表信息。 服务端注册中心（Eureka Server） 的缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。 客户端（Eureka Client）和 （Eureka Server）可以使用 JSON/XML 格式进行通讯。在默认情况下 客户端（Eureka Client）使用压缩 JSON 格式来获取注册列表的信息。 **3.集群节点之间数据信息同步：** 服务端注册中心（Eureka Server） 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。 Eureka集群扩展： 如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它 Eureka Server 当前所知的所有节点中。 另外 Eureka Server 的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。所以，如果存在多个节点，只需要将节点之间两两连接起来形成通路，那么其它注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client，多个 Eureka Server 之间通过 P2P 的方式完成服务注册表的同步。 Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。 Eureka 提供了 Region 和 Zone 两个概念来进行分区，这两个概念均来自于亚马逊的 AWS: region：可以理解为地理上的不同区域，比如亚洲地区，中国区或者深圳等等。没有具体大小的限制。根据项目具体的情况，可以自行合理划分 region。 zone：可以简单理解为 region 内的具体机房，比如说 region 划分为深圳，然后深圳有两个机房，就可以在此 region 之下划分出 zone1、zone2 两个 zone。 如下图中的 us-east-1c、us-east-1d、us-east-1e 就代表了不同的 Zone。Zone 内的 Eureka Client 优先和 Zone 内的 Eureka Server 进行心跳同步，同样调用端优先在 Zone 内的 Eureka Server 获取服务列表，当 Zone 内的 Eureka Server 挂掉之后，才会从别的 Zone 中获取信息。  **4.调用服务：**         充当服务消费者的客户端会定时从注册中心中拉取，更新及缓存服务信息列表，当消费者需调用某个服务的时候，则从服务信息列表中获取相服务的相关信息，比如IP，端口等。 ## **二、Eureka 工作流程总结** 1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息 2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务 3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常 4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例 5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端 6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式 7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地 8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存 9、Eureka Client 获取到目标服务器信息，发起服务调用 10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除