黑马商城day3-微服务01

一. 认识微服务

1.1 单体架构

单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。

当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。

但随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：

• 团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支，你绝对会陷入到解决冲突的泥潭之中。

• 系统发布效率低：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。

• 系统可用性差：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用。

在上述问题中，前两点相信大家在实战过程中应该深有体会。对于第三点系统可用性问题，很多同学可能感触不深。接下来我们就通过黑马商城这个项目，给大家做一个简单演示。

首先，我们修改hm-service模块下的com.hmall.controller.HelloController中的hello方法，模拟方法执行时的耗时：

接下来，启动项目，目前有两个接口是无需登录即可访问的：

• http://localhost:8080/hi

• http://localhost:8080/search/list

经过测试，目前/search/list 是比较正常的，访问耗时在30毫秒左右。

接下来，我们假设/hi这个接口是一个并发较高的热点接口，我们通过Jemeter来模拟500个用户不停访问。

导入Jemeter并测试：

这个脚本会开启500个线程并发请求http://localhost/hi这个接口。由于该接口存在执行耗时（500毫秒），这就服务端导致每秒能处理的请求数量有限，最终会有越来越多请求积压，直至Tomcat资源耗尽。这样，其它本来正常的接口（例如/search/list）也都会被拖慢，甚至因超时而无法访问了。

我们测试一下，启动测试脚本，然后在浏览器访问http://localhost:8080/search/list这个接口，会发现响应速度非常慢：

如果进一步提高/hi这个接口的并发，最终会发现/search/list接口的请求响应速度会越来越慢。

可见，单体架构的可用性是比较差的，功能之间相互影响比较大。

当然，有同学会说我们可以做水平扩展。

此时如果我们对系统做水平扩展，增加更多机器，资源还是会被这样的热点接口占用，从而影响到其它接口，并不能从根本上解决问题。这也就是单体架构的扩展性差的一个原因。

而要想解决这些问题，就需要使用微服务架构了。

1.2.微服务

微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：

• 单一职责：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块。

• 团队自治：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模不超过10人（2张披萨能喂饱）

• 服务自治：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响

例如，黑马商城项目，我们就可以把商品、用户、购物车、交易等模块拆分，交给不同的团队去开发，并独立部署：

那么，单体架构存在的问题有没有解决呢？

• 团队协作成本高？

  • 由于服务拆分，每个服务代码量大大减少，参与开发的后台人员在1~3名，协作成本大大降低

• 系统发布效率低？

  • 每个服务都是独立部署，当有某个服务有代码变更时，只需要打包部署该服务即可

• 系统可用性差？

  • 每个服务独立部署，并且做好服务隔离，使用自己的服务器资源，不会影响到其它服务。

综上所述，微服务架构解决了单体架构存在的问题，特别适合大型互联网项目的开发，因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构，分布式就是服务拆分的过程，其实微服务架构正式分布式架构的一种最佳实践的方案。

当然，微服务架构虽然能解决单体架构的各种问题，但在拆分的过程中，还会面临很多其它问题。比如：

• 如果出现跨服务的业务该如何处理？

• 页面请求到底该访问哪个服务？

• 如何实现各个服务之间的服务隔离？

1.3.SpringCloud

微服务拆分以后碰到的各种问题都有对应的解决方案和微服务组件，而SpringCloud框架可以说是目前Java领域最全面的微服务组件的集合了。而且SpringCloud依托于SpringBoot的自动装配能力，大大降低了其项目搭建、组件使用的成本。对于没有自研微服务组件能力的中小型企业，使用SpringCloud全家桶来实现微服务开发可以说是最合适的选择了！

目前SpringCloud最新版本为2022.0.x版本，对应的SpringBoot版本为3.x版本，但它们全部依赖于JDK17，目前在企业中使用相对较少。

SpringCloud版本	SpringBoot版本
2022.0.x aka Kilburn	3.0.x
2021.0.x aka Jubilee	2.6.x, 2.7.x (Starting with 2021.0.3)
2020.0.x aka Ilford	2.4.x, 2.5.x (Starting with 2020.0.3)
Hoxton	2.2.x, 2.3.x (Starting with SR5)
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

因此，我们推荐使用次新版本：Spring Cloud 2021.0.x以及Spring Boot 2.7.x版本。

