Spring Cloud微服务网关技术介绍

1. 单体项目拆分微服务后的问题
   • 服务地址问题：单体项目端口固定（如黑马商城为8080），拆分微服务后端口各异（如购物车808、商品8081、支付8086等）且可能变化，前端难以确定请求的服务地址及应对变化。
   • 登录校验问题：单体项目登录校验后所有功能可获取用户信息，拆分后若各微服务都做登录校验，代码重复度高，且分发密钥风险大。

2. 网关解决方案及作用
   • 网关功能概述：网关负责请求路由转发和身份校验，类似小区看门大爷，住户类比微服务。前端只需知网关地址（设为8080），所有请求发往网关后，网关根据请求路由至相应微服务（如查商品路由到商品微服务，查用户路由到用户微服务），并在路由前校验用户身份，登录则解析获取用户信息并向后传递，避免微服务重复校验，同时保护微服务，使前端开发体验与单体架构一致，成为微服务开发必备组件。
   • 路由转发与微服务地址获取：网关通过注册中心获取微服务地址，微服务启动时注册信息到注册中心，网关启动后拉取，地址变更时注册中心推送。微服务多实例部署时，网关利用负载均衡算法挑选实例转发请求。
3. Spring Cloud网关组件
   

---

1. 网关路由转发功能介绍与入门案例规划
   • 核心功能阐述：网关主要有两个核心功能，一是对前端请求进行路由转发，二是对用户身份进行校验，本节课主要学习路由转发功能。
   • 路由转发流程分析：由于微服务拆分，前端难以知晓请求对象，网关作为微服务群入口，可从注册中心获取服务地址，前端请求网关后，网关判断应由哪个微服务处理（路由），再从注册中心拉取实例列表并负载均衡挑选实例发送请求（转发）。
   • 入门案例步骤规划：创建网关服务实现路由转发分为四步，重点是路由规则配置，包括创建新项目模块、引入网关相关依赖、编写启动类、配置路由规则，其中前三步是创建网关微服务，依赖坐标可复制，本节课重点学习路由规则配置。

---

Spring Cloud网关路由特殊配置

网关路由特殊配置引入

1. 背景：上节课学习了网关路由规则基本配置，能满足多数开发需求，但特殊复杂需求需特殊路由配置。
2. 路由配置类：网关路由配置由RouteDefinition类读写，常见四个属性，ID是路由唯一标识，URI是目标服务地址，配置方式与上节课基本一致；重点关注路由断言predicates和路由过滤器filters属性。

路由断言

1. 作用：判断请求是否符合规则，符合则路由到对应目标地址。
2. 断言方式
   • Spring内部提供12种，如按请求路径匹配的Path、按时间判断的After和Before（与After相反）、按请求头、cookie、请求方式等匹配。
   • 语法与上节课类似，路径规则中{}为占位符，一般按/开头后接*的方式配置。
3. 配置方式：可参考官网spring cloud gateway中的Route Predicate Factory部分，路由断言由工厂类处理，工厂名以RoutePredicateFactory为后缀，以路由规则名字为前缀，官网有详细示例。

路由过滤器

1. 作用：对进入网关的前端请求和微服务响应结果进行加工处理。
2. 过滤器种类及示例
   • Spring提供30多种，如AddRequestHeader（添加请求头）、RemoveRequestHeader（移除请求头）、AddResponseHeader（添加响应头）、RemoveResponseHeader（移除响应头）、RewritePath（重写请求路径）、StripPrefix（去除请求路径中的N段前缀）等。
   • 以StripPrefix为例，可解决前端请求路径与微服务路径不一致问题，如前端请求路径含/API前缀，微服务路径无此前缀，可通过StripPrefix去除前缀使路由正确。
3. 配置语法：与路由断言类似，如AddRequestHeader过滤器，等号左边为过滤器名字，右边为以逗号隔开的键值形式参数（请求头的key和value）。
4. 演示示例：以添加请求头过滤器AddRequestHeader为例，在idea中操作，在商品微服务路由下添加filters，具体配置可参考源码或直接复制粘贴，如添加名为truth的请求头，值为anyone Long press like button will be rich；在商品微服务controller中利用@RequestHeader注解获取请求头并打印（设置required = false），测试时先重启网关和商品服务，访问网关后查看idea中是否成功打印出添加的请求头内容，以此验证过滤器生效。

