微服务学习2

目录

一.网关路由

1.1.认识网关

1.2网关快速入门

1.2.1.创建项目

1.2.2.引入依赖

1.2.3.启动类

1.2.4.配置路由

1.3.路由过滤

二.网关登录校验

2.1网关请求处理流程

2.2网关过滤器

2.2.2网关过滤器

2.3自定义GlobalFilter

2.4.登录校验

2.4.1.JWT工具

2.4.2.登录校验过滤器

2.5.微服务获取用户

2.5.1.保存用户到请求头

2.5.2.拦截器获取用户

2.6.OpenFeign传递用户

三.配置管理

3.1.配置共享

3.1.1.添加共享配置

3.1.2.拉取共享配置

3.2.配置热更新

3.2.1.添加配置到Nacos

3.2.2.配置热更新

---

在之前的学习中，我们将黑马商城项目拆分为5个微服务：

• 用户服务

• 商品服务

• 购物车服务

• 交易服务

• 支付服务

由于每个微服务都有不同的地址或端口，入口不同，在与前端联调的时候发现了一些问题：

• 请求不同数据时要访问不同的入口，需要维护多个入口地址，麻烦

• 前端无法调用nacos，无法实时更新服务列表

单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，这就存在一些问题：

• 每个微服务都需要编写登录校验、用户信息获取的功能吗？

• 当微服务之间调用时，该如何传递用户信息？

不要着急，这些问题都可以在今天的学习中找到答案，我们会通过网关技术解决上述问题。今天的内容会分为3章：

• 第一章：网关路由，解决前端请求入口的问题。

• 第二章：网关鉴权，解决统一登录校验和用户信息获取的问题。

• 第三章：统一配置管理，解决微服务的配置文件重复和配置热更新问题。

通过今天的学习你将掌握下列能力：

• 会利用微服务网关做请求路由

• 会利用微服务网关做登录身份校验

• 会利用Nacos实现统一配置管理

• 会利用Nacos实现配置热更新

一.网关路由

1.1.认识网关

什么是网关？

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

更通俗的来讲，网关就像是以前园区传达室的大爷。

• 外面的人要想进入园区，必须经过大爷的认可，如果你是不怀好意的人，肯定被直接拦截。

• 外面的人要传话或送信，要找大爷。大爷帮你带给目标人。

在这个例子中：

门卫问你是谁，是在做身份校验

告诉你你要找的人在几楼几单元，是路由

你找不到，他带你过去，这叫转发

这个小区可以类比为一个微服务集群， 小区里的一个个住户就是一个个微服务，门卫大爷就是网关， 访问的人就相当于前端

这个网关我们可以用8080这个端口（为了方便，就跟之前单体项目一样，不用修改）。以后前端所有的业务和请求都访问8080端口到达网关。而网关的作用就是：根据前端的请求去判断应该由哪个微服务去处理这个请求！

而这个判断的过程就是请求的路由 。知道了这个请求应该由哪个微服务处理，接下来网关就会把这个请求转发到具体的微服务，这个过程就是路由转发的过程。

那么有人就可能会有疑问了：这里这么多微服务，网关怎么知道每个服务的实例和ip地址呢？而且它们的地址和端口可能会变化啊？

这里就要提到注册中心了！所有的微服务一启动/修改，都会把自己的信息注册到注册中心，注册中心里就会有所有的微服务信息了。我们的网关其实也是一个微服务，网关启动了以后也可以去注册中心，拉取所有的服务地址，这样一来网关就清楚的知道了所有的微服务地址了！以后微服务有变更注册中心也会推送给网关。

还有一点：网关在做路由转发之前，还会对来请求的用户进行身份校验，解析身份信息后还可以在路由转发的过程中传递给下游的微服务。

在前端看来，只知道网关地址，因此整个微服务对前端来说都是隐藏的，在前端看来，后端和原来的单体架构是差不多的。前端开发体验是一致的。

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

