微服务解耦核心在于职责边界、数据所有权和通信契约的刚性约束，需通过一对一数据库绑定、事件驱动替代跨库查询、网络分层隔离及去中心化配置实现；docker compose 仅执行设计，不自动解耦。
微服务计算与存储的彻底解耦，核心不在“容器化”本身，而在于架构设计中对职责边界、数据所有权和通信契约的刚性约束。Docker Compose 是实现这一目标的高效编排载体，但它不自动解耦——解耦靠设计，Compose 只负责忠实执行这个设计。
明确服务与数据库的一对一绑定关系
每个微服务必须拥有专属数据库实例（或逻辑隔离的 schema），禁止跨服务直连其他服务的数据库。这不是技术限制，而是契约强制：
- 在 docker-compose.yml 中为每个服务定义独立的数据库服务（如 user-db、order-db），不复用同一 PostgreSQL 容器
- 服务代码中只连接自己名下的 DB（如 user-service 连 user-db），连接字符串通过 environment 或 env_file 注入，不硬编码
- 数据库迁移脚本与服务代码共仓管理，版本同步发布，避免“库已升级、服务未更新”导致的数据结构错配
用事件驱动替代跨库查询与同步写操作
当一个服务需要另一服务的数据（例如订单服务需要用户姓名），不能走 JOIN 或远程 SELECT，必须通过异步事件完成最终一致性：
- 用户服务修改昵称后，向 Kafka（或 Redis Stream）发布 UserUpdated 事件
- 订单服务订阅该事件，将昵称冗余存入本地 order_summary 表（仅用于展示），不参与业务逻辑判断
- Compose 中将消息中间件（如 kafka、zookeeper）作为独立 service 编排，所有服务通过网络名访问，不嵌入任何服务内部
网关与内部网络分层隔离
外部请求和内部服务通信必须走不同网络平面，从基础设施层切断越权访问可能：
- 定义两个自定义网络：public_net（供 gateway 和 nginx 使用）和 internal_net（供业务服务与数据库通信）
- gateway-service 只接入 public_net，并通过 internal_net 调用 order-service 等后端，但 不暴露数据库端口给 public_net
- 数据库服务（如 postgres）仅接入 internal_net，完全屏蔽外部可达性；其 ports 字段不声明，或显式设为 expose 而非 ports
配置与启动依赖去中心化管理
避免因配置混杂或启动时序误判导致隐性耦合：
- 每个服务的环境变量（DB_URL、KAFKA_BROKERS 等）全部来自独立 .env 文件或 env_file，不通过 link 或 environment 继承其他服务变量
- depends_on 仅表达容器启动顺序，不保证服务就绪；实际健康检查由应用自身探针（如 /actuator/health）+ Compose 的
