SpringCloud组件：Eureka服务注册是采用主机名还是IP地址？

eureka 英[juu02c8ri:ku0259] 美[ju028a"ri:ku0259] int. （因找到某物，尤指问题的答案而高兴） 我发现了，我找到了; [例句]"Eureka! I"ve got it!"“找到了！我找到了！”

首先通过以下一幅图简单看下eureka的服务注册发现流程是什么样的： 1、服务提供者提供应用服务，注册到eureka server中。 2、服务消费者每30秒去去注册中心拉取服务的ip，端口，接口地址等信息。 3、服务消费者拉取到服务提供者的应用信息后，可以直接去调用服务提供者的接口。 服务注册的原理主要涉及到eureka server的存储结构，采用一个三层缓存的结构。具体内部的实现逻辑参考二中的图。 当服务提供者完成服务信息注册后，会维持一个心跳，定时向eureka server 发送rest请求，告诉其还活着。默认心跳间隔30s。 eureka client会定期（默认30s）向eureka server获取获取注册的服务信息，这个获取分为 全量获取 和 增量获取 。默认配置下，当客户端首次启动后，会向服务端发起一次全量获取并缓存本地信息，之后每隔30s发起一次增量获取，更新本地缓存 通常服务间调用使用组件feign，发起rest请求；其内集成了ribbon，ribbon默认使用了轮训的负载策略，会将eureka client拉取的注册信息拉取到自己这，实现负载。 关于feign和ribbon会在后续学习中具体讲解。 表示要从注册中心删除该服务的注册信息，使该服务不能被调用。 服务下线的方式： 在eureka server中有一个定时任务Evict，该任务默认每60s执行一次，其作用域在readWriteCacheMap和register上。 当有服务提供者在默认90s时间内，没有进行服务续约，当Evict执行时，会对这样失效的注册信息进行剔除。通常是宕机的服务或者强制kill的服务。 官方定义 ：自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。 Eureka Server在运行期间会统计心跳失败的比例在15分钟内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，不会让它们立刻过期。 此配置在默认环境下开启。 自我保护存在的问题，在保护期间，服务挂掉，导致服务无法下线，造成调用接口失败。 因为eureka client本地缓存注册表信息，当eureka server宕机后服务间仍然可以访问，但是服务提供端和服务消费端又分为以下情况： 当服务消费端重启后，本地缓存失效，与服务提供端的映射不存在了，无法进行服务调用。 当服务提供端重启后，在服务调用端的本地缓存中，仍然保存有在eureka宕机前的缓存信息，可以正常调用服务。 参考： https://blog.csdn.net/fox_bert/article/details/104210074 eureka采用的同步方式是peer to peer（对等复制），副本间不分主从，任何副本都可以接收写操作，然后每个副本间互相进行数据更新。 Eureka Server 本身依赖了 Eureka Client，也就是每个 Eureka Server 是作为其他 Eureka Server 的 Client。 Eureka Server 启动后，会通过 Eureka Client 请求其他 Eureka Server 节点中的一个节点，获取注册的服务信息，然后复制到其他 peer 节点。 Eureka Server 每当自己的信息变更后，例如 Client 向自己发起注册、续约、注销请求， 就会把自己的最新信息通知给其他 Eureka Server，保持数据同步。 存在的问题： 1）每个节点都可以进行写操作，会导致数据冲突。 2）如果自己的信息变更是另一个Eureka Server同步过来的，这是再同步回去的话就出现数据同步死循环了。 问题 1）解决方案： Eureka 是通过 lastDirtyTimestamp 这个类似版本号的属性来解决该问题。 lastDirtyTimestamp 是注册中心里面服务实例的一个属性，表示此服务实例最近一次变更时间。 问题 2）解决方案： Eureka Server 在执行复制操作的时候，使用 HEADER_REPLICATION 这个 http header 来区分普通应用实例的正常请求，说明这是一个复制请求，这样其他 peer 节点收到请求时，就不会再对其进行复制操作，从而避免死循环。 通过前面了解到，eureka并没有保证数据的强一致性，只保证了数据的 最终一致性 ，通过集群模式保证了 高可用 。

eureka. 好啊，有办法啦。

Eureka 作为 Spring Cloud 体系中最核心、默认的注册中心组件，研究它的运行机制，有助于我们在工作中更好地使用它。 回到上节的服务注册调用示意图，服务提供者和服务的消费者，本质上也是 Eureka Client 角色。整体上可以分为两个主体：Eureka Server 和 Eureka Client。 Eureka Server：注册中心服务端 注册中心服务端主要对外提供了三个功能： 服务注册 服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表 提供注册表 服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表 同步状态 Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。 Eureka Client：注册中心客户端 Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。 Register: 服务注册 服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等。 Renew: 服务续约 Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。 默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改。 服务续约的两个重要属性 Eviction 服务剔除 当 Eureka Client 和 Eureka Server 不再有心跳时，Eureka Server 会将该服务实例从服务注册列表中删除，即服务剔除。 Cancel: 服务下线 Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。 发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容： GetRegisty: 获取注册列表信息 Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。 如果由于某种原因导致注册列表信息不能及时匹配，Eureka Client 则会重新获取整个注册表信息。 Eureka Server 缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。 获取服务是服务消费者的基础，所以必有两个重要参数需要注意： Remote Call: 远程调用 当 Eureka Client 从注册中心获取到服务提供者信息后，就可以通过 Http 请求调用对应的服务；服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。 默认情况下，如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。 固定时间内大量实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制，那么什么是自我保护机制呢？ Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 即会进入自我保护机制。 Eureka Server 触发自我保护机制后，页面会出现提示： Eureka Server 进入自我保护机制，会出现以下几种情况： (1 Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 (2 Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) (3 当网络稳定时，当前实例新的注册信息会被同步到其它节点中 Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。 如果在保护期内刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，即会调用失败。对于这个问题需要服务消费者端要有一些容错机制，如重试，断路器等。 通过在 Eureka Server 配置如下参数，开启或者关闭保护机制，生产环境建议打开： 再来看看 Eureka 集群的工作原理。我们假设有三台 Eureka Server 组成的集群，第一台 Eureka Server 在北京机房，另外两台 Eureka Server 在深圳和西安机房。这样三台 Eureka Server 就组建成了一个跨区域的高可用集群，只要三个地方的任意一个机房不出现问题，都不会影响整个架构的稳定性。 从图中可以看出 Eureka Server 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。 如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它 Eureka Server 当前所知的所有节点中。 另外 Eureka Server 的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。所以，如果存在多个节点，只需要将节点之间两两连接起来形成通路，那么其它注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client，多个 Eureka Server 之间通过 P2P 的方式完成服务注册表的同步。 Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。 Eureka 分区 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 中获取信息。 Eurka 保证 AP Eureka Server 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。 了解完 Eureka 核心概念，自我保护机制，以及集群内的工作原理后，我们来整体梳理一下 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 将实例从注册表中删除 这就是Eurka基本工作流程 讲了 Eureka 核心概念、Eureka 自我保护机制和 Eureka 集群原理。通过分析 Eureka 工作原理，我可以明显地感觉到 Eureka 的设计之巧妙，通过一些列的机制，完美地解决了注册中心的稳定性和高可用性。 Eureka 为了保障注册中心的高可用性，容忍了数据的非强一致性，服务节点间的数据可能不一致， Client-Server 间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。

eureka应该算是来自希腊语εu03cdρηκα（读音像）“尤里卡”原是古希腊语,意思是：“好啊!有办法啦!”古希腊学者阿基米德,有一次在浴盆里洗澡,突然来了灵感,发现了他久未解决的计算浮力问题的办法,因而惊喜地叫了一声“尤里卡”,从此发现了阿基米德定律.！我觉得eureka是珊瑚岩派来的沟通的使者，她就是珊瑚岩和人类交流的方法，所以这样给女主取名。（个人猜想）！

eureka[juə"ri:kə]n.优铜，尤里卡高电阻铜镍合金eureka[juə"ri:kə]interj.[希腊语]我发现了!我想出了!(据说是古希腊学者阿基米德根据比重原理测出希罗王王冠所含黄金的纯度时所发出的惊叹语；现用作因重要发明而发出的惊叹语)

eureka英 [,jʊ(ə)"riːkə] 美 [jʊ"rikə] int. 有了！；找到了！n. (Eureka)人名；(西)欧雷卡

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具，Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现 Eureka采用C-S的设计架构，包含Eureka Server 和Eureka Client两个组件 Applecation-server :服务提供者 Application-cliene:服务消费者 服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。 在默认配置中EurekaServer服务在一定时间（默认为90秒）没接受到某个服务的心跳连接后，EurekaServer会注销该服务。但是会存在当网络分区发生故障，导致该时间内没有心跳连接，但该服务本身还是健康运行的情况。Eureka通过“自我保护模式”来解决这个问题。 在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。 CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。 Zookeeper保证CP Zookeeper 为主从结构，有leader节点和follow节点。当leader节点down掉之后，剩余节点会重新进行选举。选举过程中会导致服务不可用，丢掉了可用行。 Eureka保证CP Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。 Eureka服务端依赖 服务端配置 将微服务注册到Eureka中 服务实例配置

我们先来看看Eureka的集群架构图1，服务注册。 Eureka Server作为服务注册中心，为微服务架构提供服务注册功能。微服务节点启动后，会在Eureka中进行注册，Eureka Server中会存储所有的可用微服务节点信息。2，Eureka客户端。 Eureka Client是一个java客户端，用于简化与Eureka Server的交互。客户端同时也具备一个内置的、使用轮询算法的负载均衡器。3，心跳检测。 在应用启动后，客户端将会向Eureka Server发送心跳（默认为30秒，我们项目配置的是30秒）。Eureka Serber如果在多个心跳周期内没有收到某个微服务节点的心跳，将会剔除该节点（默认90秒，我们项目配置的是90秒）。4，集群数据同步。 Eureka Server之间通过复制的方式来进行数据同步。5，客户端缓存功能。 Eureka Client具有缓存功能，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。6，清理失效节点。7，自我保护模式。 自我保护模式是指在网络出现异常的情况下，由于Eureka Server无法收到客户端的心跳续约，Eureka Server会判断该节点不可用，但其实该节点可能是正常的，可用的。为了避免误删，Eureka Server引入了自我保护模式。一旦Eureka Server发现当前收到的心跳总次数小于心跳阈值的85%（默认值），就会进入自我保护模式，此时Eureka Server不会清理任何节点。直到Eureka Server收到的心跳总次数大于等于心跳阈值的85%。 自我保护模式的设计哲学是：在不确定节点是否可用的情况下，尽可能保留节点。问题：Eureka Server的服务发现，是如何工作的？答：服务发现和服务注册是同一个概念。

下面我们来说一下eureka的网络通信。eureka主要包含两个方面的网络通信： Eureka-Client 请求 Eureka-Server 的网络通信 Eureka-Server 集群内，Eureka-Server 请求 其它的Eureka-Server 的网络通信 EurekaJerseyClient ，EurekaHttpClient 接口。主要是基于 Apache HttpClient4 实现的 Jersey Client。关于Jersey，就不在这里介绍了。 EurekaJerseyClientImpl ，EurekaHttpClient 实现类，看下具体的实现 EurekaJerseyClientBuilder ，EurekaJerseyClientImpl 内部类，用于创建 EurekaJerseyClientImpl 。调用 build方法，创建 EurekaJerseyClientImpl 。 EurekaHttpClient ，Eureka-Server HTTP 访问客户端，定义了具体的 Eureka-Server API 调用方法。 EurekaHttpResponse ，请求响应对象。 TransportClientFactory ，创建 EurekaHttpClient 的工厂接口。 AbstractJerseyEurekaHttpClient ，实现 EurekaHttpClient 的抽象类，真正实现了具体的 Eureka-Server API 调用方法。看下具体的实现 JerseyApplicationClient ，实现 Eureka-Client 请求 Eureka-Server 的网络通信。 JerseyEurekaHttpClientFactory ，创建 JerseyApplicationClient 的工厂类。 JerseyEurekaHttpClientFactoryBuilder ，JerseyEurekaHttpClientFactory 内部类，用于创建 JerseyEurekaHttpClientFactory 。 JerseyReplicationClient ，Eureka-Server 集群内，Eureka-Server 请求 其它的Eureka-Server 的网络通信。 实现 AbstractJerseyEurekaHttpClient的addExtraHeaders方法，添加自定义头 x-netflix-discovery-replication=true，看下具体的实现 实现HttpReplicationClient 接口，实现了 submitBatchUpdates方法 MetricsCollectingEurekaHttpClient ，监控指标收集 EurekaHttpClient ，配合 Netflix Servo实现监控信息采集。看下具体的实现 RedirectingEurekaHttpClient ，寻找非 302 重定向的 Eureka-Server 的 EurekaHttpClient 。看下具体的实现 RetryableEurekaHttpClient ，支持向多个 Eureka-Server 请求重试的 EurekaHttpClient 。看下具体的实现 SessionedEurekaHttpClient ，支持会话的 EurekaHttpClient 。执行定期的重建会话，防止一个 Eureka-Client 永远只连接一个特定的 Eureka-Server 。反过来，这也保证了 Eureka-Server 集群变更时，Eureka-Client 对 Eureka-Server 连接的负载均衡。看下具体的实现 对于 Eureka-Server 来说，调用 JerseyReplicationClient的createReplicationClient静态方法即可创建用于 Eureka-Server 集群内，Eureka-Server 请求 其它的Eureka-Server 的网络通信客户端。 对于 Eureka-Client 来说，分成用于注册应用实例( registrationClient )和查询注册信息( newQueryClient )的两个不同网络通信客户端。在 DiscoveryClient 初始化时进行创建。看下具体的实现 eureka的网络通信就介绍到这里了。

EUREKA不是手摇床品牌，EUREKA而是吸尘器品牌。ureka由美国FredWardell创立于1909年，是有着百年历史的专业吸尘器品牌，总部位于美国底特律。eureka提供针对各种细分使用场景的性能、易使用、专业智能的清洁解决方案，持续改善整体清洁体验，让消费者的生活更轻松。因此EUREKA不是手摇床品牌。

1、范围不同。Nacos的阈值是针对某个具体Service的，而不是针对所有服务的；但Eureka的自我保护阈值是针对所有服务的。nacos支持CP和AP两种；eureka只支持AP。nacos使用netty，是长连接；eureka是短连接，定时发送。2、保护方式不同。Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关（eureka.server.enable-self-preservation: false)。Nacos保护方式：当域名健康实例（Instance)占总服务实例（Instance)的比例小于阈值时，无论实例（Instance)是否健康，都会将这个实例（Instance)返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例（Instance)能正常工作。3、连接方式不同。nacos支持动态刷新，在控制器（controller）上加＠RefreshScope注解即可，采用Netty连接，是长连接；eureka本身不支持动态刷新，需要配合MQ完成动态刷新，且是短连接，是定时发送。

