springcloud eureka

Eureka 是什么？
   Eureka 是Spring Cloud的服务治理组件，有三个核心角色： 服务注册中心、服务提供者、服务消费者。Eureka 主管服务注册中心。 是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于dubbo的注册中心比如Zookeeper。
    Netflix 在设计Eureka 时遵守的就是AP原则（CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得）
    Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。
    系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

Eureka和Zookeeper的区别？

为什么 Eureka 比 Zookeeper 更适合作为注册中心呢？主要是因为 Eureka 是基于 AP 原则构建的，而 ZooKeeper 是基于 CP 原则构建的。

在分布式系统领域有个著名的 CAP 定理，即 C 为数据一致性；A 为服务可用性；P 为服务对网络分区故障的容错性。这三个特性在任何分布式系统中都不能同时满足，最多同时满足两个。

Zookeeper 有一个 Leader，而且在这个 Leader 无法使用的时候通过 Paxos（ZAB）算法选举出一个新的 Leader。这个 Leader 的任务就是保证写数据的时候只向这个 Leader 写入，Leader 会同步信息到其他节点。通过这个操作就可以保证数据的一致性。

总而言之，想要保证 AP 就要用 Eureka，想要保证 CP 就要用 Zookeeper。

Dubbo 中大部分都是基于 Zookeeper 作为注册中心的。Spring Cloud 中当然首选 Eureka。

三、eureka的特性

服务提供者

    “服务提供者” 在启动的时候会通过发送REST请求的方式将自己注册到EurekaServer 上， 同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求之后， 将元数据信息存储在一个双层结构Map中， 其中第一层的key是服务名， 第二层的key是 具体服务的实例名。（我们可以回想一下之前在实现Ribbon负载均衡的例子中， Eureka信 息面板中一个服务有多个实例的清况， 这些内容就是以这样的双层Map形式 存储的。） 在服务注册时， 需要确认一下 eureka.cli ent.register-with-eureka=true 参数是否正确， 该值默认为true。 若设置为false将不会 启动注册操作。
    两个服务提供者分别注册到了两个不同的服务注册中心上， 也就是说， 它们的信息分别被两个服务注册中心所维护。 此时， 由于服务注册中心之间因 互相注册为服务， 当服务提供者发送注册请求到一个服务注册中心时， 它会将该请求转发 给集群中相连的其他注册中心， 从而实现注册中心之间的服务同步 。 通过服务同步，两个 服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到。
    在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活 着 ”， 以防止Eureka Server的 “剔除任务 ” 将该服务实例从服务列表中排除出去，我们称 该操作为服务续约(Renew)。 eureka.instance.lease-renewal-interval-in-seconds 参数用于定义服 务续约任务的调用间隔时间，默认为30秒。 eureka.instance.lease-expiration-duration-in-seconds参数用于定义服务失效的时间，默认为90秒。

服务消费者

    获取服务。 服务注册中心已经注册了 一个服务， 并且该服务有两个实例。 当我们启动 服务消费者的时候， 它会发送一个REST请求给服务注册中心，来获取上面注册的服务清 单 。 为了性能考虑， Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓 存清单会每隔30秒更新 一次。 获取服务是服务消费者的基础，所以必须确保eureka.client.fetch-registry= true参数没有被修改成false, 该值默认为true。若希望修改缓存清单的 更新时间，可 以通过 eureka.client.registry-fetch-interval-seconds= 30参数进行修改， 该参数默认值为30, 单位为秒。
    服务调用。服务消费者在 获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例 的元数据信息。 因为有这些服务实例的详细信息， 所以客户端可以根据自己的需要决定具 体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均 衡。
    服务下线。在系统运行过程中必然会面临关闭或重启服务的某个实例的情况， 在服务关闭期间， 我们自然不希望客户端会继续调用关闭了的实例。 所以在客户端程序中， 当服务实例进行 正常的关闭操作时， 它会触发一个服务下线的 REST请求给Eureka Server, 告诉服务注册 中心：“我要下线了” 。 服务端在接收到请求之后， 将该服务状态置为下线(DOWN), 并把 该下线事件传播出去。

