【SpringCloud】从入门到精通（下）

网关与路由

什么是网关？顾明思议，网关就是网络的关口。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验。
现在前端不能请求各个微服务地址，只能去请求网关

• 网关可以做安全控制，也就是登录身份校验，校验通过才放行
• 通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去

在SpringCloud当中，提供了两种网关实现方案：

• Netflix Zuul：早期实现，目前已经淘汰
• SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强

因此，我们选择性能更好的SpringCloudGateway来作为我们微服务的网关

快速入门

由于网关本身也是一个独立的微服务，因此也需要创建一个模块开发功能。大概步骤如下：

• 创建网关微服务
• 引入SpringCloudGateway、NacosDiscovery依赖
• 编写启动类
• 配置网关路由

创建项目

名为hm-gatery父工程为hmall

引入依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>hmall</artifactId><groupId>com.heima</groupId><version>1.0.0</version></parent><modelVersion>4.0.0</modelVersion><artifactId>hm-gateway</artifactId><properties><maven.compiler.source>11</maven.compiler.source><maven.compiler.target>11</maven.compiler.target></properties><dependencies><!--common--><dependency><groupId>com.heima</groupId><artifactId>hm-common</artifactId><version>1.0.0</version></dependency><!--网关--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></dependency><!--nacos discovery--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency><!--负载均衡--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency></dependencies><build><finalName>${project.artifactId}</finalName><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build>
</project>

编写启动类

package com.hmall.gateway;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplication
public class GatewayApplication {public static void main(String[] args) {SpringApplication.run(GatewayApplication.class, args);}
}

配置路由

server:port: 8080
spring:application:name: gatewaycloud:nacos:server-addr: 192.168.150.101:8848gateway:routes:- id: item # 路由规则id，自定义，唯一uri: lb://item-service # 路由的目标服务，lb代表负载均衡，会从注册中心拉取服务列表predicates: # 路由断言，判断当前请求是否符合当前规则，符合则路由到目标服务- Path=/items/**,/search/** # 这里是以请求路径作为判断规则- id: carturi: lb://cart-servicepredicates:- Path=/carts/**- id: useruri: lb://user-servicepredicates:- Path=/users/**,/addresses/**- id: tradeuri: lb://trade-servicepredicates:- Path=/orders/**- id: payuri: lb://pay-servicepredicates:- Path=/pay-orders/**

四个属性含义如下：

• id：路由的唯一标示
• predicates：路由断言，其实就是匹配条件
• filters：路由过滤条件，后面讲
• uri：路由目标地址，lb://代表负载均衡，从注册中心获取目标微服务的实例列表，并且负载均衡选择一个访问。

这里我们重点关注路由断言

名称	说明	示例
After	是某个时间点后的请求	- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before	是某个时间点之前的请求	- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between	是某两个时间点之前的请求	- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie	请求必须包含某些cookie	- Cookie=chocolate, ch.p
Header	请求必须包含某些header	- Header=X-Request-Id, \d+
Host	请求必须是访问某个host（域名）	- Host=.somehost.org,.anotherhost.org
Method	请求方式必须是指定方式	- Method=GET,POST
Path	请求路径必须符合指定规则	- Path=/red/{segment},/blue/**
Query	请求参数必须包含指定参数	- Query=name, Jack或者- Query=name
RemoteAddr	请求者的ip必须是指定范围	- RemoteAddr=192.168.1.1/24
weight	权重处理

网关的登录与校验

单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。

鉴权思路分析

我们的登录是基于JWT来实现的，校验JWT的算法复杂，而且需要用到秘钥。如果每个微服务都去做登录校验，这就存在着两大问题：

• 每个微服务都需要知道JWT的秘钥，不安全
• 每个微服务重复编写登录校验代码、权限校验代码，麻烦

那么该怎么办呢，其实我们所有的请求都会经过网关，如果在网关当中对用户身份进行校验，那么就可以避免这些问题

网关过滤器

登录校验必须在请求转发到微服务之前做，否则就失去了意义。而网关的请求转发是Gateway内部代码实现的，要想在请求转发之前做登录校验，就必须了解Gateway内部工作的基本原理。

1. 客户端请求进入网关后由HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（Route），然后将请求交给WebHandler去处理。
2. WebHandler则会加载当前路由下需要执行的过滤器链（Filter chain），然后按照顺序逐一执行过滤器（后面称为Filter）。
3. 图中Filter被虚线分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前和之后被执行。
4. 只有所有Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。
5. 微服务返回结果后，再倒序执行Filter的post逻辑。
6. 最终把响应结果返回。

如图所示，当中有一个名为NettyRoutingFilter的过滤器，他是过滤器链中的最后一个（承担着将请求分发给微服务的作用），那么试想一下，如果我们能够自己定义一个过滤器，在NettyRoutingFilter之前，并且在pre部分，那么是不是就可以对用户身份进行校验。

网关过滤器链中的过滤器有两种：

• GatewayFilter：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route.
• GlobalFilter：全局过滤器，作用范围是所有路由，不可配置

其实GatewayFilter和GlobalFilter这两种过滤器的方法签名完全一致：

/*** 处理请求并将其传递给下一个过滤器* @param exchange 当前请求的上下文，其中包含request、response等各种数据* @param chain 过滤器链，基于它向下传递请求* @return 根据返回值标记当前请求是否被完成或拦截，chain.filter(exchange)就放行了。*/
Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);

