OpenResty 是基于 Nginx 的高性能 Web 平台，集成了 LuaJIT，提供了许多额外的模块。以下是 OpenResty 中的模块功能详解。

本章订单服务完全本地落库故意不校验用户、商品、价格，方便演练后续服务间调用为第 5~7 章引出 OpenFeign、远程用户校验、商品校验及库存扣减逻辑做准备。

协议域名端口只要有一项不同，就属于不同 Origin。前端页面：Gateway：端口不同，所以属于跨域。跨域主要是浏览器安全策略IDEA HTTP Client、Postman 和后端代码通常不会受浏览器 CORS 限制。gateway.http 能调用成功浏览器页面一定能成功调用OPTIONS是否允许当前来源？是否允许 POST？是否允许 Content-Type？是否允许自定义请求头？预检请求

第 8 章已经完成了 Gateway 统一入口：但是现在所有业务接口只要知道地址就能访问，例如：这显然不符合真实项目要求。本章要完成的目标是：本章最终请求链路如下：2、为什么需要统一鉴权2.1 当前项目缺少什么能力在没有统一鉴权之前，业务接口存在几个问题。第一，任何人都能访问业务接口。第二，订单服务仍然信任客户端传入的 。这非常危险。客户端传什么用户 ID，服务端就用什么用户 ID，相当于把身份决

微服务之间往往是链式调用。↓cloud-user↓如果响应非常慢，中等待商品服务返回的线程就会被占住。当请求越来越多时，中越来越多线程被阻塞。cloud-product 慢↓cloud-order 线程堆积↓cloud-order 也变慢或不可用↓Gateway 请求堆积↓整个链路被拖垮这就是微服务中常说的服务雪崩。1. 不是项目统一 Result 格式2. 前端不好统一处理3. 用户看不懂英文提

商品详情每次都查 MySQL，有没有必要？然后一步一步走到了完整缓存链路。

第 11 章我们把 Redis 接入到了 ，解决了商品详情接口反复查询 MySQL 的问题，也顺手演练了缓存穿透、缓存击穿、缓存雪崩和缓存一致性。这一章开始引入 RabbitMQ。不过这一章不只是演示“发一条消息、收一条消息”。如果只做到这一步，RabbitMQ 学起来会很轻，但真正写项目时还是不知道怎么处理异常。这一章继续沿用前面的订单链路，从创建订单这个场景出发，一步一步解决这些问题：这一章最

第 12 章我们完成了 RabbitMQ 可靠消息链路：RabbitMQ 解决的是：但是当前下单流程里还有一个更靠前的问题：如果商品服务已经扣减库存，而订单服务随后保存失败，会发生什么？当前两个服务各自只有本地事务：所以原始结果可能是：第 13 章就是围绕这个问题，引入 Seata AT 模式，让订单和库存能够作为一个全局事务整体提交或整体回滚。本章主线是：2、本章环境与涉及模块本章继续基于前面章

单服务 Knife4j↓OpenAPI 3 注解↓多服务独立文档↓Gateway 调试↓↓Gateway 聚合↓生产关闭边界springdoc 负责生成文档Knife4j 负责展示与调试Gateway 负责聚合与鉴权OpenAPI Security 负责描述认证JwtAuthGlobalFilter 负责真正校验 JWT文档页面看起来正确不代表真实请求一定正确请求地址请求头状态码实际响应。

单服务 MDC↓Gateway 统一生成 TraceId↓所有业务服务接收↓OpenFeign 继续透传↓CircuitBreaker 线程池传播↓@Async 线程池传播↓失败链路验证Gateway 负责确定入口 TraceId请求头负责跨服务传递MDC 负责进入日志Feign 拦截器负责新的 HTTP 请求ExecutorService 和 TaskDecorator 负责线程切换finall