另外，Alibaba的微服务产品SpringCloudAlibaba目前也成为了SpringCloud组件中的一员，我们课堂中也会使用其中的部分组件。

在我们的父工程hmall中已经配置了SpringCloud以及SpringCloudAlibaba的依赖：这样，我们在后续需要使用SpringCloud或者SpringCloudAlibaba组件时，就无需单独指定版本了。

2.微服务拆分

接下来，我们就一起将黑马商城这个单体项目拆分为微服务项目，并解决其中出现的各种问题。

2.1 熟悉黑马商城

2.2 拆分原则和项目结构

2.2.1 拆分原则

从拆分目标来说，要做到：

• 高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。
• 低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖。

从拆分方式来说，一般包含两种方式：

• 纵向拆分：按照业务模块来拆分
• 横向拆分：抽取公共服务，提高复用性

所谓纵向拆分，就是按照项目的功能模块来拆分。例如黑马商城中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。

而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。

2.2.2 微服务项目结构

一般微服务项目有两种不同的工程结构：

• 完全解耦：每一个微服务都创建为一个独立的工程，甚至可以使用不同的开发语言来开发，项目完全解耦。

  • 优点：服务之间耦合度低

  • 缺点：每个项目都有自己的独立仓库，管理起来比较麻烦

• Maven聚合：整个项目为一个Project，然后每个微服务是其中的一个Module

  • 优点：项目代码集中，管理和运维方便（授课也方便）

  • 缺点：服务之间耦合，编译时间较长

2.3.拆分购物车、商品服务

• 将hm-service中与商品管理相关功能拆分到一个微服务module中，命名为item-service
• 将hm-service中与购物车有关的功能拆分到一个微服务module中，命名为cart-service

1.创建一个新module，父类为hmall

2.因为item-service是从hm.service中分离出来的，所以从hm.service的pom文件中拷贝需要的依赖

<?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"><modelVersion>4.0.0</modelVersion><parent><groupId>com.heima</groupId><artifactId>hmall</artifactId><version>1.0.0</version></parent><artifactId>item-service</artifactId><properties><maven.compiler.source>11</maven.compiler.source><maven.compiler.target>11</maven.compiler.target><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding></properties><dependencies><!--common--><dependency><groupId>com.heima</groupId><artifactId>hm-common</artifactId><version>1.0.0</version></dependency><!--web--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!--数据库--><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId></dependency><!--mybatis--><dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</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>

3.创建启动类、修改mapper扫描路径，创建所需的包controller、service、mapper、domain等

4.拷贝service中的yml配置文件，创建独立数据库，并修改yml内容，包括名称、数据库、swagger

server:port: 8081
spring:application:name: item-service #微服务名称profiles:active: devdatasource: #微服务不仅要应用独立，数据也要做到独立，所以每个微服务都应该配一个mysql，但考虑到成本，这里打算给每个微服务独立一个数据库模拟独立mysqlurl: jdbc:mysql://${hm.db.host}:3306/hm-item?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghaidriver-class-name: com.mysql.cj.jdbc.Driverusername: rootpassword: ${hm.db.pw}
mybatis-plus:configuration:default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandlerglobal-config:db-config:update-strategy: not_nullid-type: auto
logging:level:com.hmall: debugpattern:dateformat: HH:mm:ss:SSSfile:path: "logs/${spring.application.name}" #根据模块名称输出日志，每个模块的日志是独立的
knife4j:enable: trueopenapi:title: 黑马商城商品管理接口文档description: "黑马商城商品管理接口文档"email: [e-mail]: 虎哥url: https://www.itcast.cnversion: v1.0.0group:default:group-name: defaultapi-rule: packageapi-rule-resources:- com.hmall.item.controller

5.拷贝代码，从domain开始拷贝，处理每个代码报错。

2.4 服务调用

在拆分的时候，我们发现一个问题：就是购物车业务中需要查询商品信息，但商品信息查询的逻辑全部迁移到了item-service服务，导致我们无法查询。

最终结果就是查询到的购物车数据不完整，因此要想解决这个问题，我们就必须改造其中的代码，把原本本地方法调用，改造成跨微服务的远程调用（RPC，即Remote Produce Call）。

因此，现在查询购物车列表的流程变成了这样：

注入一个RestTemplate，调用restTemplate像item-service发送http请求。

