ThinkPHP微服务架构核心是重构治理逻辑：数据库连接须动态化（Db::setConnectConfig+配置中心）、服务注册走Consul/Nacos、模块物理隔离、通信明确同步/异步；禁用硬编码、共享库及控制器直连。
配置 ThinkPHP 微服务架构，核心不是改几个配置文件，而是重构服务治理逻辑：数据库连接必须脱离 config/database.php、服务注册要走外部中心、模块边界得物理隔离、通信方式需明确同步或异步。硬编码、共享数据库、控制器里直连其他服务——这些单体习惯在微服务里会立刻暴露为故障点。
数据库连接必须动态化
ThinkPHP 本身不支持运行时热更新数据库配置。database.php 只能留骨架：
- 清空 connections 数组，只保留 'default' => 'mysql' 和空的 'connections' => []
- 真实参数（hostname、database、username 等）全部移出代码，存入 Nacos/Apollo/Consul，格式用 JSON 或 YAML，键名严格小写+下划线（如 db_user_center）
- 用 Db::setConnectConfig() 注册连接，传入唯一标识符（如 'user_db'），不能用 Db::connect(['type'=>'mysql',...]) 建临时连接——它不进连接池，高并发下易打爆 MySQL
- 注册动作不在控制器里做，放在中间件或服务启动阶段；重复注册同名会覆盖，但旧连接不会自动关闭，需手动清理连接池
服务注册与发现不能靠硬编码
ThinkPHPMicro 默认用 Redis 做注册中心，但生产环境建议对接 Consul 或 Nacos：
- 配置 config/service.php 中 registry.type 为 'consul'，填入地址和 token
- config/server.php 里设唯一 server_name（如 'order-service'），host/port 指向本机监听地址
- 启动时执行 php think run，框架自动注册服务元数据（IP、端口、健康检查路径）到中心
- 调用方用 \think\service\Client::request('user-service', '/api/info') 发起 RPC，或通过网关反向代理 HTTP 请求
模块拆分要物理隔离，不能只是目录划分
微服务不是把模块放不同目录就完事，每个服务应是独立可部署单元：
立即学习“PHP免费学习笔记（深入）”；
- 每个业务域（user、order、payment）建单独 Git 仓库，各自 composer.json 独立管理依赖
- 共用的 DTO、异常类、SDK 提取为私有 Composer 包，通过 packagist 或私仓引入
- 禁止模型中写 protected $connection = 'xxx' —— 它只在类加载时读一次，配置中心推送新库地址后完全无感知
- 路由定义分离：各服务 route.php 只管自身接口，API 网关（如 Kong/Traefik）统一聚合 /api/user/* → user-service
通信与配置必须解耦
避免服务间强依赖，所有外部依赖都应视为可插拔组件：
- HTTP 调用用 Guzzle 封装，设超时（≤3s）、重试（≤2次）、熔断（失败率＞50%暂停10s）
- 事件通知走消息队列（RabbitMQ/Kafka），订单创建后发 order.created 事件，库存服务订阅处理，不直接调用
- 配置中心拉取失败时要有降级策略，比如从本地 config/fallback.php 读默认值，而不是直接报错退出
- 日志统一加 trace_id，用 Monolog + ELK 采集；监控指标暴露 /metrics 接口，接入 Prometheus 抓取 QPS、延迟、错误率
