黑马商城微服务--网关路由

1.网关路由就是 识别前端发过来的请求 请求的是哪个微服务  并转发请求到微服务进行处理 

集成了多个ipport的一个入口  使得前端在链接里无需考虑请求的是哪个服务  ip端口号都是啥

同时还有校验身份的功能 跟路由器里的转发表和AAA协议很想  核心 参数 id  uri predicate

2 网关yaml选择了8080 很明显要代替原来的单体架构总ipport 由他接受前端写好的访问的8080来转发给其他port 如果设置成非8080会导致改很多东西，同时网关需要拉取各微服务 所以他拉取多nacos注册实例需要负载均衡 因此这个gateway要loadblancer依赖

3  他这个网管属性的uri里面必须是lb开头的 ai给出的回答是：

1. ​​lb 表示负载均衡（Load Balancing）​​

   • lb 是协议标识符，明确告知 Gateway 需通过​​负载均衡策略​​访问目标服务。
   • 例如 lb://item-service 表示：从注册中心（如 Nacos）获取 item-service 服务的所有可用实例，并按负载均衡规则（如轮询、随机）选择一个实例转发请求。                                              

关于我自己的思考大体是前台远程调用网关 封装的网关组件通过nacos调用微服务  大概是把负载均衡获取实例  并得到实例ip的过程缩写成lb了  完整uri加载应该就是实例ip加服务路径了

4.关于三大参数：

         1. id自定义 要求唯一 黑马的是跟yml里面配置的application名字一样

          2.predicate匹配规则：

5.正如黑马所说 网关要maven加载启动项目还要编辑配置 也就是说网关和api模块的区别在于网关是一个微服务 会被加载实例  生成对应的服务 即使网关不存在本身service层和数据写入层 他只是通过controller接受调用并通过gateway远程转发 

也就是说网管专门用来服务ipport管理的是通过gateway转发的其他服务是通过 访问生产者client对象来进行对nacos注册生产者实例ip获取及远程调用  

而api（下含feign-client）模块只是公共代码抽取 只能算一个对象或者被其他服务访问时调用   其他服务有了一个可以调用它的实例

6.发生了网关的转发调用到了items 微服务 item是一个微服务 因为他只有一个启动类和一个服务配置  也就是说一个微服务可以接受两种及以上controller能收到的前缀连接

7.奇怪为什么我docker部署的nginx ip无法对后台交互 反而是localhost的才可以 我有点忘

ai非往nacos版本和grpc系统上引我就知道肯定是什么很蠢的错误了 好像是当时docker run nginx只是为了前端拉起html  js逻辑好像真不在docker容器内  怪不得一直密码错误

8.

predicate是种类非常多 包括：

各predicate 都由各自工厂类进行处理

关于路由过滤器就是对进入的进行处理后在进行服务调用  总觉得不该叫fliter

黑马说  如果nginx进行了对应的代理操作 这个去前缀的可以不配置

9.很多微服务需要用户校验  多个微服务本身校验即存在代码冗余 又不安全 因此选择在网关校验 把校验用户信息放请求头（防止对业务请求体造成影响）整体是一个责任链结构

可以看出来除了微服务互传其他的都是有思路的

10.网关过滤器有两种 前面的哪个是gatewayfliter

这俩都符合上述第9点的接口流程  关于globalfliter的参数有两个一个是 全局上下文参数exchange  一个是gateway fliter责任链 上一个调用下一个了链节点  最后返回了各mono不知道是啥 好像是说层层调用返回的东西  这个过程链结点之间不存在post过程 全是pre

至于这个mono大概是说这种链式传递异步效率更高  用mono去注册回调函数

11这电脑是个人才运行idea都能未响应 虽然我被迫关掉了idea 再打开没有微服务运行 但上次关闭没法停掉各微服务导致端口号还是被占用无法拉起微服务  于是只能kill掉各端口

也是让我学了下windows杀进程 解绑端口的方法

12.取出请求头校验逻辑如下：

请求头里可以有很多东西、

13.登录校验是在yml这么配的 对应的jwtproperties代码里写了  似乎是加载yml的属性类  excludepath 是不需要登录校验也能访问的路径

14.似乎这几个加载属性类要被其他主对象扫面并实例化 才算注入

15.放行逻辑

关于思路逻辑，我整理如下：

15.我至今都没想明白为什么这玩意会被注册两次bean  同模块下其实搜不到 只好在正确类上加个primary了

看明白了 黑马教的是jwtproperties本身不注册 在security隐式注册  但是我在那上面加了个component  导致重复注册   

终于验完了  周末还得使劲学习和锻炼 这两件事很痛苦所以让周末看起来很长可以很久不上班   但是痛苦完了 在被工作拷打之后还能想到自己还是会了不少  所以工作时候不至于自卑

16.前面代码逻辑大概是加载了 yml里的jwt配置生成实例解析token在链式调用中校验token

还需要传递给微服务去判断userid和鉴权 用这个mutate更改发给微服务的远程调用的请求头

传递一个更改请求头的exchange 来实现传递userid

17.可以看到这里跟苍穹外卖登陆一样都是用线程读写threadlocal每次对a的请求线程为t1  那t1也是a在响应的请求  之后对b请求线程t2 那b响应的请求也会是t2  每次都是不同的线程 但恰恰是请求的微服务响应的那个线程 所以这个threadlocal可以公共抽取

拦截器代码逻辑如下

说是网关request种类和微服务reques种类不一样api也会不一样 同时响应式的gateway和springmvc的webmvcconfig矛盾 gateway还引入了hm-common 所以后续会报错 这时候引入类似于c玛条件编译的java 条件装配：

18.好像拦截器原生机制就是按照prehandle返回值决定是否放行来进入服务

ctrl+i实现快速手写类方便很多

原来拦截器是在webmvcconfiguration配置注册生效的

但是干完了这么多还是没起作用 因为configuration要生效要被服务实例扫描到 才能配置成某一服务的configuratioin 还要在spring-factopry完成装配 ，我也终于知道meta-inf是啥了

19.前面实现了网关传递参数校验给微服务 使微服务根据userid处理  但是微服务之间的传递 级联处理其实请求头没有参数  所以级联操作就无效了

比如交易服务级联了购物车服务 你在购物车去userContext交易没给你传你肯定不好使

但是交易调用feign来给购物车发请求 如果在hm-api去解析交易的userid 并且有feign发的请求  购物车代码里去解析userid购物车context就有userid了

20.感觉蛮麻烦的 又是docker断开连接导致下单失败 又是docker时间导致支付失败的的

21.配置管理 大概是nacos创建配置id 实现共享配置和配置热加载  避免更改重启的影响和冗余代码

原来配置的动态读取xx.xx.xx 是下图这个意思 那nacos的共享配置也这么配就好了

拆解普通springboot来考虑如何加载共享配置

大概就是新建bootstrap拉起nacos 初始环境  导入本地yaml进行合并拉起最终application上下文

也就是编译过程中 会用配置类接受yml 导入实例及其上下文 重新run就是重新实例化的过程

22.bootstrap三要素：服务名 环境 nacos地址

23.配置格式正确的配置文件nacos能动态同步热更新环境里的 微服务配置

也就是bootstrap的必选项其实就是为了动态更新而输入的参数

这个热更新跟 实例化和导入原生yml一样 都是定义配置类去接受 用componnent注册后  实例就能拿到  由于bototstrap配置  在nacos按照格式命名就能动态热更新

怪不得空指针 yaml接收到的东西是 . 分隔  但是这里接受进行配置却-分隔  映射不到元素 造成寻找元素失败 指针空了