什么是服务注册？ 首先我们来了解下，服务注册、服务发现和服务注册中心的之间的关系。 举个形象的例子，三者之间的关系就好像是供货商，顾客和商店。 首先各地的供货商会将各种商品提供给商店，然后顾客需要商品的时候会去商店购买。 注册中心就好比是这个商店，供货商的动作就是服务注册，商品就是注册的服务。 当部署的服务启动后，会注册到注册中心，消费者需要什么样的服务，就自己去注册中心拉取。 那么到底什么是服务注册，为什么要将服务注册到注册中心呢？ 服务注册指的是服务在启动时将服务的信息注册到注册中心中，由注册中心统一对所有的注册的服务进行管理。 现在我们想想，假如你是消费者，你需要买一个商品，你可以去商店，也可以直接去供货商。 但是如果今天你要买很多商品，而且我们并不知道每个商品对应的供应商的地址，那么你就得挨家挨户的去跑供货商购买商品。 是不是就很麻烦了，倘若此时有一家商店，汇总了多家供货商的商品，那你是不是只需要去这一家商店就能购买到你需要的所有的商品了呢？ 这样是不是就方便了。 在我们现实开发中，比如我们需要获取用户信息的时候，而此时，我们的用户服务只部署了一个节点，那我们就可以使用IP+端口的形式访问服务。 当此时我们的服务部署了10个节点后，我们可以通过域名访问，通过nginx转发到某一个节点上，访问该节点的服务。 使用过nginx的小伙伴们都知道，每当我们需要新增一个节点的时候，我们就需要去修改nginx的配置文件，一旦服务部署的节点过多，频繁修改配置文件就变成了一件极其麻烦的事情。 这个时候，我们的注册中心，就应该粉墨登场了。 注册中心一登场，我们就尽管部署服务节点，部署完成后，服务启动，服务的信息就会被注册到注册中心，我们就不需要担心是不是又要去修改配置文件了。 什么是服务发现？ 服务发现有两种模式：一种是客户端发现模式，一种是服务端发现模式。Eureka采用的是客户端发现模式。 客户端发现模式就好比我是一个土豪顾客，我去了商店，我把所有的商品都买回家，需要的时候在这些商品里面寻找。 因为我是土豪，所以我当然不能忍受商店里有新品上架，而我却没有，所以我每隔一段时间就会商店增量获取最新的商品。 这就是Eureka中的Fetch Registry，抓取注册信息。 Eureka Client 从 Eureka Server 获取注册表信息并在本地缓存。 这里我们注意一下，Eureka Client并不是直接去服务注册表中获取数据，而是从ReadOnly缓存中获取数据。 并且会通过在上一个获取周期和当前获取周期之间获取增量更新，这些信息会定期更新(每30秒更新一次)。 获取的时候可能返回相同的实例。Eureka Client会自动处理重复信息。 因为我的土豪行为，我已经被商店老板记录在它的VVIP名单上了。可惜天有不测风云，我破产了，我再也不能这么土豪了，没办法，我告诉了老板我破产了，老板听了我的话，想都没想，直接从他的VVIP名单上将我的名字给剔除了，社会就是这么现实。 这就是Eureka中的Cancel，取消。 每一个微服务节点关闭时，Eureka Client会向Eureka Server发送一个取消请求。 Eureka Server收到你的取消请求后，就会将你从服务注册表中给剔除。 商店老板是个傲娇的人，她制定了一个规则，如果你是她VVIP名单上的人，你必须每隔一段时间就要去商店采购商品。 一旦你在一段时间内没有来采购，她就觉得你已经没有购买能力，不适合在她的VVIP名单上存在了。 她就会狠心的将你从她的VVIP名单上将我的名字给剔除了。 这就是Eureka中的Renew（更新 / 续借） Eureka Client 内部具备一个内置的负载均衡器，它使用轮训（round-robin）负载算法。 在服务启动后，每隔一定周期（默认30秒）向Eureka Server发送心跳。 如果Eureka Server在多个心跳周期内（默认90秒）没有收到Eureka Client发送过来的心跳，Eureka Server将会在服务注册表中将该节点剔除。 当然了，服务发现去注册中心拉取的是服务的信息，然后需要从服务信息中获取到服务部署的节点信息，然后通过域名地址访问到该节点的服务。 就好像一家商店，因为空间太小，只是存放了一些商品的微缩模型，模型上写着该商品所属的供货商地址，我们去商店拿到该模型后，看到供货商的地址，然后我们就可以直接去供货商那儿直接购买商品了。 什么是注册中心，注册中心的作用？ 注册中心就是一个管理器，各个服务提供者将服务注册到注册中心，由注册中心进行统一的存储和管理。 注册中心同时还有着判断服务是否可用，对于不可用的服务进行剔除的功能。 至于如何判断服务的可用性和如何剔除不可用的服务，后续会有详细的讲解。 什么是 Eureka，有什么作用？ Eureka采用CS架构，它分为两大组件。 一个是Eureka Server,注册中心服务端。 当各个微服务节点启动后，Eureka Server 会存储服务提供者注册上来的服务信息，并且提供二层缓存机制来维护整个注册中心。 另一个是Eureka Client，注册中心客户端。 Eureka Client是一个java客户端，它用来简化和Eureka Server交互。 Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。 因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。 Eureka 架构详解 如下图所示，这是官网提供给我们的Eureka的架构图Eureka 的架构，主要分为 Eureka Server 和 Eureka Client 两部分，Eureka Client 又分为 Applicaton Service 和 Application Client，Applicaton Service 就是服务提供者，Application Client 就是服务消费者。 我们首先会在应用程序中依赖 Eureka Client，项目启动后 Eureka Client 会向 Eureka Server 发送请求，进行注册，并将自己的一些信息发送给 Eureka Server。 注册成功后，每隔一定的时间，Eureka Client 会向 Eureka Server 发送心跳来续约服务，也就是汇报健康状态。如果客户端长时间没有续约，那么 Eureka Server 大约将在 90 秒内从服务器注册表中删除客户端的信息。 Eureka Client 还会定期从 Eureka Server 拉取注册表信息，然后根据负载均衡算法得到一个目标，并发起远程调用，关于负载均衡在后面的课时会详细介绍，也就是 Ribbon 组件。 应用停止时也会通知 Eureka Server 移除相关信息，信息成功移除后，对应的客户端会更新服务的信息，这样就不会调用已经下线的服务了，当然这个会有延迟，有可能会调用到已经失效的服务，所以在客户端会开启失败重试功能来避免这个问题。 Eureka Server 会有多个节点组成一个集群，保证高可用。Eureka Server 没有集成其他第三方存储，而是存储在内存中。 所以 Eureka Server 之间会将注册信息复制到集群中的 Eureka Server 的所有节点。 这样数据才是共享状态，任何的 Eureka Client 都可以在任何一个 Eureka Server 节点查找注册表信息。 Eureka 的工作流程 Eureka 的自我保护机制 什么是自我保护机制 官方定义：自我保护模式正是一种针对网络异常波动时的安全保护措施，使用自我保护模式能使Eureka集群更加健壮稳定的运行。 为什么要开启自我保护机制？ 如果Eureka Server在一定时间内（默认90s）（可优化）没有收到某一个服务节点的心跳，Eureka Server将会移除该服务实例。 但是在某些时候，遇到网络分区故障，服务节点实际上是正常存活状态，但是却无法和Eureka Server正常通信，此时如果没有引入自我保护机制，Eureka Server就会将该服务节点剔除。 自我保护模式的工作机制 如果15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就会认为客户端与注册中心发生了网络故障，Eureka Server进入自我保护机制。 自我保护机制的缺点 如果在自我保护机制中，刚好某些服务节点非正常下线，但是Eureka Server并不会剔除该服务节点，服务消费者就会获取到一个无效的服务实例。 解决方案 ① ：关闭自我保护机制(不推荐) ② ：切换请求或断路器，使用负载均衡的方式，设置当一个请求超过多少秒还未得到响应，速度切换请求到下一个注册服务，例如使用Ribbon+Hystrix配置负载均衡和断路器。 Eureka Server 进入自我保护机制后 1、Eureka Server不再从注册表中剔除因为长时间没有和注册中心续约的服务节点 2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会同步到其他Eureka Server节点上 3、网络正常后，当前Eureka Server节点会将新的服务节点信息同步到其他Eureka Server节点上 如何开启自我保护 通过 eureka.server.enable-self-preservation=true/false来开启或关闭自我保护机制。 其他关键配置： 清理失效服务节点的时间间隔： eureka.server.evication-interval-timer-in-ms默认60s 续约间隔时间： eureka.instance.lease-renewal-interval-in-seconds默认30s 续约到期时间： eureka.instance.lease-expiration-duration-in-seconds默认90s 通过源码窥探Eureka是如何开启自我保护机制的 第一步，我们引入Eureka Server 依赖。 第二步，我们找到eureka-core jar包下的路径为com.netflix.eureka下的registry包 第三步，进入AbstractInstanceRegistry 类，找到evict方法，这个是定期剔除任务的线程最终执行的方法 第四步，我们找到isLeaseExpirationEnabled()方法的实现 第五步，我们注意到 numberOfRenewsPerMinThreshold这个变量很关键，它的含义是每分钟最小的续约次数 在服务注册register和服务下线cancel两个方法中会更新这个变量，更新该变量方法如下： 以上就是Eureka开启自我保护的整个逻辑流程。 解除自我保护机制 1.当服务的网络分区故障解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于85%时，则自动解除。 2.重启服务 Eureka 的健康检查 其实很多框架的健康状态监控都是通过 actuator 来管理健康状态的，并且扩展了 health 端点。 所以说我们只要在项目中集成Actuator，我们就能管理监控项目的健康状态。 Eureka也是一样，我们可以将某些不健康的服务节点的状态告知Eureka Server，然后Eureka Server 会主动让其下线。 这个就是Eureka的健康检查。 如何实现Eureka-Actuator健康检查？ 首先我们要在pom中依赖 spring-boot-starter-actuator。 第二步，配置文件中添加 eureka.client.healthcheck.enabled=true 配置 原理分析： 首先在 EurekaDiscoveryClientConfiguration 中根据 eureka.client.healthcheck.enabled 的值来决定是否要装配 EurekaHealthCheckHandler ，然后在 EurekaClientAutoConfiguration 中会注册 HealthCheck ，但我们注册完成后会有调用任务来进行状态的更新，在 com.netflix.discovery.InstanceInfoReplicator.run() 中会进行状态更新。 Eureka 的多级缓存机制 什么是多级缓存机制 Eureka Server 为了避免同时读取内存数据造成的并发冲突问题，采用了多级缓存机制提升服务请求的响应速度。 Eureka Server的缓存是通过一个只读，一个读写缓存来实现的。 一级缓存：concurrentHashMap<key,value>readOnlyCacheMap本质是HashMap，无过期时间，保存数据信息对外输出。 readOnlyCacheMap依赖于定时器的更新，通过与readWriteCacheMap的值做对比，以readWriteCacheMap为准。 responseCacheUpdateIntervalMs：readOnlyCacheMap缓存更新间隔，默认30s 二级缓存：LoaDing<key,value>readWriteCacheMap本质是Guava缓存，包含失效机制，保护数据信息对外输出。 responseCacheAutoExpirationInSeconds：readWriteCacheMap 缓存过期时间，默认180s。 当服务节点发生注册，下线，过期，状态变更等变化时 1.在内存中更新注册表信息 2.同时过期掉readWriteCacheMap缓存，缓存清除只是会去清除readWriteCacheMap这个缓存， readOnlyCacheMap 只读 缓存并没有更新，也就说当客户端的信息发生变化之后， 只读缓存不是第一时间感知到的。只读缓存的更新只能依赖那个30秒的定时任务来更新。 3.一段时间后（默认30s），后台线程发现readWriteCacheMap缓存为空，于是也将readOnlyCacheMap中的缓存清空 4.当有服务消费者拉取注册表信息时，会调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。 在Eureka Server 中会有两个线程，一个是定时同步两个缓存的数据，默认30s，一个是定时检测心跳故障，默认90s。 服务拉取 1.服务消费者，默认每30s，拉取注册表信息 2.从readOnlyCacheMap中获取信息，如果获取为空 3.从readWriteCacheMap中获取，如果还是为空 4.调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。 Eureka的区域配置 当用户地理分布范围很广的时候，比如公司在上海、杭州、青岛等都有分公司的时候，一般都会有多个机房。 那么对于用户而言，当然是希望调用本地分公司的机房中的微服务应用。 比如：上海用户A，调用OAuth2服务，用户A当然希望调用上海机房里面的微服务应用。如果上海用户A调用杭州机房的OAuth2服务，就增加的延时时间。 所以我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用的时候，再去调用其它机房的服务，以达到减少延时的作用。 为此，eureka提供了region和zone两个概念来进行分区，Eureka基于Amazon设计的，所以对于地域的区分也与Amazon一致，Amazon分为多个region，每个region包含多个zone，所以Eureka设计时也是可以设置region与zone，请求时可以优先选择与请求服务在同一个zone的服务。 基本配置 此时无论我们调用多少次，调用的都是shanghai下面的zone1下面的服务。 一般来说我们都会结合Ribbon来实现微服务的负载均衡，而Ribbon内部会有一些专门的负载策略算法，虽然刚刚我们说过会优先请求的是指定region下指定 Zone 区域的服务实例。 但有些时候比如当在Region=shanghai下没有可用的zone，系统会默认加载 DEFAULT_ZONE，或者说或者同区域的服务负载过高...等等，也会自动切换成其他区域的服务。 Eureka的重试机制 由于 Spring Cloud Eureka 实现的服务治理机制强调了 CAP 原理中的 AP，即可用性与可靠性，牺牲了一定的一致性（在极端情况下它宁愿接受故障实例也不要丢掉"健康"实例，如同如我们上面所说的自我保护机制）。 但不论是由于触发了保护机制还是服务剔除的延迟，引起服务调用到这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！ 这显然不是我们愿意看到的，我们还是希望能够增强对这类问题的容错。所以，我们在实现服务调用的时候通常会加入一些重试机制。 从 Camden SR2 版本开始，Spring Cloud 就整合了 Spring Retry 来增强 RestTemplate 的重试能力，对于开发者来说只需通过简单的配置，原来那些通过 RestTemplate 实现的服务访问就会自动根据配置来实现重试策略。 开启Eureka的重试机制很简单，首先我们在pom中引入Spring Retry的依赖： 然后在配置文件中配置 spring.cloud.loadbalancer.retry.enabled参数来控制重试机制的开关，因为 Spring Retry默认是开启的，所以说我们只要引入依赖即可，如果说我们想要关闭的话只需要将 spring.cloud.loadbalancer.retry.enabled设置为false即可。 其实在SpringCloud的架构组件中无论是Fegin，Ribbon，还是Zuul都提供了重试机制，这些暂且不论，后续再讲到具体的组件时再进行具体的分析。 实战 Eureka 注册中心的部署 Eureka Server 项目搭建 1、创建一个 springcloud-eureka-server 的项目，然后在 pom 中增加 spring-cloud-starter-netflix-eureka-server 的依赖。 2.在pom.xml文件中新增 spring-cloud-starter-netflix-eureka-server依赖 3.在启动类 SpringcloudEurekaServerApplication上使用 @EnableEurekaServer 开启 EurekaServer 的自动装配功能。 4.添加配置文件application.properties 5.启动项目，然后访问 http://localhost:8761/ ,可以看到 Eureka 的管理页面，表示 Eureka 启动成功了。 1、创建一个 springcloud-eureka-client 的项目，然后在 pom 中增加 spring-cloud-starter-netflix-eureka-client 的依赖。 2.在启动类 SpringcloudEurekaClientApplication上使用 @EnableEurekaClient 开启 EurekaServer 的自动装配功能。 配置 eureka.client.serviceUrl.defaultZone 的地址，也就是刚刚启动的 Eureka Server 的地址， http://localhost:8761/eureka/ 。 启动客户端，然后刷新刚刚打开的Eureka主页，我们发现服务已经注册成功。 Eureka 注册中心添加密码认证 上面我们看到我们搭建好Eureka Server 后访问 http://localhost:8761/ ,没有登陆就可以直接看到 Eureka 的管理页面。 如果在实际使用中，注册中心地址有公网 IP 的话，必然能直接访问到，这样是不安全的。所以我们需要对 Eureka 进行改造，通过集成 Spring-Security 来进行安全认证，加上权限认证来保证安全性。 首先，在 pom.xml 中引入 Spring-Security 的依赖 然后在 application.properties 中加上认证的配置信息 最后增加Spring Security 配置类 这样我们启动Eureka Server成功后在访问 http://localhost:8761/ ，此时浏览器会提示你输入用户名和密码，输入正确后才能继续访问 Eureka 提供的管理页面。 总结 本章我们主要学习了Eureka相关知识，虽然Eureka已经停更了，但是很多公司还在使用它，而它也足够稳定，它所提供的功能也足够大多数公司使用。所以说现在面试中，Eureka相关题目还是经常出现的。反正学到了就是自己的。 祝愿大家早日成为大牛，有一头乌黑秀发的大牛。

