Yii本身不支持微服务，需按业务边界系统性拆分：识别高内聚低耦合的有界上下文（如auth-service）、禁用跨库查询与共享状态、用独立DB和JWT认证、通过RabbitMQ/Kafka异步通信、Docker独立部署并输出标准日志。
Yii 框架本身不提供微服务原生支持，它是一个面向单体/模块化应用的 PHP 框架。想用 Yii 构建微服务，不是调一个配置或装个扩展就能完成的事，而是要基于业务边界做系统性拆分和通信重构。
Yii 中识别可拆分的“有界上下文”
微服务拆分失败，八成栽在第一步：没真正理清业务边界。别一上来就想着“把用户模块拎出去”，先问清楚：
- 这个模块是否拥有独立的数据变更生命周期？比如
User表的增删改是否完全不依赖Order表的触发器或事务钩子？ - 它的 API 是否能被其他系统（如小程序、第三方 ERP）直接消费，而无需绕过当前 Yii 应用的中间层逻辑？
- 团队是否已形成对该模块的专属维护能力？如果还是所有人改
UserController，那只是“逻辑隔离”，不是“服务隔离”。
典型可优先拆出的上下文：auth-service（JWT 签发/校验）、notify-service（短信/邮件模板+渠道抽象）、payment-gateway（对接微信/支付宝的统一适配层）。它们共性是：高内聚、低外部状态依赖、接口契约稳定。
用 Yii REST 模块暴露服务接口，但必须砍掉单体残留
很多人把 Yii 的 yii\rest\ActiveController 一配，就以为完成了服务化。实际线上踩坑最多的是“伪 API”——接口虽走 HTTP，底层仍直连主库、复用单体模型、共享 Yii::$app->user 组件。
- 必须禁用跨库查询：删掉所有
join其他服务表的 ActiveRecord 关联，改用 API 调用（如file_get_contents('http://auth-service/users/123')或 Guzzle 客户端）。 - 数据库彻底私有化：新服务必须使用独立 DB 实例，连接配置从
main/config/db.php移出，改由自身config/main-local.php管理。 - 身份认证剥离：不再依赖
Yii::$app->user->id，改用 JWT payload 解析后的sub字段，且密钥由网关（如 Kong）或独立 auth-service 管理。
示例中常见错误写法：User::find()->joinWith('orders')->all() —— 这种代码留在微服务里，等于埋了分布式事务雷。
服务间通信不能只靠同步 HTTP，消息队列是解耦刚需
订单创建后通知库存扣减，用 curl 同步调用 inventory-service 是最危险的路径：网络抖动、下游超时、重试逻辑缺失，都会导致状态不一致。
- 核心链路异步化：订单服务发一条
order.created事件到 RabbitMQ/Kafka，库存服务作为消费者监听并处理，失败自动进死信队列。 - 避免在 Yii 控制器里写
sleep(1)或循环轮询来“等结果”，这会阻塞整个 PHP-FPM 进程。 - Yii 自带的
yii\queue扩展只适合单机任务调度，生产环境必须换amqp或kafka驱动，且消费者进程需独立于 Web 进程运行（如php yii queue/listen后台常驻）。
注意：消息体必须是自包含的，不要传 Order $order 对象引用，而应序列化关键字段：{"order_id": "ORD-20260419-001", "items": [{"sku": "A123", "qty": 2}]}。
Docker + 独立部署才是微服务落地的底线
如果所有“服务”还跑在同一台服务器的 Apache 下，只是目录不同、入口不同，那只是文件夹级别的“微服务”。真正的服务自治体现在部署粒度上。
- 每个服务必须有自己的
Dockerfile，基础镜像建议用php:8.3-cli-alpine（非apache版），Web 服务用 Swoole 或 RoadRunner 替代传统 FPM。 -
docker-compose.yml里禁止volumes映射到宿主机代码目录，所有代码打入镜像；配置通过environment注入，而非挂载config/params.php。 - 健康检查端点必须真实有效：不要返回
{"status": "ok"}就完事，要查 DB 连接、Redis 可达性、关键队列长度，例如/health?checks=db,redis,queue。
最容易被忽略的一点：日志必须集中输出到 stdout/stderr，而不是写入容器内 runtime/logs。否则 K8s 的 kubectl logs 和 ELK 收集全部失效。