默认过滤器配置

1. 配置方法：若希望过滤器对所有路由生效，可配置在defaultFilter下，与路由同级，无需在每个路由中单独配置。
2. 验证测试：测试时仅需重启网关，再次访问网关查看是否能获取到请求头，以此验证默认过滤器对所有路由生效。

---

1. 网关实现登录校验功能的分析与思路
   • 登录授权功能部署：采用JWT登录，登录授权功能置于user service（用户微服务），登录后颁发JWT token，可从token解析用户信息。
   • 多微服务对用户信息的需求及校验问题：多个微服务（如购物车服务、交易服务）需知晓登录用户信息，若在各微服务分别进行JWT校验，会导致代码重复且增加密钥泄露风险，因此考虑在网关进行校验并向后传递用户信息。
   • 校验时机的重要性：JWT校验必须在网关将请求转发到微服务之前完成，否则校验失去意义。

2. 网关底层处理流程剖析

   • 路由规则判断：网关底层基于路由规则判断前端请求应由哪个微服务处理，此过程由handler mapping接口（默认实现为root predicted handler mapping）基于路由断言完成路由规则匹配，找到符合请求的路由后存入上下文并转交给web handler接口。
   • 过滤器链的形成与作用：web handler接口（默认实现为filtering web handler）找到当前请求对应路由生效的过滤器，排序形成过滤器链，依次调用。过滤器链中的netty routine filter默认对所有路由生效且在最后执行，负责将请求转发到微服务，微服务执行完返回结果后它进行封装并存入上下文，再依次返回给其他过滤器和用户。
   • 过滤器的PRE和POST逻辑：过滤器内部有PRE和POST两部分逻辑，请求进入先执行PRE逻辑，若失败则结束，成功才继续调用下一个过滤器的PRE逻辑；执行到netty routine filter的PRE逻辑时将请求转发到微服务，微服务执行完进入POST阶段，结果经netty routine filter封装存入上下文后依次返回给上一个过滤器，PRE阶段按顺序执行，POST阶段倒序执行。

3. 网关转发前校验方案及用户信息传递问题
   

   • 自定义过滤器实现校验：需在网关内自定义过滤器，保证其执行顺序在netty routine filter之前，在PRE逻辑里实现JWT校验，从而确保转发前完成校验。
   • 网关与微服务间用户信息传递方式：网关校验得到用户信息后，将用户信息放入请求头传递给微服务。
   • 微服务之间用户信息传递问题及差异：复杂业务中微服务间相互调用（如交易服务调用购物车服务）时也需传递用户信息，虽同样基于HTTP请求，但实现方式与网关到微服务传递有所不同，因为微服务间的HTTP请求基于open feign发起，而网关到微服务是网关内置的请求方式。

---

网关过滤器自定义及登录校验逻辑实现

网关过滤器种类

1. gateway filter
   • 之前在学习网关路由时见过，在路由配置属性中有filters，其可指定过滤器及参数。
   • 过滤器约30多种，默认不生效，可配置到特定路由或default filter下，针对指定路由或所有路由生效，灵活性高，能任意指定作用范围。
2. global filter（全局过滤器）
   • 作用范围是所有路由，进入网关的请求都会被处理，无需指定或选择，声明后自动生效，使用更简单。
   • 两种过滤器的filter方法在返回值、方法名和方法参数上完全一样，该方法是编写过滤逻辑的核心，编写登录校验逻辑时方法差别不大，以global filter为例解读方法信息。

过滤器方法参数及返回值（以global filter为例）

1. 方法参数
   • server web exchange：网关内部上下文对象，用于保存网关内部共享数据，如request、response、session等，过滤器链中所有过滤器可从中读取和存入数据。
   • gateway filter chain：过滤器链，自定义过滤器业务逻辑处理完后，调用它来调用下一个过滤器，使整个链条串联。