Eureka在CAP理论当中是属于AP ， 也就说当产生网络分区时，Eureka保证系统的可用性，但不保证系统里面数据的一致性。 默认情况下，Eureka Server在一定时间内，没有接收到某个微服务心跳，会将某个微服务注销（90S）。但是当网络故障时，微服务与Server之间无法正常通信，上述行为就非常危险，因为微服务正常，不应该注销。 Eureka Server通过自我保护模式来解决整个问题，当Server在短时间内丢失过多客户端时，那么Server会进入自我保护模式，会保护注册表中的微服务不被注销掉。当网络故障恢复后，退出自我保护模式。 思想：宁可保留健康的和不健康的，也不盲目注销任何健康的服务。 自我保护机制的触发条件： （当每分钟心跳次数( renewsLastMin ) 小于 numberOfRenewsPerMinThreshold 时，并且开启自动保护模式开关( eureka.server.enable-self-preservation = true ) 时，触发自我保护机制，不再自动过期租约。） numberOfRenewsPerMinThreshold = expectedNumberOfRenewsPerMin * 续租百分比( eureka.server.renewalPercentThreshold, 默认0.85 ) expectedNumberOfRenewsPerMin = 当前注册的应用实例数 x 2 为什么乘以 2： 默认情况下，注册的应用实例每半分钟续租一次，那么一分钟心跳两次，因此 x 2 。 服务实例数：10个，期望每分钟续约数：10 * 2=20，期望阈值：20*0.85=17，自我保护少于17时 触发。

