1. 项目背景与选题价值
去年在给某连锁餐饮品牌做技术咨询时，他们的收银系统在高峰期频繁崩溃的问题让我印象深刻。传统的单体架构收银系统在面对突发客流时，经常出现响应延迟、订单丢失的情况。这正是微服务架构最能发挥优势的典型场景。
基于微服务的餐厅收银管理系统，本质上是通过业务解耦来实现弹性扩展。将订单处理、支付对接、库存管理这些高并发模块拆分为独立服务后，每个模块都可以根据实际负载动态调整实例数量。比如用餐高峰时可以单独增加订单服务的容器实例，而会员积分这类低频操作则保持最小资源占用。
2. 系统架构设计解析
2.1 微服务拆分方案
我们的服务划分严格遵循DDD（领域驱动设计）原则：
- 订单服务（Order）：处理下单、改单、退单等核心流程
- 支付服务（Payment）：聚合微信/支付宝/银联等支付渠道
- 库存服务（Inventory）：实时同步菜品库存状态
- 报表服务（Report）：生成经营数据分析看板
每个服务都包含独立的：
- API网关（Spring Cloud Gateway）
- 注册中心（Nacos）
- 配置中心（Nacos Config）
- 数据库（MySQL 8.0分库）
2.2 关键技术选型
| 技术栈 | 选型理由 |
|---|---|
| Spring Cloud | 完善的微服务生态，与Spring Boot无缝集成 |
| Docker | 容器化部署保证环境一致性，配合K8s实现自动扩缩容 |
| Redis | 高频访问的菜单数据、促销规则采用缓存，降低数据库压力 |
| RocketMQ | 订单状态变更等关键业务事件通过消息队列保证最终一致性 |
特别注意：支付服务必须部署在内网区，通过API网关暴露有限接口，符合PCI-DSS支付安全标准
3. 核心业务流程实现
3.1 下单-支付完整链路
- 客户端发起订单请求 → API网关路由到Order服务
- Order服务：
- 校验菜品库存（调用Inventory服务）
- 生成订单号（雪花算法）
- 持久化订单数据（MySQL分库键=门店ID）
- 返回预支付信息 → 客户端调起支付
- 支付成功回调 → Payment服务：
- 验证签名（防止伪造回调）
- 更新订单状态（通过RocketMQ通知Order服务）
- 触发库存扣减（异步消息保证最终一致性）
3.2 容错设计要点
- 支付状态查询补偿：当网络抖动导致未收到回调时，系统自动按订单号向支付平台主动查询
- 库存预扣减机制：下单时先占库存，15分钟未支付自动释放
- 分布式事务方案：采用Seata的AT模式处理跨服务数据一致性
4. 答辩常见问题与应对策略
4.1 技术深度类问题
Q：为什么不用单体架构？
A：从三个维度分析必要性：
- 业务维度：收银系统包含支付、库存等不同SLA要求的模块
- 性能维度：高峰期订单量是平日的5-8倍，需要弹性扩展
- 运维维度：单体架构一个模块出问题会导致整个系统不可用
4.2 落地实践类问题
Q：如何保证微服务间的数据一致性？
A：我们的解决方案是分级处理：
- 强一致性：支付等金融操作使用Seata分布式事务
- 最终一致性：库存变更通过RocketMQ消息+本地事件表
- 补偿机制：定时任务核对重要业务数据
4.3 业务价值类问题
Q：系统上线后的实际效果？
A：在某连锁餐厅实测数据显示：
- 高峰期系统响应时间从3.2s降至400ms
- 服务器成本降低40%（按需分配资源）
- 订单丢失率从0.3%降至0.02%
5. 避坑指南与经验总结
-
服务拆分陷阱：
- 过早拆分：初期可以按业务领域划分粗粒度服务
- 过度拆分：通信成本会随服务数量指数级增长
-
事务设计建议：
- 80%的场景可以用消息队列+重试机制解决
- 真正需要分布式事务的只有资金相关操作
-
性能优化实测数据：
- Redis缓存菜单数据后，下单接口QPS提升6倍
- 数据库分库后，高峰期CPU负载从90%降至35%
这个项目让我深刻体会到：微服务不是银弹，只有匹配业务规模的架构才是好架构。对于中小型餐厅，可以考虑先做模块化拆分，待业务量增长后再逐步向微服务演进。