要在 Yii3.0 项目中真正落地微服务架构，必须围绕限界上下文划分服务边界、进程隔离部署、REST+OpenAPI契约先行实现同步通信、消息队列支撑异步解耦，并确保各服务独占数据库、采用“本地事务+事件发布”保障最终一致性，否则易退化为分布式单体。
要在 Yii3.0 项目中真正落地微服务架构，不能只靠拆出多个 HTTP 接口，必须同步解决服务边界划分、进程隔离、跨服务通信机制和数据所有权归属问题——否则极易退化为“分布式单体”，上线仍需全量发布，数据库仍被多服务直连，团队协作依然强耦合。
按限界上下文识别服务边界
打开业务需求文档，逐条标注每个用户操作背后的真实业务意图，例如“下单”动作实际包含库存预占、价格校验、风控拦截、订单生成四个不可分割的子过程；其中库存预占与库存服务强绑定，价格校验依赖商品域定价规则，风控拦截属于安全子域，订单生成才是订单服务的核心职责。【跨子域的动作不能塞进同一个服务】
用事件风暴工作坊梳理出所有领域事件（如 OrderPlaced、InventoryReserved、PaymentConfirmed），将高频共发、共享同一聚合根、修改同一组实体的事件归入同一限界上下文——这个上下文就是你第一个微服务的天然边界。
检查现有代码：如果 UserController 和 OrderController 共享同一个 UserActiveRecord 模型，且都直接调用 $user->save() 写库，说明用户数据所有权未下沉，必须先将 User 相关读写逻辑全部收束到用户服务内部，其他服务只能通过 API 或事件消费用户数据。
用独立进程部署每个微服务
Yii3.0 不再默认提供多服务托管能力，每个微服务必须作为独立 PHP-FPM 进程或 Swoole Worker 运行：
方法一：为每个服务新建一个 composer 项目，执行 composer create-project yiisoft/app order-service，在 config/web.php 中仅注册该服务所需的组件（如只配订单相关中间件、不加载用户模块）。
方法二：复用同一代码仓库但分目录隔离，在 services/order/ 下放订单服务入口文件 public/index.php，其加载的配置路径为 config/services/order/，确保 DI 容器不跨服务泄漏实例。
【禁止在单一 Yii3 应用内用模块模拟微服务】——模块间仍共享容器、日志、DB 连接池，无法实现独立部署与扩缩容，违背微服务本质。
同步通信：REST+OpenAPI契约先行
第一步：在订单服务根目录运行 php yii openapi/generate --output=docs/openapi.yaml，生成当前服务对外暴露的 OpenAPI 3.0 文档。
第二步：将生成的 openapi.yaml 提交至 Git，并通知库存服务团队据此开发客户端 SDK——SDK 必须由 OpenAPI 自动生成（推荐使用 Swagger Codegen 或 OpenAPI Generator），避免手写 HTTP 调用导致契约漂移。
第三步：库存服务在 config/services/inventory/client.php 中配置订单服务地址：'order_api_url' => 'https://order.api.internal'，并在构造函数注入 OrderApiClientInterface，而非硬编码 cURL。
这一步操作起来很简单，直接把文件拖进去就行。但若跳过契约生成直接写接口调用，后续订单服务字段改名或删除参数时，库存服务会静默失败，排查成本极高。
异步通信：基于消息队列解耦状态变更
方法一：用 Yii3 官方扩展 yiisoft/queue + Redis 驱动：
安装：composer require yiisoft/queue；
在订单服务中触发事件：$this->queue->push(new OrderPlacedEvent($orderId))；
库存服务监听该事件：在 config/console.php 中注册 InventoryReservationHandler 为消费者，处理失败时自动重试 3 次后转入死信队列。
方法二：对接 Kafka（生产环境推荐）：
配置 kafka://kafka-broker:9092 为消息源，订单服务发送消息到 order.placed 主题，库存服务订阅该主题并反序列化 JSON 消息体；【消息体必须是不可变结构，禁止传对象实例或闭包】
注意：不要在消息中携带用户明文信息或支付敏感字段，只传必要 ID 和状态码，敏感数据通过后续 REST 查询获取。
数据一致性：最终一致性的三步落地
① 所有微服务各自独占数据库实例，禁止跨库 JOIN 或直接访问其他服务表；
② 关键业务流程（如下单）采用“本地事务 + 发布事件”模式：订单服务在事务内写订单表 → 成功后发 OrderPlaced 消息 → 库存服务消费消息并执行库存预占；
③ 对账服务每日扫描订单与库存状态差异，发现不一致时触发补偿任务——例如订单已创建但库存未预占，则回调库存服务补操作，或人工介入。
