架构师：通透，才能写出好代码！

回想一下，在本系列第一篇文章就有提到过，Eureka它是使用轻量级DI框架：谷歌的Guice来管理其依赖的。通过前面这么多篇文章的学习，有理想相信亲们已经了解了Eureka几乎每个组件的作用以及**它们的依赖关系**。即使如此，但若现在要你构件其一个**完整可用**的Eureka Client客户端，你觉得呢？相信拿到这个“题目”的感觉和我是一样的：我去，这也太麻烦了吧，组件这么多，框架依赖关系还一层一层的错综复杂，难点并不是因为它困难，而是很麻烦。是的，这是每一个稍大型软件均会遇见的难题：类/组件多了

如果说Eureka里最核心的一个对象/类是什么，我想当属`InstanceInfo`了。它贯穿于`Client、Server`俩端，承载着一个实例的所有描述，它是事件的主体，一切皆围绕着它来进行。另外，还需注意的是Eureka使用的是Guice作为它的依赖注入DI基础组件，因此源码处你进场能看见`@Singleton、@Inject`等注解的使用，为了不妨碍你的阅读和研究，建议可先认识下`Google Guice`这个轻量级依赖注入的相关支持，这里我也很暖心的给你准备好了直达电梯

本系列文章学习源生Eureka，以及它在`Spring Cloud`技术体系中的应用和原理剖析。本文开始研究Spring Cloud体系中的注册中心：当前最流行的`Eureka`。`Eureka`作为服务注册中心对**整个微服务架构**起着**最核心**的整合作用，因此我个人认为对Eureka还是有很大的必要进行深入研究。

Netflix OSS套件，Spring Cloud的官方推荐

上坡的路都是累的设置难受的，要控制好自己的情绪。–> 返回专栏总目录 <–代码下载地址：https://github.com/f641385712/netflix-learning目录前言正文详解String#intern()源码(native代码)参阅代码示例总结前言继上篇文章分享了Eureka内置的一个小工具RateLimiter限流器后，本文继续分享其另外一个实用小...

关于**基于令牌桶**的限流器实现，我想最出名的当属Google开源项目Guava中的`RateLimiter`了吧，它具有非常强大的功能特点，使用也非常的方便。但本文介绍的不是Google家族的`RateLimiter`，而是Eureka自己实现的一个工具`RateLimiter`，它虽然功能没Google的那么强大，但实现了最为核心的功能，所以还是值得学习和使用的。

关于`DiscoveryClient`这一个类的解析竟然已经到了第8篇了，经过了前7篇高密度的讲述，主体内容其实已经基本完成了，但正所谓“革命尚未统一”，就差本文临门一脚。接下来将会把其余下内容：接口方法的实现进行讲述清楚便算大功告成，并且对其最为重要的`shutdown()`方法进行一个详细的介绍。本文内容简单易懂，`shutdown()`方法实用性较强，相信会是一段颇为愉快的“旅程”。

本文接着上篇文章的讲解，继续深入`DiscoveryClient`初始化阶段剩下的两个步骤：`register()`注册当前实例和`initScheduledTasks()`初始化调度任务。

在通过前面几篇文章介绍`DiscoveryClient`后，对它的核心内容已经有了较为深入的理解，此刻你基本可以放心的对自己说：对Eureka（client端）已经了解到了7、8成了。但作为一个有态度、有追求的程序员，我们可以更优秀。本文将结合前几篇所述内容作为铺垫，深入挖掘`DiscoveryClient`初始化过程中几个大步骤的细节，进入精雕细琢阶段，包括它对“众多”任务的组织和启动，掌握其要领方得安心。

DiscoveryClient中有两个非常重要的内部类：`HeartbeatThread`和`CacheRefreshThread`，他俩是调度任务中真正干活的两个**任务类**，因此单摘出来放在一起讲述一把，防止迷路。另外，前面有篇文章专门介绍了实例复制器`InstanceInfoReplicator`，它也用于周期性对当前实例进行注册。那么你是否疑问：它和`HeartbeatThread`有什么区别和联系呢？本文也会进行对比

继上篇文章介绍了对注册表的全量获取后，本文来到注册表获取的主菜：Delta增量获取。增量操作并不少见，在MySql、Redis等里都有所体现，它一种轻量级方式实现，好处不言而喻。如果说全量获取是初级程序员，那么增量获取怎么也算高工了。增量获取属于精细化操作，它需要考虑的因素众多，因此处理起来也就会复杂一些。

Eureka属于c-s的设计模式，Client端本地需要维护一份注册表信息，因此它需要周期性的去远程Server端获取，这种获取注册表的方式有两种：**全量获取和增量获取**。全量获取：顾名思义，**大而全**是它的特点，通信上属于一种相对较重的操作。增量获取：每次仅获取**发生了变化的数据**，通信轻量，但缺点是落地逻辑复杂，需要client + server端共同协作实现。本文将先重点介绍全量获取的实现。

