去年和朋友创业搞社区团购，惨淡收场，但技术架构沉淀了下来。这套基于SpringCloud Alibaba的微服务方案，经历过晚高峰的并发考验，今天拿出来复盘一下，重点聊聊我们当时如何划分服务，以及怎么搞定最头疼的分布式事务问题。
创业失败了，但代码是无辜的。当时我们几个技术合伙人，对微服务摩拳擦掌，觉得不用微服务都不好意思叫互联网项目。现在看，有些设计过度了，但也有不少值得坚持的地方。
一、微服务怎么拆？我们走过的弯路
最初我们按标准电商维度拆：用户、商品、订单、支付、库存。跑起来就出问题了。社区团购有个核心特征：“今日下单，明日自提”，所有业务都围绕“团”和“提货点”展开。
最终我们的服务划分是：
user-service (用户服务)：基础，不说了。
product-service (商品服务)：特别注意，商品价格和库存是按“团”维度管理的。同一个苹果，A小区团和B小区团价格、库存独立。
group-service (核心)：这是我们的业务中台，管理“开团”、“参团”、“成团”状态，以及“提货点”信息。所有其他服务都重度依赖它。
order-service (订单服务)：生成订单、状态流转。
inventory-service (库存服务)：最复杂的服务之一。要处理下单预扣、支付后真实扣减、次日未提货自动返还、团长手动核销等一系列操作。我们把它独立出来，用Redis+Lua脚本保证原子性。
payment-service (支付服务)：对接微信支付，成功后发消息。
delivery-service (核销/履约服务)：处理团长扫码核销。
operation-service (运营后台)：供内部使用。
教训：别为了拆而拆。“团”这个强业务概念，必须有一个核心服务来承载和协调，它就是group-service。
二、分布式事务：跨服务下单的最终一致性方案
用户下单，涉及group-service（校验团状态）、inventory-service（扣库存）、order-service（生成订单）。怎么保证要么一起成功，要么一起失败？
我们放弃了Seata的AT模式（性能和维护成本考虑），采用了“本地消息表+最终一致性”，这是当时我们小团队最能把握的方案。
下单入口（order-service）：在一个本地事务中，①生成“待支付”订单，②向本地消息表插入一条“扣库存”消息。事务保证这两步原子性。
定时任务扫描消息表，将消息通过RocketMQ发送出去。
inventory-service：消费消息，执行预扣库存。如果失败（比如库存不足），则回发一条“扣库存失败”消息。
order-service：消费“扣库存失败”消息，将订单状态改为“无效”。
同时，我们还有个“兜底对账”的Job，每小时跑一次，对比订单状态和库存流水，对状态不一致的进行补偿或告警。
三、高并发场景下的应对
晚高峰抢菜：核心是读多写少。
写：扣库存用Redis Lua，扛住瞬时压力。
读：商品详情、团信息，全部上Redis缓存。注意，团状态（是否已成团）这种高频变化的数据，我们用了Redis Hash + 本地缓存（Caffeine）两级缓存，本地缓存设短时间（如2秒），极大减轻Redis压力。
网关：用Spring Cloud Gateway做统一限流和熔断，特别是对“查询团长今日订单”这类接口。
四、复盘与反思
如果用现在的眼光看，inventory-service和group-service耦合有点紧，部分逻辑可以下沉为领域能力。但整体架构经受住了考验。微服务拆分的边界不是技术，而是业务能力与变更频率。社区团购的业务变化像风一样快，独立的operation-service让我们能快速迭代运营功能，而不影响核心交易链路。
