「已注销」用了将近两个月，把SpringBoot + Vue + SpringCloud这套微服务架构下的潮服购物商城从零搭完，从最开始对着教程一脸茫然，到后来能独立排查服务间调用超时、分布式事务回滚失败这类问题，中间踩的坑确实不少。这篇文章就把整个项目的设计与实现过程完整拆开讲，包括服务拆分逻辑、基础组件选型、前后端联调方案、分布式环境下的高并发处理，以及让我差点崩溃的几个疑难问题。项目结构偏传统B2C商城，但技术点覆盖很全面，适合准备做SpringCloud微服务方向课设或毕设的同学参考，也适合刚接触微服务、想系统了解一下完整落地过程的朋友。
1. 一个商城系统，为什么非要用微服务架构
先把这个最核心的问题说清楚。很多人在开题的时候都会犹豫，一个服装商城而已，单体架构两三天就能写完，非要用SpringCloud搞成微服务，是不是自己给自己找麻烦？我的答案是：要看这个系统的定位是什么。如果只是做一个功能演示，单体确实足够；但如果是作为毕设或课设，想体现分布式架构、服务治理、高并发处理这些核心能力，微服务就是你绕不开的选择。
微服务给这个潮服商城带来的直接好处有三个。
第一个是物理隔离与独立扩展。商城业务天然有热度差异——活动期间的秒杀流量、商品详情的频繁访问、用户登录的持续并发、后台管理的低频率操作，这些模块的负载特征完全不同。微服务架构下，我可以单独给订单服务、商品服务分配更多实例，而用户服务和后台服务保持低配运行，资源利用率比单体高很多。
第二个是故障隔离。单体架构里，如果某个模块出现内存溢出，整个进程挂掉，前台后台全部瘫痪。拆成微服务后，即使订单服务OOM了，商品浏览、用户登录依然可用。这一点在实际部署中被验证得特别明显——上线初期搜索服务因为索引问题频繁崩溃，但前台购物流程完全没有受影响。
第三个是团队协作层面的，尤其是论文和答辩环节。微服务架构天然要求清晰的模块边界，每个服务有独立的代码仓库、独立的数据表、独立的接口定义，这让系统设计部分的论述变得非常自然。你在论文里可以明确画出服务依赖关系图，阐述每个服务的自治性，这种结构化的表达比单体架构更容易讲清楚。
但也必须泼一盆冷水——微服务是有代价的。分布式环境的调试复杂度陡增，服务间调用超时、数据一致性、链路追踪，这些问题在单体模式下根本不存在。如果你们的项目时间只有两周，我建议老老实实用单体。我做这个项目的时间线大概是：前期设计两周，框架搭建一周，核心业务开发三周，联调排错接近两周，前后加起来差不多八周才敢说系统整体稳定。时间预算心里要有数。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 潮服商城的微服务边界划分与数据库拆分
服务拆分是整个项目的灵魂。拆多了，开发工作量爆炸；拆少了，算不上微服务。我最终把系统拆成了六个核心服务，外加两个基础设施层组件。这个划分不是拍脑袋定的，而是从业务流程、数据归属、扩展频率三个维度逐步推出来的。
2.1 六个核心业务服务的职责界定
- 用户服务（user-service）：负责注册登录、JWT签发与校验、用户资料、收货地址、会员等级。这个服务是所有服务中调用频率最高的，所以把鉴权相关的逻辑全部收敛在这里，其他服务只通过网关校验令牌，不直接调用用户服务。
- 商品服务（product-service）：负责潮服的分类管理、SPU/SKU管理、商品详情、库存查询。服装行业的商品模型比较特殊，一个款式（SPU）下有多个颜色尺码组合（SKU），所以这里的表结构设计和传统电商有差异，后面细说。
- 购物车服务（cart-service）：独立拆出来可能有人觉得多余，但购物车读写频繁、数据结构简单，独立之后不会因为商品模块的复杂查询拖慢速度。加上后续如果做推荐功能，购物车数据是重要的行为依据。
- 订单服务（order-service）：这是整个系统的核心环节，涉及下单、订单状态流转、超时取消、售后流程。订单表的数据量增长最快，而且订单操作涉及库存和账户变动，必须单独隔离，保证事务边界清晰。
- 支付服务（payment-service）：对接模拟支付流程，负责支付单创建、回调处理、对账。实际开发中我并没有对接真实的支付宝或微信支付，而是做了一个模拟支付通道，但保留了完整的回调验签逻辑，后续接真实支付可以无缝切换。
- 搜索推荐服务（search-service）：基于Elasticsearch实现潮服的商品搜索、筛选、排序以及简单的"相似推荐"。服装的检索维度很多，品牌、风格、颜色、尺码、价格区间都是筛选条件，数据库里做这种多维度组合查询性能很差，独立搜索引擎是合理方案。
2.2 数据库拆分的关键决策
数据库拆分遵循一个原则——每个服务独占自己的库，服务之间不共享表，跨服务的数据需求一律通过接口调用或事件通知解决。这个原则执行起来会遇到很多实际困难，我举两个例子。
第一个是购物车场景。购物车表归属购物车服务，但页面要展示商品封面图、名称、单价，这些数据在商品服务里。如果每次查询购物车都去调商品服务接口，一方面增加网络开销，一方面耦合性太强。我的做法是购物车表里冗余了商品ID、名称、封面图URL、单价这几个非核心字段，价格作为快照定期更新。这样页面渲染一次查询搞定，商品服务挂了购物车还能以快照形式展示。
第二个是订单场景。订单服务需要扣减库存，但库存数据归属商品服务维护。传统单体里一个事务就能搞定，微服务下必须拆成两个步骤：订单服务先调商品服务的库存扣减接口，成功后本地再创建订单。这就是典型的分布式事务问题，我采用了库存预扣 + 订单确认的柔性事务方案，第5章会展开讲。
具体到表设计，以商城的核心链路为例，用户服务的有 user、user_address、user_level；商品服务的有 spu、sku、category、brand、sku_stock；订单服务的有 order_master（订单主表）、order_item（订单明细）、order_status_log（状态流转记录）；购物车服务有 cart_item；支付服务有 payment_order。每张表都加上 create_time、update_time、deleted 三个基础字段，为后面的逻辑删除和审计留余地。订单表和支付表的设计我在第2.3小节单独说。
2.3 服装行业特有的商品模型设计
潮服商城和3C家电不一样，服装的商品模型复杂在规格维度。我设计的商品结构是这样的：
spu 表存放款式级信息，字段包括 spu_id、spu_name、category_id、brand_id、style（风格标签，比如街头/工装/休闲）、season（季节属性）、main_image、description。sku 表存放售卖级信息，字段包含 sku_id、spu_id、sku_name、color、size、price、stock。下单时选中的是一组SKU的集合，订单明细里记录的是SKU级别的快照信息。
把库存放在SKU这一层是关键点。因为服装的库存管理是"款多量少"，一个款式可能有几十个SKU组合，每个SKU的库存可能只有个位数。如果把库存放在SPU层，下单时无法精确判断哪个颜色尺码缺货。SKU层拆得越细，后续的库存核对、采购补货越精准。
值得注意的是服装的尺码体系很混乱——有的品牌的S对应160，有的对应165，还有的用数字尺码。所以在商品服务里单独建了一张 size_chart 表，记录了每个品牌对应的尺码对照表，商品详情页根据品牌动态展示尺码引导。这个细节在答辩时很容易被老师问到，因为它是服装电商区别于通用电商的典型业务特征。
3. 微服务基础设施落地：注册中心、网关、配置中心与认证
服务拆好了，数据库分好了，接下来是把SpringCloud这套基础设施搭起来。这个阶段最折磨人，因为版本兼容性问题一个接一个。我最终确定的版本组合是：SpringBoot 2.7.8 + SpringCloud 2021.0.5 + SpringCloud Alibaba 2021.0.5.0 + Nacos 2.2.0。这里特别提醒一下，SpringCloud和SpringCloud Alibaba的版本必须严格对应，否则会出现连不上Nacos、Feign客户端Bean加载失败这类诡异问题。JDK统一用1.8，不要升到17，很多中间件对JDK17的支持还有坑。
3.1 Nacos双中心——注册中心与配置中心
Nacos在这个项目里承担了两个职责。作为注册中心，所有服务启动后把自己注册到Nacos，服务之间通过服务名互相发现，不再关心对方的IP和端口。这里有个很实用的小技巧：本地开发时服务注册的是 localhost，部署到服务器后需要改成内网IP，我是通过bootstrap.yml里的 spring.cloud.nacos.discovery.ip 参数在部署时注入，避免改代码重新打包。
作为配置中心，我把所有服务的公共配置抽离到Nacos。以数据源配置为例，开发环境和部署环境的数据库地址不同，但代码里不应该出现这些差异。做法是各服务本地只留一个 bootstrap.yml 指定应用名和Nacos地址，真正的数据源、Redis、MQ连接信息全部放在Nacos配置中心的Data ID里，用 spring.profiles.active 区分dev和prod两套配置。这样部署环境切换时只需要改Nacos里的配置，服务重启即生效，不用重新打包。
动态配置刷新是一个加分项。商品服务有个阈值配置"库存低于多少时触发预警通知"，这个值在运维过程中经常调整。Nacos支持配置监听，修改配置后通过 @RefreshScope 注解让Bean重新加载配置值，不用重启服务。这个功能在演示环节效果很好，老师会认可你对配置治理的理解深度。
3.2 网关层的统一认证与路由聚合
网关选了SpringCloud Gateway，没有选Zuul。Gateway基于WebFlux，性能更好，而且和SpringCloud的整合更现代。网关对外暴露端口8070，前端所有请求统一打到这个端口，由网关按路由规则转发到具体服务。
网关做了三件核心的事。
第一是路由转发。定义了每个服务的前缀规则，比如 /api/user/** 转发到user-service，/api/product/** 转发到product-service，/api/order/** 转发到order-service。配合StripPrefix过滤器去掉前缀后再转发，这样下游服务收到的路径是干净的。
第二是统一鉴权。写了一个全局过滤器 AuthGlobalFilter，用户登录成功后拿到JWT令牌，后续所有请求在Header里带 Authorization: Bearer <token>。网关负责解析JWT，校验签名和有效期，校验通过后把解析出的用户ID通过请求头 X-User-Id 传递给下游服务。这样下游服务不需要关心token解析，只需要信任网关传递的用户信息。白名单路径（比如登录接口、商品搜索接口）在配置文件中声明，直接放行。这个设计的最大好处是鉴权逻辑集中在网关层，后续增加服务不需要重复实现认证代码。
第三是跨域处理。开发阶段前端跑在8080端口，网关在8070端口，浏览器会拦截跨域请求。在网关层统一添加CORS配置，允许的前端源地址写在配置中心里，方便部署阶段调整。
这里有一个我踩过的很深的坑：网关过滤器和Feign拦截器对JWT令牌的处理容易冲突。网关把token解析后转成用户ID传给下游，但下游服务内部通过Feign调用其他服务时，需要把请求头里的用户信息继续传递下去，否则链路断了。解决办法是写一个Feign的 RequestInterceptor，从当前请求上下文取出 X-User-Id，写入Feign请求头。如果不加这一步，会出现"用户登录了，但订单服务调商品服务查询时拿不到用户身份"的诡异问题。
3.3 认证流程的完整链路
认证流程整体走JWT + 无状态会话方案。用户提交用户名密码，用户服务校验通过后生成token，token的有效期设置为24小时，这个值不用太长，配合前端的主动刷新机制，安全性更高。token里只包含 userId 和 userName，不塞太多信息，避免体积过大影响每次请求的传输效率。
Redis在这里承担了token状态管理的角色。登录成功后，除了签发JWT，还会在Redis里写入一个 login:token:{userId} 的记录，值为token，设置了和JWT一致的过期时间。用户登出或修改密码时，直接删除Redis里对应的key，下次请求网关解析JWT时再检查Redis是否存在，不存在就判定为失效。这个设计弥补了JWT"签发后无法主动失效"的天然缺陷，可以在用户被顶号时强制下线。
4. 核心商业链路：商品浏览、购物车与订单状态机的实现
基础组件搭好之后，进入业务开发阶段。这个阶段我建议从商品模块开始，因为它的依赖最少，写起来最顺畅，能快速积累信心。然后依次做购物车、下单、支付，最后做搜索推荐，因为搜索推荐依赖的商品数据最完整。
4.1 商品浏览的缓存策略与详情页聚合接口
商品列表页是流量最大的页面，数据库抗不住高频查询，必须引入Redis缓存。我用的缓存模式是Cache Aside：先查缓存，缓存不命中再查数据库，然后回填缓存。针对潮服商城的业务特点，缓存key做了分级设计，首页推荐位的数据量不大但访问最集中，直接缓存整个列表结构；分类页按分类ID做缓存；商品详情页的缓存以 product:detail:{spuId} 为key，过期时间设为30分钟。
缓存穿透和缓存雪崩的处理必须提前做，不然后期测试的时候问题会集中爆发。穿透的解决办法是缓存空值——查不到的商品也缓存一个空对象，过期时间设短一些，比如5分钟。雪崩的解决办法是给缓存时间加一个随机扰动，比如基础过期时间是30分钟，实际设置时在24到36分钟之间随机，避免同一批key同时过期引发数据库瞬时压力。
商品详情页还有一个典型的BFF（Backend for Frontend）问题。页面要展示SPU基本信息、所有SKU列表（含价格和库存）、品牌信息、尺码对照表、同风格推荐。如果前端分别调用五个接口自己聚合，要发五次HTTP请求，首屏渲染很慢。我在商品服务里提供了一个聚合接口 /api/product/spu/detail/{spuId}，服务内部并行调用内部的Mapper查询各块数据，拼装成一个完整的DetailDTO返回。前端一次请求拿到全部数据。这里的并行查询用了 CompletableFuture，四个查询并行执行，总耗时从400毫秒降到120毫秒左右，效果非常明显。
4.2 购物车表的结构设计与合并逻辑
购物车表的数据结构设计直接影响后续的下单逻辑。我的 cart_item 表是这么设计的：
id：主键user_id：用户IDsku_id：SKU IDspu_id：冗余的SPU ID，用于分款式管理购物车quantity：数量checked：是否选中，1选中0未选中add_time：加入时间
为什么要把SKU独立一行而不用聚合存储？因为购物车需要频繁修改数量、勾选状态、删除单个SKU，关系表结构对这些操作支持得最好。同一个SPU下的多个SKU（比如同一件衣服的两个颜色）会分成两行记录，前端展示时再按SPU分组渲染。
购物车还有一个经典问题——未登录状态加入购物车后，用户登录了怎么办？我没有做太复杂的方案，采用的是合并策略：用户登录后首次加载购物车时，前端把本地存储的临时购物车数据提交给后端，后端遍历临时列表，如果用户购物车里已有相同SKU，则数量相加；如果不存在，则新增记录。合并完成后清空本地存储。这个逻辑花了我一个下午，但做完之后体验确实顺滑，答辩时可以当亮点讲。
4.3 订单状态机的定义与流转控制
订单模块是整个系统里最考验设计能力的部分。我的订单状态设计如下：
| 状态码 | 状态名 | 说明 |
|---|---|---|
| 0 | 待支付 | 下单成功，等待支付 |
| 1 | 已支付（待发货） | 支付回调成功 |
| 2 | 已发货 | 商家后台发货 |
| 3 | 已签收 | 用户确认收货 |
| 4 | 已完成 | 交易完成 |
| 5 | 已取消 | 用户主动取消或超时取消 |
| 6 | 退款中 | 售后申请处理中 |
| 7 | 已退款 | 退款完成 |
| 8 | 已关闭 | 关闭状态 |
这里最有技术含量的部分是超时未支付自动取消。用户在待支付状态下超过30分钟未付款，订单要自动取消并释放库存。实现方案有两个，一个是定时任务轮询订单表，一个是延迟队列。我在项目里用了RabbitMQ的延迟队列插件，下单成功后发送一条延迟消息，30分钟后消费者收到消息，检查订单是否仍处于待支付状态，是则更新为取消状态并调用库存服务回补库存。相比定时轮询，这个方案的实时性更好，不会出现"明明过了30分钟，订单还要等下一轮扫描才能取消"的问题。
状态流转的严格控制也很重要。订单状态的每一次变更，都要先确认当前状态是否符合流转条件，然后在 order_status_log 表里插入一条记录，记录操作人、操作时间、旧状态、新状态、变更原因。这个表看似不起眼，但在售后争议排查时是唯一可追溯的依据。答辩时老师问我"怎么保证订单状态不能乱跳"，这个字段的设计就是答案。
4.4 下单扣库存的分布式事务处理
下单这个动作，在微服务架构下涉及订单服务和商品服务两个独立的数据库，这是整个系统最核心的分布式事务场景。
我用的方案是事务消息（本地消息表 + 消息队列）。当用户点击提交订单，订单服务执行以下步骤：
- 开启本地事务，创建订单记录（状态为待支付），同时往本地消息表插入一条"预扣库存"的消息记录，状态为待发送。
- 本地事务提交后，定时任务扫描本地消息表中待发送的消息，投递到RabbitMQ。
- 商品服务消费MQ消息，执行库存预扣，执行成功后返回确认；如果失败，消息进入重试队列。
- 支付成功后，支付服务发送"订单已支付"事件，商品服务收到事件后把预扣库存转为实际扣减。
- 如果订单超时未支付被取消，订单服务发送"订单取消"事件，商品服务收到后回补预扣库存。
这套方案的好处是保证了最终一致性，订单创建和库存扣减不会因为网络抖动或服务宕机出现长期不一致。消息在本地消息表里持久化，重启后定时任务会继续发送未完成的消息，不会丢消息。相比Seata的AT模式，这个方案虽然要多写很多代码，但对底层机制的理解更透，答辩的时候能讲出深度。如果时间紧张，直接用Seata的AT模式接入也是可行方案，但我个人不建议完全依赖框架，至少要把事务消息方案的原理想清楚。
5. 前端Vue设计：从页面到网关的完整链路
前端我选了Vue3 + Vite + Element Plus + Pinia + Vue Router的组合，没有用Vue2和三件套。Vite的开发体验比Webpack好太多，冷启动基本秒开，热更新也及时。Element Plus提供的Table、Form、Dialog组件做后台管理页面足够用。Pinia相比Vuex简单直接，没有那么多概念，非常适合中小型项目。状态管理用来存用户信息、购物车数量、权限路由这类全局数据。
5.1 前端与微服务网关的通信约定
前端和后端的连接方式很简单——所有HTTP请求统一发给网关地址 http://localhost:8070，网关负责转发。为了统一鉴权，我封装了一个axios实例，请求拦截器里从Pinia的userStore中取出token，加到Header的 Authorization 字段。响应拦截器做统一错误处理：401（token过期或无效）时清除本地登录态，跳转登录页并弹提示；其他业务错误码统一弹Message提示。
这里有一个跨域细节值得提一下。生产环境下，前端打包后的静态文件由Nginx提供，网关在8070端口，Nginx需要配置反向代理，把 /api/ 前缀的请求转发到网关。开发环境下，Vite的proxy配置同样代理到8070。两套环境的差异全部收敛在 vite.config.js 的proxy和Nginx的配置里，前端代码不需要感知环境的切换。
5.2 商品分类页与潮流风格的视觉呈现
潮服商城的视觉呈现和传统商城有区别，目标用户是追求个性、喜好潮牌的年轻人，所以首页的设计偏向"视觉杂志"风格。商品列表的卡片式布局、大图预览、标签化风格标识（街头、工装、机能、复古）都是围绕这个定位做的。
前端有一个综合筛选组件是根据搜索服务的数据构建的，筛选条件包括风格、季节、品牌、价格区间、颜色、尺码。用户每调整一个筛选条件，组件就重新请求搜索接口，服务端利用Elasticsearch的组合查询返回筛选结果和聚合信息（比如每个分类的商品数量）。这里的体验优化点在于防抖——用户在快速点击筛选条件时，前端会延迟300毫秒再发请求，避免频繁触发后端查询。
5.3 页面路由鉴权与用户状态保持
前端路由需要区分用户角色。我用了一个动态路由方案：登录后拿到用户信息，判断用户角色，然后通过 router.addRoute 动态添加对应的路由。普通用户注册后是"会员"角色，可以访问个人中心、购物车、订单列表；后台管理账号是"管理员"角色，额外挂载商品管理、订单管理、用户管理、数据统计这些路由。
路由守卫的逻辑是这样的：router.beforeEach 里判断目标路由是否需要登录，需要的话检查Pinia里是否有token和用户信息；没有则跳转登录页，并带上 redirect 参数，登录成功后跳回原页面。这里有个细节——刷新页面后Pinia的数据会丢失（除非做了持久化），所以需要从localStorage中恢复用户信息。我直接用Pinia的持久化插件解决，token和用户信息同步存储到localStorage，刷新后自动恢复。这个功能不做的话，用户一刷新页面就会因为状态丢失被踢回登录页，体验极差。
6. 分布式疑难杂症排查记录
最后写一下这个项目里最消耗时间、也最有价值的排错过程。每一个问题单独拿出来都能写一篇博客，这里挑三个最典型的分享，希望你们少走弯路。
6.1 Feign调用超时导致下单失败率飙升
上线前的压测阶段，我模拟50并发下单，发现失败率高达20%。排查链路发现，订单服务通过Feign调用商品服务的库存扣减接口时，经常抛出 Read timed out 异常。
问题的根因在Feign的默认超时设置上。OpenFeign默认的连接超时是10秒，读取超时是60秒，但下单接口涉及本地事务+MQ消息投递，部分请求的响应时间接近甚至超过了60秒。压测并发一高，线程池排队加剧了延迟，最终触发超时。
排查时我先用 arthas 的trace命令追踪了库存接口的实际耗时，发现大多数请求在50毫秒内完成，但偶发到2秒以上——这是数据库连接池在高并发下的等待时间。然后我用 jstack 看线程状态，确认了大量线程阻塞在数据库连接获取上，这才找到真正的根因是连接池配置过小。修改 HikariCP 的 maximum-pool-size 从10调到50后，超时问题基本消失。随后再把Feign的超时参数调成连接超时5秒、读取超时10秒，兜底了极端情况。这个排查过程让我意识到，框架层的问题往往只是表象，资源池的配置才是真正需要关注的。
6.2 RabbitMQ延迟队列不触发的版本兼容坑
订单超时自动取消功能在开发环境测试正常，但把RabbitMQ换到服务器版本后，延迟消息一直没有触发。排查后发现是服务器的RabbitMQ没有安装延迟消息插件，延迟交换机创建失败，但没有任何启动报错，只是消息进入交换机后石沉大海。
解决方案很简单，下载对应版本的 rabbitmq_delayed_message_exchange 插件，解压到插件目录，启用即可。但这里有个隐藏问题：插件版本必须和RabbitMQ服务版本严格对应，否则启用失败。我一开始下载了一个新版插件装到旧版RabbitMQ上，用 rabbitmq-plugins enable 命令时报了版本不兼容的错误，换了对应版本之后才成功。这个排查本身不难，但因为错误不直接暴露，白白花了两个晚上。
6.3 Vue打包后刷新页面404的问题
前端用Vue Router的history模式时，打包部署到Nginx后，访问首页正常，但一旦访问 /goods/123 这种二级路由，刷新页面就报404。原因很明确——history模式下的路由是浏览器端的，Nginx没有对应的物理文件，刷新时Nginx找不到路径就返回404。
配置Nginx的 try_files 指令可以解决这个问题：当请求的路径不存在时，回退到 index.html：
nginx复制location / {
root /usr/share/nginx/html;
index index.html;
try_files $uri $uri/ /index.html;
}
这个配置是前端部署必配项。第一次部署时我在Nginx的配置里忘记加 try_files，然后抓耳挠腮了一个小时才想起来是这个经典问题。希望你们不要步我后尘。
7. 设计与论文文档的产出经验
很多同学忽略文档，但设计文档和论文恰恰是毕设的大头。我的体会是，代码实现越复杂，文档越要从顶层逻辑入手，避免被细节淹没。
宏观层面，整个系统的设计文档核心是一张架构图（我在文档里用文字描述了层次结构，你们也可以用工具画）：展示层Vue → 网关层Gateway → 服务层六个微服务 → 基础设施层Nacos、Redis、RabbitMQ → 数据层各类数据库。每一层的职责、交互协议、关键配置都要交代清楚。
功能需求部分用用例图的方式描述各角色的操作，管理员和会员的用例分开画。系统设计部分重点描述数据库ER图和表结构。论文的创新点部分，微服务架构、分布式事务的最终一致性、基于延迟队列的订单超时处理，这三个点分别展开写出理论和实现细节，就是很好的"核心章节"。
关于答辩，我的建议是准备几个"为什么"的问题：为什么用微服务、为什么选Nacos不选Eureka、为什么不直接用Seata、订单超时取消为什么用延迟队列不用定时任务。这些问题想透了，答辩基本没有难度。前期觉得踩坑很痛苦的调试过程，到写文档的时候反而成了最充实的素材。
整套系统从零到一跑通之后，回头看最大的收获不是把这些框架用了一遍，而是理解了每个组件在分布式环境下各自解决什么问题、付出什么代价。希望这篇文章能帮你们避开我走过的弯路，把精力多放在业务深度和疑难排查上。