主要介绍了`DiscoveryClient`的成员属性，达30+个之多。我们发现其成员属性中，绝大多数否是final修饰，也就是说他们大多均得在`DiscoveryClient`初始化阶段完成赋值，由此你也能感受到它初始化的“压力”。确实，`DiscoveryClient`的初始化阶段是它，**甚至是整个Eureka Client**最为重要的逻辑片段之一，属于掌握Eureka一定、必须精通的知识点。在上文已经了解了它的成员属性以及含义后，本文在其基础上继续深入，深入讲解`DiscoveryClient

说到`DiscoveryClient`，很多小伙伴对它望而却步。那么从此篇开始，**正式**进入Eureka Client端最深水区内容，同时它也是最难啃的一块骨头：`DiscoveryClient`。由于本类过于庞大且复杂，我会分拆为多篇文章逐步讲解，势必要达到完全掌握的目的。了解一个类，就从它的**成员属性**开始吧。本文将对`DiscoveryClient`的众多成员属性做详尽解释，相信通过本文你也能大概了解到它的全貌了。

上篇文章介绍了`DiscoveryClient`服务注册时使用到的一个小工具`InstanceInfoReplicator`，其实它也属于前置知识。本文继续此部分的内容，为详细了解Eureka Client端最重要API `DiscoveryClient`做好铺陈。这么做的目的是想说：直接面对一个庞然大物是有“恐惧”的，然而流行框架的优点是它一般都具有良好的“模块化”设计，因此我们便可针对每个相对较小的模块逐个击破之，最后再知识整合即可。

`DiscoveryClient`作为服务发现客户端，提供服务注册功能是其核心能力之一。在进行Register服务注册的时候，最终目的就是把本实例`InstanceInfo`发送给Eureka Server服务端。看似比较简单，但想作成一个产品级的功能还是有众多因素需要考虑的：周期性执行、数据准确性、自动执行、手动触发、并发、限流等，这些因素均可能影响着注册上去数据的准确性，因此有必要考虑在内。为了集中解决这些小问题，Eureka提供了一个为服务注册小工具：`InstanceInfoReplicator

`Eureka`作为一个注册中心，核心功能可概括为两个：服务注册和服务发现/服务查找。它属于C-S架构，服务注册属于Server端提供的能力，而服务查找它贯穿于服务端及客户端均有，它们的公用抽象接口是`LookupService`。本文以及接下来几篇文章会讲解客户端对服务查找的实现：通过请求服务端获取注册列表，提供给服务使用。

上篇文章介绍了使用`EurekaHttpClients`可以快速创建`ClusterResolver`集群解析器，但是相关方法均为私有的，并不可直接访问（`newBootstrapResolver()`除外）。主要原因是Eureka并不希望你直接访问它（也没这种必要），这些方法仅为构建一个`EurekaHttpClient`实例来提供支持即可，这便是本文内容。本文将结合具体的实例代码，全面介绍`EurekaHttpClients`的使用方式。

前面用多篇文章详细介绍了远程通信模块中`EurekaHttpClient`的实现，含Low-Level以及Top-Level的各种实现。那么面对这么多的底层or高层实现，如何快速组合得到一个最终可用的、具有产品级功能的远程通信Client客户端呢？Eureka为了简化这个操作，提供了`EurekaHttpClients`工具对常用典型场景做了快速处理，这边是将下来要讲解的主要内容。

上篇文章从源码处了解到了`RetryableEurekaHttpClient`的工作原理，作为`EurekaHttpClient`高级别实现中最重要的一个，本文将用代码来演示它的使用，达到巩固理解以及能够深入了解Eureka内部机制的目的。另外一个重点是介绍它的`transport.retryableClientQuarantineRefreshPercentage`这个配置项，因为有一句话叫：只要了解了此配置项，肯定就了解了`RetryableEurekaHttpClient`。

接着上文的节奏，本文来到`EurekaHttpClient`的top-level实现中最后一个，也是最为重要的一个实现：`RetryableEurekaHttpClient`，它用于保证Client端的高可用。如果你了解了Hystrix、Ribbon、Hystrix等组件你会发现，它们都会有涉及到重试的相关知识点。因为业内基本有这么一个共识：只要涉及到远程通信必有Retry重试，而作为C-S模式的实现，`Eureka`更是不例外。

前面已有几篇文章介绍了`EurekaHttpClient`接口以及其Low-Level实现：`JerseyApplicationClient`。对于底层实现非常的干脆利落，无异于直接使用HC发送请求，正常情况下可以work得很好，但是缺乏容错性等一些产品及特性如“重试”等。本文将介绍`EurekaHttpClient`的Top-Level部分，它**在Low-Level部分的基础上**包裹上一些产品及的功能，以能提高容错性，达到高可用的目的。实际生产中不可能直接使用Low-Level的实现，而是使用经过

接着上文的内容，本文继续介绍另外一个非常重要的包装器模式的`ClusterResolver`实现类：`AsyncResolver`。字面意思：它是一个异步解析器，但其实却又不是传统意义上的异步的意思，那到底意寓如何，本文将作出解释说明。关于`ClusterResolver`已经持续用了好几篇文章，本文是它的最后一篇。`ClusterResolver`对理解高可用集群的搭建非常重要，因此若你近期想尝试Eureka的高可用建设，需要深入了解一波。

