如何通过 Docker Compose 定义容器间的通信链路实现服务解耦教程

服务解耦的核心在于严格隔离通信边界：通过独立网络划分业务域、禁止跨域直连、依赖DNS服务发现、专属数据库与事件驱动、网关统一入口及内外网分离，从基础设施层保障松耦合。

服务解耦不是靠“连得上”实现的，而是靠“不该连的坚决不连”来保障。Docker Compose 本身不制造解耦，它只是把你的解耦设计忠实地跑起来——关键在配置逻辑是否体现边界意识。

用独立网络划分通信域

每个业务域（如用户、订单、支付）应有专属内部网络，禁止跨域直连。这不是可选项，是契约底线：

• 在 docker-compose.yml 的 networks 区块中为每个域定义独立 bridge 网络，例如 user-net、order-net
• 服务只加入自己所属网络：user-service 加入 user-net，order-service 加入 order-net，两者默认不通
• 若需跨域交互（如订单查用户昵称），必须经由网关或消息中间件中转，不能在代码里写 jdbc:postgresql://user-db:5432

靠服务名通信，而非 IP 或端口硬编码

容器间调用必须依赖 Docker 内置 DNS 解析，这是实现松耦合的基础机制：

• 同一网络内的服务，直接用 http://service-name:port 访问（如 http://auth-service:3000/login）
• 确保所有服务都声明 networks，且不在 ports 下暴露内部端口给宿主机——暴露仅用于外部接入点（如 API 网关）
• 禁止在应用代码或配置中写死容器 IP；若发现 172.x.x.x 地址，说明设计已退化为紧耦合

用事件驱动替代跨库查询

数据库直连是最常见的隐性耦合源头。解耦必须从数据所有权开始划清界限：

• 每个微服务配专属数据库实例（如 user-db、order-db），不复用同一容器
• 删除所有跨服务 SQL 查询（JOIN / remote SELECT）；需要对方数据时，订阅其发布的事件（如 UserProfileUpdated）
• 消息中间件（Kafka / Redis Streams）作为独立 service 编排，所有服务通过服务名连接它，不嵌入 SDK 或本地队列

网关统一入口，隔离内外通信平面

外部请求和内部服务调用必须走不同网络路径，从基础设施层切断越权可能：

• 定义两个网络：public-net（供 Nginx / API Gateway 使用）、internal-net（供业务服务与 DB 通信）
• 网关服务只接入 public-net，并通过 internal-net 调用后端，但绝不把数据库端口映射到 public-net
• 数据库服务只接入 internal-net，ports 字段留空或仅用 expose，确保外部完全不可达