Hyperf 微服务需手动设计：按业务域（如用户、商品、订单中心）拆分为独立应用，各自治理数据库与API；通信首选JSON-RPC/gRPC，对外通过网关聚合；配套服务发现、配置中心、分布式追踪等基础设施。
Hyperf 中的微服务不是靠框架“自动实现”的，而是基于其高性能协程能力、灵活的组件体系和标准通信协议（如 JSON-RPC、gRPC、HTTP）来手动设计与组织服务边界。核心在于：用 Hyperf 构建多个独立可部署的 HTTP 或 RPC 服务，并通过服务发现、配置中心、统一网关等机制协同工作。
服务拆分原则：从业务域出发，而非技术便利
拆分前先梳理业务上下文（Bounded Context），比如电商系统可划分为：用户中心、商品中心、订单中心、库存中心。每个中心对应一个独立 Hyperf 应用，拥有自己的数据库、缓存、API 和生命周期。
- 避免按“功能层”拆（如所有 Controller 合为一个服务），这仍是单体思维
- 每个服务只暴露明确契约（如 OpenAPI 或 Protobuf 接口），内部实现完全自治
- 优先保证服务内高内聚（如订单创建、支付回调、发货状态更新应在同一服务）
通信方式选型：RPC 为主，HTTP 为辅
Hyperf 原生支持多种通信协议，推荐组合使用：
- 服务间调用首选 JSON-RPC 或 gRPC：性能高、类型安全、天然支持负载均衡与熔断（配合 Sentinel 或 SkyWalking）
- 对外 API 统一走 Gateway（如 Hyperf-Gateway）：聚合多个后端服务，做鉴权、限流、日志、协议转换
- 避免直接跨服务操作对方数据库——必须通过对方提供的接口，哪怕只是简单查一条数据
基础设施配套：让服务真正“独立运行”
单有代码拆分不够，还需支撑性组件：
- 服务注册与发现：集成 Nacos、Consul 或 Etcd，启动时自动注册，调用方动态拉取实例列表
- 配置中心：将数据库连接、Redis 地址、开关配置等外置，不同环境（dev/test/prod）差异化管理
- 分布式追踪：启用 Zipkin/Jaeger，通过 Trace ID 串联跨服务请求链路，快速定位延迟瓶颈
- 日志统一收集：用 Filebeat + ELK 或 Loki + Grafana，确保问题可追溯
本地开发与联调：用 Docker Compose 模拟真实拓扑
每个 Hyperf 服务写好 Dockerfile，再通过 docker-compose.yml 编排依赖关系：
- 定义 MySQL、Redis、Nacos 等基础服务容器
- 各业务服务设置 depends_on 和 networks，确保启动顺序与网络互通
- 配合 hyperf/config-center 或 env 文件注入环境变量，无需改代码即可切换测试配置