前两篇对`ClusterResolver`以及其几个**独立子类**进行了讲解，本文继续。从本文起将介绍其**装饰者模式**的几个子类，它的最大特点是：可以装饰任意一个`ClusterResolver`解析器，在其基础上包装/扩展上对应功能。装饰者模式有个非常显著的特点：它对目标进行“包裹”，并且可以可以一层一层的一直包裹下去。本文主要介绍`ZoneAffinityClusterResolver`：它在目标解析器上面增加了区域感知的能力。

本文继续上文的内容，介绍`ClusterResolver`的其它实现如：本地集群解析器`ApplicationsResolver`。

注册中心是在微服务体系中是最重要的基础设施之一，对高可用的要求是极高的。比如`Eureka`在生产上肯定是集群式部署，要求高一点的甚至还会采取多区域(region)、多可用区(zone)进行混合部署。那么既然Eureka Server端部署如此“复杂”，Client端如何“配合”呢？这边是本文要介绍的集群解析器`ClusterResolver`它的作用。

上篇文章介绍了Eureka一个迷人小工具`TimedSupervisorTask`：它是Eureka进行周期性任务调度如心跳、缓存刷新的基础。本文继续介绍它另外一个小工具`EndpointUtils`，不同于`TimedSupervisorTask`它是一个传统的工具类：提供一些静态方法来处理和`Eureka`端点`EurekaEndpoint`相关的工作。本工具类提供（从配置文件里）解析出`DiscoveryClient`使用的`ServiceUrl`的工具方法，这些处理规则对你了解**Eureka是

本文介绍Eureka里一个设计巧妙、代码简洁的迷人小工具类：`TimedSupervisorTask`。它是一个固定间隔的周期性任务（因为它自己实现了`Runnable`接口），一旦遇到**timeout超时**就会将下一次任务的执行时间**翻倍**，如果继续超时就继续翻倍，直到达到设定的上限为止（达到上限后就是固定时间间隔了），周而复始。因为它实现简单，但达到的效果却很好，被广泛运用在Eureka的各种定时任务里，因此本文予以介绍学习。

通过前两篇文章一步一步介绍了如何构建出一个`JerseyApplicationClient`实例来完成服务注册、服务下线等功能。而上文讲到了使用Eureka提供的`EurekaJerseyClient`通过Builder模式去构建已经比较方便了，但是仍旧存在一个小问题：无法摆脱`Jersey`关键字的感知，自然底层上也就无法摆脱对Jersey库的强依赖。即使你并不需要使用Jersey的API来做事，但使用时你却**明显的知道**你实际就是在用Jersey来干活，似乎有点欲盖弥彰。这种“强耦合”很明显是制

上篇文章介绍了Eureka底层通信模块中的默认基于Jersey实现：`JerseyApplicationClient`，文末指出我们一般并不会通过构造器去**直接**构造出它的实例来完成请求的发送。本文将结合代码示例的方式进一步讲述为何不建议手动构建的原因，以及逐步引导出“规范”的使用方式。

我们知道，Eureka不同于别的组件，它属于C-S的模式，具有客户端和服务端（服务端可以是集群），so那必然在C和S之间需要**远程通信**。而其实远程通信的方式有多种，如http、tcp等，首篇文章已经说过Eureka它是基于Http协议的RESTAPI来实现的通信，因此C端发送的定时Http请求。Eureka仅仅是**默认使用**Jersey作为它的HC来发送Http请求，但其实它并没有限制死HC的具体技术实现，因为它面向的是抽象接口`EurekaHttpClient`去做的。

前面文章已经介绍了`InstanceInfo`，知道了它是个不带行为的近似POJO类，特点是属性特别的多，因此直接使用起来挺笨重的且多有不便。在加上它并没有重要逻辑的管理，因此本文介绍一个它的管理类：`ApplicationInfoManager`，以后你若要操作`InstanceInfo`一般均可通过它来完成。

通过前面文章我们已经了解了`Eureka`的核心概念之一：实例`InstanceInfo`，实例可以说是Eureka操作的最小单位。本文继续介绍其两个范围更广的概念：应用(`Application`)和注册表(`Applications`)。

接着上文介绍完`EurekaInstanceConfig`对于实例的配置后，本文继续介绍对Client客户端的配置接口：`EurekaClientConfig`。他两者将共同为`EurekaClient`的初始化提供基础数据支持。

大家对`Spring Cloud`技术体系的使用应该有个感受：配置太多了，真的是多如牛毛啊。这是实话且是现状，因此坊间笑言：现在很多架构师为“配置工程师”或许更为恰当。话“粗”理不“粗”，但这足矣体现了配置对一个组件的重要性，so本文及后面几篇文章会着重介绍这些配置，逐个解释其含义，以及辅助代码介绍如何使用。