hmall-微服务开发02

1. 网关路由

网关就是网络的关口。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的路由和转发以及数据安全的校验。

前端请求不能直接访问微服务，而是要请求网关：

• 网关可以做安全控制，也就是登录身份校验，校验通过才放行

• 通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去

1.1 创建网关服务

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

• 创建网关微服务

• 引入SpringCloudGateway、NacosDiscovery依赖

• 编写启动类

• 配置网关路由

注意：在测试的时候，启动GatewayApplication，以 http://localhost:8080 拼接微服务接口路径来测试。例如：http://localhost:8080/items/page?pageNo=1&pageSize=1   

要同时启动网关服务和商品服务，要是服务启动不成功，重启nacos。

测试成功：

1.1.1 路由过滤

路由规则中，routes对应的类型如下

是一个集合，也就是说可以定义很多路由规则。集合中的RouteDefinition就是具体的路由规则定义，其中常见的属性如下：

四个属性含义如下：

• id: 路由的唯一标示

• predicates: 路由断言，其实就是匹配条件

• filters: 路由过滤条件，后面讲

• url: 路由目标地址，lb:// 代表负载均衡，从注册中心获取目标微服务的实例列表，并且负载均衡选择一个访问。

这里predicates，也就是路由断言。SpringCloudGateway中支持的断言类型有很多：

名称	说明	示例
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	权重处理

2. 网关登录校验

网关是所有微服务的入口，一切请求都需要先经过网关。可以把登录校验的工作放到网关去做：

• 只需要在网关和用户服务保存秘钥

• 只需要在网关开发登录校验功能

登录校验的流程：

2.1 网关过滤器

如图所示：

1. 客户端请求进入网关后由HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（Route），然后将请求交给WebHandler去处理。

2. WebHandler则会加载当前路由下需要执行的过滤器链（Filter chain），然后按照顺序逐一执行过滤器（后面称为Filter）。

3. 图中Filter被虚线分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前和之后被执行。

4. 只有所有Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。

5. 微服务返回结果后，再倒序执行Filter的post逻辑。

6. 最终把响应结果返回

如图中所示，最终请求转发是有一个名为 NettyRoutingFilter 的过滤器来执行的，而且这个过滤器是整个过滤器链中顺序最靠后的一个。所以要登录校验，可以定义一个过滤器，在其中实现登录校验逻辑并且将过滤器执行顺序定义到 NettyRoutingFilter 之前！

网关过滤器链中的过滤器有两种，两种过滤器的方法签名完全一致：

• GatewayFilter：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route。

• GlobalFilter：全局过滤器，作用范围是所有路由，不可配置。

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

FilteringWebHandler在处理请求时，会将GlobalFilter装饰为GatewayFilter，然后放到同一个过滤器链中，排序以后依次执行。

2.2 实现网关登录校验

根据文档操作，目录结构如下所示：

重启测试，会发现访问/items开头的路径，未登录状态下不会被拦截：

访问其他路径则，未登录状态下请求会被拦截，并且返回401状态码：

2.3 微服务获取用户

由于网关发送请求到微服务依然采用的是HTTP请求，因此我们可以将用户信息以请求头的方式传递到下游微服务。然后微服务可以从请求头中获取登录用户信息。考虑到微服务内部可能很多地方都需要用到登录用户信息，因此可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。

流程图如下:

• 改造网关过滤器，在获取用户信息后保存到请求头，转发到下游微服务（http请求在转发到微服务之后就失效，由微服务调用其他微服务时需要重新在请求头中加入用户信息）

• 编写微服务拦截器，拦截请求获取用户信息，保存到ThreadLocal后放行

2.3.1 保存用户到请求头

更改com/hmall/gateway/filter/AuthGlobalFilter.java文件

2.3.2 拦截器获取用户

在hm-common中已经有一个用于保存登录用户的ThreadLocal工具：

在hm-common模块下定义一个拦截器：

在hm-common模块下编写的SpringMVC配置类，配置登录拦截器：

注意：这个配置类默认是不会生效的，因为它所在的包是com.hmall.common.config，与其它微服务的扫描包不一致，无法被扫描到，因此无法生效。

基于SpringBoot的自动装配原理，要将其添加到resources目录下的META-INF/spring.factories文件中：

2.5.3 恢复购物车代码

2.4 OpenFeign传递用户

思考