Gateway内置的GatewayFilter过滤器使用起来非常简单，无需编码，只要在yaml文件中简单配置即可。而且其作用范围也很灵活，配置在哪个Route下，就作用于哪个Route.

spring:cloud:gateway:routes:- id: test_routeuri: lb://test-servicepredicates:-Path=/test/**filters:- AddRequestHeader=key, value # 逗号之前是请求头的key，逗号之后是value

想让过滤器作用与所有路由

spring:cloud:gateway:default-filters: # default-filters下的过滤器可以作用于所有路由- AddRequestHeader=key, valueroutes:- id: test_routeuri: lb://test-servicepredicates:-Path=/test/**

自定义过滤器

自定义GatewayFilter

自定义GatewayFilter不是直接实现GatewayFilter，而是实现AbstractGatewayFilterFactory。最简单的方式是这样的：

@Component
public class PrintAnyGatewayFilterFactory extends AbstractGatewayFilterFactory<Object> {@Overridepublic GatewayFilter apply(Object config) {return new GatewayFilter() {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 获取请求ServerHttpRequest request = exchange.getRequest();// 编写过滤器逻辑System.out.println("过滤器执行了");// 放行return chain.filter(exchange);}};}
}

注意：该类的名称一定要以GatewayFilterFactory为后缀！

然后在yaml配置中这样使用：

spring:cloud:gateway:default-filters:- PrintAny # 此处直接以自定义的GatewayFilterFactory类名称前缀类声明过滤器

自定义GlobalFilter

@Component
public class PrintAnyGlobalFilter implements GlobalFilter, Ordered {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 编写过滤器逻辑System.out.println("未登录，无法访问");// 放行// return chain.filter(exchange);// 拦截ServerHttpResponse response = exchange.getResponse();response.setRawStatusCode(401);return response.setComplete();}@Overridepublic int getOrder() {// 过滤器执行顺序，值越小，优先级越高return 0;}
}

登录校验

接下来，我们就利用自定义GlobalFilter来完成登录校验。

@Component
@RequiredArgsConstructor
@EnableConfigurationProperties(AuthProperties.class)
public class AuthGlobalFilter implements GlobalFilter, Ordered {private final JwtTool jwtTool;private final AuthProperties authProperties;private final AntPathMatcher antPathMatcher = new AntPathMatcher();@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {// 1.获取RequestServerHttpRequest request = exchange.getRequest();// 2.判断是否不需要拦截if(isExclude(request.getPath().toString())){// 无需拦截，直接放行return chain.filter(exchange);}// 3.获取请求头中的tokenString token = null;List<String> headers = request.getHeaders().get("authorization");if (!CollUtils.isEmpty(headers)) {token = headers.get(0);}// 4.校验并解析tokenLong userId = null;try {userId = jwtTool.parseToken(token);} catch (UnauthorizedException e) {// 如果无效，拦截ServerHttpResponse response = exchange.getResponse();response.setRawStatusCode(401);return response.setComplete();}// TODO 5.如果有效，传递用户信息System.out.println("userId = " + userId);// 6.放行return chain.filter(exchange);}private boolean isExclude(String antPath) {for (String pathPattern : authProperties.getExcludePaths()) {if(antPathMatcher.match(pathPattern, antPath)){return true;}}return false;}@Overridepublic int getOrder() {return 0;}
}

微服务获取用户信息

现在，网关已经可以完成登录校验并获取登录用户身份信息。但是当网关将请求转发到微服务时，微服务又该如何获取用户身份呢？
服务又该如何获取用户身份呢？
由于网关发送请求到微服务依然采用的是Http请求，因此我们可以将用户信息以请求头的方式传递到下游微服务。然后微服务可以从请求头中获取登录用户信息。考虑到微服务内部可能很多地方都需要用到登录用户信息，因此我们可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。

保存用户信息到请求头

还在上面定义的那个拦截器当中，我们将第五步改造一下

拦截器获取用户

看我们整个项目，每个微服务模块都用到了hm-common，因此我们可以把MVC的拦截器定义在common当中，这样就不用在每个微服务模块定义拦截器了，并且在common当中定义一个存储用户信息的ThreadLocal工具。

public class UserInfoInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {// 1.获取请求头中的用户信息String userInfo = request.getHeader("user-info");// 2.判断是否为空if (StrUtil.isNotBlank(userInfo)) {// 不为空，保存到ThreadLocalUserContext.setUser(Long.valueOf(userInfo));}// 3.放行return true;}@Overridepublic void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {// 移除用户UserContext.removeUser();}
}

MVC注册拦截器，在这里我们加上这个条件@ConditionalOnClass(DispatcherServlet.class)是因为网关有自己的一套拦截流程和MVC那一套不一样，网关当中也引入了common模块，如果把MVCConfig也变为网关当中一个Bean，势必会报错，因此我们加上这个条件，因为网关当中没有引入MVC的依赖，所以就不会注册这个Bean

@Configuration
@ConditionalOnClass(DispatcherServlet.class)
public class MvcConfig implements WebMvcConfigurer {@Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(new UserInfoInterceptor());}
}

需要注意的是，这个包在com.hmall.common.config与其他微服务扫描的包不一致，这时候我们就需要用到springboot的自动装配原理，我们要将其添加到resources目录下的META-INF/spring.factories文件中：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\com.hmall.common.config.MyBatisConfig,\com.hmall.common.config.MvcConfig

OpenFeign传递用户

我们想象，我们是不是有其他微服务的业务会调用其他微服务，刚好这个被调用的微服务要获取到用户的id，那么我们该怎么传递呢。
这里要借助Feign中提供的一个拦截器接口：feign.RequestInterceptor

public interface RequestInterceptor {/*** Called for every request. * Add data using methods on the supplied {@link RequestTemplate}.*/void apply(RequestTemplate template);
}

@Bean
public RequestInterceptor userInfoRequestInterceptor(){return new RequestInterceptor() {@Overridepublic void apply(RequestTemplate template) {// 获取登录用户Long userId = UserContext.getUser();if(userId == null) {// 如果为空则直接跳过return;}// 如果不为空则放入请求头中，传递给下游微服务template.header("user-info", userId.toString());}};
}

配置管理

我们的微服务项目还有以下几个问题需要解决

• 网关路由在配置文件中写死了，如果变更必须重启微服务
• 某些业务配置在配置文件中写死了，每次修改都要重启服务
• 每个微服务都有很多重复的配置，维护成本高

添加共享配置

我们可以吧每个微服务模块中的公共模块都抽取出来，放到nacos当中

拉取共享配置

接下来，我们要在微服务拉取共享配置。将拉取到的共享配置与本地的application.yaml配置合并，完成项目上下文的初始化。
不过，需要注意的是，读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。
也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos 地址，该如何去加载nacos中的配置文件呢？流程如下图

也就是说，我们如果把nacos的配置放在application.yaml文件当中，SpringCloud根本就不知道从哪里拉取配置，导致项目启动失败，这时候我们就需要用到bootstrap.yaml

引入依赖

  <!--nacos配置管理--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency><!--读取bootstrap文件--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId></dependency>

新建bootstrap.yaml

内容如下

spring:application:name: cart-service # 服务名称profiles:active: devcloud:nacos:server-addr: 192.168.150.101 # nacos地址config:file-extension: yaml # 文件后缀名shared-configs: # 共享配置- dataId: shared-jdbc.yaml # 共享mybatis配置- dataId: shared-log.yaml # 共享日志配置- dataId: shared-swagger.yaml # 共享日志配置

配置热更新

有很多的业务相关参数，将来可能会根据实际情况临时调整。例如购物车业务，购物车数量有一个上限，默认是10，对应代码如下：

但是现在有个问题，如果有一天我们想更改这个数值，那么就只能去重启项目然后才能更改这个数值，这显然非常麻烦
这就要用到Nacos的配置热更新能力了，分为两步：

• 在Nacos中添加配置
• 在微服务读取配置

添加配置到nacos

我们这里要注意dataId的格式：[服务名]-[spring.active.profile].[后缀名]

文件名称由三部分组成：

• 服务名：我们是购物车服务，所以是cart-service
• spring.active.profile：就是spring boot中的spring.active.profile，可以省略，则所有profile共享该配置
• 后缀名：例如yaml

这里我们直接使用cart-service.yaml这个名称，则不管是dev还是local环境都可以共享该配置。
配置内容如下：

hm:cart:maxAmount: 1 # 购物车商品数量上限

最后提交配置

配置热更新

接着，我们在微服务中读取配置，实现配置热更新。
在cart-service中新建一个属性读取类：

package com.hmall.cart.config;import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;@Data
@Component
@ConfigurationProperties(prefix = "hm.cart")
public class CartProperties {private Integer maxAmount;
}

接着在代码中更改，然后我们试着在nacos中更改这个数值，测试后就会发现他会随着我们的更改而改变

动态路由

网关的路由配置全部是在项目启动时由org.springframework.cloud.gateway.route.CompositeRouteDefinitionLocator在项目启动的时候加载，并且一经加载就会缓存到内存中的路由表内（一个Map），不会改变。也不会监听路由变更，所以，我们无法利用上节课学习的配置热更新来实现路由更新。

那么我们该怎么更改路由呢

监听Nacos配置变更

如果希望 Nacos 推送配置变更，可以使用 Nacos 动态监听配置接口来实现。

public void addListener(String dataId, String group, Listener listener)

• dataId(String) 配置 ID，保证全局唯一性，只允许英文字符和 4 种特殊字符（“.”、“:”、“-”、“_”）。不超过 256 字节。
• group(String) 配置分组，一般是默认的DEFAULT_GROUP。
• listener(Listener) 监听器，配置变更进入监听器的回调函数。

实例代码

String serverAddr = "{serverAddr}";
String dataId = "{dataId}";
String group = "{group}";
// 1.创建ConfigService，连接Nacos
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
ConfigService configService = NacosFactory.createConfigService(properties);
// 2.读取配置
String content = configService.getConfig(dataId, group, 5000);
// 3.添加配置监听器
configService.addListener(dataId, group, new Listener() {@Overridepublic void receiveConfigInfo(String configInfo) {// 配置变更的通知处理System.out.println("recieve1:" + configInfo);}// 方法返回 null 时，Nacos 会使用默认的执行器来处理配置变更通知。默认执行器通常会在 Nacos 客户端的内部线程中执行 receiveConfigInfo 方法。@Overridepublic Executor getExecutor() {return null;}
});

这里核心的步骤有2步：

• 创建ConfigService，目的是连接到Nacos
• 添加配置监听器，编写配置变更的通知处理逻辑

由于我们采用了spring-cloud-starter-alibaba-nacos-config自动装配，因此ConfigService已经在com.alibaba.cloud.nacos.NacosConfigAutoConfiguration中自动创建好了：

NacosConfigManager中是负责管理Nacos的ConfigService的，具体代码如下：

因此，只要我们拿到NacosConfigManager就等于拿到了ConfigService，第一步就实现了。

第二步，编写监听器。虽然官方提供的SDK是ConfigService中的addListener，不过项目第一次启动时不仅仅需要添加监听器，也需要读取配置，因此建议使用的API是这个：

String getConfigAndSignListener(String dataId, // 配置文件idString group, // 配置组，走默认long timeoutMs, // 读取配置的超时时间Listener listener // 监听器
) throws NacosException;

这时候我们就可以在项目启动的时候先配置一次路由，再在配置更新的时候去更新路由

更新路由

更新路由要用到org.springframework.cloud.gateway.route.RouteDefinitionWriter这个接口：

package org.springframework.cloud.gateway.route;import reactor.core.publisher.Mono;/*** @author Spencer Gibb*/
public interface RouteDefinitionWriter {/*** 更新路由到路由表，如果路由id重复，则会覆盖旧的路由*/Mono<Void> save(Mono<RouteDefinition> route);/*** 根据路由id删除某个路由*/Mono<Void> delete(Mono<String> routeId);}

• id：路由id
• predicates：路由匹配规则
• filters：路由过滤器
• uri：路由目的地

将来我们保存到Nacos的配置也要符合这个对象结构，将来我们以JSON来保存，格式如下：

{"id": "item","predicates": [{"name": "Path","args": {"_genkey_0":"/items/**", "_genkey_1":"/search/**"}}],"filters": [],"uri": "lb://item-service"
}

等同于下面

spring:cloud:gateway:routes:- id: itemuri: lb://item-servicepredicates:- Path=/items/**,/search/**

实现动态路由

引入一下依赖

<!--统一配置管理-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!--加载bootstrap-->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

配置bootstrap.yaml

spring:application:name: gatewaycloud:nacos:server-addr: 192.168.150.101config:file-extension: yamlshared-configs:- dataId: shared-log.yaml # 共享日志配置

在gatery中配置路由监听器

@Slf4j
@Component
@RequiredArgsConstructor
public class DynamicRouteLoader {private final RouteDefinitionWriter writer;private final NacosConfigManager nacosConfigManager;// 路由配置文件的id和分组private final String dataId = "gateway-routes.json";private final String group = "DEFAULT_GROUP";// 保存更新过的路由idprivate final Set<String> routeIds = new HashSet<>();@PostConstructpublic void initRouteConfigListener() throws NacosException {// 1.注册监听器并首次拉取配置String configInfo = nacosConfigManager.getConfigService().getConfigAndSignListener(dataId, group, 5000, new Listener() {@Overridepublic Executor getExecutor() {return null;}@Overridepublic void receiveConfigInfo(String configInfo) {updateConfigInfo(configInfo);}});// 2.首次启动时，更新一次配置updateConfigInfo(configInfo);}private void updateConfigInfo(String configInfo) {log.debug("监听到路由配置变更，{}", configInfo);// 1.反序列化List<RouteDefinition> routeDefinitions = JSONUtil.toList(configInfo, RouteDefinition.class);// 2.更新前先清空旧路由// 2.1.清除旧路由for (String routeId : routeIds) {writer.delete(Mono.just(routeId)).subscribe();}routeIds.clear();// 2.2.判断是否有新的路由要更新if (CollUtils.isEmpty(routeDefinitions)) {// 无新路由配置，直接结束return;}// 3.更新路由routeDefinitions.forEach(routeDefinition -> {// 3.1.更新路由writer.save(Mono.just(routeDefinition)).subscribe();// 3.2.记录路由id，方便将来删除routeIds.add(routeDefinition.getId());});}
}

subscribe()方法的主要作用是订阅一个 Mono 或者 Flux 序列，进而触发序列的执行。在响应式编程里，Mono 或者 Flux 所定义的操作属于声明式的，只有在被订阅时才会真正执行。

微服务保护

在微服务远程调用当中仍然有几个问题需要我们去解决

• 首先是业务的健壮性问题。
  例如我们之前的查询购物车的接口，需要查询到商品的最新信息，然后与之前的价格作对比，比较价格，但是如果商品查询服务发生了故障呢，那么查询购物车的接口也会发生故障，但是这是我们不愿意看到的，我们希望的是购物车接口能够正常返回结果，即使没有最新的商品信息
• 还有级联的失败问题
  还是查询购物车的业务，假如商品服务业务并发较高，占用过多Tomcat连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败。
  此时查询购物车业务需要查询并等待商品查询结果，从而导致查询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的Tomcat连接占用较多，所有接口的响应时间都会增加，整个服务性能很差， 甚至不可用。
  
  依次类推，整个微服务群中与购物车服务、商品服务等有调用关系的服务可能都会出现问题，最终导致整个集群不可用。
  

还有跨微服务的事务问题，比如下单业务，经过一下过程

• 商品服务：扣减库存
• 订单服务：保存订单
• 购物车服务：清理购物车

这些业务全部都是数据库的写操作，我们必须确保所有操作的同时成功或失败。但是这些操作在不同微服务，也就是不同的Tomcat，这样的情况如何确保事务特性呢？

服务保护方案

服务保护方案有以下三种

• 请求限流
• 线程隔离
• 服务熔断
  请求限流，降低了并发上限；线程隔离，降低了可用资源数量；服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升，
  接下来，我们就逐一了解这些方案的原理。

请求限流

我们想，我们服务故障出现的原因一部分是因为该服务的并发太高，导致服务资源耗尽，最终宕机。因此请求限流就能很好的解决这个问题，能够避免服务流量激增。
请求限流往往会有一个限流器，数量高低起伏的并发请求曲线，经过限流器就变的非常平稳。这就像是水电站的大坝，起到蓄水的作用，可以通过开关控制水流出的大小，让下游水流始终维持在一个平稳的量。

线程隔离

当一个业务接口响应时间长，而且并发高时，就可能耗尽服务器的线程资源，导致服务内的其它接口受到影响。所以我们必须把这种影响降低，或者缩减影响的范围。线程隔离正是解决这个问题的好办法。
为了避免某个接口故障或压力过大导致整个服务不可用，我们可以限定每个接口可以使用的资源范围，也就是将其“隔离”起来。

服务熔断

线程隔离虽然避免了雪崩问题，但故障服务（商品服务）依然会拖慢购物车服务（服务调用方）的接口响应速度。而且商品查询的故障依然会导致查询购物车功能出现故障，购物车业务也变的不可用了。

所以，我们要做两件事情：

• 编写服务降级逻辑：就是服务调用失败后的处理逻辑，根据业务场景，可以抛出异常，也可以返回友好提示或默认数据。
• 异常统计和熔断：统计服务提供方的异常比例，当比例过高表明该接口会影响到其它服务，应该拒绝调用该接口，而是直接走降级逻辑。

Sentinel

Sentinel是阿里巴巴开源的一款服务保护框架，目前已经加入SpringCloudAlibaba中。国内开源还带是我阿里巴巴哥。

官方网站：Sentinel官方网站

安装

Sentinel 的使用可以分为两个部分:

• 核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。
• 控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

（1）下载jar包

地址：下载地址

（2）运行
将jar包放在任意非中文、不包含特殊字符的目录下运行，运行时不要打开powershell，而是要在文件地址当中输入cmd然后运行

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

（3）访问
运行无错误之后，访问8090端口，可以看到控制台

微服务整合

导入依赖

<!--sentinel-->
<dependency><groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

设置配置

spring:cloud: sentinel:transport:dashboard: localhost:8090

请求限流

在簇点链路后面点击流控按钮，即可对其做限流配置：

QPS单机阈值也就是每秒最大请求数量

线程隔离

限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

比如，查询购物车的时候需要查询商品，为了避免因商品服务出现故障导致购物车服务级联失败，我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源：

这样，即便商品服务出现故障，最多导致查询购物车业务故障，并且可用的线程资源也被限定在一定范围，不会导致整个购物车服务崩溃。

OpenFeign整合Sentinel

配置

feign:sentinel:enabled: true # 开启feign对sentinel的支持

然后重启服务，可以看到查询商品的FeignClient自动变成了一个簇点资源：

配置线程隔离

设置并发线程数

服务熔断

在上节课，我们利用线程隔离对查询购物车业务进行隔离，保护了购物车服务的其它接口。由于查询商品的功能耗时较高（我们模拟了500毫秒延时），再加上线程隔离限定了线程数为5，导致接口吞吐能力有限，最终QPS只有10左右。这就导致了几个问题：

• 第一，超出的QPS上限的请求就只能抛出异常，从而导致购物车的查询失败。但从业务角度来说，即便没有查询到最新的商品信息，购物车也应该展示给用户，用户体验更好。也就是给查询失败设置一个降级处理逻辑。
• 第二，由于查询商品的延迟较高（模拟的500ms），从而导致查询购物车的响应时间也变的很长。这样不仅拖慢了购物车服务，消耗了购物车服务的更多资源，而且用户体验也很差。对于商品服务这种不太健康的接口，我们应该直接停止调用，直接走降级逻辑，避免影响到当前服务。也就是将商品查询接口熔断。

也就是说虽然进行了线程隔离，但是当许多请求打过来的时候，还是会影响统一微服务的其他业务，并且还会影响用户的体验

编写降级逻辑

触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，用户体验会更好。
给FeignClient编写失败后的降级逻辑有两种方式：

• 方式一：FallbackClass，无法对远程调用的异常做处理
• 方式二：FallbackFactory，可以对远程调用的异常做处理，我们一般选择这种方式。
  这里我们使用第二种方法来实现降级处理

步骤一：在hm-api模块中给ItemClient定义降级处理类，实现FallbackFactory：

@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {@Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {@Overridepublic List<ItemDTO> queryItemByIds(Collection<Long> ids) {log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);// 查询购物车允许失败，查询失败，返回空集合return CollUtils.emptyList();}@Overridepublic void deductStock(List<OrderDetailDTO> items) {// 库存扣减业务需要触发事务回滚，查询失败，抛出异常throw new BizIllegalException(cause);}};}
}

步骤二：在hm-api模块中的com.hmall.api.config.DefaultFeignConfig类中将ItemClientFallback注册为一个Bean：

@Bean
public ItemClientFallbackFactory itemClientFallbackFactory() {return new ItemClientFallbackFactory();
}

步骤三：在hm-api模块中的ItemClient接口中使用ItemClientFallbackFactory：

重启后，再次测试，发现被限流的请求不再报错，走了降级逻辑。

服务熔断

查询商品的RT较高（模拟的500ms），从而导致查询购物车的RT也变的很长。这样不仅拖慢了购物车服务，消耗了购物车服务的更多资源，而且用户体验也很差。如果这个服务不是慢，而是挂了，那么每次请求来我们还要去请求他，而我们明明知道他已经挂了。
对于商品服务这种不太健康的接口，我们应该停止调用，直接走降级逻辑，避免影响到当前服务。也就是将商品查询接口熔断。当商品服务接口恢复正常后，再允许调用。这其实就是断路器的工作模式了。

状态机包括三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
• open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态持续一段时间后会进入half-open状态
• half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
  • 请求成功：则切换到closed状态
  • 请求失败：则切换到open状态

[图片]
这种是按照慢调用比例来做熔断，上述配置的含义是：

• RT超过200毫秒的请求调用就是慢调用
• 统计最近1000ms内的最少5次请求，如果慢调用比例不低于0.5，则触发熔断
• 熔断持续时长20s

分布式事务

首先我们看看项目中的下单业务整体流程：

由于创建订单，清空购物车和扣减库存这三个动作在三个不同的微服务当中。因此下单业务就会跨多个数据库完成业务，而每个微服务都会执行自己本地的事务

• 交易服务：下单事务
• 购物车服务：清理购物车事务
• 库存服务：扣减库存事务

整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。我们必须保证整个全局事务同时成功或失败。
我们知道每一个分支事务就是传统的单体事务，都可以满足ACID特性，但全局事务跨越多个服务、多个数据库，是否还能满足呢？

ACID

• 原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的所有操作要么全部成功执行，要么全部不执行。例如，在银行转账的事务中，从一个账户扣款和向另一个账户存款这两个操作必须同时成功或者同时失败，不能出现只完成其中一个操作的情况。
• 一致性（Consistency）：事务执行前后，数据库的完整性约束没有被破坏，数据库始终处于一致的状态。比如，在转账事务中，转账前两个账户的余额总和与转账后两个账户的余额总和应该是相等的，满足数据的一致性要求。
• 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不能被其他事务干扰，各个事务之间相互隔离。不同的隔离级别会对事务的并发执行产生不同的影响，例如读未提交、读已提交、可重复读和串行化等隔离级别，从低到高逐渐增强隔离性。
• 持久性（Durability）：事务一旦提交，它对数据库所做的修改就会永久保存下来，即使数据库系统出现故障也不会丢失。例如，在转账事务提交后，即使数据库服务器突然断电，重新启动后，转账的结果也应该是持久保存的，不会恢复到转账前的状态。

经过我的测试，不同微服务的事务合在一起并不会遵守ACID,归其原因就是参与事务的多个子业务在不同的微服务，跨越了不同的数据库。虽然每个单独的业务都能在本地遵循ACID，但是它们互相之间没有感知，不知道有人失败了，无法保证最终结果的统一，也就无法遵循ACID的事务特性了。

Seata

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在2019年开源的Seata了。（又是我阿里巴巴）

Seata官网

分布式事务无法一致的原因就是不同微服务之间无法相互感知，你不知道我，我不知道你，彼此不知道彼此的状态，因此解决的思想也非常简单：
就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。

Seata也不例外，在Seata的事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM (Resource Manager) - 资源管理器：管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

部署TC服务

准备表

seata.sql可以去黑马资料当中下载

准备配置文件

修改seata配置文件当中nacos地址和mysql地址

Docker部署

docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP=192.168.150.101 \
-v ./seata:/seata-server/resources \
--privileged=true \
--network hm-net \
-d \
seataio/seata-server:1.5.2

微服务集成Seata

引入依赖

  <!--seata--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-seata</artifactId></dependency>

配置

seata:registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址type: nacos # 注册中心类型 nacosnacos:server-addr: 192.168.150.101:8848 # nacos地址namespace: "" # namespace，默认为空group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUPapplication: seata-server # seata服务名称username: nacospassword: nacostx-service-group: hmall # 事务组名称service:vgroup-mapping: # 事务组与tc集群的映射关系hmall: "default"

不新建就是默认的命名空间

不划分就是默认的分组

也有不同的集群，我可能有不同的集群（部署在不同的服务器上）

一个事务组最好在一个集群当中

添加数据库表

seata的客户端在解决分布式事务的时候需要记录一些中间数据，保存在数据库中。因此我们要先准备一个这样的表。
将课前资料的seata-at.sql分别文件导入hm-trade、hm-cart、hm-item三个数据库中

测试

接下来就是测试的分布式事务的时候了。
我们找到trade-service模块下的com.hmall.trade.service.impl.OrderServiceImpl类中的createOrder方法，也就是下单业务方法。
将其上的@Transactional注解改为Seata提供的@GlobalTransactional：

@GlobalTransactional注解就是在标记事务的起点，将来TM就会基于这个方法判断全局事务范围，初始化全局事务。

我们重启trade-service、item-service、cart-service三个服务。再次测试，发现分布式事务的问题解决了！

XA模式

Seata支持四种不同的分布式事务解决方案：

• XA
• TCC
• AT
• SAGA

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

两阶段提交

正常情况：

异常情况：

一阶段：

• 事务协调者通知每个事务参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

• 事务协调者基于一阶段的报告来判断下一步操作
• 如果一阶段都成功，则通知所有事务参与者，提交事务
• 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

Seata的XA模型

RM一阶段的工作：

1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC

TC二阶段的工作：

1. TC检测各分支事务执行状态
2. 如果都成功，通知所有RM提交事务
3. 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

优缺点

优点：

• 满足强一致性，满足ACID原则
• 常用数据库都支持，实现简单，并且没有代码侵入

缺点：

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

实现步骤

编辑配置

seata:data-source-proxy-mode: XA

其次，我们要利用@GlobalTransactional标记分布式事务的入口方法：

AT模式

Seata的AT模型

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态
  阶段二提交时RM的工作：
• 删除undo-log即可
  阶段二回滚时RM的工作：
• 根据undo-log恢复数据到更新前

流程图

优缺点

优点：

• 性能较好，一个事物的提交不用等待其他事务的成功与失败

缺点：

• 中间存在着端在的数据不一致现象，但是最终会保证一致性