nacos和eureka的区别区别如下：springcloud eureka是注册中心，负责微服务的注册与发现，起到承上启下的作用，在微服务架构中相当于人体的 大脑，很重要，nacos是阿里巴巴出的，功能类似eureka。nacos的部署方式与springcloud eureka不太一样，euraka是需要创建springboot项目，然后将euraka服务端通过gav的方式加载进来，然后部署项目。nacos是直接从阿里巴巴nacos的官网下载jar包，启动服务。Eureka Server：之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

Eureka的意义包括动漫人物名、日本电影名、美剧名、拉丁语词和电子商务主题。Eureka作为珊瑚岩与人类的桥梁隐喻“找到了”交流的方式。她并非唯一的克拉利安，而是唯一成功与人类共鸣的克拉利安。在本篇中主要体现了她与兰顿的心灵成长，从冷漠的美人成长为温暖的爱人。从少年陪伴兰顿成长为青年；从懵懂未知的情愫成长为穿越戒限的爱情。她是一个不完整的个体，不论是心灵还是肉体，她也会彷徨，也会恐惧。但是兰顿用自己的热情，自己信念融化了她的冰冷，赢得了她的感情。同时，也赢得了珊瑚岩的认同——拯救了人类。Eureka的形象是所有这个年龄的少年的缩影。她坚持不懈的寻找自我价值，对感情的执着，成就了这一完美的形象。

服务治理：Spring Cloud Eureka Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为 Eureka增加了Spring Boot风格的自动化配置，我们只需通过简单引入依赖和注解配置就能 让Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合。 在本章中，我们将指引读者学习下面这些核心内容，并构建起用于服务治理的基础设 施。 ·构建服务注册中心 ·服务注册与服务发现 。Eureka的基础架构 Eureka的服务治理机制 Eureka的配置 服务治理 服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务 实例的自动化注册与发现。为什么我们在微服务架构中那么需要服务治理模块呢？微服务 系统没有它会有什么不好的地方吗？ 在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来 完成服务的调用。比如，有两个服务A和B,其中服务A需要调用服务B来完成一个业务 操作时，为了实现服务的高可用，不论采用服务端负载均衡还是客户端负载均衡，都需 要手工维护服务的具体实例清单。但是随着业务的发展，系统功能越来越复杂，相应一下的 微服务应用也不断增加，我们的静态配置就会变得越来越难以维护。并且面对不断发展的 业务，我们的集群规模、服务的位置、服务的命名等都有可能发生变化，如果还是通过手 工维护的方式，那么极易发生错误或是命名冲突等间题。同时，对于这类静态内容的维护 为了解决微服务架构中的服务实例维护问题，产生了大量的服务治理框架和产品。这 也必将消耗大量的人力。 些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化 管理。 服务注册：在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册 中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告 知注册中心，注册中心按服务名分类组织服务清单。比如，我们有两个提供服务A 的进程分别运行于192.168.0.100：8000和192.168.0.101：8000位置上， 另外还有三个提供服务B的进程分别运行于192.168.0.100：9000、 192.168.0.101:9000、192.168.0.102:9000位置上。当这些进程均启动， 并向注册中心注册自己的服务之后，注册中心就会维护类似下面的一个服务清单。 另外，服务注册中心还需要以心跳的方式去监测清单中的服务是否可用，若不可用 需要从服务清单中剔除，达到排除故障服务的效果。 服务名 位置 服务A 192.168.0.100:8000、192.168.0.101:8000 服务B 192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000 服务发现：由于在服务治理框架下运作，服务间的调用不再通过指定具体的实例地 址来实现，而是通过向服务名发起请求调用实现。所以，服务调用方在调用服务提 供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中 心咨询服务，并获取所有服务的实例清单，以实现对具体服务实例的访问。比如， 现有服务C希望调用服务A,服务C就需要向注册中心发起咨询服务请求，服务注 册中心就会将服务A的位置清单返回给服务C,如按上例服务A的情况，C便获得 了服务A的两个可用位置192.168.0.100：8000和192.168.0.101：8000。 当服务要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服 务调用，这就是后续我们将会介绍的客户端负载均衡。这里我们只是列举了一种简 单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性 能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用哦场景 在缓存和服务剔除等机制上也会有一些不同的实现策略。

