微服务不是拆服务，是先把中间件账算清

叙事主角：老李，AI 时代的互联网架构师 架构探讨：微服务组件体系与中间件体系

接入层

一、痛点：拆完服务，中间件先把你拖垮

不识庐山真面目，只缘身在此山中。

讨论里最常出现的问题是：「你们微服务怎么拆的？」老李更想反问：「拆完之后，谁扛注册发现、配置、限流、事务和消息？」

讲真，很多团队把「拆服务」当成成绩单。服务多了，故障域也多了。HeroDash 早期把 Spring Cloud 铺开：Nacos、Sentinel、Seata、RabbitMQ/NATS、Redis、ES、Milvus，挂上 K8s。迭代周期缩短约 50%。账也硬——每个中间件都是独立故障面。

GFS 末端配送日运单从 10 万冲到 100 万，救场的不是再拆两个服务，而是 RocketMQ 消息中心把日均千万级推送触达率顶到 99.99%，再配 Flink + StarRocks 把链路算清。禅游发行平台用户约 14 亿、峰值约 3 万 QPS：WebFlux 网关异步化加熔断，再配 Dubbo 系 RPC（简历技术栈写 Dubbox，高并发改造按 Dubbo3 能力讲清即可）。前海映像跨境供应链用 Dubbo 拆用户、订单、仓储、物流、财务——边界跟领域走，不跟时髦走。

小结：聊「拆了几个服务」，不如聊「中间件怎么分层、怎么容量、怎么一致」。

二、是什么：两套体系，一张分层图

工欲善其事，必先利其器。

老李把常谈内容压成两本账。

组件体系（服务怎么活）：网关、注册发现、配置中心、熔断限流、分布式事务编排。 中间件体系（服务靠什么活）：MQ、缓存、检索、向量库、流计算、OLAP。

是什么：两套体系，一张分层图

微服务不是 Spring Cloud 的别名。Dubbo3 + 网关 + Nacos 同样完整。组件管调用怎么通、怎么控；中间件管数据怎么传、怎么存、怎么查。Nacos 一身两职：实例心跳与配置推送。配置变更要灰度、可回滚，别把生产当实验田。

三、为什么用：拆服务的扳机，不是技术冲动

凡事预则立，不预则废。

老李只认四条拆分扳机：

为什么用：拆服务的扳机，不是技术冲动

反例也硬：日运单还在 1 万、团队 3 人，先上 Seata + 五套 MQ，等于给自己挖坑。HeroDash 迭代能砍半，靠组件齐、发布链路短，不是服务拆得碎。反直觉一点：服务越碎，中间件账单越贵。

四、架构决策：MQ 选型与一致性边界

运用之妙，存乎一心。

MQ 怎么选

MQ 怎么选 · 场景

别背「谁最强」。看吞吐、延迟、顺序、堆积、运维成本五维，再落到自己项目。

一致性三档，别一上来 Seata

一致性三档，别一上来 Seata

GFS 触达率 99.99%，靠可靠投递、幂等消费、对账，不是每个触达开全局事务。前海映像订单与仓储跨域：写路径本地事务落库，状态靠 MQ 推进；资金类只在短关键路径评估编排/TCC，简历里没写「全链路 Seata 化」。Seata 是手术刀，不是创可贴。

五、装什么、怎么验证：最小可运行栈

纸上得来终觉浅，绝知此事要躬行。

老李用 Cursor / Claude Code 拉最小栈时，强调别只会背 YAML：

1. Nacos 起注册与配置；Gateway 或 WebFlux 挂路由。
2. Sentinel 配慢调用熔断 + QPS 限流；压测看拒绝策略。
3. 选一个 MQ：业务事件 RabbitMQ，履约推送 RocketMQ。
4. Redis 做热点与幂等键；ES 做检索；向量场景再上 Milvus。
5. 只有明确跨库短事务才上 Seata，并写空回滚用例。

验收就三条：注册可见、熔断可触发、消息可堆积可消费。K8s 再补探针、HPA、资源配额——HeroDash 这条跑通，才敢谈迭代缩短约 50%。

六、实战复盘：治理三板斧 + 容量账

操千曲而后晓声，观千剑而后识器。

三板斧：限流挡入口洪峰；熔断切下游坏牙；降级保主路径。禅游约 3 万 QPS 峰值，先把网关线程模型改成异步，再挂 Sentinel 规则。顺序反了，规则再多也是装饰。

容量账（架构评审常过这本）：

• 网关：连接数、超时、线程或事件循环
• MQ：生产 TPS、消费并行度、堆积告警阈值
• Redis：命中率、大 key、热 key
• ES / Milvus：写入延迟、查询 P99、索引重建窗口
• 事务：Seata 全局锁时长、回滚比例

GFS 日运单十倍增长，消息中心先扩容再拆服务。拆错顺序，运维先崩。

七、洞见三条

博观而约取，厚积而薄发。

洞见一：先画组件分层，再谈服务清单

报「拆了 20 个服务」不如画清：网关 → 治理 → 业务 → 中间件。分层清楚，拆分才有约束。

洞见二：最终一致是默认，Seata 是例外

履约、推送、物流状态机吃得消「可延迟可补偿」。强一致只留给库存扣减、资金记账这类短关键路径。

洞见二：最终一致是默认，Seata 是例外

洞见三：中间件容量是架构的一半

没有堆积告警、没有熔断演练、没有大 key 治理，谈高可用都是口号。真要过关，得看有没有扛过真实峰值。

八、总结：方法论收口

知止而后有定，定而后能静。

核心就一条：微服务体系 = 组件治理 + 中间件容量 + 一致性边界。拆服务跟领域与组织走；MQ 跟场景走；事务能本地就本地，能最终就最终；三板斧挂在入口与下游依赖上。

总结：方法论收口

方法论速查表

方法论速查表 · 问题