yii框架本身不是为微服务设计的，适合单体模块化而非跨进程服务化；仅当出现跨库migrate、多表深度关联查询、超时错误无法缓存缓解三大信号时，才值得考虑服务化。
Yii 框架本身不是为微服务设计的，强行“搭建微服务架构”只会导致路由混乱、服务发现失效、事务断裂——它适合做单体模块化，而非跨进程服务化。
Yii 项目该不该拆成微服务？
先看三个信号：如果 yii migrate 要跨库执行、User::find()->with('profile', 'orders') 查询已稳定依赖 4 张以上业务表、日志里频繁出现 PHP Fatal error: Maximum execution time of 30 seconds exceeded 且无法靠缓存缓解，才值得考虑服务化。否则用 Yii 的 Module + RESTfulController + 独立数据库分库，已足够支撑百万级订单/日活。
模块化拆分时怎么避免“假微服务”陷阱
常见错误是把 modules/order 和 modules/user 直接打包成 Docker 镜像、配 Nginx 反向代理，但内部仍共用 common/config/main-local.php 和同一个 db 组件——这本质是“单体套壳”，不是服务化。
- 每个模块必须拥有独立数据库连接配置（不能复用
Yii::$app->db） - 跨模块调用禁止使用
Yii::$app->getModule('user')->getUserService()这类直接引用，改用 HTTP 客户端（如GuzzleHttp\Client）或消息队列（amqp） -
console/controllers/MigrateController.php必须按模块隔离，php yii migrate --migrationPath=@order/migrations不能混跑
服务间通信用 REST 还是 gRPC？
Yii 原生对 gRPC 支持极弱（无内置序列化器、无拦截器链、需手动编译 .proto 并维护 pb.php 文件），而 yii\rest\ActiveController + JSON + JWT 已能覆盖 90% 场景。除非你有强实时性要求（如库存秒杀扣减），否则别碰 gRPC。
实操建议：
- 对外暴露接口统一用
yii\rest\UrlRule配置'pattern' => 'v1/<module:>/<action:>'</action:></module:> - 内部服务调用加
X-Service-Name请求头，便于网关层限流和链路追踪 - 禁止在
behaviors()中硬编码http://user-service/api/v1/profile，改用环境变量getenv('USER_SERVICE_URL')
Docker 部署时最常漏掉的三件事
很多人写完 Dockerfile 就以为完成了，结果上线后 502 频发或数据库连不上——根本原因不是 Yii 配置，而是容器网络与启动顺序没理清。
- 必须用
depends_on+ 自定义健康检查脚本（例如 curl -f http://user-service/health），不能只靠depends_on等容器启动就认为服务就绪 -
entrypoint.sh中要包含chmod +x /app/yii（Yii console 命令在 Alpine 镜像中默认无执行权限） - 数据库连接字符串里的 host 不能写
localhost，得用 docker-compose 定义的服务名（如user-db），否则容器内解析失败
真正难的从来不是怎么拆，而是怎么让 OrderService 在扣减库存失败时，能原子性地回滚 PaymentService 已生成的预支付单——Yii 没有分布式事务框架，这事得靠 Saga 模式或本地消息表，不是改几行 config/web.php 就能解决的。
