微做事架构三大要素，业务建模、技能体系和研发过程。

微做事架构的第一要素：业务建模

为什么我们首先须要考虑的是这个要素呢？由于微做事架构与传统 SOA 等技能体系有实质差异，便是其做事的粒度和做事本身的面向业务和组件化特性。
针对做事建模，我们首先须要明确做事的种别，以及做事与业务之间的关系，尽可能明确领域的边界。

针对做事建模，推举利用领域驱动设计（Domain Driven Design，DDD）方法，通过识别领域中的各个子域、判断这些子域是否独立、考虑子域与子域的交互关系，从而明确各个界线高下文（Boundary Context）之间的边界。

对付领域的划分，业界主流的分类方法认为，系统中的各个子域可以分成核心子域、支撑子域和通用子域三种类型，个中系统中的核心业务属于核心子域，专注于业务某一方面的子域称为支撑子域，可以作为某种根本举动步伐的功能可以归到通用子域。
下面以电商系统为例子。

务环绕业务能力建模，而业务能力每每表示的是一种分层构造。
按照我的履历，我们可以把业务体系中的做事分成如下几种类型：根本做事、通用做事、定制服务和其他做事等。
这里，我们同样给出基于电阛阓景的业务做事分层示例图，如下所示：

每个行业、每个公司具有不同的业务体系和产品形态，我无意对业务建模的运用处景做过多展开。
但在课程的后续内容中，我们会基于 DDD 设计思想，并通过一个详细的案例来先容如何完成对系统的业务建模，以帮助你在日常开拓过程中节制如何利用 DDD 来完成对业务系统的领域建模的系统方法。

微做事架构的第二要素：技能体系

在本课程中，我也基于目前业界主流的微做事实现技能提炼了八大技能体系，包括做事通信、做事管理、做事路由、做事容错、做事网关、做事配置、做事安全和做事监控。

做事通信

对付微做事架构而言，我们关注的是网络连接模式、I/O 模型和做事调用办法。

我们知道基于TCP 协议的网络连接有两种基本办法，也便是常日所说的长连接和短连接。
Dubbo 框架就采取的是长连接，而本课程中要先容的 Spring Cloud 则采取了短连接。

做事之间通信的另一个关注点是 I/O 模型。
I/O 模型也有壅塞式 I/O 和非壅塞式 I/O 等多种实现办法。
以做事网关而言，像Netflix 的 Zuul便是壅塞式 I/O，而Spring 自研的 Spring Cloud Gateway则采取的是非壅塞式 I/O。

做事通信的另一个主题是调用办法，这方面同样存在同步调用和异步调用两大类实现机制。
为了简化开拓职员的利用过程，常日都会采取异步转同步的实现机制，也便是说开拓职员利用同步的办法进行方法调用，而框架本身会基于 Future 等机制实现异步的远程处理。

做事管理

做事注册中央是保存做事调用所需的路由信息的存储仓库，也是做事供应者和做事消费者进行交互的媒介，充当着做事注册和创造做事器的浸染。
诸如 Dubbo、Spring Cloud 等主流的微做事框架都基于 Zookeeper、Eureka 等分布式系统折衷工具构建了做事注册中央。

做事路由

Spring Cloud 等主流的微做事框架也都内置了 Ribbon 等客户端负载均衡组件。

另一方面，负载均衡的出发点更多的是供应做事分发而不是办理路由问题，常见的静态、动态负载均衡算法也无法实现风雅化的路由管理。
这时候我们就可以采取路由规则。
路由规则常见的实现方案是白名单或黑名单，即把须要路由的做事地址信息（如做事 IP）放入可以掌握是否可见的路由池中进行路由。
同样，路由规则也是微做事开拓框架的一项常见功能。

做事容错

业界存在一批与做事容错干系的技能组件，包括以失落效转移 Failover 为代表的集群容错策略，以线程隔离、进程隔离为代表的做事隔离机制，以滑动窗口、令牌桶算法为代表的做事限流机制，以及做事熔断机制。
而从技能实现办法上看，在 Spring Cloud 中，这些机制部分包含不才面要先容的做事网关中，而另一部分则被提炼成单独的开拓框架，例如专门用于实现做事熔断的 Spring Cloud Circuit Breaker 组件。

做事网关

做事网关的核心要点是，所有的客户端和消费端都通过统一的网关接入微做事，在网关层处理所有的非业务功能。

在功能设计上，做事网关在完成客户端与做事器端报文格式转换的同时，它可能还具有身份验证、监控、缓存、要求管理、静态相应处理等功能。
另一方面，也可以在网关层制订灵巧的路由策略。
针对一些特定的 API，我们须要设置白名单、路由规则等各种限定。
在本课程中，我们会基于 Netflix Zuul 和 Spring Cloud Gateway 这两种网关对这些功能分别展开先容。

做事配置

在微做事架构中，考虑到做事数量和配置信息的分散性，一样平常都须要引入配置中央的设计思想和干系工具。
与注册中央一样，配置中央也是微做事架构中的根本组件，其目的也是对做事进行统一管理，差异在于配置中央管理的工具是配置信息而不是做事的实例信息。

为了知足以上哀求，配置中央常日须要依赖分布式折衷机制，即通过一定的方法确保配置信息在分布式环境中的各个做事中能得到实时、同等的管理。
可以采取诸如 Zookeeper 等主流的开源分布式折衷框架来构建配置中央。
当然，像 Spring Cloud 也供应了专门的配置中央实现工具 Spring Cloud Config。

做事安全

一样平常意义上的访问安全性，都是环绕认证和授权这两个核心观点来展开的。
也便是说我们首先须要确定用户身份，然后再确定这个用户是否有访问指定资源的权限。
站在单个微做事的角度讲，我们系统每次做事访问都能与授权做事器进行集成以便获取访问 Token。
站在多个做事交互的角度讲，我们须要确保 Token 在各个微做事之间的有效传播。
另一方面，做事内部，我们可以利用不同的访问策略限制服务资源的访问。

