Eureka 的服务注册中心

第⼀部分：微服务架构（回顾） 架构的演变过程：

随着互联⽹的发展，⽤户群体的扩⼤，⽹站流量的增⻓，单体架构已⽆法满⾜请求压⼒和业务，架构的变化势在必⾏。

单体架构------>垂直架构------>SOA架构------>微服务架构

单体架构：项⽬所有的功能模块都放在⼀个⼯程中编码、编译、打包并且部署在⼀个Tomcat容器中的架构模式就是单体应⽤架构。

垂直架构：垂直划分的原则是基于业务特性来做，核⼼⽬标第⼀个是为了业务之间互不影响，第⼆个是在研发团队的壮⼤后为了提⾼效率，减少之间的依赖。

SOA: 即⾯向服务的架构。根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。

微服务架构: 可以说是SOA架构的⼀种拓展，这种架构模式下它拆分粒度更⼩、服务更独⽴。把应⽤拆分成为⼀个个微⼩的服务，不同的服务可以使⽤不同的开发语⾔和存储，服务之间往往通过Restful等轻量级通信。

微服务架构关键在于微⼩、独⽴、轻量级通信。

微服务架构和SOA架构很明显的⼀个区别就是服务拆分粒度的不同

第⼆部分：SpringCloud概述

微服务的优缺点：

微服务架构的优点:

微服务很⼩，便于特定业务功能的聚焦 A B C D

微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发

微服务很⼩，便于重⽤和模块之间的组装

微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合微服务架构下，我们更容易引⼊新技术

微服务架构下，我们可以更好的实现DevOps开发运维⼀体化；

微服务架构的缺点

微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂；

微服务架构下，分布式链路跟踪难等；

SpringCloud 是什么？

• Spring Cloud是⼀系列框架的有序集合（Spring Cloud是⼀个规范）
• 开发服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等
• 利⽤Spring Boot的开发便利性简化了微服务架构的开发（⾃动装配）

架构及其核⼼组件（框架）

服务注册：服务提供者将所提供服务的信息（服务器IP和端⼝、服务访问协议等）注册/登记到注册中⼼

服务发现：服务消费者能够从注册中⼼获取到较为实时的服务列表，然后根究⼀定的策略选择⼀个服务访问

服务负载均衡：负载均衡即将请求压⼒分配到多个服务器（应⽤服务器、数据库服务器等），以此来提⾼服务的性能、可靠性。

服务熔断：熔断即断路保护。微服务架构中，如果下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护系统整体可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施就叫做熔断。

链路追踪：微服务架构越发流⾏，⼀个项⽬往往拆分成很多个服务，那么⼀次请求就需要涉及到很多个服务。不同的微服务可能是由不同的团队开发、可能使⽤不同的编程语⾔实现、

整个项⽬也有可能部署在了很多服务器上（甚⾄百台、千台）横跨多个不同的数据中⼼。所谓链路追踪，就是对⼀次请求涉及的很多个服务链路进⾏⽇志记录、性能监控。

API网关： API⽹关更专注在安全、路由、流量等问题的处理上。

如：1）统⼀接⼊（路由）

2）安全防护（统⼀鉴权，负责⽹关访问身份认证验证，与“访问认证中⼼”通信，实际认证业务逻辑交移“访问认证中⼼”处理）

3）⿊⽩名单（实现通过IP地址控制禁⽌访问⽹关功能，控制访问）

4）协议适配（实现通信协议校验、适配转换的功能）

5）流量管控（限流）

6）⻓短链接⽀持

7）容错能⼒（负载均衡）

核心组件有哪些：Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件 和 第⼆代 Spring Cloud组件。

SringCloud 的协同工作机制：

Spring Cloud中的各组件协同⼯作，才能够⽀持⼀个完整的微服务架构。⽐如：

• • 注册中⼼负责服务的注册与发现，很好将各服务连接起来
  • API⽹关负责转发所有外来的请求
  • 断路器负责监控服务之间的调⽤情况，连续多次失败进⾏熔断保护。
  • 配置中⼼提供了统⼀的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
  • 等等

Spring Cloud 与 Dubbo 对⽐

Dubbo是阿⾥巴巴公司开源的⼀个⾼性能优秀的服务框架，基于RPC调⽤，对于⽬前使⽤率较⾼的。

Spring Cloud Netflflix来说，它是基于HTTP的，所以效率上没有Dubbo⾼，但问题在于Dubbo体系的组件不全，不能够提供⼀站式解决⽅案，⽐如服务注册与发现需要借助于Zookeeper等实现，

⽽Spring Cloud Netflflix则是真正的提供了⼀站式服务化解决⽅案，且有Spring⼤家族背景。前些年，Dubbo使⽤率⾼于SpringCloud，但⽬前Spring Cloud在服务化/微服务解决⽅案中已经有了⾮常好的发展趋势。

Spring Cloud 与 Spring Boot 的关系

Spring Cloud 只是利⽤了Spring Boot 的特点，让我们能够快速的实现微服务组件开发，否则不使⽤Spring Boot的话，我们在使⽤Spring Cloud时，