2. 返回值
   • 返回值为mono，网关过滤器内部分为PRE和post两部分逻辑，实现filter方法后写的业务属于PRE部分。PRE执行完调用chain调用下一个过滤器，所有过滤器PRE执行完后将请求转发到微服务，微服务返回结果才执行post部分。

定义global filter示例

1. 定义一个类实现global filter接口，加上component注解注册为spring bean，实现filter方法编写PRE逻辑（如模拟登录校验逻辑，先获取请求头，这里仅打印请求头，实际登录校验时再从请求头获取登录凭证）。
2. 校验逻辑完成后利用chain放行（调用filter方法并传入exchange，使下一个过滤器可使用上下文）。

控制过滤器执行顺序

1. 过滤器定义后要保证在netty routing filter之前执行，因为其作用是做转发，希望在转发前做登录校验，所以优先级要更高。
2. 通过查看nt routing filter源码发现它实现了order接口来排序，order接口要求实现get order方法返回int值，值越小优先级越高，netty routing filter默认优先级为integer最大值（最低优先级）。
3. 自定义过滤器实现order接口并设置较小优先级值（如0）即可在其之前执行

总结

1. 自定义global filter方式：写类实现接口，实现filter方法利用ServerWebExchange exchange获取请求信息做登录校验，校验完成利用过滤器链放行。
2. 控制过滤器执行顺序靠order接口，实现get order方法返回int值，值越小优先级越高，NTROUTFILTER默认优先级最低，自定义过滤器值比其小即可。掌握这些后，登录校验可行。

---

自定义gateway filter概述

• gateway filter特点：使用时可自由指定作用范围，能配置自定义参数，比global filter更灵活，但自定义较麻烦，日常开发多选用global filter，做登录校验功能时也常用global filter。
  - 自定义方式：需继承abstract gateway filter factory，其作用是读取配置创建定制化过滤器对象，采用工厂模式，定义的是过滤器工厂。过滤器工厂内有apply方法，基于配置创建过滤器对象，采用匿名内部类实现filter方法编写逻辑。
  - 过滤器工厂命名要求：名字必须以gateway filter factory为后缀，类名前缀将作为过滤器名字在配置文件中使用。

2. 无参gateway filter的定义与实现
   • 定义无参过滤器工厂类：如print any gateway filter工厂类，继承Abstract gateway filter factory，泛型为object，实现apply方法。
   • 注册工厂类：给工厂类加@Component注解注册为bean。
   • 构造过滤器：在apply方法中用匿名内部类构造gateway filter，实现filter方法，可编写PRE或post逻辑，此处仅打印执行信息。
   • 过滤器执行顺序问题：全局过滤器和自定义过滤器执行顺序需控制，匿名内部类无法实现order接口指定顺序，解决办法一是单独写类实现gateway filter和order接口，二是使用装饰模式。
   • 装饰模式实现：定义OrderGatewayFilter类，接受gateway filter和order参数，实现GTFILTER和order接口，构造函数记录参数，filter方法调用委托对象的filter方法，返回记录的order，使用该装饰模式为自定义过滤器添加顺序。
   • 配置生效与测试：在yml文件中配置过滤器，可定义在某一路由下或default下（作用于所有），配置print any过滤器。重启服务，清空日志，浏览器访问后查看日志，验证global filter先执行（顺序为1），print any gateway filter后执行（顺序为0，值越大优先级越低）。
3. 带参gateway filter的定义方式
   • 定义属性类：自定义带参gateway filter更复杂，需定义专门属性类匹配参数，一般定义在过滤器工厂内部为内部类，变量数量与参数数量对应。

---

网关登录校验功能实现

1. 准备工作及工具介绍
   • 网关过滤器类型：网关过滤器有gateway filter和global filter两种，日常开发多用global filter，本节课用它实现登录校验功能。
   • 黑马商城登录方式：基于JWT实现，相关密钥和工具类在单体架构项目hm service中，需拷贝到网关项目。包括保存JWT密钥的加密文件hmall.jks、加载属性的JwtProperties类、生成密钥并注册到spring容器的SecurityConfig类、配置不需要登录校验路径的exclude paths、读取路径属性AuthProperties类，以及生成和解析token的工具类JwtTool。