在实现微做事安全访问上，我们常日利用 OAuth2 协议来实现对做事访问的授权机制，利用 JWT 技能来构建轻量级的认证体系。
Spring 家族也供应了 Spring Security 和 Spring Cloud Security 框架来完全这些组件的构建。

做事监控

在微做事架构中，当做事数量达到一定量级时，我们难免会碰着两个核心问题。
一个是如何管理做事之间的调用关系？另一个是如何跟踪业务流的处理过程和结果？这就须要构建分布式做事跟踪机制。

分布式做事跟踪机制的建立须要完成调用链数据的天生、采集、存储及查询，同时也须要对这些调用链数据进走运算和可视化管理。
这些事情不是大略一个工具和框架能全部完成，因此，在开拓微做事系统时，我们常日会整合多个开拓框架进行链路跟踪。
例如，在 Spring Cloud 中，就供应了 Spring Cloud Sleuth 与 Zipkin 的集成方案。

微做事架构的第三要素：研发过程

Martin Fowler 在先容微做事架构时，同样也提出了环绕“业务功能”组织团队的研发管理理念。

当探求把一个大的运用程序进行拆分的方法时，研发过程常日都会环绕产品团队、项目管理、大前端和做事器端团队而展开，这些团队也便是常日所说的职能团队。
任何一个需求，无论大小，都将导致跨团队协作，从而增加沟通和协作本钱。

而微做事架构则方向环绕业务功能的组织来分割做事，而不是面向某项技能能力。
因此，团队是跨职能的特色团队，每个做事都环绕着业务进行构建，并且能够被独立支配莅临盆环境。
这部分内容并不是本课程的重点，我们不做进一步展开。

Spring Cloud先容

Spring Cloud 所基于的 Spring Boot，已经成为 Java EE 领域中最盛行的开拓框架，用来简化 Spring 运用程序的框架搭建和开拓过程。

在设计思想上，Spring Boot 充分利用约定优于配置（Convention over Configuration）的自动化配置机制。
与传统的 Spring 运用程序比较， Spring Boot 在启动依赖项自动管理、简化支配并供应运用监控等方面对开拓过程做了优化。

Spring Cloud 中的组件非常多，我们无意对所有组件都进行详细展开，而是梳理了开拓一个微做事系统所必需的八大核心组件。
如下图所示。

案例驱动

在物联网和智能穿着式设备日益发达确当下，试想一下这样的日常场景，患者通过智好手环、便携式脉诊仪等一些智能穿着式设备检测自身的各项康健信息，然后把这些康健信息实时上报到云平台，云平台检测到用户康健信息中的非常情形时会通过人工或自动的办法进行一定的康健干预，从而确保用户康健得到担保。
这是大康健领域非常范例的一个业务场景，也是我们案例的来源。

领域驱动

从领域建模的角度进行剖析，我们可以把该系统分成三个子域，即：

用户（User）子域，用于用户管理，用户可以通过注册成为系统用户，同时也可以修正或删除用户信息，并供应用户信息有效性验证的入口。
设备（Device）子域，用于设备管理，医护职员可以查询某个用户的某款穿着式设备以便获取设备的详细信息，同时基于设备获取当前的康健信息。
康健干预（Intervention）子域，用于康健干预管理，医护职员可以根据用户当前的康健信息天生对应的康健干预。
当然，也可以查询自己所提交康健干预确当前状态。

从子域的分类上讲，用户子域比较明确，显然该当作为一种通用子域。
而康健干预是 SpringHealth 的核心业务，以是该当是核心子域。
至于设备子域，在这里比较方向于归为支撑子域。

基于以上剖析，我们可以把 SpringHealth 划分成三个微做事，即 user-service、device-service 和 intervention-service。
下图展示了 SpringHealth 的基本架构，在图中，intervention-service 须要基于 REST 风格完成与 user-service 和 device-service 做事之间的远程交互。

做事设计

做事列表

当我们采取 Spring Cloud 构建完全的微做事技能办理方案时，部分技能组件须要通过独立做事的形式进走运作，详细包括：

（1）注册中央做事。
我们将这个做事命名为 eureka-server。

（2）配置中央做事。
我们将这个做事命名为 config-server。

（3）API网关做事。
针对 Zuul 和 Spring Cloud Gateway 这两款工具，我们建立两个独立的 zuul-server 和 gateway-server 做事，并根据须要分别采取个中的一个做事进走运行。

（4）安全授权做事。
我们把这个做事命名为 auth-server。

（5）案例中末了一个根本举动步伐类做事是 Zipkin 做事，这个做事并不是必需的，而是取决于我们是否须要对做事访问链路进行可视化展示。
因此将构建一个独立的 zipkin-server 做事。

以上这种划分只是一种场景。

做事数据

在案例中，我们针对三个业务做事，也将建立独立的三个数据库，数据库的访问信息通过配置中央进行集中管理，如下图所示：

利用 Spring Cloud 实现做事管理

做事管理

从架构设计上讲，状态变更管理可以采取发布-订阅模式，表示在做事供应者可以根据做事定义发布做事，而做事消费者则通过对自己感兴趣的做事进行订阅并获取包括做事地址在内的各项元数据。
发布-订阅功能还表示在状态变更推送，即当注册中央做事定义发生变革时，主动推送变更到该做事的消费者。

基于发布-订阅设计思想，就出身了一种做事监听机制。
做事监听机制确保做事消费者能够实时监控做事更新状态，是一种被动吸收变更关照的实现方案，常日采取监听器以及回调机制，如下图所示。

做事注册

基于 Eureka 构建注册中央（不建议利用，厂家放弃更新）

构建单点 Eureka 做事器