• Netflix Zuul：早期实现，目前已经淘汰

• SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强

我们以SpringCloudGateway为例来讲解，官方网站：

https://spring.io/projects/spring-cloud-gateway#learn

1.2网关快速入门

网关做转发的过程（去注册中心拉取服务、负载均衡挑选实例、转发请求）这些都是与业务无关的事情。因此，可以由网关自动完成。

但是，网关的路由，也就是判断这个请求应该交给哪个微服务去处理，这个动作当然应该和业务相关，因为不同的业务由不同的服务去处理。这就需要我们开发者去配置路由规则了。

1.2.1.创建项目

首先，我们要在hmall下创建一个新的module，命名为hm-gateway，作为网关微服务：

1.2.2.引入依赖

在hm-gateway模块的pom.xml文件中引入依赖：

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

1.2.3.启动类

在hm-gateway模块的com.hmall.gateway包下新建一个启动类：

代码如下：

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);
    }
}

1.2.4.配置路由

接下来，在hm-gateway模块的resources目录新建一个application.yaml文件，内容如下：

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

路由属性：

id：路由的唯一标识，可以自定义，但要确保多套路由id不同，一般和微服务名称保持一致。

uri：路由到的目标微服务的地址。例：lb://item-service "item-service"代表微服务名称，这样就可以根据微服务名称到注册中心去拉取服务列表。前面的"lb"代表负载均衡（LoadBalance缩写），这样就会到服务列表里负载均衡挑选一个实例。

