ThinkPHP6.1分布式服务拆分核心是逻辑解耦、职责收敛与通信可控，聚焦app/service下PascalCase命名的领域服务类，控制器仅收参、调服务、返JSON，服务间通过接口抽象、事件驱动和Redis等轻量机制通信，支撑权限、验证码、分布式锁等模块同步解耦。
一、按业务域划分 Service 模块（非传统“模块”）
ThinkPHP6 的“模块”（如 `app/admin`）适合前后端一体的子系统；而分布式服务拆分应聚焦在 **`app/service` 下的领域服务类**，每个类代表一个可独立演进的业务能力单元：• 命名严格使用 PascalCase + 场景化后缀：`OrderPaymentService`、`UserVerificationService`、`MatchMakingService`（陪玩匹配）、`NotificationDispatchService`
• 禁止泛义命名（如 `UserService`），避免职责蔓延；一个 Service 类只解决一个明确业务问题
• 类文件直接放在 `app/service/` 目录下，不嵌套子目录（避免路径过深），靠命名体现归属，例如 `app/service/MatchMakingService.php`
• 若某业务域复杂度高（如订单含创建、支付、退款、售后），可进一步拆为 `OrderCreateService`、`OrderRefundService` 等，而非塞进一个大类
立即学习“PHP免费学习笔记（深入）”；
二、控制器仅作“请求路由”，不掺杂任何业务判断
每个接口方法退化为三步流水线，彻底剥离业务实现：• 收参：统一用验证器（`Validate`）预处理，得到结构化 `$data`
• 调服务：通过容器获取对应 Service 实例，例如 `app()->make(MatchMakingService::class)->start($data)`
• 返结果：直接 `return json($result)`，不拼数组、不手动处理状态码（由 Service 返回标准化结构）
• 绝对禁止：在控制器里查数据库、发 HTTP 请求、写日志、判断权限、开启事务——这些全部移出
三、服务间通信走轻量协议，不直连 DB 或全局配置
Service 层要能“拎出来跑”，就必须切断隐式依赖：• 数据操作交给 Model 或 Query 类，Service 只调用 `UserModel::where(...)->find()`，不出现 `Db::table()`
• 第三方能力抽象为接口：定义 `SmsInterface`、`VoiceRoomInterface`，生产环境绑定 `TencentVoiceRoom`，测试环境绑定 `MockVoiceRoom`
• 配置项不调 `config('sms.template_id')`，而是由控制器或中间件注入参数，例如 `$service->joinRoom($userId, $roomId, $config)`
• 跨服务协作不直接 new 或 app()->make()，改用事件驱动：`event(new OrderPaid($order))`，由监听器触发积分更新、通知推送等下游动作
四、支撑性模块同步解耦，避免单点瓶颈
光拆 Service 不够，配套机制也要分布化：• 权限校验 → 提炼为独立中间件（如 `AuthMiddleware`）或 `AuthService::check($token)`，控制器不写 if 判断
• 验证码 → 改用 Redis 存储（key 为 UUID），生成与校验流程解耦 Session，适配前后端分离（参考验证码插件改造方案）
• 分布式锁 → 抢单、库存扣减等场景，统一用 `Redis::set($lockKey, $value, ['nx', 'px' => 10000])` 封装成 `DistributedLock::acquire()` 工具方法
• 日志与监控 → 关键 Service 方法入口加 `Log::info('MatchMakingService.start', [...])`，不依赖文件写入，对接 ELK 或云日志服务
不复杂但容易忽略。拆分目标不是立刻上 Kubernetes，而是让每个 `Service` 类具备“可测试、可替换、可迁移”的基因——今天跑在单机 TP6 应用里，明天就能打包成 Swoole RPC 服务独立部署。