新建 Maven 工程并命名为 eureka-server。
同时我们引入了 spring-cloud-starter-eureka-server 依赖，该依赖是 Spring Cloud 中实现 Spring Cloud Netflix Eureka 功能的主体 jar 包：

创建 Spring Boot 的启动类 EurekaServerApplication，代码如下所示。
包含 @EnableEurekaServer 表明的做事意味着便是一个 Eureka 做事器组件。

Eureka 也为开拓职员供应了一系列的配置项。
这些配置项可以分成三大类，一类用于掌握 Eureka 做事器端行为，以 eureka.server 开头；一类则是从客户端角度出发考虑配置需求，以 eureka.client 开头；而末了一类则关注于注册到 Eureka 的做事实例本身，以 eureka.instance 开头。
请把稳，Eureka 除了充当做事器端组件之外，实际上也可以作为客户端注册到 Eureka 本身，这时候它利用的便是客户端配置项。

现在，我们考试测验在 eureka-server 工程的 application.yml 文件中添加了如下配置信息。
我们不肯望 Eureka 做事对自身进行注册，registerWithEureka、fetchRegistry都设置为false。

构建 Eureka 做事器集群

我们常日都须要构建一个 Eureka 做事器集群来确保注册中央本身的可用性。
与传统的集群构建办法不同，如果我们把 Eureka 也视为一个做事，也便是说 Eureka做事自身也能注册到其他 Eureka 做事上，从而实现相互注册，并构成一个集群。
在 Eureka中，这种实现高可用的支配办法被称为 Peer Awareness 模式。

现在我们准备两个 Eureka 做事实例 eureka1 和 eureka2。
在 Spring Boot 中，我们分别供应 application-eureka1.yml 和 application-eureka2.yml 这两个配置文件来设置干系的配置项。
个中 application-eureka1.yml 配置文件的内容如下：

对应的，application-eureka2.yml 配置文件的内容如下：

构建 Eureka 集群模式的关键点在于利用客户端配置项 eureka.client.serviceUrl.defaultZone 用于指向集群中的其他 Eureka 做事器。
以是 Eureka 集群的构建办法实际上便是将自己作为做事并向其他注册中央注书籍身，这样就形成了一组相互注册的做事注册中央以实现做事列表的同步。
显然，这个场景下 registerWithEureka 和 fetchRegistry配置项该当都利用其默认的 true 值，以是我们不须要对其进行显式的设置。

如果你考试测验利用本机搭建集议论况，显然 eureka.instance.hostname 配置项中的 eureka1 和 eureka2 是无法访问的，以是须要在本机hosts 文件中添加以下信息。

127.0.0.1 eureka1

127.0.0.1 eureka2

理解 Eureka 做事器实现事理

做事注册（Register）是做事管理的最基本观点，内嵌了 Eureka 客户真个各个微做事通过向 Eureka 做事器供应 IP 地址、端点等各项与做事创造干系的基本信息完成做事注册操作。

由于 Eureka 客户端与做事器端通过短连接完成交互，以是在做事续约（Renew）中，Eureka 客户端须要每隔一定韶光主动上报自己的运行时状态，从而进行做事续约。

做事取消（Cancel）的意思便是 Eureka 客户端主动奉告 Eureka 做事器自己不想再注册到 Eureka 中。
当Eureka客户端连续一段韶光没有向 Eureka 做事器发送做事续约信息时，Eureka 做事器就会认为该做事实例已经不再运行，从而将其从做事列表中进行剔除（Evict）。

Eureka 做事存储源码解析

对付一个注册中央而言，我们首先须要关注它的数据存储方法。
在 Eureka 中，我们创造 InstanceRegistry 接口及实在现类（位于 com.netflix.eureka.registry 包中）承接了这部分职能。
InstanceRegistry 的类层构造如下所示：

从上图中，不丢脸出 Spring Cloud 中同样存在一个 InstanceRegistry（位于 org.springframework.cloud.netflix.eureka.server 包中），它实际上是基于 Netflix 中 InstanceRegistry 实现的一种包装。
我们在上图中 InstanceRegistry 接口的实现类 AbstractInstanceRegistry 中创造了 Eureka 用于保存注册信息的数据构造，如下所示：

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

可以看到这是一个双层的 HashMap，采取的是 JDK 中线程安全的 ConcurrentHashMap。
个中第一层的 ConcurrentHashMap 的 Key 为 spring.application.name，也便是做事名，Value 为一个 ConcurrentHashMap；而第二层的 ConcurrentHashMap 的 Key 为 instanceId，也便是做事的唯一实例 ID，Value 为 Lease 工具。

Eureka 采取 Lease（租约）这个词来表示对做事注册信息的抽象，Lease 工具保存了做事实例信息以及一些实例做事注册干系的韶光，如注册韶光 registrationTimestamp、最新的续约韶光 lastUpdateTimestamp 等。
如果用图形化的表达办法来展示这种数据构造，可以参考下图：

而对付 InstanceRegistry 本身，它也继续了 Eureka 中两个非常主要的接口，即LeaseManager 接口和 LookupService 接口。
个中 LeaseManager 接口定义如下：

显然 LeaseManager 做的事情便是 Eureka 注册中央模型中的做事注册、做事续约、做事取消和做事剔除等核心操作，关注于对做事注册过程的管理。
而 LookupService 接口定义如下，关注于对运用程序与做事实例的管理：

在内部实现上，实际上对付注册中央做事器而言，做事注册、续约、取消和剔除平分歧操作所实行的事情流程基本同等，即都是对做事存储的操作，并把这一操作同步到其他 Eureka 节点。
我们这里选择用于做事注册操作的 register 方法进行展开，register 方法非常长，我们对源码进行裁剪，得出如下所示的核销处理流程：

Eureka 做事缓存源码解析