服务注册中心

    失效剔除。 有些时候， 我们的服务实例并不一定会正常下线， 可能由于内存溢出、 网络故障等原 因使得服务不能正常工作， 而服务注册中心并未收到 “服务下线” 的请求。 为了从服务列 表中将这些无法提供服务的实例剔除， Eureka Server在启动的时候会创建一个定时任务， 默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔 除出去。
    自我保护。Eureka Server 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%, 如果出现低于的情况（在 单机调试的时候很容易满足， 实际在生产环境上通常是由于网络不稳定导致）， Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期， 尽可能保护这些注册信 息。 但是， 在这段保护期间内实例若出现问题， 那么客户端很容易拿到实际已经不存在的 服务实例， 会出现调用失败的清况， 所以客户端必须要有容错机制， 比如可以使用请求重 试、 断路器等机制。 由于本地调试很容易触发注册中心的保护机制， 这会使得注册中心维护的服务实例不 那么准确。 所以， 我们在本地进行开发的时候， 可以使用 eureka.server.enable-self-preservation=false 参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。

Eureka 包含两个组件：Eureka Server和Eureka Client

    Eureka Server 提供服务注册服务

    各个节点启动后，会在EurekaServer 中进行注册，这样EurekaServer 中的服务注册表建辉存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到

    Eureka Client Java客户端

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

Eureka 自我保护机制

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式。

某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存
 四、eureka的原理及流程

Eureka作为分布式系统的注册中心，主要作用是用于服务治理，Eureka分为Eureka Server和Eureka Client。
（1）Eureka Server—注册中心服务端：服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会在服务注册表中存储该服务的信息。服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表。
（2）Eureka Client—注册中心客户端：Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。
（3）服务注册后，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。
（4）微服务默认每30秒，就会从eureka服务端获取一次最新的服务列表。如果某台微服务down机，或者添加了几台机器，此时eureka server会通知订阅他的客户端，并让客户端更新服务列表，而且还会通知其他eureka server更新此信息。
（5）心跳检测，微服务每30秒向eureka server发送心跳，eureka server若90s之内都没有收到某个客户端的心跳，则认为此服务提供者出了问题，会从注册的服务列表中将其删除，并通知订阅它的客户端更新服务列表，而且还会通知其他eureka server更新此信息。
（6）保护机制：默认情况下，如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络故障，导致此实例被注销。固定时间内大量实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制。
 

1）Eureka Server 启动成功，等待服务注册，每个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 将实例从注册表中删除

      Eureka Server 之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。


Eureka 自带了一个 Web 的管理页面，方便我们查询注册到上面的实例信息，但是有一个问题：如果在实际使用中，注册中心地址有公网 IP 的话，必然能直接访问到，这样是不安全的。所以我们需要对 Eureka 进行改造，加上权限认证来保证安全性。

与eureka相关的组件有哪些，相比之下有何特点？

consul、eureka、nacos对比

配置中心

  • eureka 不支持
  • consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新
  • nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新

注册中心

  • eureka

    • 依赖：依赖ZooKeeper
    • 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现，
    • ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。
    • 版本迭代：目前已经不进行升级
    • 集成支持：只支持SpringCloud集成
    • 访问协议：HTTP
    • 雪崩保护：支持雪崩保护
    • 界面：英文界面，不符合国人习惯
    • 上手：容易

  • consul

    • 依赖：不依赖其他组件

    • 应用内/外：属于外部应用，侵入性小

    • ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。

    • 版本迭代：目前仍然进行版本迭代

    • 集成支持：支持SpringCloud K8S集成

    • 访问协议：HTTP/DNS

    • 雪崩保护：不支持雪崩保护

    • 界面：英文界面，不符合国人习惯

    • 上手：复杂一点

  • nacos

    • 依赖：不依赖其他组件
    • 应用内/外：属于外部应用，侵入性小
    • ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍）
    • 版本迭代：目前仍然进行版本迭代
    • 集成支持：支持Dubbo 、SpringCloud、K8S集成
    • 访问协议：HTTP/动态DNS/UDP
    • 雪崩保护：支持雪崩保护
    • 界面：中文界面，符合国人习惯
    • 上手：极易，中文文档，案例，社区活跃

转自： https://blog.csdn.net/m0_37515193/article/details/100409770

http://c.biancheng.net/view/5325.html

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/hellohero55/p/12724909.html