4. 部署拓扑模式（一）：单机多进程部署、多机负载均衡部署、反向代理与网关拓扑
部署拓扑是服务边界在物理或虚拟环境中的落地形态。不同的拓扑模式决定了进程间通信（IPC）的路径、数据序列化开销、故障隔离半径以及运维复杂度。本章聚焦三种基础但核心的拓扑模式：单机多进程、多机负载均衡、反向代理与网关，并分析每种模式下数据传输机制的设计要点。
4.1 单机多进程部署拓扑
单机多进程是最简单的分布式雏形。多个服务进程共享同一台主机的操作系统内核，但拥有独立的进程地址空间。这种模式常用于开发环境、边缘节点或资源受限的嵌入式后端。
4.1.1 拓扑结构
所有进程通过 localhost 网络栈或 Unix Domain Socket 进行通信。进程间不共享堆内存，数据必须序列化后跨越进程边界。
关键特征： 共享内核但隔离地址空间；无网络跳数；IPC 延迟极低（微秒级）；故障隔离弱（一个进程崩溃可能影响主机资源）。
4.1.2 数据传输机制设计要点
| 维度 | 设计建议 | 说明 |
|---|---|---|
| 序列化协议 | Protobuf / FlatBuffers | 避免 JSON 文本解析开销；共享内存场景下可使用零拷贝序列化 |
| 连接管理 | 长连接 + 连接池 | localhost 场景下连接建立成本低，但仍需池化避免频繁握手 |
| 故障隔离 | 进程级 watchdog | 单进程崩溃不应影响其他进程；使用 supervisor 或 systemd 自动拉起 |
| 资源争抢 | CPU 亲和性 + cgroup | 避免多个进程抢占同一 CPU 核导致抖动 |
避坑提示： 单机多进程不等于“无网络开销”。即使使用 localhost，TCP 协议栈仍会经过完整的传输层处理。对延迟极度敏感的场景（< 50μs），应优先考虑 Unix Domain Socket 或共享内存（mmap + 信号量）。
4.2 多机负载均衡部署拓扑
当单机资源无法承载流量或需要高可用时，服务必须水平扩展到多台物理机或容器。多机负载均衡拓扑引入 负载均衡器（Load Balancer, LB） 作为流量入口，将请求分发到后端服务实例集群。
4.2.1 拓扑结构
LB 位于客户端与服务集群之间。后端服务实例无状态（或状态外迁），每个实例独立运行在不同主机上。LB 负责健康检查、会话保持、流量分发。
4.2.2 负载均衡策略对比
| 策略 | 适用场景 | 数据一致性影响 |
|---|---|---|
| 轮询（Round Robin） | 请求处理时间均匀的无状态服务 | 无影响 |
| 最少连接（Least Connections） | 长连接服务或请求处理时间差异大 | 无影响 |
| IP Hash / 一致性哈希 | 需要会话保持（Session Stickiness） | 需配合分布式缓存或黏滞会话 |
| 加权分发（Weighted） | 异构机器性能差异明显 | 无影响 |
4.2.3 数据传输机制变化
- 网络跳数增加： 客户端 → LB → 后端实例，至少 2 跳。延迟从单机微秒级上升到毫秒级（通常 1-5ms 内网）。
- 序列化要求不变： 跨主机必须使用 TCP/UDP 传输，序列化协议需考虑带宽和解析效率。
- 健康检查数据流： LB 定期向后端发送探针（如 HTTP GET /health），后端需暴露轻量健康端点，避免探针请求污染业务指标。
- 会话状态外迁： 若使用黏滞会话，LB 需在请求头或 Cookie 中携带路由标识；若使用分布式会话，则需独立 Session Store（如 Redis）。
设计建议： 多机拓扑下，务必为每个服务实例配置独立的 优雅关闭（Graceful Shutdown） 流程。实例收到 SIGTERM 后，应先从 LB 注销（通过 API 或等待健康检查失败），再处理完正在进行的请求，最后关闭连接。这能有效避免“惊群”和请求丢失。
4.3 反向代理与网关拓扑
反向代理和 API 网关是部署拓扑中更上层的抽象。它们不仅做流量分发，还承担 协议转换、安全防护、流量治理、请求聚合 等职责。网关拓扑通常位于 LB 之后、服务集群之前，形成多层代理结构。
4.3.1 反向代理 vs 网关：职责边界
| 维度 | 反向代理（如 Nginx / HAProxy） | API 网关（如 Kong / APISIX / Envoy） |
|---|---|---|
| 核心职责 | 负载均衡、SSL 终止、静态资源缓存 | 路由、认证、限流、协议转换、请求/响应改写 |
| 协议支持 | HTTP/HTTPS、TCP、UDP | HTTP/HTTPS、gRPC、WebSocket、Dubbo 等 |
| 可编程性 | 静态配置为主，少量 Lua/JS 扩展 | 插件体系（Lua / Go / Wasm） |
| 数据面性能 | 极高（纯 C / 事件驱动） | 较高（但插件引入额外开销） |
| 配置动态性 | 需 reload 或少量动态 | 支持热更新、控制面与数据面分离 |
4.3.2 典型网关拓扑结构
现代微服务架构中，网关通常以 Sidecar 模式 或 独立部署模式 存在。下图展示了一个包含反向代理和网关的两层拓扑：
4.3.3 网关拓扑下的数据传输设计
- 请求路径： 客户端 → 反向代理（TLS 终止） → API 网关（路由/鉴权） → 后端服务。每一跳都可能修改请求头（如 X-Forwarded-For, X-Request-Id）。
- 协议转换： 网关常承担 HTTP ↔ gRPC 转换。例如外部客户端使用 HTTP/1.1 JSON，网关将其转换为 gRPC Protobuf 请求转发给后端。
- 超时与重试： 网关层必须设置合理的上游超时（如 5s），并谨慎启用重试（防止重试风暴）。
- 链路追踪： 网关是注入 Trace ID 的最佳位置。所有经过网关的请求应携带统一的分布式追踪上下文（如 W3C Trace Context）。
关键原则： 网关不应承担业务逻辑。它只做 横切关注点（Cross-cutting Concerns） 的集中处理。业务逻辑必须下沉到后端服务，否则网关会退化为“单体瓶颈”。
4.4 三种拓扑模式对比总结
| 维度 | 单机多进程 | 多机负载均衡 | 反向代理 + 网关 |
|---|---|---|---|
| 部署单元 | 同一主机多个进程 | 多台主机多个实例 | 多层代理 + 多实例 |
| IPC 延迟 | 0.1 – 1 ms | 1 – 5 ms（内网） | 2 – 10 ms（含代理处理） |
| 故障隔离 | 弱（共享内核） | 强（主机级隔离） | 强（多层冗余） |
| 运维复杂度 | 低 | 中 | 高 |
| 适用阶段 | 开发 / 边缘节点 | 生产水平扩展 | 微服务 / 多协议 / 安全管控 |