一、重构背景：V1.0的瓶颈与业务需求
1.1 单体架构的局限性
初版系统采用微擎（PHP） 框架+Layui前端组件，虽快速实现MVP（最小可行产品），但面临显著瓶颈：
- 性能瓶颈：PHP+MySQL单体架构在日订单超5000单时，接口响应延迟达800ms以上，高峰时段数据库CPU占用率超90%；
- 迭代效率低：新增功能需全量部署，平均耗时15分钟，且模块耦合度高（如点餐与库存逻辑交叉）；
- 扩展性不足：无法独立扩容高并发模块（如支付、推荐引擎），制约业务增长。
1.2 市场需求升级
餐饮客户提出新需求：
- 多终端支持：需同时覆盖H5、微信小程序、Android/iOS APP，而Layui仅适配PC端；
- 智能能力集成：菜品推荐需引入AI算法（如协同过滤），原PHP架构难以支撑实时计算；
- 微服务化：连锁餐厅要求分店独立管理库存与订单，需业务模块解耦。
二、技术选型：微服务架构的升级路径
2.1 后端框架迁移：微擎 → ThinkPHP 6.0
- 解耦与独立性：
通过 Sunphp框架（兼容ThinkPHP6）重构微擎模块，将原/addons/目录下的业务代码剥离为独立服务，消除对微擎后台的强依赖。 - 关键技术适配：
2.2 前端架构升级：Layui → UniApp
- 多端统一开发：
采用UniApp+Vue3重构前端，一套代码编译至H5、小程序、APP，解决Layui仅限PC端的痛点。 - 性能优化实践：
2.3 微服务基础设施
| 组件 | 选型 | 解决的核心问题 |
|---|---|---|
| API网关 | Kong | 路由分发、限流（支持5000+QPS） |
| 服务注册 | Nacos | 动态服务发现与配置管理 |
| 通信协议 | gRPC（Go服务） | 高并发模块如支付、推荐引擎 |
| 消息队列 | RabbitMQ | 订单异步处理，削峰填谷 |
三、核心模块重构实践
3.1 智能点餐服务
- AI推荐引擎：
- 性能对比：
3.2 分布式订单服务（ThinkPHP多应用模式）
- 分库分表设计：
- 事务一致性：
基于RabbitMQ实现最终一致性：
3.3 多端UI统一方案（UniApp ）
- 跨端适配技巧：
- 典型页面重构：
四、微服务治理与高可用保障
4.1 服务监控体系
- 全链路追踪：SkyWalking监控gRPC/HTTP调用链，定位慢请求（如推荐服务超时）；
- 告警策略：库存服务错误率＞1%时触发企业微信机器人告警。
4.2 安全加固措施
- 数据传输：敏感字段（如支付信息）采用算法加密；
- 权限控制：RBAC模型扩展为“门店-角色-操作”三级权限，支持连锁分店独立管理。
4.3 持续交付流水线
plaintextplaintext复制代码提交 → SonarQube静态扫描 → Jenkins构建镜像 →
K8s灰度发布（10%流量）→ 全量上线 - 效果：版本迭代周期从2周缩短至2天。
五、落地效果与未来规划
5.1 业务指标提升
| 指标 | V1.0 | V2.0 | 提升幅度 |
|---|---|---|---|
| 并发订单能力 | 5,000/日 | 50,000/日 | 900% |
| 推荐转化率 | 12% | 28% | 133% |
| 系统宕机时长 | 年均4小时 | 年均10分钟 | 96% |
5.2 技术债务清理
- 去中心化：完全脱离微擎框架，消除年费成本与授权风险；
- 技术栈统一：后端以PHP为主，前端全栈Vue，降低团队学习成本。
5.3 未来演进方向
- 服务网格化：引入Istio管理东西向流量，实现A/B测试、熔断策略可视化；
- AI深度集成：CV识别菜品（如后厨自动核验菜品分量），提升品控效率；
- 低代码扩展：基于ThinkPHP+UniApp搭建模块市场，支持客户自助拼装功能。
研发团队结语 “技术选型服务于业务节奏——从微擎单体到ThinkPHP微服务，从Layui到UniApp，每一次重构都是对‘技术赋能产业’理念的践行。未来我们将继续探索AI与餐饮场景的深度融合，让代码产生温度，让技术创造价值。” **——菏泽微智 技术总监**
技术合作
邮箱：18653057518@163.com | 官网：http://www.wx186.cn
本文为菏泽微智「技术分享」系列第二篇，转载需授权并注明出处。
