📚 课程目录第1章发布拓扑基础

1. 发布拓扑基础

发布拓扑（Deployment Topology）是描述软件系统在发布过程中，各组件、节点、服务及其依赖关系的结构化蓝图。它定义了“什么服务部署在哪里、如何连接、依赖什么”，是发布与回滚操作的基础地图。

在 Go 后端微服务架构中，发布拓扑通常包含多个服务实例、网关、数据库、缓存、消息队列等组件，以及它们之间的网络通信路径。没有清晰的发布拓扑，回滚操作极易引发级联故障。

核心认知： 发布拓扑 ≠ 系统架构图。系统架构图描述“理想状态”，发布拓扑描述“当前发布状态 + 可回滚状态”。每次发布都会产生一个新的拓扑快照。

发布拓扑由三个基本要素构成：节点、服务、依赖。三者缺一不可，共同决定发布与回滚的可行性。

要素	定义	Go 后端示例	回滚影响
节点	运行服务的物理或虚拟计算单元	Kubernetes Pod、ECS 实例、裸金属服务器	节点故障导致服务不可用，需先恢复节点再回滚
服务	提供特定业务能力的进程/容器	user-service、order-service、gateway	服务版本回退需考虑 API 兼容性
依赖	服务间的调用关系或资源绑定	gRPC 调用、Redis 连接、MySQL 读写	依赖链断裂导致级联回滚

系统架构定义了“组件如何组织”，发布拓扑定义了“组件如何发布与回滚”。两者是设计态与运行态的关系。

  实战经验： 在 Go 后端项目中，我们使用 topology.yaml 文件管理发布拓扑快照，每次 CI/CD 构建自动生成。回滚时只需执行 rollback --snapshot v1.2.3，系统自动恢复拓扑状态。

下图展示了一个典型的 Go 后端微服务发布拓扑，包含网关、业务服务、基础组件和外部依赖。箭头表示服务间的调用依赖关系。

每次发布生成一个拓扑快照，包含以下关键信息。回滚时直接恢复上一个快照的拓扑状态。

回滚陷阱： 如果 v1.2.0 新增了 Kafka 依赖，回滚到 v1.1.0 时必须先清理 Kafka 中的未消费消息，否则会导致数据不一致。发布拓扑必须记录“新增依赖”的清理步骤。

下表总结了不同架构风格下，发布拓扑的特点与回滚策略差异。

架构风格	拓扑节点数	依赖复杂度	回滚粒度	Go 后端典型场景
单体架构	1~3	低	全量回滚	早期 Go 单体应用
微服务架构	10~100+	高	单服务 / 依赖链	Go 微服务 + gRPC
服务网格	20~200+	极高	流量灰度回滚	Go + Istio / Envoy
无服务器架构	动态	中	函数版本回滚	Go + AWS Lambda

发布拓扑的版本化是回滚的基础。每个拓扑快照包含完整的节点、服务、依赖信息，形成一条可追溯的发布链。回滚时，系统根据拓扑快照自动计算回滚路径。