音标是/juu0259‘ri:ku0259/ 用汉语念出来就是“优蕊卡

在应用启动类上添加@EnableEurekaServer注解，声明为Eureka Server 配置文件application.yml中添加以下内容： 启动应用，访问 http://localhost:8761 添加如下依赖： 在配置文件application.yml中添加如下配置： 也可使用@EnableEurekaClient注解替代@EnableDiscoveryClient，EnableEurekaClient只支持Eureka，而EnableDiscoveryClient是一个高度的抽象还支持Zookeeper和Consul 只需修改Eureka Server端口号启动多个实例，然后将eureka.client.serviceUrl.defaultZone地址相互配置为其他节点地址即可。而客户端无需配置多个defaultZone，只需配置一个，Eureka Server集群节点之间会相互同步

简单来说， Eureka Server 的高可用，实际上就是将自己也作为服务向其他服务注册中心进行注册，这样就可以形成一组相互注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。 另外，从官网文档中有提到 Zones 、 Regions ， Region 和 Zone （或者Availability Zone）均是 AWS 的概念。在非AWS环境下，我们可以先简单地将region理解为Eureka集群，zone理解成机房。下图就可以理解为一个Eureka集群被部署在了zone1机房和zone2机房中。 对这些概念的其他相关知识，也深入了解，大家感兴趣，可自行搜索下吧。 示例前，先看看集群模式下，Eureka的架构图。 修改spring-cloud-eureka-server项目 1.由于是在同一台进行模拟，首先修改hosts文件，当浏览器请求一个地址时，首先会从此文件选择对应对应的IP地址，找不到时才请求CDS域名解析服务器进行解析 C:WindowsSystem32driversetchosts文件： 127.0.0.1 eureka-server 127.0.0.1 eureka-server1 分别启动2个注册中心 Eureka客户端注册至集群上 客户端只需要通过修改配置文件的eureka.client.service-url.defaultZone值即可。 修改spring-cloud-eureka-client项目 修改配置文件application.properties 分别启动二个服务提供端，启动后，可以看见eureka-client注册到2个注册中心上去了。 高可用测试 为了验证高可用性是否成功，创建一个spring-cloud-eureka-server-ha-test项目，作为服务消费者使用RestTemplate+ribbon进行调用spring-cloud-eureka-client的服务。 创建spring-cloud-eureka-server-consumer-message项目 pom依赖： 1.配置文件，配置注册中心地址 2.启动类，配置RestTemplateBean类，同时加入@LoadBalanced注解实现服务调用。 3.编写一个控制类，简单调用EUREKA-CLIENT服务方法。 4.启动应用类，访问注册中心和 http://localhost:9600 。 PS:福利来了，上源码！福利来了，上源码！ 福利来了，上源码！ https://github.com/TheWays/springCloud 记得点赞哈

EUREKA易瑞康这企业在佛山真是不错了，没有听说什么黑料，而且在里面工作过的都没有差评，都说在公司的幸福感比较高。它家是做中高端的现代家居品牌的，在美国创立的品牌，供应链遍布全球，母公司是很有实力的一个老牌企业。家居行业也属于咱们生活刚需，比较有发展前景。公司里面的晋升机制比较完善，好好做的话是有希望冲击一下管理层，待遇也能跟着提高。新人的待遇是五险、年假、绩效奖、节日奖都有，公司团队很年轻化，风格比较独特，沟通效率高，也不怎么加班……在佛山EUREKA这样的外企感觉并不算很多。要去面试的话可以提前在网上多搜索一些相关资料，做做功课成功率更高。认真答题，希望被采纳。

Eureka 服务端的界面是可以自定义的，而且方式比较简单，下面我们来看下修改方式。 在某一些公司内部，服务注册中心界面可能需要完全自定义，需要携带一些公司的特性以及元素，如果是这样那么本章节的内容可以帮到你，效果可以查看我公开的 Open Eureka Server 服务。 使用 IDEA 开发工具创建一个 SpringBoot 项目，在 pom.xml 内添加依赖如下所示： 我们在启动类 XxxApplication 使用 @EnableEurekaServer 注解来启用 Eureka 管理端的功能，如下所示： 接下来我们在 application.yml 配置文件内添加 Eureka 相关配置信息，如下所示： 在 spring-cloud-netflix-eureka-server-xx.xx.xx.jar 依赖文件内我们可以找到 tempaltes.eureka 目录，结构如下图所示： templates.eureka 目录下存放了 Erueka Server 管理页面的模板文件，我们可以将模板文件复制出来到当前项目的 resources/templates/eureka 目录下，然后进行自定义界面内容。 我们找到 navbar.ftlh 文件，这个文件内是 Eureka Server 在首页显示系统信息、服务注册列表、服务服务器基本信息的展示页面，我们简单在 System Status 分类下的第一个 table 内添加一行信息，如下所示： 我们来启动或重启下本项目，访问http://127.0.0.1:10000，查看效果如下图所示： 通过修改 templates.eureka 目录下的文件我们就可以完成 Eureka Server 界面的自定义的操作，完全可以将页面的内容都进行定制化，心随所动，赶紧行动起来吧~ 本篇文章示例源码可以通过以下途径获取，目录为 customize-eureka-manage-page ：

在我们启动一个服务后，可能要过一分多钟才能被其他服务调用到，那么这种情况不管是开发/测试环境，亦或是生产环境都会影响效率。出现该问题的原因有以下几种： 所以终上所述，一个服务注册上线需要的最大时间为30（eureka.server.response-cache-update-interval-ms）+30（eureka.client.registry-fetch-interval-seconds）+30（ribbon.ServerListRefreshInterval）=90秒。 在服务停掉后，Eureka Server并不能快速的将已停止的服务实例剔除，对调用方而言，请求到已停止的服务实例上则会提示拒绝连接，出现该问题的原因有以下几种： 综合以上服务注册慢/注销慢的原因，我们的解决方案其实就是将上述的一些参数时间缩短。参考配置如下： 上述的配置只适用于中小型应用，需要注意的是，如果把请求Eureka Server的时间都调小的话（比如获取注册表、发送心跳等），在系统服务实例的数量很大的情况下，那么会对Eureka Server造成压力。 如果Eureka服务节点在短时间里丢失了大量客户端的心跳连接时，（注：可能发生了网络故障，有可能客户端实例还在正常运行），那么这个Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好。 对于不存在跨区、跨网络机房的中小型应用而言，建议关闭自我保护模式。

想记住莫过于了解它的更多背景知识了。eureka原是希腊语，音译过来是尤里卡。据说是阿基米德根据比重原理发现测出王冠黄金纯度时所发出的惊叹语。西欧有一个创立于1985年的尤里卡计划，旨在通过科技实力提升全球竞争力。请采纳～

1、在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。

Eureka源码采用1.7.2版本 本人小白，此文为本人阅读源码笔记，如果您读到本文，您需要自己甄别是否正确，文中的说明只代表本人理解，不一定是正确的！！！ 自我保护机制设计的初衷是防止服务注册服务因为本地网络故障，长时间未接受到心跳请求，造成错误的移除大量服务实例，其实调用服务还是可用的 自我保护机制是和自动故障移除联系在一起的，针对的移除实例也是自动故障移除 在服务故障移除的方法中有这样一个判断，当返回false时候，直接返回，不进行故障实例的摘除 进入该方法 关于获取上一分钟心跳总数，Eureka Server内部采用的是定时线程进行统计，使用两个AtomicLong进行保存当前和上一分钟的心跳总数 该方法初始化了运行了定时调度的线程进行统计，默认执行间隔为1min，执行流程： 那么当前的心跳总数是怎么计算的呢，直接看心跳的renew()方法，是否嵌入了计数器累计操作 如上所示，当接收到心跳时，当前心跳计数器进行了递增操作 而getNumOfRenewsInLastMin()获取上一分钟心跳总数就是获取lastBucket数量，再找下该定时任务启动的入口 和自动故障移除的定时同时启动的，那么lastBucket代表了上一分钟的心跳总数 接下来，我们需要看看期望每分钟最小心跳总数的由来： numberOfRenewsPerMinThreshold最开始的初始化计算是在Eureka Server初始化计算的，使用当前Server拉取到的服务实例总数 * 0.85 在openForTraffic()方法中使用初始化拉取的服务实例总数作为基数标准进行计算，(int) (this.expectedNumberOfRenewsPerMin * serverConfig.getRenewalPercentThreshold()) -> count * 2 * 0.85, 集群模式下，count为其他节点中已注册的服务实例总数，单节点就为0 下面我们看看在注册中心接收到注册，下线等请求执行时，维护numberOfRenewsPerMinThreshold 注册，当前实例数量+2，下线，当前实例数量-2，然后再次*0.85，计算期望每分钟最小心跳数 在Eureka Server中有专门的定时任务进行更新numberOfRenewsPerMinThreshold,默认每15min执行一次 主要流程如下： 注意，自动服务故障移除没有进行numberOfRenewsPerMinThreshold的更新 <font color= "blue">服务故障实例的摘除需要判断当前是否处于自我保护模式，而自我保护模式的默认是开启(isSelfPreservationModeEnabled)，需要判断上一分钟的心跳总数是否大于期望每分钟最小心跳数，如果在15分钟内，累计丢失了15%以上的节点心跳，那么Eureka Server就会认为当前所处的网络环境异常，从而处于自动保护模式，故障实例将不会移除，再等待15min后，进行expectedNumberOfRenewsPerMin的基于当前服务实例的重新计算后，自我保护模式才会关闭!</font> 自我保护服务开启模拟：