Eureka 做事器端组件的另一个核心功能是供应做事列表。
为了提高性能，Eureka 做事器会缓存一份所有已注册的做事列表，并通过一定的定时机制对缓存数据进行更新。

我们知道为了获取注册到 Eureka 做事器上详细某一个做事实例的详细信息。

Eureka 中所有对做事器真个访问都是通过RESTful 风格的资源（Resource） 进行获取，ApplicationResource 类（位于com.netflix.eureka.resources 包中）供应了根据运用获取注册信息的入口。
我们来看该类的 getApplication 方法，核心代码如下所示：

可以看到这里是构建了一个 cacheKey，并直接调用了 responseCache.get(cacheKey) 方法来返回一个字符串并构建相应。
个中最核心的便是这里的 get 方法：

从类层关系上看，ResponseCache 只有一个实现类 ResponseCacheImpl，我们来看它的 get 方法，创造该方法利用了如下处理策略：

可以看到上述代码中有两个缓存，一个是 readOnlyCacheMap，一个是 readWriteCacheMap。
个中 readOnlyCacheMap 便是一个 JDK 中的 ConcurrentMap，而 readWriteCacheMap 利用的则是 Google Guava Cache 库中的 LoadingCache 类型。
在创建 LoadingCache过程中，缓存数据的来源是调用 generatePayload 方法来天生。

而在这个 generatePayload 方法中，就会调用前面先容的 AbstractInstanceRegistry 中的 getApplications 方法获取运用信息并放到缓存中。
这样我们就实现了把注册信息与缓存信息进行关联。

这里有一个设计和实现上的技巧。
把缓存设计为一个只读的 readOnlyCacheMap 以及一个可读写的 readWriteCacheMap，可以更好地分离职责。
但由于两个缓存中保存的实际上是同一份数据，以是，我们在不断更新 readWriteCacheMap 时，也须要确保 readOnlyCacheMap 中的数据得到同步。
为此 ResponseCacheImpl 供应了一个定时任务 CacheUpdateTask，如下所示：

显然，这个定时任务紧张是从 readWriteCacheMap 更新数据到 readOnlyCacheMap。

Eureka 高可用源码解析

我们已经在前面的内容中理解到 Eureka 的高可用支配办法被称为 Peer Awareness 模式。
对应的，我们在 InstanceRegistry 的类层构造中也已经看到了它的一个扩展接口 PeerAwareInstanceRegistry 以及该接口的实现类 PeerAwareInstanceRegistryImpl。

我们还是环绕做事注册这个场景展开谈论，在 PeerAwareInstanceRegistryImpl 中同样存在一个 register 方法，如下所示：

我们在这里看到了一个非常主要的replicateToPeers 方法，该方法作便是用来实现做事器节点之间的状态同步。
replicateToPeers 方法的核心代码如下所示：

为了理解这个操作，我们首先须要理解 Eureka 中的集群模式，这部分代码位于 com.netflix.eureka.cluster 包中，个中包含了代表节点的 PeerEurekaNode 和 PeerEurekaNodes 类，以及用于节点之间数据通报的 HttpReplicationClient 接口。
而 replicateInstanceActionsToPeers 方法中则根据不同的 Action 来调用 PeerEurekaNode 的不同方法。
例如，如果是 StatusUpdate Action，则会调动 PeerEurekaNode的statusUpdate 方法，而该方法又会实行如下代码。

replicationClient.statusUpdate(appName, id, newStatus, info);

这句代码完成了 PeerEurekaNode 之间的通信，而 replicationClient 是 HttpReplicationClient 接口的实例，该接口定义如下：

HttpReplicationClient 接口继续自 EurekaHttpClient 接口，而 EurekaHttpClient 接口属于 Eureka 客户端组件，我们会不才一课时先容 Eureka 客户端基本事理时进行详细先容。
在这里，我们只须要明白 Eureka 供应了 JerseyReplicationClient（位于 com.netflix.eureka.transport 包下）这一基于 Jersey 框架实现的HttpReplicationClient。
以 statusUpdate 方法为例，它的实现过程如下：

这是范例的基于 Resource 的 RESTful 风格的调用方法，用到了 ApacheHttpClient4 工具类。
通过以上剖析，我们已经从紧张维度上节制了全体 Eureka 做事器端内部的运行机制。

做事创造

实现做事注册

我们首先须要确保在 Maven 工程中添加对 Eureka 客户端组件 spring-cloud-starter-netflix-eureka-client 的依赖，如下所示。

然后，我们来看 user-service 的 Bootstrap 类，这里引入了一个新的表明 @EnableEurekaClient。
当然，随着我们后续内容的演进，你会创造可以利用统一的 @SpringCloudApplication 表明，来实现 @SpringBootApplication 和 @EnableEurekaClient 这两个表明整合在一起的效果。

user-service 中的配置内容如下所示：

这里的 serviceUrl 配置项在上一课时中已经先容过，serviceUrl.defaultZone 指定的便是 Eureka 做事器的地址。

当然，如果我们同样基于上一课时中先容的 Peer Awareness 模式构建了 Eureka 做事器集群，那么 eureka.client.serviceUrl.defaultZone 配置项的内容就该当是“http://eureka1:8761/eureka/,http://eureka2:8762/eureka/”，用于指向当前的集议论况。

实现做事创造

当我们成功创建并启动了 user-service 之后，就可以在Eureka的界面创造做事已经注册了。
我们可以获取该做事的做事名称、IP 地址、端口、是否可用等基本信息，也可以访问 statusPageUrl、healthCheckUrl 等地址查看当前做事的运行状态，更为主要的是得到了 leaseInfo 等与做事注册过程直接干系的根本数据，这些根本数据有助于我们理解 Eureka 作为注册中央的事情事理。

理解 Eureka 客户端基本事理