思考：购物车服务不是有Threadlocal吗？为什么还要用openfeign传递用户？

1. 分布式环境中的上下文传递

在分布式微服务架构中，每个服务都有自己的上下文和生命周期。ThreadLocal变量仅限于单个服务中的单个请求线程，它无法跨服务传递。订单服务和购物车服务是两个独立的服务，它们不能共享ThreadLocal中的数据。

2. HTTP请求无状态

HTTP协议是无状态的，这意味着每个请求都是独立的，没有内在的机制来传递上下文信息。每次调用都需要显式地传递必要的信息（如用户信息），否则目标服务无法获得这些上下文信息

请求流程

1. 客户端请求到网关：

   • 客户端发送请求到API网关。

   • API网关负责路由请求到相应的微服务，如订单服务。

2. 网关转发请求到订单服务：

   • 网关将请求转发给订单服务。

   • 在订单服务中，hm-common模块中的拦截器会生效，将用户信息从请求头中提取出来并存储到ThreadLocal中。

3. 订单服务调用购物车服务：

   • 订单服务在处理请求时，需要调用购物车服务来获取购物车信息。

   • 订单服务使用OpenFeign客户端来进行远程调用。

   • OpenFeign的拦截器会在发送请求前，从订单服务的ThreadLocal中获取用户信息，并将其写入到HTTP请求头中。

4. 购物车服务处理请求：

   • 购物车服务接收到来自订单服务的HTTP请求。

   • 在购物车服务中，hm-common模块中的拦截器再次生效，将请求头中的用户信息提取出来，并存储到购物车服务的ThreadLocal中。

   • 购物车服务使用从ThreadLocal中获取的用户信息来处理业务逻辑。

Feign中提供的一个拦截器接口：feign.RequestInterceptor

public interface RequestInterceptor {

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

只需要实现这个接口，然后实现apply方法，利用RequestTemplate类来添加请求头，将用户信息保存到请求头中。这样以来，每次OpenFeign发起请求的时候都会调用该方法，传递用户信息。Openfeign每次发起远程调用前，底层都会自动调用apply方法。

在hm-api模块的com.hmall.api.config.DefaultFeignConfig中添加一个Bean：

3. 配置管理

微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。

网关的路由同样是配置，因此同样可以基于这个功能实现动态路由功能，无需重启网关即可修改路由配置。

3.1 配置共享

可以把微服务共享的配置抽取到Nacos中统一管理，这样就不需要每个微服务都重复配置了。分为两步：

• 在Nacos中添加共享配置

• 微服务拉取配置

3.1.1 添加共享配置

访问http://localhost:8848/nacos ，在配置管理 -> 配置列表中点击+新建一个jabc配置

新建log配置：

新建swagger配置：

3.1.2 拉取共享配置

接下来，要在微服务拉取共享配置。将拉取到的共享配置与本地的application.yaml配置合并，完成项目上下文的初始化。

注意： 读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos 地址，该如何去加载nacos中的配置文件呢？

SpringCloud在初始化上下文的时候会先读取一个名为bootstrap.yaml(或者bootstrap.properties)的文件，如果将nacos地址配置到bootstrap.yaml中，那么在项目引导阶段就可以读取nacos中的配置了。

以cart-service服务整合Nacos配置管理为例：

1）在cart-service模块引入依赖

  <!--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>

2）新建bootstrap.yaml

在cart-service中的resources目录新建一个bootstrap.yaml文件：

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

3）修改application.yaml

由于一些配置挪到了bootstrap.yaml，因此application.yaml需要修改为：

server:
  port: 8082
feign:
  okhttp:
    enabled: true # 开启OKHttp连接池支持
hm:
  swagger:
    title: 购物车服务接口文档
    package: com.hmall.cart.controller
  db:
    database: hm-cart

重启购物车服务，访问http://localhost:8082/doc.html 成功，配置成功生效。

3.2 配置热更新

详情见文档：Docs

(前后端联调没做，电脑卡炸了）

3.3 动态路由

3.3.1 监听Nacos配置变更

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

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

请求参数说明：

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

3.3.2 更新路由

更新路由要用到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);

}

这里更新的路由，也就是RouteDefinition，包含下列常见字段：

• id：路由id

• predicates：路由匹配规则

• filters：路由过滤器

• uri：路由目的地

3.3.3 实现动态路由

见文档。