eureka是蒸汽拖把品牌。而且是那种百年品牌，历史还蛮悠久的，现在在美国的市场占有率也非常高，eureka蒸汽拖把打扫卫生时候蒸汽可以深入到狭缝里面，这个是一般拖把做不到的，而且蒸汽拖把还可以杀菌，应用场景也蛮多的，最近国内要上市了。

Eureka集群没有主从概念，所有节点全部平等，集群间数据通过5个Http接口完成数据同步，下面介绍这几种接口以及同步流程。 假设Eureka1服务最早启动，Eureka2服务启动时将Eureka1作为自己的上报服务(每个Eureka-Client只给一个Eureka-Server上报信息)，首先调用 GET /eureka/apps/ 获取已有注册列表。 获取到注册列表后，将自己添加到注册列表中，并发送注册信息到Eureka1上 将Eureka2注册的事件写入自己的注册列表中，并以广播的形式通知剩余全部节点，收到通知的服务将Eureka2注册到自己的注册列表中 这次与第一步骤类似，但是这次只获取注册列表的变化信息。 Eureka2之后每30s向Eureka1上报健康信息，也就是续约。 过程与第二步一致。 自我保护机制的工作机制是：如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况： Eureka Server存在三个变量：(registry、readWriteCacheMap、readOnlyCacheMap)保存服务注册信息，默认情况下定时任务每30s将readWriteCacheMap同步至readOnlyCacheMap，每60s清理超过90s未续约的节点，Eureka Client每30s从readOnlyCacheMap更新服务注册信息，而UI则从registry更新服务注册信息。

1、eureka的读音：英[ju_ri_k_]，美[ju_ri_k_]2、Eureka，古希腊词语，词性为感叹词，意思是：我发现了，我找到了；有了。3、例句：Eureka!Ifinallyfoundouthissecret!有了！我终于发现了他的秘密！

1、eureka的读音：英[ju_ri_k_]，美[ju_ri_k_]2、Eureka，古希腊词语，词性为感叹词，意思是：我发现了，我找到了；有了。3、例句：Eureka!Ifinallyfoundouthissecret!有了！我终于发现了他的秘密！

1、eureka的读音：英[ju_ri_k_]，美[ju_ri_k_]2、Eureka，古希腊词语，词性为感叹词，意思是：我发现了，我找到了；有了。3、例句：Eureka!Ifinallyfoundouthissecret!有了！我终于发现了他的秘密！

不是正规的英语大概是I got it!/I have found it/yes！ 的意思

eureka.server.enable-self-preservation=true eureka.server.eviction-interval-timer-in-ms= 60000 eureka.server.delta-retention-timer-interval-in-ms=0 eureka.server.rate-limiter-burst-size=10 eureka.server.rate-limiter-enabled=false eureka.server.rate-limiter-full-fetch-average-rate=100 eureka.server.rate-limiter-throttle-standard-clients=false eureka.server.rate-limiter-registry-fetch-average-rate=500 eureka.server.rate-limiter-privileged-clients= eureka.server.renewal-percent-threshold=0.85 eureka.server.renewal-threshold-update-interval-ms=0 eureka.server.response-cache-auto-expiration-in-seconds=180 eureka.server.response-cache-update-interval-ms=0 eureka.server.retention-time-in-m-s-in-delta-queue=0 eureka.server.sync-when-timestamp-differs=true eureka.server.use-read-only-response-cache=true eureka.server.enable-replicated-request-compression=false eureka.server.batch-replication=false eureka.server.max-elements-in-peer-replication-pool=10000 eureka.server.max-elements-in-status-replication-pool=10000 eureka.server.max-idle-thread-age-in-minutes-for-peer-replication=15 eureka.server.max-idle-thread-in-minutes-age-for-status-replication=15 eureka.server.max-threads-for-peer-replication=20 eureka.server.max-threads-for-status-replication=1 eureka.server.max-time-for-replication=30000 eureka.server.min-available-instances-for-peer-replication=-1 eureka.server.min-threads-for-peer-replication=5 eureka.server.min-threads-for-status-replication=1 eureka.server.number-of-replication-retries=5 eureka.server.peer-eureka-nodes-update-interval-ms=600000 eureka.server.peer-eureka-status-refresh-time-interval-ms=0 eureka.server.peer-node-connect-timeout-ms=200 eureka.server.peer-node-connection-idle-timeout-seconds=30 eureka.server.peer-node-read-timeout-ms=200 eureka.server.peer-node-total-connections=1000 eureka.server.peer-node-total-connections-per-host=10 eureka.server.registry-sync-retries= eureka.server.registry-sync-retry-wait-ms= eureka.server.wait-time-in-ms-when-sync-empty=0 eureka.client.enabled=true eureka.client.register-with-eureka=false eureka.client.fetch-registry=false eureka.client.filter-only-up-instances=true eureka.client.serviceUrl.defaultZone=http:// {server.port}/eureka/ eureka.client.eureka-connection-idle-timeout-seconds=30 eureka.client.eureka-server-connect-timeout-seconds=5 eureka.client.eureka-server-read-timeout-seconds=8 eureka.client.eureka-server-total-connections=200 eureka.client.eureka-server-total-connections-per-host=50 eureka.client.cache-refresh-executor-exponential-back-off-bound=10 eureka.client.cache-refresh-executor-thread-pool-size=2 eureka.client.heartbeat-executor-exponential-back-off-bound=10 eureka.client.heartbeat-executor-thread-pool-size=5 eureka.client.eureka-service-url-poll-interval-seconds=300 eureka.client.initial-instance-info-replication-interval-seconds=40 eureka.client.instance-info-replication-interval-seconds=30 eureka.client.registry-fetch-interval-seconds=30 eureka.client.region=us-east-1 eureka.client.prefer-same-zone-eureka=true eureka.client.availability-zones.china=defaultZone,defaultZone1,defaultZone2 eureka.client.fetch-remote-regions-registry= eureka.client.allow-redirects=false eureka.client.client-data-accept= eureka.client.disable-delta=false eureka.client.escape-char-replacement=__ eureka.client.dollar-replacement="_-" eureka.client.g-zip-content=true eureka.client.log-delta-diff=false eureka.client.on-demand-update-status-change=true eureka.client.registry-refresh-single-vip-address= eureka.client.should-enforce-registration-at-init=false eureka.client.should-unregister-on-shutdown=true eureka.instance.hostname=localhost eureka.instance.app-group-name= eureka.instance.appname= eureka.instance.instance-id= eureka.instance.ip-address= eureka.instance.prefer-ip-address=false

来自希腊语，类似" I see " 的意思

nacos和eureka的范围不同，Nacos的阈值是针对某个具体Service的，而不是针对所有服务的；但Eureka的自我保护阈值是针对所有服务的。nacos支持CP和AP两种；eureka只支持AP。nacos使用netty，是长连接；eureka是短连接，定时发送。 Nacos与Eureka的保护方式不同 Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enable-self-preservation: false) Nacos保护方式：当域名健康实例 (Instance) 占总服务实例(Instance) 的比例小于阈值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。