原本程序：

    private void handleCartItems(List<CartVO> vos) {//1.获取商品idSet<Long> itemIds = vos.stream().map(CartVO::getItemId).collect(Collectors.toSet());// 2.查询商品List<ItemDTO> items = itemService.queryItemByIds(itemIds);if (CollUtils.isEmpty(items)) {return;}// 3.转为 id 到 item的mapMap<Long, ItemDTO> itemMap = items.stream().collect(Collectors.toMap(ItemDTO::getId, Function.identity()));// 4.写入vofor (CartVO v : vos) {ItemDTO item = itemMap.get(v.getItemId());if (item == null) {continue;}v.setNewPrice(item.getPrice());v.setStatus(item.getStatus());v.setStock(item.getStock());}}

主要修改部分：

2.5.总结

什么时候需要拆分微服务？

• 如果是创业型公司，最好先用单体架构快速迭代开发，验证市场运作模型，快速试错。当业务跑通以后，随着业务规模扩大、人员规模增加，再考虑拆分微服务。

• 如果是大型企业，有充足的资源，可以在项目开始之初就搭建微服务架构。

如何拆分？

• 首先要做到高内聚、低耦合

• 从拆分方式来说，有横向拆分和纵向拆分两种。纵向就是按照业务功能模块，横向则是拆分通用性业务，提高复用性

服务拆分之后，不可避免的会出现跨微服务的业务，此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为RPC，即远程过程调用。RPC的实现方式有很多，比如：

• 基于Http协议

• 基于Dubbo协议

我们课堂中使用的是Http方式，这种方式不关心服务提供者的具体技术实现，只要对外暴露Http接口即可，更符合微服务的需要。

Java发送http请求可以使用Spring提供的RestTemplate，使用的基本步骤如下：

• 注册RestTemplate到Spring容器

• 调用RestTemplate的API发送请求，常见方法有：

  • getForObject：发送Get请求并返回指定类型对象

  • PostForObject：发送Post请求并返回指定类型对象

  • put：发送PUT请求

  • delete：发送Delete请求

  • exchange：发送任意类型请求，返回ResponseEntity

3.服务注册和发现

在上一章我们实现了微服务拆分，并且通过Http请求实现了跨微服务的远程调用。不过这种手动发送Http请求的方式存在一些问题。

试想一下，假如商品微服务被调用较多，为了应对更高的并发，我们进行了多实例部署，如图：

此时，每个item-service的实例其IP或端口不同，问题来了：

• item-service这么多实例，cart-service如何知道每一个实例的地址？

• http请求要写url地址，cart-service服务到底该调用哪个实例呢？

• 如果在运行过程中，某一个item-service实例宕机，cart-service依然在调用该怎么办？

• 如果并发太高，item-service临时多部署了N台实例，cart-service如何知道新实例的地址？

为了解决上述问题，就必须引入注册中心的概念了，接下来我们就一起来分析下注册中心的原理。

3.1.注册中心原理

在微服务远程调用的过程中，包括三个角色：

• 服务提供者：提供接口供其它微服务访问，比如item-service

• 服务消费者：调用其它微服务提供的接口，比如cart-service

• 注册中心：记录并监控微服务各实例状态，推送服务变更信息

在大型微服务项目中，服务提供者的数量会非常多，为了管理这些服务就引入了注册中心的概念。注册中心、服务提供者、服务消费者三者间关系如下：

流程如下：

• 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心

• 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）

• 调用者自己对实例列表负载均衡，挑选一个实例

• 调用者向该实例发起远程调用

当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？

• 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）

• 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除

• 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表

• 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表

3.2.Nacos注册中心

1.在mysql中导入nacos数据库

2.修改nacos配置文件，在虚拟机中使用docker部署nacos

进入root目录，然后执行下面的docker命令：

docker run -d \
--name nacos \
--env-file ./nacos/custom.env \
-p 8848:8848 \
-p 9848:9848 \
-p 9849:9849 \
--restart=always \
nacos/nacos-server:v2.1.0-slim

3.http://192.168.32.118:8848/nacos 登录nacos，首次登录默认用户名和密码都是nacos

3.3.服务注册

接下来，我们把item-service注册到Nacos，步骤如下：

• 引入依赖

• 配置Nacos地址

• 重启

1.在item-service的pom.xml中添加依赖：

<!--nacos 服务注册发现-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2.在item-service的application.yml中添加nacos地址配置：

spring:application:name: item-service # 服务名称cloud:nacos:server-addr: 192.168.150.101:8848 # nacos地址

3.为了测试一个服务多个实例的情况，我们再配置一个item-service的部署实例：

点击运行：

nacos平台：一个服务，两个实例

同时控制台也会打印向nacos注册服务的日志信息。

3.4.服务发现

服务的消费者要去nacos订阅服务，这个过程就是服务发现，步骤如下：

• 引入依赖

• 配置Nacos地址

• 发现并调用服务

前两步与服务注册流程完全一致。

可以发现，这里Nacos的依赖于服务注册时一致，这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人，也可以被别人调用，即可以是调用者，也可以是提供者。

因此，等一会儿cart-service启动，同样会注册到Nacos

3.先注入DiscoveryClient，再通过discoverClient获取服务的实例列表，通过随机获取其中一个实例，获取该实例的uri，将uri编入 restTemplate 请求参数，实现通过服务实例名称连接服务，防止写死地址。

同时发现，每次有列表中服务挂掉或新服务注册，nacos会向所有实例（调用者和提供者）发送消息，控制台会显示。

程序：

    private final DiscoveryClient discoveryClient;private void handleCartItems(List<CartVO> vos) {//1.获取商品idSet<Long> itemIds = vos.stream().map(CartVO::getItemId).collect(Collectors.toSet());// 2.查询商品//2.1 根据服务名称获取服务的实例列表List<ServiceInstance> instances = discoveryClient.getInstances("item-service");if(CollUtils.isEmpty(instances)){return;}//2.2 手写负载均衡，从服务列表中挑一个实例ServiceInstance instance = instances.get(RandomUtil.randomInt(instances.size()));URI uri = instance.getUri();//2.3 利用RestTemplate发起http请求，得到http的响应ResponseEntity<List<ItemDTO>> response = restTemplate.exchange(uri+"/items?ids={ids}",HttpMethod.GET,null,//这里本来是字节码对象，但是List<ItemDTO>这是个存在泛型的集合，会发生泛型擦除，所以使用一个对象通过反射来传泛型new ParameterizedTypeReference<List<ItemDTO>>() {},Map.of("ids", CollUtil.join(itemIds, ",")));//2.2 解析响应体//请求不一定会成功，所以要先判断if (!response.getStatusCode().is2xxSuccessful()){//查询失败，直接结束return;}List<ItemDTO> items = response.getBody();if (CollUtils.isEmpty(items)) {return;}// 3.转为 id 到 item的mapMap<Long, ItemDTO> itemMap = items.stream().collect(Collectors.toMap(ItemDTO::getId, Function.identity()));// 4.写入vofor (CartVO v : vos) {ItemDTO item = itemMap.get(v.getItemId());if (item == null) {continue;}v.setNewPrice(item.getPrice());v.setStatus(item.getStatus());v.setStock(item.getStock());}}

4.OpenFeign

在上一章，我们利用Nacos实现了服务的治理，利用RestTemplate实现了服务的远程调用。但是远程调用的代码太复杂了：

而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。

因此，我们必须想办法改变远程调用的开发模式，让远程调用像本地方法调用一样简单。而这就要用到OpenFeign组件了。

其实远程调用的关键点就在于四个：

• 请求方式

• 请求路径

• 请求参数

• 返回值类型

OpenFeign是一个声明式的http客户端，所以，OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便。

4.1.快速入门

我们还是以cart-service中的查询我的购物车为例。因此下面的操作都是在cart-service中进行。

1.引入依赖，OpenFeign和堵在均衡组件SpringCloudLoadBalancer

        <!--openFeign--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId></dependency><!--负载均衡器--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency>

2.通过@EnableFeignClients，启动OpenFeign功能

3.编写FeignClient接口类，类名上加@FeignClient("服务实例名")；接口方法定义请求方式、请求路径、请求参数、响应参数类型。

4.使用FeginClient中的接口方法获取响应参数。

feign替我们完成了服务拉取、负载均衡、发送http请求的所有工作，而且不再需要RestTemplate了，还省去了RestTemplate的注册。

4.2.连接池

Feign底层发起http请求，依赖于其它的框架。其底层支持的http客户端实现包括：

• HttpURLConnection：默认实现，不支持连接池

• Apache HttpClient ：支持连接池

• OKHttp：支持连接池

因此我们通常会使用带有连接池的客户端来代替默认的HttpURLConnection。比如，我们使用OKHttp.

1.引入依赖

<!--OK http 的依赖 -->
<dependency><groupId>io.github.openfeign</groupId><artifactId>feign-okhttp</artifactId>
</dependency>

2.修改yml，开启连接池功能

feign:okhttp:enabled: true # 开启OKHttp功能

验证：我们可以打断点验证连接池是否生效，在org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient中的execute方法中打断点：Debug方式启动cart-service，请求一次查询我的购物车方法，进入断点：可以发现这里底层的实现已经改为OkHttpClient

4.3.最佳实践

前两节我们实现了使用OpenFeign代替手写“获取服务实例、发送请求并接收”，但是存在一个问题：如果其他模块也要调用item的接口功能，也像前两节一样实现一个FeignClient？每个模块都重写一遍？非常麻烦。

避免重复编码的办法就是抽取。不过这里有两种抽取思路：

• 思路1：抽取到微服务之外的公共module

• 思路2：每个微服务自己抽取一个module

思路1：

思路2：

方案1抽取更加简单，工程结构也比较清晰，但缺点是整个项目耦合度偏高。

方案2抽取相对麻烦，工程结构相对更复杂，但服务之间耦合度降低。

这里我们选择使用方案1，但事实上建议选择方案2。

1.新建一个hm-api模块，并引入依赖：

由于这个模块是用来实现服务远程连接功能的，所以只需OpenFeign和负载均衡的依赖。

2.将cart-service中的itemDTO和client都复制到hm-api中；向cart-service的pom文件引入hm-api依赖。

删除cart-service中原来的ItemDTO和ItemClient，重启项目，发现报错了：这里因为ItemClient现在定义到了com.hmall.api.client包下，而cart-service的启动类定义在com.hmall.cart包下，扫描不到ItemClient，所以报错了。

3.当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。有两种方式解决：

• 方式1：声明扫描包：

• 方式2：声明要用的FeignClient

4.4.日志配置

我们调用一个cart的接口观察控制台：

这个接口调用了OpenFeign，但是控制台并没有相关日志的输出，这为未来调试带来不便。

OpenFeign只会在FeignClient所在包的日志级别为DEBUG时，才会输出日志。而且其日志级别有4级：

• NONE：不记录任何日志信息，这是默认值。

• BASIC：仅记录请求的方法，URL以及响应状态码和执行时间

• HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息

• FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

Feign默认的日志级别就是NONE，所以默认我们看不到请求日志。

1.要定义日志级别需要声明一个类型为Logger.Level的Bean，在其中定义日志级别：

2.但此时这个Bean并未生效（因为不在配置类中），要想配置某个FeignClient的日志，可以在@FeignClient注解中声明：

@FeignClient(value = "item-service", configuration = DefaultFeignConfig.class)

3.要想全局配置，让所有FeignClient都按照这个日志配置，则需要在@EnableFeignClients注解中声明：

控制台输出日志：

5. 拆分剩余服务

5.1 用户和地址服务

这部分相对简单，不需要引入外部服务；需要注意登录校验部分，只需要引入生成Jwt令牌部分功能，而不需要关注拦截器校验jwt令牌功能。

1.创建user-service模块，创建启动类，配置pom文件。

pom文件部分：登录功能需要有加密依赖，还有nacos依赖

2.复制配置项；复制domain、mapper、service、controller类

配置项：保留jwt令牌生成的配置项

3.复制生成jwt令牌的程序：jwtTool和两个config类。

有效配置文件设置为local，开启测试：

启动UserApplication，访问http://localhost:8084/doc.html#/default/用户相关接口/loginUsingPOST，测试登录接口：

5.2 交易服务

基本步骤和用户服务部分一致，不同点：

trade部分功能需要嗲用其他服务来实现。我们通过OpenFeign来实现。

1.根据具体需求，创建对应的FeignClient。

2.在trade启动类上加上开启OpenFeign的注解。启动TradeApplication，访问http://localhost:8085/doc.html，测试查询订单接口：

5.3 支付服务

这部分和交易服务基本一致，除了基本应用程序，还需要引入外部服务，都是适用OpenFeign实现。只需要注意不要漏复制文件即可。