网关组件 Zuul 性能一般，未来将退出 Spring Cloud 生态圈，所以直接使用 GateWay，把 GateWay 划分到第一代 Spring Cloud 核心组件中。
各组件整体结构如下：
Gateway：所有服务的入口；日志、黑白名单、鉴权。
Ribbon：负载均衡。
Hystrix：熔断器，服务熔断，服务降级。
Feign：远程调用。
Eureka：服务注册与发现；微服务名称、IP、端口号。
Config：搭建配置中心微服务；实现对配置文件的统一管理，配置自动刷新 - bus。
Actor
---> Gateway 网关
--转发-->
{
[搜索微服务，搜索微服务]，
[商品微服务，商品微服务]，
[支付微服务，支付微服务]，
[秒杀微服务，秒杀微服务]，
RestTemplate + Ribbon + Hystrix 或 Feign
}
---->
{
服务注册中心 Eureka，
配置中心 Config
}
从形式上来说，Feign 一个顶三，Feign = RestTemplate + Ribbon + Hystrix。
常用的服务注册中心：Eureka、Nacos、Zookeeper、Consul。
注意：服务注册中心本质上是为了解耦服务提供者和服务消费者。
服务消费者 -> 服务注册中心 -> 服务提供者。
对于任何一个微服务，原则上都应存在或者支持多个提供者（比如商品微服务部署多个实例），这是由微服务的分布式属性决定的。
更进一步，为了支持弹性扩、缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态 LoadBalance 机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
1. 启动：
容器 --> 服务注册中心
容器 --> 服务提供者
容器 --> 服务消费者
2. 注册：
服务消费者 --> 服务注册中心
服务提供者 --> 服务注册中心
3. 获取服务信息：
服务消费者 <--获取服务信息--> 服务注册中心
4. Invoke：
服务消费者 --负载均衡-熔断机制--> 服务提供者
分布式微服务架构中，服务注册中心用于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不再需要通过硬编码方式得到提供者的地址信息。消费者只需要知道当前系统发布了那些服务，而不需要知道服务具体存在于什么位置，这就是透明化路由。
1）服务提供者启动。
2）服务提供者将相关服务信息主动注册到注册中心。
3）服务消费者获取服务注册信息：Pull 模式 - 服务消费者可以主动拉取可用的服务提供者清单；Push 模式 - 服务消费者订阅服务，当服务提供者有变化时，注册中心也会主动推送更新后的服务清单给消费者。
4）服务消费者直接调用服务提供者。
另外，注册中心也需要完成服务提供者的健康监控，当发现服务提供者失效时需要及时剔除。
Zookeeper：
Dubbo + Zookeeper
zookeeper = 存储 + 监听通知
Zookeeper 是一个分布式服务框架，是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Zookeeper 用来做服务注册中心，主要是因为它具有节点变更通知功能，只要客户端监听相关服务节点，服务节点的所有变更，都能及时的通知到监听客户端，这样作为调用方只要使用 Zookeeper 的客户端就能实现服务节点的订阅和变更通知功能了，非常方便。另外，Zookeeper 可用性也可以，因为只要半数以上的选举节点存活，整个集群就是可用的，最少节点数为 3。
Eureka：
Eureka 由 Netflix 开源，并被 Pivatal 集成到 Spring Cloud 体系中，它是基于 RestfulAPI 风格开发的服务注册与发现组件。
Consul：
Consul 是由 HashiCorp 基于 Go 语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件， 采用 Raft 算法保证服务的一致性，且支持健康检查。
Nacos：
Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是注册中心 + 配置中心的组合，帮助我们解决微服务开发必会涉及到的服务注册与发现，服务配置，服务管理等问题。Nacos 是 Spring Cloud Alibaba 核心组件之一，负责服务注册与发现，还有配置。
CAP 定理：
CAP 定理又称 CAP 原则，指的是在一个分布式系统中，Consistency 一致性、 Availability 可用性、Partition tolerance 分区容错性，最多只能同时三个特性中的两个，三者不可兼得。
P：分区容错性 - 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务（一定的要满足的）。
C：数据一致性 - all nodes see the same data at the same time.
A：高可用 - Reads and writes always succeed.
CAP 不可能同时满足三个，要么是 AP，要么是 CP。
对比：
服务注册中心的一般原理、对比了主流的服务注册中心方案，目光聚焦 Eureka。
Eureka 基础架构：
Eureka Server 需要手动搭建一个工程，并引入相关依赖，进行对应的配置文件设置。
Renew 心跳 / 心跳检测：服务注册默认 30s 续约，默认 90s 没有收到续约就会将 Client 实例从服务列表中剔除。
ApplicationService 服务提供者
----> Eureka Client
--注册服务--> Eureka Server 注册中心
Eureka Server 注册中心
--服务列表-缓存--> Eureka Client
----> ApplicationClient 客户端消费者
ApplicationClient 客户端消费者 --调用服务--> ApplicationService 服务提供者
Eureka 交互流程及原理：
不同的 Eureka Server 会互相同步复制（Replicate）服务实例列表；
每个 Eureka Server 是一个集群；
Eureka Server 搭建集群来保持高可用服务注册中心；
每个 Eureka Server 可能处于不同地域不同的机房。
Eureka 服务注册中心：[Eureka Server 1, Eureka Server 2, Eureka Server 3]
Appllication Service 服务提供者 - 含有 Eureka Client
Application Client 服务消费者 - 含有 Eureka Client
服务提供者可以进行 Register, Renew, Cancel, Get Registry 于服务注册中心。
服务消费者可以进行 Get Registry 于服务注册中心。
服务消费者 Make Remote Call 于服务提供者。
Eureka 包含两个组件 - Eureka Server 和 Eureka Client：
Eureka 通过心跳检测、健康检查和客户端缓存等机制，提高系统的灵活性、可伸缩性和高可用性。
实现过程：
1）搭建 Eureka Server 服务 lagou-cloud-eureka
lagou-parent 中增加 Spring Cloud 版本号依赖管理；Spring Cloud 是一个综合的项目，下面有很多子项目，比如 eureka 子项目；Greemwich 对应的 Spring Boot 是 2.0.x 版本。
<dependencyManagement>
<dependencies>
<!-- SCN -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Greenwich.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
2）lagou-cloud-eureka 工程 pom.xml 中引入依赖
<dependencies>
<!-- Eureka server 依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
</dependencies>
注意：在父工程的 pom 文件中手动引入 jaxb 的 jar，因为 Jdk 9 之后默认没有加载该模块，但是 Eureka Server 使用到，所以需要手动导入，否则 Eureka Server 服务无法启动。
父工程 lagou-parent 的 pom 中增加依赖：
<!-- 引入 Jaxb，开始 -->
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.2.11</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2.11</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.2.10-b140310.1920</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
<!-- 引入 Jaxb，结束 -->
3）在 application.yml 文件中配置 Eureka server 服务端口，服务名等信息：
server:
port: 9200
spring:
application:
name: lagou-cloud-eureka
eureka:
# Eureka server 本身也是 eureka 的一个客户端，因为在集群下需要与其他 eureka server 进行数据的同步
client:
# 定义 eureka server url, 如果是集群情况下 defaultZone 设置为集群下的别的 Eureka Server 的地址，多个地址使用逗号隔开
service-url:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka
# 自己就是服务不需要注册自己
register-with-eureka: false
# 自己就是服务不需要从 Eureka Server 获取服务信息, 默认为 true
fetch-registry: false
instance:
# 当前 eureka 实例的主机名
hostname: localhost
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
4）编写启动类，声明当前服务为 Eureka 注册中心
package com.renda.eureka;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
/**
* @author Renda Zhang
* @since 2020-11-01 16:36
*/
@SpringBootApplication
@EnableEurekaServer // 表示当前项目为 Eureka Server
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
5）访问 http://localhost:9200/，如果出现 Eureka 注册中心后台页面，则表明 Eureka Server 发布成功。
6）商品微服务和页面静态化微服务注册到 Eureka。
两个微服务的 POM 文件中都添加 Eureka Client 依赖：
<!-- Eureka client -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
两个微服务的 application.yml 都配置 Eureka 服务端信息：
eureka:
client:
service-url:
defaultZone: http://localhost:9200/eureka/
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
修改两个微服务的启动类，加上注解：
// 将当前项目作为 Eureka Client 注册到 Eureka Server, 只能在 Eureka 环境中使用
@EnableEurekaClient
或者使用可以应用在所有服务注册中心环境的注解：
// 将当前项目表示为注册中心的客户端，向注册中心进行注册，可以在所有的服务注册中心环境下使用
@EnableDiscoveryClient
7）刷新 Eureka 注册中心后台页面，发现新增了两个微服务信息。
在互联网应用中，服务实例很少有单个的。
如果 EurekaServer 只有一个实例，该实例挂掉，正好微服务消费者本地缓存列表中的服务实例也不可用，那么这个时候整个系统都受影响。
在生产环境中，会配置 Eureka Server 集群实现高可用。
Eureka Server 集群之中的节点通过点对点（P2P）通信的方式共享服务注册表。
开启两台 Eureka Server 以搭建集群。
修改个人电脑中 host 地址:
127.0.0.1 LagouCloudEurekaServerA
127.0.0.1 LagouCloudEurekaServerB
将 lagou-cloud-eureka 复制一份为 lagou-cloud-eureka2
lagou-cloud-eureka 的 application.yml：
server:
port: 9200
spring:
application:
name: lagou-cloud-eureka
eureka:
# Eureka server 本身也是 eureka 的一个客户端，因为在集群下需要与其他 eureka server 进行数据的同步
client:
# 定义 eureka server url, 如果是集群情况下 defaultZone 设置为集群下的别的 Eureka Server 的地址，多个地址使用逗号隔开
service-url:
defaultZone: http://LagouCloudEurekaServerB:9201/eureka
# 表示是否向 Eureka 中心注册自己的信息，因为自己就是 Eureka Server 所以不进行注册, 默认为 true
register-with-eureka: true
# 是否查询 / 拉取 Eureka Server 服务注册列表，默认为 true
fetch-registry: true
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
lagou-cloud-eureka2 的 application.yml：
server:
port: 9201
spring:
application:
name: lagou-cloud-eureka
eureka:
# Eureka server 本身也是 eureka 的一个客户端，因为在集群下需要与其他 eureka server 进行数据的同步
client:
# 定义 eureka server url, 如果是集群情况下 defaultZone 设置为集群下的别的 Eureka Server 的地址，多个地址使用逗号隔开
service-url:
defaultZone: http://LagouCloudEurekaServerA:9200/eureka
# 表示是否向 Eureka 中心注册自己的信息，因为自己就是 Eureka Server 所以不进行注册, 默认为 true
register-with-eureka: true
# 是否查询 / 拉取 Eureka Server 服务注册列表，默认为 true
fetch-registry: true
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
商品微服务的 application.xml：
server:
# 微服务的集群环境中，通常会为每一个微服务叠加。
port: 9000
spring:
application:
name: lagou-service-product
datasource:
driver-class-name: com.MySQL.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/renda01?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
username: root
password: password
eureka:
client:
service-url:
# 把 eureka 集群中的所有 url 都填写了进来，也可以只写一台，因为各个 eureka server 可以同步注册表
defaultZone: http://LagouCloudEurekaServerA:9200/eureka, http://LagouCloudEurekaServerB:9201/eureka
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
页面静态化微服务 application.xml：
server:
# 后期该微服务多实例，端口从 9100 递增（10 个以内）
port: 9100
Spring:
application:
name: lagou-service-page
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/renda01?useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
username: root
password: password
eureka:
client:
service-url:
# 把 eureka 集群中的所有 url 都填写了进来，也可以只写一台，因为各个 eureka server 可以同步注册表
defaultZone: http://LagouCloudEurekaServerA:9200/eureka, http://LagouCloudEurekaServerB:9201/eureka
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
服务消费者调用服务提供者
改造页面静态化微服务：之前是直接通过 RestTemplate 写死 URL 进行调用，现在通过 Eureka 方式进行调用。
@RestController
@RequestMapping("/page")
public class PageController {
@Autowired
RestTemplate restTemplate;
@Autowired
DiscoveryClient discoveryClient;
@GetMapping("/getProduct/{id}")
public Products getProduct(@PathVariable Integer id) {
// 1.获得 Eureka 中注册的 lagou-service-product 实例集合
List<ServiceInstance> instances = discoveryClient.getInstances("lagou-service-product");
// 2.获得实例集合中的第一个
ServiceInstance instance = instances.get(0);
// 3.根据实例信息拼接 IP 地址
String host = instance.getHost();
int port = instance.getPort();
String url = "http://" + host + ":" + port + "/product/query/" + id;
// 调用并返回
return restTemplate.getForObject(url, Products.class);
}
}
启动注册中心集群和微服务并使用 Postman 进行测试：
GET http://localhost:9100/page/getProduct/1
Eureka 的元数据有两种：标准元数据和自定义元数据。
标准元数据：主机名、IP 地址、端口号等信息，这些信息都会被发布在服务注册表中，用于服务之间的调用。
自定义元数据：可以使用 eureka.instance.metadata-map 配置，符合 KEY / VALUE 的存储格式；这些元数据可以在远程客户端中访问。
eureka:
instance:
# 使用 ip 注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是 ip）
prefer-ip-address: true
# 自定义实例显示格式，加上版本号，便于多版本管理，注意是 ip-address，早期版本是 ipAddress
instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@
# 自定义元数据，会和标准元数据一起注册到服务注册中心
metadata-map:
ip: 192.168.186.128
port: 10000
user: RendaZhang
pwd: 123456
可以在程序中可以使用 DiscoveryClient 获取指定微服务的所有元数据信息：
@RestController
@RequestMapping("/page")
public class PageController {
@Autowired
RestTemplate restTemplate;
@Autowired
DiscoveryClient discoveryClient;
@GetMapping("/getProduct/{id}")
public Products getProduct(@PathVariable Integer id) {
// 1.获得 Eureka 中注册的 lagou-service-product 实例集合
List<ServiceInstance> instances = discoveryClient.getInstances("lagou-service-product");
// 2.获得实例集合中的第一个
ServiceInstance instance = instances.get(0);
// 3.根据实例信息拼接 IP 地址
String host = instance.getHost();
int port = instance.getPort();
// 获取打印自定义元数据
Map<String, String> metadata = instance.getMetadata();
Set<Map.Entry<String, String>> entries = metadata.entrySet();
for (Map.Entry<String, String> entry : entries) {
System.out.println(entry.getKey() + " : " + entry.getValue());
}
String url = "http://" + host + ":" + port + "/product/query/" + id;
// 调用并返回
return restTemplate.getForObject(url, Products.class);
}
}
服务提供者（也是 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 秒服务会从注册中心中拉取一份服务列表，这个时间可以通过配置修改；往往不需要调整。
# 向 Eureka 服务中心集群注册服务
eureka:
client:
service-url:
# 每隔多久拉取一次服务列表
registry-fetch-interval-seconds: 30
1）服务消费者启动时，从 Eureka Server 服务列表获取只读备份，缓存到本地。
2）每隔 30 秒，会重新获取并更新数据。
3）每隔 30 秒的时间可以通过配置 eureka.client.registry-fetch-interval-seconds 修改。
服务下线：
1）当服务正常关闭操作时，会发送服务下线的 REST 请求给 Eureka Server。
2）服务中心接受到请求后，将该服务置为下线状态
失效剔除：
Eureka Server会定时（间隔值是 eureka.server.eviction-interval-timer-in-ms，默认 60s）进行检查，如果发现实例在在一定时间（此值由客户端设置的 eureka.instance.lease-expiration-duration-in-seconds 定义，默认值为 90s）内没有收到心跳，则会注销此实例。
自我保护机制：
自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使 Eureka 集群更加的健壮、稳定的运行。
自我保护机制的工作机制是：如果在 15 分钟内超过 85% 的客户端节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，Eureka Server 自动进入自我保护机制，此时会出现以下几种情况：
默认情况下，如果 Eureka Server 在一定时间内（默认 90 秒）没有接收到某个微服务实例的心跳，Eureka Server 将会移除该实例。但是当网络分区故障发生时，微服务与 Eureka Server 之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。
在单机测试的时候很容易满足心跳失败比例在 15 分钟之内低于 85%，这个时候就会触发 Eureka 的保护机制，一旦开启了保护机制（默认开启），则服务注册中心维护的服务实例就不是那么准确了，此时通过修改 Eureka Server 的配置文件来关闭保护机制，这样可以确保注册中心中不可用的实例被及时的剔除（不推荐）。
eureka:
server:
# 关闭自我保护模式（默认为 true）
enable-self-preservation: false
负载均衡一般分为服务器端负载均衡和客户端负载均衡。
所谓服务器端负载均衡，比如 Nginx、F5（硬件负载） 这些，请求到达服务器之后由这些负载均衡器根据一定的算法将请求路由到目标服务器处理。
所谓客户端负载均衡，比如 Ribbon，服务消费者客户端会有一个服务器地址列表，调用方在请求前通过一定的负载均衡算法选择一个服务器进行访问，负载均衡算法的执行是在请求客户端进行。
Ribbon 是 Netflix 发布的负载均衡器。Eureka 一般配合 Ribbon 进行使用，Ribbon 利用从 Eureka 中读取到服务信息，在调用服务提供者提供的服务时，会根据一定的算法进行负载。
需求：
复制商品微服务 lagou-service-product，命名为 lagou-service-product2，端口号 9001；在商品微服务中定义接口，返回当前服务实例占用的端口号。
页面静态化微服务通过负载均衡策略调用商品微服务的 controller。
Eureka Server --服务实例列表--> 页面静态化微服务
页面静态化微服务
--Ribbon--> 负载均衡算法
----> [商品微服务 9000，商品微服务 9001，商品微服务 9002]
在微服务中使用 Ribbon 不需要额外导入依赖坐标，微服务中引入过 eureka-client 相关依赖，会自动引入 Ribbon 相关依赖坐标。
代码中使用如下，在服务消费者的 RestTemplate 上添加对应注解即可：
@SpringBootApplication
@EnableDiscoveryClient
public class PageApplication {
public static void main(String[] args) {
SpringApplication.run(PageApplication.class,args);
}
// 向容器中注入一个 RestTemplate，封装了 HttpClient
@Bean
@LoadBalanced // 启动请求的 Ribbon 负载均衡
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
在 lagou-serivce-product 中创建一个 Controller，定义方法返回当前微服务所使用的容器端口号：
com.renda.product.controller.ServiceInfoController
@RestController
@RequestMapping("/service")
public class ServiceInfoController {
@Value("${server.port}")
private String port;
@GetMapping("/port")
public String getPort(){
return port;
}
}
然后按照 lagou-serivce-product 复制创建 lagou-serivce-product2 微服务；端口改为 9001，除了 spring.applicaton.name 保持为 lagou-service-product，其它地方改为 lagou-service-product2；ProductApplication 改为 Product2Application；最后在父工程下手动加入新增的模块。最后如果 IDEA 没有显示新增模块，就删掉父工程的新增模块引入，同步一次后，再把新增模块引入代码加回去并同步。
在页面静态化微服务中调用 lagou-server-product 下的资源路径：http://lagou-server-product/server/query。
@RestController
@RequestMapping("/page")
public class PageController {
@Autowired
RestTemplate restTemplate;
@GetMapping("/getProduct/{id}")
public Products getProduct(@PathVariable Integer id) {
String url = "http://lagou-service-product/product/query/" + id;
return restTemplate.getForObject(url, Products.class);
}
@GetMapping("/loadProductServicePort")
public String getProductServerPort() {
return restTemplate.getForObject("http://lagou-service-product/service/port", String.class);
}
}
Ribbon 内置了多种负载均衡策略，内部负责复杂均衡的顶级接口为 com.netflix.loadbalancer.IRule，接口简介:
package com.netflix.loadbalancer;
/**
* Interface that defines a "Rule" for a LoadBalancer. A Rule can be thought of
* as a Strategy for loadbalacing. Well known loadbalancing strategies include
* Round Robin, Response Time based etc.
*
* @author stonse
*
*/
public interface IRule{
/*
* choose one alive server from lb.allServers or
* lb.upServers according to key
*
* @return choosen Server object. NULL is returned if none
* server is available
*/
public Server choose(Object key);
public void setLoadBalancer(ILoadBalancer lb);
public ILoadBalancer getLoadBalancer();
}
IRule 的子实现类：
IRule <--实现-- AbstractLoadBalancerRule
AbstractLoadBalancerRule <--继承-- [RandomRule, RoundRobinRule, ClientConfigEnabledRoundRobinRule, RetryRule]
RoundRobinRule <--继承-- WeightedResponseTimeRule
ClientConfigEnabledRoundRobinRule
<--继承-- [PredicateBasedRule, BestAvailableRule]
PredicateBasedRule
<--继承-- [AvailabilityFilteringRule, ZoneAvoidanceRule]
默认超过 10 次获取到的 server 都不可用，会返回一个空的 server。
如果随机到的 server 为 null 或者不可用的话，会 while 不停的循环选取。
一定时限内循环重试。默认继承 RoundRobinRule，也支持自定义注入，RetryRule 会在每次选取之后，对选举的 server 进行判断，是否为 null，是否 alive，并且在 500ms 内会不停的选取判断。而 RoundRobinRule 失效的策略是超过 10 次，RandomRule 是没有失效时间的概念，只要 serverList 没都挂。
遍历 serverList，选取出可用的且连接数最小的一个 server。该算法里面有一个 LoadBalancerStats 的成员变量，会存储所有 server 的运行状况和连接数。如果选取到的 server 为 null，那么会调用 RoundRobinRule 重新选取。
扩展了轮询策略，会先通过默认的轮询选取一个 server，再去判断该 server 是否超时可用，当前连接数是否超限，都成功再返回。
扩展了轮询策略，继承了 2 个过滤器：ZoneAvoidancePredicate 和 AvailabilityPredicate，除了过滤超时和链接数过多的 server，还会过滤掉不符合要求的 zone 区域里面的所有节点， 在一个区域/机房内的服务实例中轮询；先过滤再轮询。
修改负载均衡策略：
# 针对的被调用方微服务名称,不加就是全局生效
lagou-service-product:
ribbon:
# 请求连接超时时间
ConnectTimeout: 2000
# 请求处理超时时间
ReadTimeout: 15000
# 对所有操作都进行重试
OkToRetryOnAllOperations: true
## 根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由 MaxAutoRetries 配置），
## 如果不行，就换一个实例进行访问，如果还不行，再换一次实例访问（更换次数由 MaxAutoRetriesNextServer 配置），
## 如果依然不行，返回失败信息。
# 对当前选中实例重试次数，不包括第一次调用
MaxAutoRetries: 2
# 切换实例的重试次数
MaxAutoRetriesNextServer: 2
# 负载策略调整
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.AvailabilityFilteringRule
Ribbon 工作原理：
Actor ----> 拦截器 ----> 负载均衡算法（Ribbon）----> 目标微服务
Ribbon：按照一定算法选取服务实例
SpringCloud 充分利用了 SpringBoot 的自动装配特点。
引入的 Maven 依赖 --> spring-cloud-commons-2.1.0.RELEASE.jar --> META-INF --> spring.factories 配置文件：
# AutoConfiguration
org.springframework.boot.autoconfigure.EnableAutoConfiguration=
org.springframework.cloud.client.CommonsClientAutoConfiguration,
org.springframework.cloud.client.discovery.composite.CompositeDiscoveryClientAutoConfiguration,
org.springframework.cloud.client.discovery.noop.NoopDiscoveryClientAutoConfiguration,
org.springframework.cloud.client.discovery.simple.SimpleDiscoveryClientAutoConfiguration,
org.springframework.cloud.client.hypermedia.CloudHypermediaAutoConfiguration,
org.springframework.cloud.client.loadbalancer.AsyncLoadBalancerAutoConfiguration,
org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration,
...
点击配置文件中的 LoadBalancerAutoConfiguration 跳转到其源码文件：
@Configuration
@ConditionalOnClass(RestTemplate.class)
@ConditionalOnBean(LoadBalancerClient.class)
@EnableConfigurationProperties(LoadBalancerRetryProperties.class)
public class LoadBalancerAutoConfiguration {
@LoadBalanced
@Autowired(required = false)
private List<RestTemplate> restTemplates = Collections.emptyList();
...
@Configuration
@ConditionalOnMissingClass("org.springframework.retry.support.RetryTemplate")
static class LoadBalancerInterceptorConfig {
@Bean
public LoadBalancerInterceptor ribbonInterceptor(
LoadBalancerClient loadBalancerClient,
LoadBalancerRequestFactory requestFactory) {
return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
}
@Bean
@ConditionalOnMissingBean
public RestTemplateCustomizer restTemplateCustomizer(
final LoadBalancerInterceptor loadBalancerInterceptor) {
return restTemplate -> {
List<ClientHttpRequestInterceptor> list = new ArrayList<>(
restTemplate.getInterceptors());
list.add(loadBalancerInterceptor);
restTemplate.setInterceptors(list);
};
}
}
...
}
Hystrix 熔断器属于一种容错机制。
微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。
服务雪崩效应：是一种因“服务提供者的不可用”导致“服务调用者不可用”，并将不可用逐渐放大的现象。
[MQ 微服务，MQ 微服务，MQ 微服务] ----> 静态化微服务 ----> 商品微服务
站在静态化微服务角度来看：
扇入 - 上游服务对该服务的调用
扇出 - 该服务对下游服务的调用
扇入大是一个好事，扇出大不一定是好事。
在微服务架构中，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务 A 调用微服务 B 和微服务 C，微服务 B 和微服务 C 又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务 A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
最下游商品微服务响应时间过长，大量请求阻塞，大量线程不会释放，会导致服务器资源耗尽，最终导致上游服务甚至整个系统瘫痪。
形成原因 - 服务雪崩的过程可以分为三个阶段：
服务雪崩的每个阶段都可能由不同的原因造成：
服务提供者不可用：硬件故障、程序 Bug、缓存击穿、用户大量请求。
重试加大请求流量：用户重试、代码逻辑重试。
服务调用者不可用：同步等待造成的资源耗尽。
从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段。
介绍三种技术手段应对微服务中的雪崩效应，这三种手段都是从系统可用性、可靠性角度出发，尽量防止系统整体缓慢甚至瘫痪。
熔断机制是应对雪崩效应的一种微服务链路保护机制。在各种场景下都会接触到熔断。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，熔断该节点微服务的调用，进行服务的降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
注意：
1）服务熔断重点在“断”，切断对下游服务的调用。
2）服务熔断和服务降级往往是一起使用的，Hystrix 就是这样。
通俗讲就是整体资源不够用了，先将一些不关紧的服务停掉（调用的时候，返回一个预留的值，也叫做兜底数据），待渡过难关高峰过去，再把那些服务打开。
服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地的 Fallback 回调，返回一个默认值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。
服务出问题或者影响到核心流程的性能时，暂时将服务屏蔽掉，待高峰或者问题解决后再打开；但是有些场景并不能用服务降级来解决，比如秒杀业务这样的核心功能，这个时候可以结合服务限流来限制这些场景的并发 / 请求量。
限流措施：
Hystrix - defend your application 是由 Netflix 开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。
Hystrix 主要通过以下几点实现延迟和容错：
目的：商品微服务长时间没有响应，服务消费者 --> 页面静态化微服务快速失败给用户提示。
引入依赖：服务消费者工程（静态化微服务）中引入Hystrix依赖坐标（也可以添加在父工程中）
<!-- 熔断器 Hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
开启熔断：服务消费者工程（静态化微服务）的启动类中添加熔断器开启注解 @EnableCircuitBreaker。
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker // 启用熔断服务
public class PageApplication {
public static void main(String[] args) {
SpringApplication.run(PageApplication.class,args);
}
// 向容器中注入一个 RestTemplate，封装了 HttpClient
@Bean
@LoadBalanced // 启动请求的 Ribbon 负载均衡
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
定义服务降级处理方法：业务方法上使用 @HystrixCommand 的 fallbackMethod 属性关联到服务降级处理方法。
@RestController
@RequestMapping("/page")
public class PageController {
@Autowired
RestTemplate restTemplate;
...
/**
* 模拟服务超时，熔断处理
* 针对熔断处理，Hystrix 默认维护一个线程池，默认大小为 10。
*/
@HystrixCommand(
//只有是在 @HystrixCommand 中定义了 threadPoolKey，就意味着开启了舱壁模式（线程隔离），该方法就会自己维护一个线程池。
// 默认所有的请求共同维护一个线程池，实际开发：每个方法维护一个线程池
threadPoolKey = "getProductServerPort2",
// 每一个属性对应的都是一个 HystrixProperty
threadPoolProperties = {
// 并发线程数
@HystrixProperty(name = "coreSize", value = "1"),
// 默认线程队列值是 -1，默认不开启
@HystrixProperty(name = "maxQueueSize", value = "20")
},
// 超时时间的设置
commandProperties = {
// 设置请求的超时时间，一旦请求超过此时间那么都按照超时处理，默认超时时间是 1s
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000")
}
)
@GetMapping("/loadProductServicePort2")
public String getProductServerPort2() {
return restTemplate.getForObject("http://lagou-service-product/service/port", String.class);
}
}
商品微服务模拟超时操作：
@RestController
@RequestMapping("/service")
public class ServiceInfoController {
@Value("${server.port}")
private String port;
@GetMapping("/port")
public String getPort(){
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return port;
}
}
使用 Postman 测试：
GET http://localhost:9100/page/loadProductServicePort2
测试返回超时错误信息：getProductServerPort2 timed-out and fallback failed.。
因为没有降级处理，所以只得到 500 超时错误信息。
配置 @HystrixCommand 注解，定义降级处理方法：
@RestController
@RequestMapping("/page")
public class PageController {
@Autowired
RestTemplate restTemplate;
...
/**
* 服务降级演示：是在服务熔断之后的兜底操作
*/
@HystrixCommand(
// 超时时间的设置
commandProperties = {
// 设置请求的超时时间，一旦请求超过此时间那么都按照超时处理，默认超时时间是 1s
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000"),
// 统计窗口时间的设置
@HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds",value = "8000"),
// 统计窗口内的最小请求数
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "2"),
// 统计窗口内错误请求阈值的设置 50%
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"),
// 自我修复的活动窗口时间
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "3000")
},
// 设置回退方法
fallbackMethod = "getProductServerPortFallBack"
)
@GetMapping("/loadProductServicePort3")
public String getProductServerPort3() {
return restTemplate.getForObject("http://lagou-service-product/service/port", String.class);
}
/**
* 定义回退方法，当请求出发熔断后执行，补救措施
* 注意：
* 1.方法形参和原方法保持一致
* 2.方法的返回值与原方法保持一致
*/
public String getProductServerPortFallBack(){
// 兜底数据
return "-1";
}
}
使用 Postman 测试：
GET http://localhost:9100/page/loadProductServicePort3
Hystrix 舱壁模式即线程池隔离策略。
如果不进行任何设置，所有熔断方法使用一个 Hystrix 线程池（10 个线程），那么这样的话会导致问题，这个问题并不是扇出链路微服务不可用导致的，而是线程机制导致的，如果方法 A 的请求把 10 个线程都用了，方法 2 请求处理的时候压根都没法去访问 B，因为没有线程可用，并不是 B 服务不可用：
----> 带有 @HystrixCommand 注解方法1
--10个请求--> Hystrix 默认的线程池
----> A 服务
----> 带有 @HystrixCommand 注解方法2
--10个请求--> Hystrix 默认的线程池
----> A 服务
所有加有 @HystrixCommand 的方法会共同维护一个线程池；
默认线程池有 10 个线程，默认队列值为 -1；
如果不进行任何设置，
Hystrix 默认的线程池实现不适合在生产环境中使用。
为了避免问题服务请求过多导致正常服务无法访问，Hystrix 不是采用增加线程数，而是单独的为每一个控制方法创建一个线程池的方式，这种模式叫做“舱壁模式"，也是线程隔离的手段；即在 @HystrixCommand 中设置 threadPoolProperties 属性
出现调用错误 ----> 是否达到最小请求数
没有达到最小请求数 ----> 没有遇到问题
达到最小请求数 ----> 错误数量是否达到阈值
错误数量没有达到阈值 ----> 没有遇到问题
错误数量达到阈值 ----> 跳闸
跳闸 ----> 远程服务是否已经正常
远程服务不正常 ----> 跳闸
远程服务正常 ----> 重置断路器，调用可以通过
10 秒时间窗口：检测是否达到最小请求数和错误数量是否达到阈值。
5 秒活动窗口：检测远程服务是否已经正常。
1）当调用出现问题时，开启一个时间窗（10s）
2）在这个时间窗内，统计调用次数是否达到最小请求数？如果没有达到，则重置统计信息，回到第 1 步；如果达到了，则统计失败的请求数占所有请求数的百分比。然后统计是否达到阈值？ 如果达到，则跳闸（不再请求对应服务）；如果没有达到，则重置统计信息，回到第 1 步。
3）如果跳闸，则会开启一个活动窗口（默认 5s），每隔 5s，Hystrix 会让一个请求通过，到达那个问题服务，看是否调用成功，如果成功，重置断路器回到第 1 步，如果失败，回到第 3 步。
可以自定义的断路器行为：
@HystrixCommand(
// 超时时间的设置
commandProperties = {
// 设置请求的超时时间，一旦请求超过此时间那么都按照超时处理，默认超时时间是 1s
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000"),
// 统计窗口时间的设置
@HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds",value = "8000"),
// 统计窗口内的最小请求数
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "2"),
// 统计窗口内错误请求阈值的设置 50%
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"),
// 自我修复的活动窗口时间
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "3000")
},
)
上述通过注解进行的配置也可以配置在配置文件中：
# 配置熔断策略：
hystrix:
command:
default:
circuitBreaker:
# 强制打开熔断器，如果该属性设置为 true，强制断路器进入打开状态，将会拒绝所有的请求。 默认 false 关闭的
forceOpen: false
# 触发熔断错误比例阈值，默认值 50%
errorThresholdPercentage: 50
# 熔断后休眠时长，默认值 5 秒
sleepWindowInMilliseconds: 3000
# 熔断触发最小请求次数，默认值是 20
requestVolumeThreshold: 2
execution:
isolation:
thread:
# 熔断超时设置，默认为 1 秒
timeoutInMilliseconds: 2000
基于 spring boot 的健康检查观察跳闸状态（自动投递微服务暴露健康检查细节）：
# springboot 中暴露健康检查等断点接口
management:
endpoints:
web:
exposure:
include: "*"
# 暴露健康接口的细节
endpoint:
health:
show-details: always
使用 Postman 访问健康检查接口：
GET http://localhost:9100/actuator/health
有一次在生产环境，突然出现了很多笔还款单被挂起，后来排查原因，发现是内部系统调用时出现了 Hystrix 调用异常。在开发过程中，因为核心线程数设置的比较大，没有出现这种异常。放到了测试环境，偶尔有出现这种情况。
后来调整 maxQueueSize 属性，确实有所改善。可没想到在生产环境跑了一段时间后却又出现这种了情况，此时去查看 maxQueueSize 属性，可是 maxQueueSize 属性是设置值了。
为什么 maxQueueSize 属性不起作用，后来通过查看官方文档发现 Hystrix 还有一个 queueSizeRejectionThreshold 属性，这个属性是控制队列最大阈值的，而 Hystrix 默认只配置了 5 个，因此就算把 maxQueueSize 的值设置再大，也是不起作用的，两个属性必须同时配置。
hystrix:
threadpool:
default:
# 并发执行的最大线程数，默认 10；建议和服务器的核数一样
coreSize: 10
# BlockingQueue 的最大队列数，默认值 -1
maxQueueSize: 1000
# 即使 maxQueueSize 没有达到，达到 queueSizeRejectionThreshold 该值后，请求也会被拒绝，默认值 5
queueSizeRejectionThreshold: 800
改进后的配置案例 - 将核心线程数调低，最大队列数和队列拒绝阈值的值都设置大一点：
hystrix:
threadpool:
default:
coreSize: 10
maxQueueSize: 1500
queueSizeRejectionThreshold: 1000
想了解更多，欢迎关注我的微信公众号：Renda_Zhang