eureka.server.enable-self-preservation=true eureka.server.eviction-interval-timer-in-ms= 60000 eureka.server.delta-retention-timer-interval-in-ms=0 eureka.server.rate-limiter-burst-size=10 eureka.server.rate-limiter-enabled=false eureka.server.rate-limiter-full-fetch-average-rate=100 eureka.server.rate-limiter-throttle-standard-clients=false eureka.server.rate-limiter-registry-fetch-average-rate=500 eureka.server.rate-limiter-privileged-clients= eureka.server.renewal-percent-threshold=0.85 eureka.server.renewal-threshold-update-interval-ms=0 eureka.server.response-cache-auto-expiration-in-seconds=180 eureka.server.response-cache-update-interval-ms=0 eureka.server.retention-time-in-m-s-in-delta-queue=0 eureka.server.sync-when-timestamp-differs=true eureka.server.use-read-only-response-cache=true eureka.server.enable-replicated-request-compression=false eureka.server.batch-replication=false eureka.server.max-elements-in-peer-replication-pool=10000 eureka.server.max-elements-in-status-replication-pool=10000 eureka.server.max-idle-thread-age-in-minutes-for-peer-replication=15 eureka.server.max-idle-thread-in-minutes-age-for-status-replication=15 eureka.server.max-threads-for-peer-replication=20 eureka.server.max-threads-for-status-replication=1 eureka.server.max-time-for-replication=30000 eureka.server.min-available-instances-for-peer-replication=-1 eureka.server.min-threads-for-peer-replication=5 eureka.server.min-threads-for-status-replication=1 eureka.server.number-of-replication-retries=5 eureka.server.peer-eureka-nodes-update-interval-ms=600000 eureka.server.peer-eureka-status-refresh-time-interval-ms=0 eureka.server.peer-node-connect-timeout-ms=200 eureka.server.peer-node-connection-idle-timeout-seconds=30 eureka.server.peer-node-read-timeout-ms=200 eureka.server.peer-node-total-connections=1000 eureka.server.peer-node-total-connections-per-host=10 eureka.server.registry-sync-retries= eureka.server.registry-sync-retry-wait-ms= eureka.server.wait-time-in-ms-when-sync-empty=0 eureka.client.enabled=true eureka.client.register-with-eureka=false eureka.client.fetch-registry=false eureka.client.filter-only-up-instances=true eureka.client.serviceUrl.defaultZone=http://[图片上传失败...(image-8b05e1-1640876153404)] {server.port}/eureka/ eureka.client.eureka-connection-idle-timeout-seconds=30 eureka.client.eureka-server-connect-timeout-seconds=5 eureka.client.eureka-server-read-timeout-seconds=8 eureka.client.eureka-server-total-connections=200 eureka.client.eureka-server-total-connections-per-host=50 eureka.client.cache-refresh-executor-exponential-back-off-bound=10 eureka.client.cache-refresh-executor-thread-pool-size=2 eureka.client.heartbeat-executor-exponential-back-off-bound=10 eureka.client.heartbeat-executor-thread-pool-size=5 eureka.client.eureka-service-url-poll-interval-seconds=300 eureka.client.initial-instance-info-replication-interval-seconds=40 eureka.client.instance-info-replication-interval-seconds=30 eureka.client.registry-fetch-interval-seconds=30 eureka.client.region=us-east-1 eureka.client.prefer-same-zone-eureka=true eureka.client.availability-zones.china=defaultZone,defaultZone1,defaultZone2 eureka.client.fetch-remote-regions-registry= eureka.client.allow-redirects=false eureka.client.client-data-accept= eureka.client.disable-delta=false eureka.client.escape-char-replacement=__ eureka.client.dollar-replacement="_-" eureka.client.g-zip-content=true eureka.client.log-delta-diff=false eureka.client.on-demand-update-status-change=true eureka.client.registry-refresh-single-vip-address= eureka.client.should-enforce-registration-at-init=false eureka.client.should-unregister-on-shutdown=true eureka.instance.hostname=localhost eureka.instance.app-group-name= eureka.instance.appname= eureka.instance.instance-id= eureka.instance.ip-address= eureka.instance.prefer-ip-address=false

意思便是“成功了，找到了。谐音英文是Eureka，意思便是“成功了！找到了！”。形容顾客找到属于自己的想要。

springcloud eureka是注册中心，负责微服务的注册与发现，起到承上启下的作用，在微服务架构中相当于人体的 大脑，很重要，nacos是阿里巴巴出的，功能类似eureka。nacos的部署方式与springcloud eureka不太一样，euraka是需要创建springboot项目，然后将euraka服务端通过gav的方式加载进来，然后部署项目。nacos是直接从阿里巴巴nacos的官网下载jar包，启动服务。Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

为了保护注册中心的服务安全， 避免恶意服务注册到Eureka， 需要对Eureka Server进行安全保护， 本文基于Spring Security方案， 为Eureka Server增加最简单的Basic安全认证。 修改pom.xml，添加spring-boot-starter-security依赖： 修改application.yml，配置用户名密码： 先只启动Eureka Server， 通过浏览器的URL访问注册中心， http://localhost:7001/ 首先会跳到登录界面， 要求输入用户名密码：认证成功后，访问到管理界面： Security默认启用了csrf检验， CSRF一般指跨站请求伪造攻击， 要在Eureka Server端配置关闭csrf检验， 否则Eureka Client无法访问注册中心, 新建类WebSecurityConfig.java如下： 客户端要访问配置中心， 需要修改application.yml， 配置上面的用户名密码： 目前配置文件支持如下格式配置用户名密码： http://user:password@localhost:7001/eureka ， HTTP基本身份认证将自动添加到Eureka Client。 对于更复杂的需求， 可以创建类型为DiscoveryClientOptionalArgs的@Bean， 并将ClientFilter实例注入其中。 注意由于Eureka的限制， 不可能支持每台服务器的基本身份认证凭证， 因此集群时只使用找到的第一组身份认证凭证。 Spring cloud eureka 安全认证基本配置 1.3. Authenticating with the Eureka Server

在Server项目中 访问页面： http://localhost:8771/eureka/apps 查看metadata

在Eureka-Server启动的时候，会启动一个定时任务，用来清理过期的客户端 renewsLastMin.start() ： 在每个Eureka-Server端都维护着，每分钟的续约数量，续约数量是有一个Long类型的变量 来存储的，每过一分钟就需要对这个变量进行清0 ， 因此这个地方是为了启动这个线程 是用来清理过期客户端的任务类 serverConfig.getEvictionIntervalTimerInMs() ： 默认为60秒 , 可配置。 //判断是否过期 // 续约的时候会调用，用来更新最后更新时间 duration ： 过期间隔，默认为90秒 evictionTimestamp ： 实例下线时间，当客户端下线时，会更新这个时间。 lastUpdateTimestamp ： 为最后更新时间 ， 这里有个错误，因为续约的时候，更新这个时间的时候，加上了duration ， 但是在最终做判断的时候 lastUpdateTimestamp + duration + additionalLeaseMs ， 这个地方还加了一遍，也就导致了，当前时间必须要大于实际最后更新时间180秒，才会认为他过期 （撇开additionalLeaseMs这个因素不谈） 从上面可以得知 , 这里有个分批过期的概念，每次最多过期15%的机器，超过15%则不会自动过期 假如检测到过期的实例数量为4台 ， 总数量为10 执行过程过下： 第一个60秒到来，执行任务 也就说仅仅只可以过期两台，那么另外两台怎么办，只能等待下一次任务执行的时候 第二个60秒到来，执行任务 ， 计算是否开启保护机制时，这个时候呢， numberOfRenewsPerMinThreshold还是原来的值，也就是 10 2 0.85 = 17 , 但是由于 存活的机器数量只有6台，则每秒最大续约数为12 ， 12>17 = false , 所以会开启自动保护机制 （如果在一分钟之类，另外两台机器恢复了心跳，16>17 ， 依旧会开启），只能等待15分钟 之后，定时任务重新计算这两个参数的值。 开启自我保护机制之后，则不会继续往下执行了。。 总结： 由上可知，客户端具体的过期时间，是不确定的，但是必须大于180秒， 如果加上定时任务的时间间隔，240秒， 如果第一轮任务执行不到的话，可能会等到第二轮的时候执行，但是如果开启了自我保护机制，则没有第二轮的说法了。 如果不想启用这种机制，那么可以关闭自我保护机制，同时设置registrySizeThreshold = 0； 就可以一次性过期。

ConsulAgent是Consul的核心进程，Agent的工作是维护成员关系信息、注册服务、健康检查、响应查询等等。Consul集群的每一个节点都必须运行agent进程。Agent有两种模式：client或server。 Server要参与consensusquorum，当遇到故障情况时，这些节点通过Raft提供强一致性和强有效性，在Server节点上的较高负载意味着它们应该运行在专属的实例——它们比客户端节点更为资源密集型。在整个集群中，绝大部分都为Client节点。 client把所有的RPCs转发到server端，是相对无状态的。唯一在后台运行的时client端执行了LAN gossip pool，只消耗极少的资源和网络带宽。 Eureka 是什么? Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，一实现SpringCloud的服务发现功能。 GitHub: https://github.com/Netflix/eureka Eureka高层次的体系结构 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通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

注意：InstanceInfo是Euraka最核心的类/对象。 1.先读eureka server的配置信息，从而知道eureka server在哪，以便后面进行注册 2.接着再读取自己的配置信息，然后将自己的信息封装在InstanceInfo实例中，等下将实例发送到eureka server中 3.通过上面步骤已经知道eureka server的地址了，此时先把注册拉取到本地缓存起来 4.将上面封装的InstanceInfo实例发送到eureka server进行注册，然后初始化心跳检测以及缓存刷新（这些都是通过开启后台线程完成的） 5.再次拉取注册表更新本地注册表信息

结论 我们来比较一下，在CAP理论中，zk更看重C和P，即一致性和分区容错性。但Eureka更在意的是A和P，A为高可用。zk中有master和follower区别，当进入选举模式时，就无法正常对外提供服务。但Eureka中，集群是对等的，地位是相同的，虽不能保证一致性，但至少可以提供注册服务。 根据不同的业务场景，各有取舍吧。多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。Eureka还有客户端缓存功能 Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。