2. 工具拷贝与配置
   • 拷贝属性类：将jw properties、OLI等属性类拷贝到网关项目新建的CONFIG包中，标记为component使其生效。
   • 拷贝工具类：拷贝工具类GDP t two到网关项目，解决报错问题。
   • 拷贝密钥文件和配置文件：将密钥文件HMGK和相关配置文件拷贝到网关项目。
   • 定义全局过滤器：定义名为OsGlobalFilter的全局过滤器，实现global filter和order接口，设置order值为0，在filter方法中编写登录校验逻辑，包括获取request对象，判断请求路径是否在放行路径中，若在则放行，不在则获取token并校验解析，校验失败用401状态码拦截，校验通过则传递用户信息（本节课先打印用户id，后续再实现传递）。
3. 校验token与拦截逻辑
   • 获取token：从request获取header，通过指定请求头名字authorization获取token，判断header不为空且不为null时取出token。
   • 校验token：利用拷贝过来的工具类jp t two校验解析token，校验失败时try catch捕获异常，用401状态码拦截并设置response状态码为Unauthorized，终止请求。
   • 传递用户信息：校验通过则传递用户信息（本节课先打印用户id）。
4. 路径校验与整体回顾
   • 路径校验方法：定义判断请求路径是否需要被拦截的方法，通过注入all properties类获取放行路径，利用spring提供的ant pass match匹配器判断请求路径与放行路径是否匹配，循环遍历所有放行路径，若匹配则返回true，否则返回false。
   • 测试与回顾：完成过滤器逻辑后，配置购物车服务路由路径cars，重启网关服务进行测试。未登录访问购物车路径返回401，登录后可成功查询，说明登录拦截生效。回顾网关登录校验逻辑，主要包括获取请求和token、校验token、根据校验结果拦截或放行，拦截时通过response设置状态码401并结束请求，路径判断通过ant pass match匹配器判断配置路径与当前路径是否匹配。掌握这些API可实现整套登录拦截逻辑。

---

从网关到微服务的用户传递实现方法

1. 实现思路
   • 请求流程与用户信息传递方式：请求先到网关，网关过滤器中已实现登录校验并获取用户信息。网关到微服务是新的请求，将用户信息保存到请求头是传递信息的最佳方案，微服务可从请求头获取用户信息。
   • 微服务获取用户信息的优化：微服务业务接口基于Spring MVC，为避免在每个业务接口获取登录用户信息，可在所有业务接口执行前，通过Spring MVC拦截器获取请求头中的用户信息并保存到ThreadLocal，后续业务可随时取用。
2. 网关过滤器保存用户信息到请求头
   • 利用API修改请求头：网关提供了ServerWebExchange上下文对象，其mutate方法可对下游请求进行改变和处理，通过该方法返回的RequestBuilder可修改请求头信息。
   • 约定请求头名称与设置值：请求头名称可自定义，但需与微服务开发者约定好，本案例约定为user info，其值为用户ID（long型转字符串）。
   • 完成请求头修改与传递：修改完请求头后，需调用build方法构建新的ServerWebExchange，并将其传递到下一个过滤器，以确保修改生效。
   • 测试用户信息传递：在购物车服务的Controller中获取并打印请求头中的user info，重启网关后，通过查询购物车操作测试用户信息是否传递成功。
3. 微服务编写拦截器获取用户信息
   • 拦截器编写与功能实现
     • 创建拦截器类：在common模块的interceptor包下新建UserInfoInterceptor拦截器，实现HandlerInterceptor接口，只需实现preHandle和afterCompletion方法。
     • 获取并保存用户信息：在preHandle方法中，从Spring MVC的request对象获取请求头中的用户信息（与网关约定的user info一致），使用工具类判断不为空后，通过common中的UserContext将用户信息（字符串转long型）存入ThreadLocal。
     • 清理用户信息：在afterCompletion方法中，调用UserContext的removeUser清理用户信息。
   • 拦截器配置与生效问题解决
     • 配置拦截器：定义Spring MVC配置类MvcConfig，实现WebMvcConfigure接口并加Configuration注解，在addInterceptor方法中将UserInfoInterceptor添加到拦截器注册器，默认拦截所有路径。
     • 解决配置类扫描问题：由于配置类所在包与微服务包不同，需在resource目录下的meta - info下的spring.factories文件中记录配置类名字，使配置类生效。
     • 避免网关引用报错：因网关引用了common且无Spring MVC，会导致配置类在网关报错。通过给配置类加@ConditionalOnClass注解，以判断是否存在Spring MVC的核心API DispatcherServlet为条件，使配置类仅在微服务生效。
   • 测试拦截器生效：重启网关和微服务（如购物车服务），测试拦截器是否生效，如查询购物车时，日志显示能从ThreadLocal获取到正确的用户ID，而非写死的值。
