yii的restful接口是单体转向微服务的实用过渡载体，需通过独立module、隔离模型、绑定路由、接口抽象及数据所有权移交实现渐进式拆分。
Yii框架的RESTful接口本身不是为微服务设计的，但它是拆分单体应用、走向微服务最实用的过渡载体。 它不提供服务发现、熔断、链路追踪等微服务必需能力，但能快速暴露稳定、可版本化的HTTP接口，让模块先“逻辑独立”，再“物理独立”。
RESTful API模块在Yii中怎么组织才利于后续拆分
关键不是“能不能写API”，而是“API模块是否具备独立演进能力”。很多团队把API写在controllers/ApiV1Controller.php里，结果越写越重，最终无法剥离。
- 每个待拆服务必须有自己独立的
module目录（如modules/user），而非共用一个api模块 -
modules/user/Module.php中显式配置controllerNamespace为modules\user\controllers，避免控制器路径污染全局命名空间 - 路由规则必须绑定到模块ID，例如
'user/<action:>' => 'user/default/<action>'</action></action:>，而不是泛匹配'api/<action>'</action> - 模型类（
User、UserProfile）和验证规则全部放在modules/user/models/下，禁止跨模块引用其他模块的models
为什么不能直接用Yii的yii\rest\ActiveController对外暴露微服务
它太“单体友好”，反而掩盖了微服务真正要解决的问题。常见踩坑点：
-
ActiveController默认依赖Yii::$app->user做鉴权，但微服务间调用应使用token或service-to-service证书，而非会话态用户 - 它的
findModel()方法硬编码查本地数据库，一旦服务拆分，你得重写整个方法，而不是换一个DB连接 - 错误响应格式是
{"name":"Not Found","message":"Object not found"}，缺乏trace_id、status_code语义，不利于下游服务做统一错误处理 - 不支持gRPC或消息协议切换，后期想升级通信方式时，得推翻重写整套控制器层
数据解耦前，如何用Yii实现“伪微服务”通信
在还没上Kubernetes或服务网格时，靠Yii自身机制也能模拟服务间调用，关键是把“远程调用”封装成“本地接口调用”的假象。
- 定义统一的客户端接口，比如
UserServiceInterface，包含getUserById(int $id): array - 提供两个实现：
LocalUserService（查本库User::findOne()）和HttpUserService（用yii\httpclient\Client调https://user-service/api/v1/users/123） - 通过DI容器在配置中切换实现：
'user.service' => ['class' => HttpUserService, 'baseUrl' => 'https://user-service'] - 所有业务代码只依赖
UserServiceInterface，不感知底层是本地查还是远程调——这才是真正的解耦起点
最容易被忽略的一点：微服务拆分不是技术动作，而是数据所有权的移交。哪怕你把user模块跑在独立服务器上，只要它还在读写主库的user表，就只是个“远程过程调用”，不是微服务。真正的分界线，在于ALTER TABLE user MOVE TO shard_user_001那条命令执行完的那一刻。