对付 Eureka 而言，微做事的供应者和消费者都是它的客户端，个中做事供应者关注做事注册、做事续约和做事下线等功能，而做事消费者关注于做事信息的获取。
同时，对付做事消费者而言，为了提高做事获取的性能以及在注册中央不可用的情形下连续利用做事，一样平常都还会具有缓存机制。

在 Netflix Eureka 中，专门供应了一个客户端包，并抽象了一个客户端接口 EurekaClient。
EurekaClient 接口继续自 LookupService 接口，这个 LookupService 接口实际上也是我们上一课时中所先容的 InstanceRegistry 接口的父接口。
EurekaClient 在 LookupService 接口的根本上供应了一系列扩展方法，这些扩展方法并不是重点，我们还是更该当关注于它的类层机构，如下所示：

可以看到 EurekaClient 接口有个实现类 DiscoveryClient（位于 com.netflix.discovery 包中），该类包含了做事供应者和做事消费者的核心处理逻辑，同时供应了我们在先容 Eureka 做事器端基本事理时所先容的 register、renew 等方法。
DiscoveryClient 类的实现非常繁芜，我们重点关注它布局方法中的这行代码：

initScheduledTasks();

通过剖析该方法中的代码，我们看到系统在这里初始化了一批调度任务，详细包含缓存刷新 cacheRefresh、心跳 heartbeat、做事实例复制 InstanceInfoReplicator 等，个中缓存刷新面向做事消费者，而心跳和做事实例复制面向做事供应者。
接下来我们将分别从这两个 Eureka 客户端组件出发谈论做事注册和创造的客户端操作。

做事供应者操作源码解析

做事供应者关注做事注册、做事续约和做事下线等功能，它可以利用 Eureka 做事器供应的 RESTful API 完成上述操作。
由于篇幅关系，这里同样以做事注册为例给出做事供应者的操作流程。

在 DiscoveryClient 类中，做事注册操作由register 方法完成，如下所示。
为了大略起见，我们对代码进行了裁剪，省略了日志干系等非核心代码：

上述 register 方法会在 InstanceInfoReplicator 类的 run 方法中进行实行。
从操作流程上讲，上述代码的逻辑非常大略，即做事供应者先将自己注册到 Eureka 做事器中，然后根据返回的结果确定操作是否成功。
显然，这里的重点代码是eurekaTransport.registrationClient.register()，DiscoveryClient 通过这行代码发起了远程要求。

首先我们来看 EurekaTransport 类，这是 DiscoveryClient 类中的一个内部类，定义了 registrationClient 变量用于实现做事注册。
registrationClient 的类型是 EurekaHttpClient 接口，该接口的定义如下：

可以看到这个 EurekaHttpClient 接口定义了 Eureka 做事器的一些底层 REST API，包括 register、cancel、sendHeartBeat、statusUpdate、getApplications 等。
在 Eureka 中，关于如何实现客户端与做事器真个远程通信，从事情事理上讲只是一个 RESTful 风格的 HTTP 要求，但在详细设计和实现上可以说是非常讲求，因此类层构造上也比较繁芜。
我们先来看 EurekaHttpClient 接口的一个实现类 EurekaHttpClientDecorator，从命名上看它是一个装饰器（Decorator），如下所示：

可以看到 EurekaHttpClientDecorator 通过定义一个抽象方法 execute(RequestExecutor requestExecutor) 来包装 EurekaHttpClient，这种包装是代理机制的一种表现形式。

然后我们再来看如何构建一个 EurekaHttpClient，Eureka 也专门供应了 EurekaHttpClientFactory 类来卖力构建详细的 EurekaHttpClient。
显然，这是工厂模式的一种范例运用。
EurekaHttpClientFactory 接口定义如下：

Eureka 中存在一批 EurekaHttpClientFactory 的实现类，包括 RetryableEurekaHttpClient 和 MetricsCollectingEurekaHttpClient 等，这些类都位于 com.netflix.discovery.shared.transport.decorator 包下。
同时，在 com.netflix.discovery.shared.transport 包下，还存在一个 EurekaHttpClients 工具类，能够创建通过 RedirectingEurekaHttpClient、RetryableEurekaHttpClient、SessionedEurekaHttpClient 包装之后的 EurekaHttpClient。
如下所示：

这是 EurekaHttpClient 创建过程中的一条分支，即通过包装器对要求过程进行层层封装和代理。
而在实行远程要求时，Eureka 同样供应了另一套体系来完成真正的远程调用，原始的 EurekaHttpClient 通过 TransportClientFactory 进行创建。
TransportClientFactory 接口定义如下：

TransportClientFactory 同样存在一批实现类，个中有些是实名类，有些是匿名类。
以实名的实现类 JerseyEurekaHttpClientFactory 为例，它位于 com.netflix.discovery.shared.transport.jersey 包下，通过 EurekaJerseyClient 获取 Jersey 客户端，而 EurekaJerseyClient 又会利用 ApacheHttpClient4 工具，从而完成 REST 调用。

作为总结，这里也给你分享一个 Eureka 在设计和实现上的技巧，也便是所谓的高阶（High Level）API和低阶（Low Level）API，如下图所示：

针对高阶 API，紧张是通过装饰器模式进行一系列包装，从而创建目标 EurekaHttpClient。
而关于低阶 API 的话，紧张是 HTTP 远程调用的实现，Netflix 供应的是基于 Jersey 的版本，而 Spring Cloud 则供应了基于 RestTemplate 的版本，这点我们后面会再讲到。

做事消费者操作源码解析

我们在先容注册中央模型时，做事消费者可以配备缓存机制以加速做事路由。
对付 Eureka 而言，作为客户端组件的 DiscoveryClient 同样具备这种缓存功能。

Eureka 客户端通过定时任务完成缓存刷新操作，我们已经在前面的内容中提到 DiscoveryClient 中的 initScheduledTasks 方法用于初始化各种调度任务，对付缓存刷选而言，调度器的初始化过程如下所示：