4. 总结回顾
   • 网关传递用户信息：网关通过过滤器获取用户信息，利用exchange的API修改请求头，将用户信息添加到请求头中传递给微服务。
   • 微服务获取用户信息：微服务通过在common模块定义拦截器，在所有业务接口执行前获取请求头中的用户信息并保存到ThreadLocal，方便后续业务使用。
   • 问题解决与技术应用：解决了拦截器配置生效问题，包括配置类扫描和网关引用报错问题，运用了Spring Boot自动装配原理。通过在spring.factories文件中记录配置类名字实现自动装配，利用@ConditionalOnClass注解根据项目中是否存在Spring MVC的核心API来控制配置类生效范围。这表明Spring Boot自动装配原理在实际开发中可解决诸多问题，如本案例中的拦截器配置问题，同时也为后续在微服务之间传递登录用户信息等操作奠定了基础。

---

1. 微服务间用户信息传递问题引出
   • 背景：实现从网关到微服务的用户信息传递后，复杂业务场景中微服务间相互调用时的用户信息传递面临挑战。
   • 场景示例：以用户下单场景为例，涉及交易服务、商品服务和购物车服务。前端请求先进入交易服务，交易服务保存订单时需向商品服务扣减库存、向购物车服务清理购物车。
2. 用户信息传递流程及问题分析
   • 正常流程
     • 前端带JWT token请求到网关，网关过滤器校验token，有效则解析用户信息存于请求头并转发给微服务。
     • 微服务通过通用拦截器从请求头获取用户信息，如交易服务可拿到登录用户信息创建订单。
   • 现有问题
     • 交易服务调用购物车服务时未传用户id，仅传商品id。
     • 购物车服务从user context获取用户id，但因请求头无用户信息导致获取失败。
     • 原因是交易服务调用购物车服务未处理请求头，而购物车服务获取用户方式依赖user context，其前提是拦截器能从请求头取用户信息并存入user context，当前交易服务调用购物车服务时请求头无用户信息。
3. OpenFeign拦截器解决方案
   • 拦截器原理与作用：OpenFeign的request interceptor接口，其apply方法在每次请求时调用，可利用request template修改请求头，如添加请求头信息。
   • 拦截器定义与配置
     • 定义位置：因所有微服务调用其他服务时都需传递用户信息，故定义在公共的HM-api模块最合适，这样引用该模块的微服务在发起远程调用时拦截器自动生效。
     • 定义方式：采用匿名内部类声明，实现apply方法，在方法内从user context获取用户信息（需添加common依赖以使用user context），判断用户id不为空后添加到请求头。
     • 生效条件：配置类需加在Feign启动类上。
   • 测试效果：重启交易服务后下单测试，查看购物车服务日志，发现其执行业务时成功拿到user context中的用户信息，购物车成功删除，证明用户信息传递成功。

4. 总结回顾微服务用户信息传递方案
   • 过滤器和拦截器总结
     • 网关的global filter过滤器：进行JWT登录校验，获取用户信息后保存到请求头转发给微服务。
     • 微服务的handler interceptor拦截器：从请求头获取用户信息后保存到thread local，方便微服务内部业务使用。
     • OpenFeign的request interceptor拦截器：在微服务间基于OpenFeign调用时，将用户信息保存到请求头，确保下游微服务能获取用户信息。
   • 方案价值：此方案是解决微服务体系登录功能的整体思路，公司实现思路与之类似，对实际开发具有重要参考价值。