predicates（路由规则，可以配置多个）：前端请求到达网关后，网关需要对请求做出判断，看看到底去给哪个微服务做出处理。这个predicates就是判断的依据。等号左边是当前规则的名字，右边是规则参数。例：Path=/items/** 这里就是：根据路径判断，这里就是/items/下的所有路径都可以去对应的uri路径。

1.3.路由过滤

路由规则的定义语法如下：

spring:
  cloud:
    gateway:
      routes:
        - id: item
          uri: lb://item-service
          predicates:
            - Path=/items/**,/search/**

其中routes对应的类型如下：

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

四个属性含义如下：

• id：路由的唯一标示

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

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

• uri：路由目标地址，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.1网关请求处理流程

网关请求处理过程：我们知道网关底层是没有业务逻辑的，它要做的事就是根据我们配置的路由规则判断应该将前端请求转发到哪个对应的微服务。

HandlerMapping (路由映射器)

而这里路由规则的判断就是由HandlerMapping 接口处理的。而HandlerMapping 的默认实现是RoutePredicateHandlerMapping，而RoutePredicate翻译过来就是路由断言，我们之前就给每个路由配置了路由断言，所以他就是根据路由断言去做路由规则匹配的。所以他就可以根据我们配置的路由断言再结合前端请求进行匹配，去找到当前请求符合的路由。匹配完了以后就交给下一个人（WebHandler）处理了，这就是责任链。

WebHandler (请求处理器)

WebHandler的默认实现是FilterWebHandler，不难看出它是和过滤器有关的。事实上网关有非常多的过滤器，有的默认就是生效的，也就是说一个路由它哪些过滤器是生效的那些过滤器是不生效的，这是不一定的。而FilterWebHandler的作用就是找到当前路由对应生效的那些过滤器。放到一个集合中去做排序，形成过滤器链，之后就会依次调用这些过滤器了。那么当过滤器执行完以后又会干什么呢？这里就要提到一个特殊过滤器：NettyRoutingFilter（不用做配置，自动生效）。这个过滤器的执行位置在整个过滤器链的最后。

NettyRoutingFilter (Netty路由过滤器)

负责将请求请求转发到微服务，当微服务执行完以后，把结果返回给NettyRoutingFilter，它会把返回结果做封装，存到上下文里面，然后依次向上返回给其他过滤器，最终返回给用户。

Filter (过滤器)

我们发现这些过滤器在请求转发到微服务之前和之后好像都被调用了。没错，过滤器其实内部都有两部分逻辑"PRE"和"POST"。请求进入以后，执行过滤器的"PRE"逻辑，在此过程中，如果有过滤器的"PRE"逻辑执行失败，就会直接结束，根本就不会往下执行了。请求也不会被转发。只有所有的"PRE"逻辑执行成功的情况下，请求才会被转发到微服务。

2.2网关过滤器

如何在网关转发之前做登录校验？

现在我们已经知道：最终请求转发是有一个名为NettyRoutingFilter的过滤器来执行的，而且这个过滤器是整个过滤器链中顺序最靠后的一个。如果我们能够定义一个过滤器，在其中实现登录校验逻辑，并且将过滤器执行顺序定义到NettyRoutingFilter 之前，这就符合我们的需求了！当然这个登录校验的逻辑肯定要放在过滤器的"PRE"阶段。

网关如何将用户信息传递给微服务？

由于网关也是一个微服务，每个微服务之间都是独立的进程。因此传递用户信息不能再像我们之间使用ThreadLocal了。而网关到微服务其实就是一次新的HTTP请求，通过HTTP请求传递信息，最佳的传递方式就是通过请求头。因为把信息放到请求头里面对业务不会产生影响。

如何在微服务之间传递用户信息？

我们也可以把用户信息保存到请求头。但要注意的一点是：微服务之间的HTTP请求是基于OpenFeign发起的。而网关到微服务则是网关内部的一种HTTP请求方式。所以具体实现方式还是有差别的。

2.2.2网关过滤器

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

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

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

注意：过滤器链之外还有一种过滤器，HttpHeadersFilter，用来处理传递到下游微服务的请求头。例如org.springframework.cloud.gateway.filter.headers.XForwardedHeadersFilter可以传递代理请求原本的host头到下游微服务。

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

核心方法filter

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

filter方法参数：

1.ServerWebExchange exchange：网关内部的上下文对象，用来保存网关内部共享的一些数据的（如request、response、session、某些自定义的属性）

2.GatewayFilterChain chain：过滤器链，将来我们可以自定义一个链，然后编写自己的业务逻辑。当我们的业务逻辑处理完以后，我们可以调用这个过滤器链，然后通过它去调用下一个过滤器。

3.返回值Mono：我们知道网关要等所有过滤器的"PRE"执行完以后，它才会把请求转发到微服务。微服务返回结果才会轮到"POST"执行。看起来这个"POST"过程要等待很久很久。因此，网关采用的是一种非阻塞式编程，它需要我们去利用这个Mono去定义一个回调函数，这样我们就不用去等待了，将来有了结果以后它再去调用这个回调函数。回调函数里面的逻辑就是这个"POST"部分的逻辑。好消息是，实际开发中大部分情况下，都不需要我们自己去写这种"POST"。

注意：我们在实现filter方法以后，内部写的所有业务都属于过滤器的"PRE"部分，当"PRE"执行完，我们可以调用我们自定义的chain，利用它去调用过滤器链中的下一个过滤器。

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

Gateway中内置了很多的GatewayFilter，详情可以参考官方文档：

https://docs.spring.io/spring-cloud-gateway/docs/3.1.7/reference/html/#gatewayfilter-factories

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

例如，有一个过滤器叫做AddRequestHeaderGatewayFilterFacotry，顾明思议，就是添加请求头的过滤器，可以给请求添加一个请求头并传递到下游微服务。

使用的使用只需要在application.yaml中这样配置：

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

如果想要让过滤器作用于所有的路由，则可以这样配置：

spring:
  cloud:
    gateway:
      default-filters: # default-filters下的过滤器可以作用于所有路由
        - AddRequestHeader=key, value
      routes:
      - id: test_route
        uri: lb://test-service
        predicates:
          -Path=/test/**

2.3自定义GlobalFilter

自定义GlobalFilter则简单很多，直接实现GlobalFilter即可，而且也无法设置动态参数：

@Component
public class PrintAnyGlobalFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 编写过滤器逻辑
        System.out.println("未登录，无法访问");
        // 放行
        // return chain.filter(exchange);

        // 拦截
        ServerHttpResponse response = exchange.getResponse();
        response.setRawStatusCode(401);
        return response.setComplete();
    }

    @Override
    public int getOrder() {
        // 过滤器执行顺序，值越小，优先级越高
        return 0;
    }
}

2.4.登录校验

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

2.4.1.JWT工具

登录校验需要用到JWT，而且JWT的加密需要秘钥和加密工具。这些在hm-service中已经有了，我们直接拷贝过来：

具体作用如下：

• AuthProperties：配置登录校验需要拦截的路径，因为不是所有的路径都需要登录才能访问

• JwtProperties：定义与JWT工具有关的属性，比如秘钥文件位置

• SecurityConfig：工具的自动装配

• JwtTool：JWT工具，其中包含了校验和解析token的功能

• hmall.jks：秘钥文件

其中AuthProperties和JwtProperties所需的属性要在application.yaml中配置：

hm:
  jwt:
    location: classpath:hmall.jks # 秘钥地址
    alias: hmall # 秘钥别名
    password: hmall123 # 秘钥文件密码
    tokenTTL: 30m # 登录有效期
  auth:
    excludePaths: # 无需登录校验的路径
      - /search/**
      - /users/login
      - /items/**

2.4.2.登录校验过滤器

接下来，我们定义一个登录校验的过滤器：

代码如下：

package com.hmall.gateway.filter;

import com.hmall.common.exception.UnauthorizedException;
import com.hmall.common.utils.CollUtils;
import com.hmall.gateway.config.AuthProperties;
import com.hmall.gateway.util.JwtTool;
import lombok.RequiredArgsConstructor;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.stereotype.Component;
import org.springframework.util.AntPathMatcher;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import java.util.List;

@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();

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取Request
        ServerHttpRequest request = exchange.getRequest();
        // 2.判断是否不需要拦截
        if(isExclude(request.getPath().toString())){
            // 无需拦截，直接放行
            return chain.filter(exchange);
        }
        // 3.获取请求头中的token
        String token = null;
        List<String> headers = request.getHeaders().get("authorization");
        if (!CollUtils.isEmpty(headers)) {
            token = headers.get(0);
        }
        // 4.校验并解析token
        Long 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;
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

2.5.微服务获取用户

现在，网关已经可以完成登录校验并获取登录用户身份信息。但是当网关将请求转发到微服务时，微服务又该如何获取用户身份呢？

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

据图流程图如下：

因此，接下来我们要做的事情有：

• 改造网关过滤器，在获取用户信息后保存到请求头，转发到下游微服务

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

2.5.1.保存用户到请求头

首先，我们修改登录校验拦截器的处理逻辑，保存用户信息到请求头中：

mutate ：在Spring WebFlux中，mutate 方法通常与 ServerHttpResponse 的构建器模式相关。当你想定制或修改HTTP响应时，可以使用 ServerHttpResponse 的构建器来创建或修改一个响应。例如，你可以使用 ServerHttpResponse.Builder 来创建一个带有特定状态码和响应体的响应。

2.5.2.拦截器获取用户

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

其中已经提供了保存和获取用户的方法：

接下来，我们只需要编写拦截器，获取用户信息并保存到UserContext，然后放行即可。

由于每个微服务都有获取登录用户的需求，因此拦截器我们直接写在hm-common中，并写好自动装配。这样微服务只需要引入hm-common就可以直接具备拦截器功能，无需重复编写。

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

具体代码如下：

package com.hmall.common.interceptor;

import cn.hutool.core.util.StrUtil;
import com.hmall.common.utils.UserContext;
import org.springframework.web.servlet.HandlerInterceptor;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

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

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserContext.removeUser();
    }
}

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

具体代码如下：

package com.hmall.common.config;

import com.hmall.common.interceptors.UserInfoInterceptor;
import org.springframework.boot.autoconfigure.condition.ConditionalOnClass;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.DispatcherServlet;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

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

注意：由于网关gateway-service也引用了common-service。所以网关中也有了MvcConfig（common-service中的MVC配置类）。这是因为WebMvcConfig（MvcConfig实现的接口）属于SpringMVC包下的。而网关底层不是SpringMVC那一套的，这里我们使用的Spring Cloud Gateway底层是一种非阻塞式的响应式编程，基于的是WeFlux。所以它里面根本没有SpringMVC的东西，如果我们直接把MvcConfig导入过来，就会报错。因此加上条件注解：@ConditionalOnClass(DispatcherServlet.class)

DispatcherServlet，是SpringMVC的核心API，而网关中没有，所以加上了这个注解，网关中就不会导入MvcConfig类！

不过，需要注意的是，这个配置类默认是不会生效的，因为它所在的包是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

2.6.OpenFeign传递用户

在Java中，ThreadLocal 的作用域是一个线程。每个线程都有自己的 ThreadLocal 变量副本，其他线程无法直接访问另一个线程的 ThreadLocal 变量。这意味着即使在微服务远程调用中，ThreadLocal 变量也只属于发起远程调用的线程，不会被传递到远程微服务。

在微服务远程调用中，一般情况下会开启新的线程 而不是新的进程来处理远程调用。每个线程都会执行特定的任务，具有自己的线程上下文和堆栈，线程之间会共享进程的资源。因此，在进行微服务远程调用时，需要注意线程隔离和数据共享的问题。

客户端发请求经过网关，网关进行身份校验并把用户信息，存储在当前线程的ThreadLocal中，而远程调用的话，就到了一个新的线程，因此远程调用的微服务的ThreadLocal中没有用户信息了。需要在远程调用的请求头中传入用户信息，重新获取。

前端发起的请求都会经过网关再到微服务，由于我们之前编写的过滤器和拦截器功能，微服务可以轻松获取登录用户信息。

但有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务。比如下单业务，流程如下：

下单的过程中，需要调用商品服务扣减库存，调用购物车服务清理用户购物车。而清理购物车时必须知道当前登录的用户身份。但是，订单服务调用购物车时并没有传递用户信息，购物车服务无法知道当前用户是谁！

由于微服务获取用户信息是通过拦截器在请求头中读取，因此要想实现微服务之间的用户信息传递，就必须在微服务发起调用时把用户信息存入请求头。

微服务之间调用是基于OpenFeign来实现的，并不是我们自己发送的请求。我们如何才能让每一个由OpenFeign发起的请求自动携带登录用户信息呢？

这里要借助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发起请求的时候都会调用该方法，传递用户信息。

由于FeignClient全部都是在hm-api模块，因此我们在hm-api模块的com.hmall.api.config.DefaultFeignConfig中编写这个拦截器：

在com.hmall.api.config.DefaultFeignConfig中添加一个Bean：

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

现在微服务之间通过OpenFeign调用时也会传递登录用户信息了。

三.配置管理

到目前为止我们已经解决了微服务相关的几个问题：

• 微服务远程调用

• 微服务注册、发现

• 微服务请求路由、负载均衡

• 微服务登录用户信息传递

不过，现在依然还有几个问题需要解决：

• 网关路由在配置文件中写死了，如果变更必须重启微服务

• 某些业务配置在配置文件中写死了，每次修改都要重启服务

• 每个微服务都有很多重复的配置，维护成本高

这些问题都可以通过统一的配置管理器服务 解决。我们可以把经常可能发生变更的配置或者是网关的路由配置都交给配置管理服务去管理。当我们要修改的时候就去配置管理服务去修改。它有个作用：它可以去监听这些配置的变更，当发现配置变更的时候，它会去推送变更的配置给对应的网关和微服务。这样一来，这些微服务内部无需重启就能立即生效！

配置管理的两大功能：1、配置共享 2、避免更新后的重启，实现配置热更新！

而Nacos不仅仅具备注册中心功能，也具备配置管理的功能：

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

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

3.1.配置共享

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

• 在Nacos中添加共享配置

• 微服务拉取配置

3.1.1.添加共享配置

以cart-service为例，我们看看有哪些配置是重复的，可以抽取的：

首先是jdbc相关配置：

然后是日志配置：

然后是swagger以及OpenFeign的配置：

我们在nacos控制台分别添加这些配置。

首先是jdbc相关配置，在配置管理->配置列表中点击+新建一个配置：

在弹出的表单中填写信息：

其中详细的配置如下：

spring:
  datasource:
    url: jdbc:mysql://${hm.db.host:192.168.150.101}:${hm.db.port:3306}/${hm.db.database}?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    driver-class-name: com.mysql.cj.jdbc.Driver
    username: ${hm.db.un:root}
    password: ${hm.db.pw:123}
mybatis-plus:
  configuration:
    default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandler
  global-config:
    db-config:
      update-strategy: not_null
      id-type: auto

注意这里的jdbc的相关参数并没有写死，例如：

• 数据库ip：通过${hm.db.host:192.168.150.101}配置了默认值为192.168.150.101，同时允许通过${hm.db.host}来覆盖默认值

• 数据库端口：通过${hm.db.port:3306}配置了默认值为3306，同时允许通过${hm.db.port}来覆盖默认值

• 数据库database：可以通过${hm.db.database}来设定，无默认值

然后是统一的日志配置，命名为shared-log.yaml，配置内容如下：

logging:
  level:
    com.hmall: debug
  pattern:
    dateformat: HH:mm:ss:SSS
  file:
    path: "logs/${spring.application.name}"

然后是统一的swagger配置，命名为shared-swagger.yaml，配置内容如下：

knife4j:
  enable: true
  openapi:
    title: ${hm.swagger.title:黑马商城接口文档}
    description: ${hm.swagger.description:黑马商城接口文档}
    email: ${hm.swagger.email:zhanghuyi@itcast.cn}
    concat: ${hm.swagger.concat:滴滴滴}
    url: https://www.itcast.cn
    version: v1.0.0
    group:
      default:
        group-name: default
        api-rule: package
        api-rule-resources:
          - ${hm.swagger.package}

注意，这里的swagger相关配置我们没有写死，例如：

• title：接口文档标题，我们用了${hm.swagger.title}来代替，将来可以有用户手动指定

• email：联系人邮箱，我们用了${hm.swagger.email:``zhanghuyi@itcast.cn``}，默认值是zhanghuyi@itcast.cn，同时允许用户利用${hm.swagger.email}来覆盖。

3.1.2.拉取共享配置

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

不过，需要注意的是，读取Nacos配置是SpringCloud上下文（ApplicationContext）初始化时处理的，发生在项目的引导阶段。然后才会初始化SpringBoot上下文，去读取application.yaml。

也就是说引导阶段，application.yaml文件尚未读取，根本不知道nacos 地址，该如何去加载nacos中的配置文件呢？

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

因此，微服务整合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: 192.168.150.101 # 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

重启服务，发现所有配置都生效了。

3.2.配置热更新

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

现在这里购物车是写死的固定值，我们应该将其配置在配置文件中，方便后期修改。

但现在的问题是，即便写在配置文件中，修改了配置还是需要重新打包、重启服务才能生效。能不能不用重启，直接生效呢？

这就要用到Nacos的配置热更新能力了，分为两步：

• 在Nacos中添加配置

• 在微服务读取配置

3.2.1.添加配置到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 # 购物车商品数量上限

提交配置，在控制台能看到新添加的配置：

3.2.2.配置热更新

接着，我们在微服务中读取配置，实现配置热更新。

在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控制台，将购物车上限配置为5：

无需重启，再次测试购物车功能：

加入成功！

无需重启服务，配置热更新就生效了！