对付做事消费者而言，最主要的操作便是获取做事注册信息。
在这里的 refreshRegistry 方法中，我们创造在进行一系列的校验之后，终极调用了 fetchRegistry 方法以完成注册信息的更新，该方法代码如下。
为了大略起见，我们对代码进行了部分裁剪，只保留主流程：

这里的几个带注释的方法都非常有用，由于 getAndStoreFullRegistry 的逻辑相比拟较大略，我们将重点先容 getAndUpdateDelta 方法，以便学习在 Eureka 中如何实现增量数据更新的设计技巧。
裁剪之后的 getAndUpdateDelta 方法代码如下所示：

回顾 Eureka 做事器端基本事理，我们知道 Eureka 做事器端会保存一个做事注册列表的缓存。

Eureka 官方文档中提到这个数据保留韶光是三分钟，而 Eureka 客户真个定时调度机制会每隔 30 秒刷选本地缓存。
原则上，只要 Eureka 客户端一直地获取做事器真个更新数据，就能担保自己的数据和 Eureka 做事器真个保持同等。
但如果客户端在 3 分钟之内没有获取更新数据，就会导致自身与做事器真个数据不一致，这是这种更新机制所必须要考虑的问题，也是我们自己在设计类似场景时的一个把稳点。

针对上述问题，Eureka 采取了同等性 HashCode 方法来进行办理。
Eureka 做事器端每次返回的增量数据中都会带有一个同等性 HashCode，这个 HashCode 会与 Eureka 客户端用本地做事列表数据算出的同等性 HashCode 进行比对，如果两者不一致就证明增量更新出了问题，这时候就须要实行一次全量更新。

在 Eureka 中，打算同等性 HashCode 的方法如下所示，可以看到这一方法基于做事注册实例信息完成编码打算过程，终极返回一个 String 类型的打算结果：

作为总结，Eureka 客户端缓存定时更新的流程如下图所示，可以看到它与做事注册的流程基本同等，也便是说在 Eureka 中，做事供应者和做事消费者作为 Eureka 做事器的客户端采取了同一套体系完成与做事器真个交互。

负载均衡

Spring Cloud 中同样存在着与 Eureka 配套的负载均衡器，这便是 Ribbon 组件。
Eureka 和 Ribbon 的交互办法如下图所示：

本日，我们就将结合上图详细先容如何利用 Ribbon 来实现负载均衡的利用方法。
Ribbon 的定位是一款用于供应客户端负载均衡的工具软件。
Ribbon 会自动地基于某种内置的负载均衡算法去连接做事实例，我们也可以设计并实现自定义的负载均衡算法并嵌入 Ribbon 中。
同时，Ribbon 客户端组件供应了一系列完善的赞助机制用来确保做事调用过程的可靠性和容错性，包括连接超时和重试等。
Ribbon 是客户端负载均衡机制的范例实现方案，以是须要嵌入在做事消费者的内部进行利用。

Ribbon 的核心功能

1.利用 @LoadBalanced 表明。

@LoadBalanced 表明用于润色发起 HTTP 要求的 RestTemplate 工具类，并在该工具类中自动嵌入客户端负载均衡功能。
开拓职员不须要针对负载均衡做任何分外的开拓或配置。

2.利用 @RibbonClient 表明。

Ribbon 还许可你利用 @RibbonClient 表明来完备掌握客户端负载均衡行为。
这在须要定制化负载均衡算法等某些特定场景下非常有用，我们可以利用这个功能实现更细粒度的负载均衡配置。

利用 DiscoveryClient 获取做事实例信息

接下来，让我们来演示如何根据做事名称获取 Eureka 中的做事实例信息。
通过 DiscoveryClient 可以很随意马虎实现这一点。

首先，我们获取当前注册到 Eureka 中的做事名称全量列表，如下所示：

List<String> serviceNames = discoveryClient.getServices();

基于这个做事名称列表可以获取所有自己感兴趣的做事，并进一步获取这些做事的实例信息：

List<ServiceInstance> serviceInstances = discoveryClient.getInstances(serviceName);

ServiceInstance 工具代表做事实例，包含了很多有用的信息，定义如下：

显然，一旦获取了一个 ServiceInstance 列表，我们就可以基于常见的随机、轮询等算法来实现客户端负载均衡，也可以基于做事的 URI 信息等实现各种定制化的路由机制。
一旦确定负载均衡的终极目标做事，就可以利用 HTTP 工具类来根据做事的地址信息发起远程调用。

在 Spring 的天下中，访问 HTTP 端点最常见的方法便是利用 RestTemplate 工具类，让我们一起来做一些回顾。
在演示 RestTemplate 的利用方法之前，我们先在 SpringHealth 案例的 user-service 添加一个 HTTP 端点，如下所示：

然后，我们构建一个测试类来访问这个 HTTP 端点。
如果我们能够获取注册中央中的做事定义，我们就可以通过 ServiceInstance 对该做事进行调用，如下所示：

可以看到，这里通过 RestTemplate 工具类就可以利用 ServiceInstance 中的 URL 轻松实现 HTTP 要求。
在上面的示例代码中，我们通过 instances.get(0) 方法获取的是做事列表中的第一个做事，然后利用 RestTemplate 的 exchange() 方法封装全体 HTTP 要求调用过程并获取结果。

通过 @Loadbalanced 表明调用做事

如果你节制了 RestTemplate 的利用方法，那么在 Spring Cloud 中基于 Ribbon 来实现负载均衡非常大略，要做的事情便是在 RestTemplate 上添加一个表明，仅此而已。

接下来，我们连续利用前面先容的 user-service 进行演示。
由于涉及负载均衡，以是我们首先须要运行至少两个 user-service 做事实例。
另一方面，为了显示负载均衡环境下的调用结果，我们在 UserController 中添加日志方便在运行时不雅观察掌握台输出信息。
重构后的 UserController 的代码如下所示。