Eureka注册中心的管理界面以及服务注册时，没有任何认证机制，如果这个地址有公网IP的话，必然能直接访问到，这样是不安全的，安全性比较差，如果其它服务恶意注册一个同名服务，但是实现不同，可能就有风险了 如何解决这个问题呢？加用户认证即可，通过spring-security来开始用户认证 开启安全认证，并且配置用户信息 重新启动注册中心，访问 http://localhost:8761/ 此时浏览器会提示你输入用户名和密码，输入正确后才能继续访问Eureka提供的管理页面。 注册中心开启认证后，项目中的注册中心地址的配置也需要改变,需要加上认证的用户名和密码

Eureka 出自《交响诗篇》人物简介：年龄不明，高性能LFO "Nirvash"尼尔瓦修 的驾驶员，从外表上看是个留有青色头发的15、16岁少女。优莱卡是由珊瑚岩产生的与人类以同等形态交流的媒介－克拉利安，最初本身并没有任何感情。由于能够良好地驾驭LFO并听从命令，最初被作为军队的杀人工具。但她在与人类的接触中逐渐学习到了情感，在一次屠杀行动中收留了家人被自己杀死的三个孤儿。后脱离军队加入了月光号，偶然认识兰顿后，对自己的存在感产生疑惑，并出现了情绪不稳定的状况。

zookeeper与eureka区别：1：zookeeper保证cp原则（一致性）而Eureka保证的是ap原则（可用性）2：zookeeper在选举期间注册服务瘫痪不可用，而Eureka各个节点平等，只要一台就能保证服务可以，但查询到的数据不一定是最新的，可以很好的应对网络故障导致的部分节点失联3：zookeeper有header和follower角色（当header挂掉，会从剩下的follower里面选举一个header），Eureka各个节点平等4：zookeeper采用半数存活原则（避免脑裂），Eureka采用自我保护机制来解决分区问题5：kafka就是使用的zookeeper作为注册中心，理论上Eureka更适合作为注册中心

本文主要研究下netflix的EurekaHttpClient eureka-client-1.8.8-sources.jar!/com/netflix/discovery/shared/transport/EurekaHttpClient.java eureka-client-1.8.8-sources.jar!/com/netflix/discovery/shared/transport/decorator/EurekaHttpClientDecorator.java eureka-client-1.8.8-sources.jar!/com/netflix/discovery/shared/transport/EurekaHttpClientFactory.java eureka-client-1.8.8-sources.jar!/com/netflix/discovery/shared/transport/TransportClientFactory.java 上面这三个是有专门的类实现，下面这几个是匿名类实现 netflix的eureka关于httpClient的接口为EurekaHttpClient，其工厂方法主要分类top level的EurekaHttpClientFactory以及low level的TransportClientFactory。

u2003u2003在 《有了云服务器能干什么》 一文中曾讲到从小小云有限的资源中扒拉了一小块来折腾微服务，在连肝数日之后，终于有了基本的微服务雏形（有SSO、有权限控制、有跨服务器资源访问）。 u2003u2003接下来会用一个系列来记录微服务折腾的过程。本文主要记录服务发现Eureka的折腾之路。 u2003u2003关于Eureka 的用法网上早已有海量的文章可查阅，所以这里不再赘叙。但是作为资源有限的小云使用，本就不可能运行太多的服务（硬件天花板限制），所以需要调整Eureka Server的配置方案，使其更符合个人小云使用。 u2003u2003我们都知道Eureka默认开启了自保护模式，这个模式很好很强大，就像王者荣耀一样，确实很好玩，可要是没日没夜撸太多，就变成亡者农药了，所以 适度 、 适合 才是最重要的。 u2003u2003作为一个单纯的私人小云，个人觉得没有必要使用Eureka自我保护模式。为什么这么说呢？从其所适合的场景就可以看出。 u2003u2003将上述内容通过简单的例子转换一下，某天小R发现通过微信联系不上女神的时候，那么大概率是对方将小R移出了好友或已读不回（ 收不到续订心跳 ），如果此时小R够理智的话接下来要做的事应该是默默的从微信中删除女神的账号（ 删除无效客户端 ），并通过朋友圈向所有好友宣布已与女神再无关系（ 刷新缓存，更新客户端列表 ），然后等待新的女神向小R发送好友申请（ 新的客户端注册 ）。但要是某天小R发现大部分人都不能通过微信联系的时候（ 失联的客户端超过门限 ），就得考虑是不是自己的微信出问题了( 网络问题或其他非客户端问题 )，而不是把联系不上的好友都删除（ 自我保护，等待故障恢复 ）。 u2003u2003而我们小小云上运行的微服务数量基数小，一两个微服务出现异常就很容易超过Eureka自我保护的门限值，而此时更合理的处理方式是快速移出无效客户端信息，防止将流量引向已故障的服务上（ 快速反馈502错误，减轻网关压力 ），没必要进入自我保护模式等待故障恢复。 u2003u2003关闭自保护模式：<kbd>eureka.server.enable-self-preservation=false</kbd> u2003u2003快速更新是指Eureka Server所维持的客户端信息快速更新，即当有客户端下线时，Eureka Server能立即更新客户端信息表。 u2003u2003那么首先得及时判断客户端是否下线，Eureka Server通过<kbd>eureka.server.renewal-threshold-update-interval-ms</kbd>来控制以什么样的频率去检测所有已注册客户端的心跳。该选项默认为15分钟，不过考虑到本人学艺不精，技不如人做出来的客户端质量拉胯，所以越早发现，才能越早治疗（手动重启），这里我修改为2分钟检测一次。 u2003u2003发现有异常客户端之后，就得抓紧将异常的客户端移出。而Eureka Server是通过<kbd>eureka.server.eviction-interval-timer-in-ms</kbd>控制以什么样的频率去移出已失效的客户端。该选项默认为60秒。当然和上面一样，我希望能更快完成无效客户端的移出动作，所以我修改为5秒。 u2003u2003Eureka Server内部有自己的数据缓存策略，这里不展开细讲。为了更快完成客户端列表的刷新，我们通过禁用ReadOnlyCache缓存来实现。<kbd>eureka.server.use-read-only-response-cache: false</kbd> u2003u2003服务端这样配置差不多就可以做到快速更新了，可是光服务端快是不行的，客户端也得跟上才行。而客户端最需要做的是“ 常联系，快退出 ”。 u2003u2003“常联系”是要客户端加快与服务端发送心跳的间隔，两次心跳间隔时间越长，服务端的反应就越慢，理论上从客户端出现问题到客户端信息被移出，最长时间就是心跳间隔时间。如果心跳间隔为10分钟，那么该客户端最长需要10分钟（此处实际还需加上服务端的检测间隔时间）后才会被移出。 u2003u2003“快退出”则是指客户端出现“失联”后，要让服务端快速、果断的移出该客户端，而不是磨磨蹭蹭拖半天。控制这一切的是由两个选项完成的。 <kbd>eureka.instance.lease-renewal-interval-in-seconds</kbd> <kbd>eureka.instance.lease-expiration-duration-in-seconds</kbd>。 以下是完整配置yml u2003u2003Eureka Server自带了一个web查看页面，可通过该页面查看当前服务端的状态以及注册客户端的状态。原生页面的功能很好用，只是不太适合我的小云而已（毕竟有些功能我都不会用到，自然也就不关注了）。 u2003u2003对于小云上运行的微服务，我更关注的是各个注册的客户端状态是否正常、Eureka状态是否正常（小云资源有限，稍不留神就OOM Kill了）。所以需要自定义Eureka的页面，做到 打开链接，直达关键信息 。 u2003u2003关于Eureka自定义页面网上相关教程也挺多的，这里就不重复了。简单来讲，首先将<kbd>spring-cloud-netflix-eureka-server</kbd>包中templates.erueka目录拷贝至工程resources下，然后按需修改对应的4个ftlh文件即可。 u2003u2003当客户端向Eureka Server注册的时候，Eureka会在30秒内连续3次检测客户端的状态（健康检测），之后才会将该客户端信息刷新至客户端列表当中。而在Docker执行环境下，通常使用编排工具（如Docker-compose）将所有服务一起启动，虽然服务均已运行，但是仍有可能收到404错误（需等待30秒后再访问）。 u2003u2003客户端向Eureka Server注册时默认使用主机名进行注册，但是当该客户端在Docker中运行时，使用的主机名其实为Docker Container ID。如果是跨服务器访问则无法通过其查找到真正的客户端（DNS不知道注册使用的Docker Container ID所对应的IP地址），而如果仅使用<kbd>preferIpAddress</kbd>选项，虽然可用IP地址替换主机名完成注册，但不幸的是，所使用的IP为Docker Container IP，而非跨服务器所能访问的地址（一般需公网IP地址），所以依然不可被别的服务器使用。因此还需加上<kbd>eureka.instance.ip-address</kbd>，通过手动指定IP地址的方式，让客户端可达，这在后续记录中也会提到。

通过翻阅Eureka源码，发现有一个Configuration： org.springframework.cloud.netflix.eureka.server.EurekaServerAutoConfiguration,里面有注册一个InstanceRegistry. 都已经发现这个类，那么接下来就好办了，我们重写覆盖这个注入即可。 废话不多说，找到关键注册类，覆盖InstanceRegistry即可 写一个CustomInstanceRegistry,配置写在类注释中。 注意:允许注册的Ip地址配置在属性文件中,YML文件配置示例,注意这个配置是我设置的。 备注:所有框架都是有套路的，不是我们没有造框架的能力，而是我们懒，喜欢拿来主义。