每⼀个组件的相关Jar包都需要我们⾃⼰导⼊配置以及需要开发⼈员考虑兼容性等各种情况。所以Spring Boot是我们快速把Spring Cloud微服务技术应⽤起来的⼀种⽅式。

第三部分：案例准备 以及问题

我们在⾃动投递微服务中使⽤RestTemplate调⽤简历微服务的简历状态接⼝时（Restful API 接⼝）。在微服务分布式集群环境下会存在什么问题呢？怎么解决？

存在的问题：

1）在服务消费者中，我们把url地址硬编码到代码中，不⽅便后期维护。

2）服务提供者只有⼀个服务，即便服务提供者形成集群，服务消费者还需要⾃⼰实现负载均衡。

3）在服务消费者中，不清楚服务提供者的状态。

4）服务消费者调⽤服务提供者时候，如果出现故障能否及时发现不向⽤户抛出异常⻚⾯？

5）RestTemplate这种请求调⽤⽅式是否还有优化空间？能不能类似于Dubbo那样玩？

6）这么多的微服务统⼀认证如何实现？

7）配置⽂件每次都修改好多个很麻烦！？等等。。。。

第四部分：第⼀代 Spring Cloud 核⼼组件

第 1 节 Eureka服务注册中⼼

注意：服务注册中⼼本质上是为了 解耦 服务提供者和服务消费者。

对于任何⼀个微服务，原则上都应存在或者⽀持多个提供者（⽐如简历微服务部署多个实例），这是由微服务的分布式属性决定的。

更进⼀步，为了⽀持弹性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动态变化的，也是⽆法预先确定的。

因此，原本在单体应⽤阶段常⽤的静态LB(load banlence 负载均衡)机制就不再适⽤了，需要引⼊额外的组件来管理微服务提供者的注册与发现，⽽这个组件就是服务注册中⼼。

服务注册中心的运行原理：

1）服务提供者启动

2）服务提供者将相关服务信息主动注册到注册中⼼

3）服务消费者获取服务注册信息：

pull模式：服务消费者可以主动拉取可⽤的服务提供者清单

push模式：服务消费者订阅服务（当服务提供者有变化时，注册中⼼也会主动推送更新后的服务清单给消费者）

4）服务消费者直接调⽤服务提供者

另外，注册中⼼也需要完成服务提供者的健康监控，当发现服务提供者失效时需要及时剔除； 及时剔除已经下线的服务。

主流服务注册中⼼对⽐

Zookeeper

Zookeeper它是⼀个分布式服务框架，它主要是⽤来解决分布式应 ⽤中经常遇到的⼀些数据管理问题，如：统⼀命名服务、状态同步服务、集群管理、分布式应⽤配置项的管理等。

简单来说zookeeper本质=存储+监听通知。znode

Zookeeper ⽤来做服务注册中⼼，主要是因为它具有节点变更通知功能，只要客户端监听相关服务节点，服务节点的所有变更，都能及时的通知到监听客户端，

这样作为调⽤⽅只要使⽤ Zookeeper 的客户端就能实现服务节点的订阅和变更通知功能了，⾮常⽅便。

另外，Zookeeper 可⽤性也可以，因为只要半数以上的选举节点存活，整个集群就是可⽤的。最低3台zk 服务器即可。

Eureka

由Netflflix开源，并被Pivatal集成到SpringCloud体系中，它是基于 RestfulAPI⻛格开发的服务注册与发现组件。

Consul （停更 弃用）

Consul是由HashiCorp基于Go语⾔开发的⽀持多数据中⼼分布式⾼可⽤的服务发布和注册服务软件， 采⽤Raft算法保证服务的⼀致性，且⽀持健康检查。

Nacos

Nacos是⼀个更易于构建云原⽣应⽤的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是 注册中⼼ + 配置中⼼的组合，帮助我们解决微服务开发必会涉及到的服务注册 与发现，服务配置，服务管理等问题。

Nacos 是Spring Cloud Alibaba 核⼼组件之⼀，负责服务注册与发现以及配置中心。

Eureka注册中心的应用

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

Eureka Client： 是⼀个Java客户端，⽤于简化与Eureka Server的交互；

Eureka Server：提供服务发现的能⼒，各个微服务启动时，会通过Eureka Client向Eureka Server 进⾏注册⾃⼰的信息（例如⽹络信息），Eureka Server会存储该服务的信息；

renew 心跳(续约)：告知eureka server 自己还活着。能够正常提供服务。默认每隔30秒进行一次心跳检查。如果90没有通过心跳监测，就会剔除 该服务。

下图是官⽹描述的⼀个架构图：

1）图中us-east-1c、us-east-1d，us-east-1e代表不同的区也就是不同的机房

2）图中每⼀个Eureka Server都是⼀个集群。

3）图中Application Service作为服务提供者向Eureka Server中注册服务，Eureka Server接受到注册事件会在集群和分区中进⾏数据同步，

Application Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进⾏服务调⽤。

4）微服务启动后，会周期性地向Eureka Server发送⼼跳（默认周期为30秒）以续约⾃⼰的信息。

5）Eureka Server在⼀定时间内没有接收到某个微服务节点的⼼跳，EurekaServer将会注销该微服务节点（默认90秒）。