我们知道 intervention-service 会访问 user-service 以便天生康健干预信息。
对付 user-service 而言，intervention-service 便是它的客户端。
我们在 intervention-service 的启动类 InterventionApplication中，通过 @LoadBalanced 表明创建 RestTemplate。
现在的 InterventionApplication 类代码如下所示：

对付 intervention-service 而言准备事情已经就绪，现在就可以编写访问 user-service 的远程调用代码。
我们在 intervention-service 工程中添加一个新的 UserServiceClient 类并添加以下代码：

可以看到以上代码便是注入 RestTemplate，然后通过 RestTemplate 的 exchange() 方法对 user-service 进行远程调用。
但是请把稳，这里的 RestTemplate 已经具备了客户端负载均衡功能，由于我们在 InterventionApplication 类中创建该 RestTemplate 时添加了 @LoadBalanced 表明。
同样请把稳，URL“http://userservice/users/{userName}”中的”userservice”是在 user-service 中配置的做事名称，也便是在注册中央中存在的名称。
至于这里的 UserMapper 类，只是一个数据传输工具，用于完成序列化操作。

通过 @RibbonClient 表明自定义负载均衡策略

在前面的演示中，我们完备没有觉得到 Ribbon 组件的存在。
在基于 @LoadBalanced 表明实行负载均衡时，采取的是 Ribbon 内置的负载均衡机制。
默认情形下，Ribbon 利用的是轮询策略，我们无法掌握详细生效的是哪种负载均衡算法。
但在有些场景下，我们就须要对负载均衡这一过程进行更加风雅化的掌握，这时候就可以用到 @RibbonClient 表明。

常日，我们须要指定这里的目标做事名称以及负载均衡配置类。
以是，为了利用 @RibbonClient 表明，我们须要创建一个独立的配置类，用来指定详细的负载均衡规则。
以下代码演示的便是一个自定义的配置类 SpringHealthLoadBalanceConfig：

显然该配置类的浸染是利用 RandomRule 更换 Ribbon 中的默认负载均衡策略 RoundRobin。
我们可以根据须要返回任何自定义的 IRule 接口的实现策略，关于 IRule 接口的定义放不才一课时进行谈论。

有了这个 SpringHealthLoadBalanceConfig 之后，我们就可以在调用特定做事时利用该配置类，从而对客户端负载均衡实现细粒度的掌握。
在 intervention-service 中利用 SpringHealthLoadBalanceConfig 实现对 user-service 访问的示例代码如下所示：

可以把稳到，我们在 @RibbonClient 中设置了目标做事名称为 userservice，配置类为 SpringHealthLoadBalanceConfig。
现在每次访问 user-service 时将利用 RandomRule 这一随机负载均衡策略。

比拟 @LoadBalanced 表明和 @RibbonClient 表明，如果利用的是普通的负载均衡场景，那么常日只须要 @LoadBalanced 表明就能完成客户端负载均衡。
而如果我们要对 Ribbon 运行时行为进行定制化处理时，就可以利用 @RibbonClient 表明。

Netflix Ribbon 基本架构

作为一款客户端负载均衡工具，要做的事情无非便是两件：第一件事情是获取注册中央中的做事器列表；第二件事情是在这个做事列表中选择一个做事进行调用。

Netflix Ribbon 中的核心类

Netflix Ribbon 的核心接口 ILoadBalancer 便是环绕着上述两个问题来设计的，该接口位于 com.netflix.loadbalancer 包下，定义如下：

ILoadBalancer 接口的类层构造如下所示：

个中 AbstractLoadBalancer 是个抽象类，只定义了两个抽象方法，并不构成一种模板方法的构造。
以是我们直接来看 ILoadBalancer 接口，该接口最基本的实现类是 BaseLoadBalancer，可以说负载均衡的核心功能都可以在这个类中得以实现。
这个类代码非常多且杂，我们在理解上须要对其进行裁剪，从而捉住重点。

我们先来梳理 BaseLoadBalancer 包含的作为一个负载均衡器该当具备的一些核心组件，比较主要的有以下三个。

1.IRule

IRule 接口是对负载均衡策略的一种抽象，可以通过实现这个接口来供应各种适用的负载均衡算法，我们在上一课时先容 @RibbonClient 表明时已经看到过这个接口。
该接口定义如下：

显然 choose 方法是该接口的核心方法，我们不才文中会基于该方法对各种负载均衡算法进行详细展开。

2. IPing

IPing 接口判断目标做事是否存活，定义如下：

可以看到 IPing 接口中只有一个 isAlive() 方法，通过对做事发出"Ping"操作来获取做事相应，从而判断该做事是否可用。

3.LoadBalancerStats

LoadBalancerStats 类记录负载均衡的实时运行信息，用来作为负载均衡策略的运行时输入。

把稳，在 BaseLoadBalancer 内部掩护着 allServerList 和 upServerList 这两个线程的安全列表，以是对付 ILoadBalancer 接口定义的 addServers、getReachableServers、getAllServers 这几个方法而言，紧张便是对这些列表的掩护和管理事情。
以 addServers 方法为例，它的实现如下所示：

显然，这里的处理过程便是将原有的做事实例列表 allServerList 和新传入的做事实例列表 newServers 都合并到一个 newList 中，然后再调用 setServersList 方法用这个新的列表覆盖旧的列表。

针对负载均衡，我们重点该当关注的是 ILoadBalancer 接口中 chooseServer 方法的实现，不难想象该方法肯定通过前面先容的 IRule 接口集成了详细负载均衡策略的实现。
在 BaseLoadBalancer 中的 chooseServer 方法如下所示：

果真，这里利用了 IRule 接口的 choose 方法。
接下来就让我们看看 Ribbon 中的 IRule 接口为我们供应了详细哪些负载均衡算法。