6）每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的⽅式完成服务注册列表的同步。(通过同步复制机制保持 eureka server 服务器中注册的服务信息一致)

7）Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者。

Eureka通过⼼跳检测、健康检查和客户端缓存等机制，提⾼系统的灵活性、可伸缩性和可⽤性。

Eureka控制台信息展示：

搭建Eureka Server HA⾼可⽤集群 replicate 互相同步数据

在互联⽹应⽤中，服务实例很少有单个的。

即使微服务消费者会缓存服务列表（缓存的都是历史信息），但是如果EurekaServer只有⼀个实例，该实例挂掉，

正好微服务消费者本地缓存列表中的服务实例也不可⽤，那么这个时候整个系统都受影响。

在⽣产环境中，我们会配置Eureka Server集群实现⾼可⽤。Eureka Server集群之中的节点通过点对点（P2P）通信的⽅式共享服务注册表。我们开启两台 Eureka Server 以搭建集群。

Eureka细节详解

Eureka元数据详解

Eureka的元数据有两种：标准元数据和⾃定义元数据。

标准元数据：主机名、IP地址、端⼝号等信息，这些信息都会被发布在服务注册表中，⽤于服务之间的调⽤。

⾃定义元数据：可以使⽤eureka.instance.metadata-map配置，符合key/value的存储格式。这些元数据可以在远程客户端中访问。类似于：

instance: prefer-ip-address: true metadata-map: // ⾃定义元数据(kv⾃定义) cluster: cl1 region: rn1

标准元数据：

1.4.2 Eureka客户端详解

服务提供者（也是Eureka客户端）要向EurekaServer注册服务，并完成服务续约等⼯作

服务注册详解（服务提供者）

1）当我们导⼊了eureka-client依赖坐标，配置Eureka服务注册中⼼地址

2）服务在启动时会向注册中⼼发起注册请求，携带服务元数据信息

3）Eureka注册中⼼会把服务的信息保存在Map中。

服务续约详解（服务提供者）：服务每隔30秒会向注册中⼼续约(⼼跳)⼀次（也称为报活）,如果没有续约，租约在90秒后到期，然后服务会被失效。每隔30秒的续约操作我们称之为⼼跳检测

往往不需要我们调整这两个配置。

#向Eureka服务中⼼集群注册服务 eureka: instance: # 租约续约间隔时间，默认30秒 lease-renewal-interval-in-seconds: 30 # 租约到期，服务时效时间，默认值90秒,服务超过90秒没有发⽣⼼跳，EurekaServer会将服务从列表移除 lease-expiration-duration-in-seconds: 90

获取服务列表详解（服务消费者）

每隔30秒服务会从注册中⼼中拉取⼀份服务列表，这个时间可以通过配置修改。往往不需要我们调整

1）服务消费者启动时，从 EurekaServer服务列表获取只读备份，缓存到本地

2）每隔30秒，会重新获取并更新数据

3）每隔30秒的时间可以通过配置 eureka.client.registry-fetch-interval-seconds修改

Eureka 服务端的角度详解

服务下线

1）当服务正常关闭操作时，会发送服务下线的REST请求给Eureka Server 服务端。

2）服务中⼼接受到请求后，将该服务置为下线状态

失效剔除

Eureka Server会定时（间隔值是eureka.server.eviction-interval-timer-in-ms，默认60s）进⾏检查，

如果发现实例在在⼀定时间（此值由客户端设置的eureka.instance.lease-expiration-duration-in-seconds定义，默认值为90s）内没有收到⼼跳，则会注销此实例。

⾃我保护（重点）

服务提供者 —> 注册中⼼

定期的续约（服务提供者和注册中⼼通信），假如服务提供者和注册中⼼之间的⽹络有点问题，不代表服务提供者不可⽤，不代表服务消费者⽆法访问服务提供者。

如果在15分钟内超过85%的客户端节点都没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼出现了⽹络故障，Eureka Server⾃动进⼊⾃我保护机制。

为什么会有⾃我保护机制？

默认情况下，如果Eureka Server在⼀定时间内（默认90秒）没有接收到某个微服务实例的⼼跳，Eureka Server将会移除该实例。

但是当⽹络分区故障发⽣时，微服务与Eureka Server之间⽆法正常通信，⽽微服务本身是正常运⾏的，此时不应该移除这个微服务，所以引⼊了⾃我保护机制。

服务中⼼⻚⾯会显示如下提示信息

当处于⾃我保护模式时：经验：建议⽣产环境打开⾃我保护机制

1）不会剔除任何服务实例（可能是服务提供者和EurekaServer之间⽹络问题），保证了⼤多数服务依然可⽤

2）Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可⽤，当⽹络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

3）在Eureka Server⼯程中通过eureka.server.enable-self-preservation配置可⽤关停⾃我保护，默认值是打开

eureka: server: enable-self-preservation: false # 关闭⾃我保护模式（缺省为打开）经验：建议⽣产环境打开⾃我保护机制

Eureka核⼼源码剖析 从 eureka server 和 eureka client 两个角度进行剖析：