Netflix Ribbon 中的负载均衡策略

一样平常而言，负载均衡算法可以分成两大类，即静态负载均衡算法和动态负载均衡算法。
静态负载均衡算法比较随意马虎理解和实现，范例的包括随机（Random）、轮询（Round Robin）和加权轮询（Weighted Round Robin）算法等。
所有涉及权重的静态算法都可以转变为动态算法，由于权重可以在运行过程中动态更新。
例如动态轮询算法中权重值基于对各个做事器的持续监控并不断更新。
其余，基于做事器的实时性能剖析分配连接是常见的动态策略。
范例动态算法包括源 IP 哈希算法、最少连接数算法、做事调用时延算法等。

回到 Netflix Ribbon，IRule 接口的类层构造如下图所示：

可以看到 Netflix Ribbon 中的负载均衡实现策略非常丰富，既供应了 RandomRule、RoundRobinRule 等无状态的静态策略，又实现了 AvailabilityFilteringRule、WeightedResponseTimeRule 等多种基于做事器运行状况进行实时路由的动态策略。

在上图中还看到了 RetryRule 这种重试策略，该策略会对选定的负载均衡策略实行重试机制。
严格意义上讲重试是一种做事容错而不是负载均衡机制，但 Ribbon 也内置了这方面的功能。

静态的几种策略相对都比较大略，而像 RetryRule 实际上不算是严格意义上的负载均衡策略，以是这里重点关注 Ribbon 所实现的几种不同的动态策略。

1.BestAvailableRule 策略

选择一个并发要求量最小的做事器，逐个稽核做事器然后选择个中生动要求数最小的做事器。

2.WeightedResponseTimeRule 策略

该策略与要求的相应韶光有关，显然，如果相应韶光越长，就代表这个做事的相应能力越有限，那么分配给该做事的权重就该当越小。
而相应韶光的打算就依赖于前面先容的 ILoadBalancer 接口中的 LoadBalancerStats。
WeightedResponseTimeRule 会定时从 LoadBalancerStats 读取均匀相应韶光，为每个做事更新权重。
权重的打算也比较大略，即每次要求的相应韶光减去每个做事自己均匀的相应韶光便是该做事的权重。

3.AvailabilityFilteringRule 策略

通过检讨 LoadBalancerStats 中记录的各个做事器的运行状态，过滤掉那些处于一贯连接失落败或处于高并发状态的后端做事器。

Spring Cloud Netflix Ribbon

而 Spring Cloud 中的 Spring Cloud Netflix Ribbon 便是就专门针对 Netflix Ribbon 供应了一个独立的集成实现。

Spring Cloud Netflix Ribbon 相称于 Netflix Ribbon 的客户端。
而对付 Spring Cloud Netflix Ribbon 而言，我们的运用做事相称于它的客户端。
Netflix Ribbon、Spring Cloud Netflix Ribbon、运用做事这三者之间的关系以及核心入口如下所示：

这次，我们打算从运用做事层的 @LoadBalanced 表明入手，切入 Spring Cloud Netflix Ribbon，然后再从 Spring Cloud Netflix Ribbon 串联到 Netflix Ribbon，从而形玉成部负载均衡闭环管理。

@LoadBalanced 表明

利用过 Spring Cloud Netflix Ribbon 的同学可能会问，为什么通过 @LoadBalanced 表明创建的 RestTemplate 就能自动具备客户端负载均衡的能力？这也是一个口试过程中常常被问到的问题。

事实上，在 Spring Cloud Netflix Ribbon 中存在一个自动配置类——LoadBalancerAutoConfiguration 类。
而在该类中，掩护着一个被 @LoadBalanced 润色的 RestTemplate 工具的列表。
在初始化的过程中，对付所有被 @LoadBalanced 表明润色的 RestTemplate，调用 RestTemplateCustomizer 的 customize 方法进行定制化，该定制化的过程便是对目标 RestTemplate 增加拦截器 LoadBalancerInterceptor，如下所示：

这个 LoadBalancerInterceptor 用于实时拦截，可以看到它的布局函数中传入了一个工具 LoadBalancerClient，而在它的拦截方法实质上便是利用 LoadBalanceClient 来实行真正的负载均衡。
LoadBalancerInterceptor 类代码如下所示：

可以看到这里的拦截方法 intercept 直接调用了 LoadBalancerClient 的 execute 方法完成对要求的负载均衡实行。

LoadBalanceClient 接口

LoadBalancerClient 是一个非常主要的接口，定义如下：

这里有两个 execute 重载方法，用于根据负载均衡器所确定的做事实例来实行做事调用。
而 reconstructURI 方法则用于构建做事 URI，利用负载均衡所选择的 ServiceInstance 信息重新布局访问 URI，也便是用做事实例的 host 和 port 再加上做事的端点路径来布局一个真正可供访问的做事。

LoadBalancerClient 继续自 ServiceInstanceChooser 接口，该接口定义如下：

从负载均衡角度讲，我们该当重点关注实际上是这个 choose 方法的实现，而供应详细实现的是实现了 LoadBalancerClient 接口的 RibbonLoadBalancerClient，而 RibbonLoadBalancerClient 位于 spring-cloud-netflix-ribbon 工程中。
这样我们的代码流程就从运用程序转入到了 Spring Cloud Netflix Ribbon 中。

在 LoadBalancerClient 接口的实现类 RibbonLoadBalancerClient 中，choose 方法终极调用了如下所示的 getServer 方法：

这里的 loadBalancer 工具便是前面先容的 Netflix Ribbon 中的 ILoadBalancer 接口的实现类。
这样，我们就把 Spring Cloud Netflix Ribbon 与 Netflix Ribbon 的整体协作流程串联起来。

更多资料，私信回答【1】......

今日份分享已结束，请大家多多包涵和指示！