📚 课程目录第2章单体架构的发布拓扑

2. 单体架构的发布拓扑：单体应用的部署模型、优缺点分析、适合的场景与边界划分

单体架构（Monolithic Architecture）是软件系统最传统的组织方式。在 Go 后端实践中，早期项目或工具型服务常采用此模型。理解单体架构的发布拓扑，是掌握更复杂分布式拓扑的基础。

2.1 单体应用的部署模型

在单体架构中，所有功能模块（用户管理、订单处理、支付、通知等）被编译为同一个二进制文件或同一个容器镜像，部署在一组相同的服务器节点上。典型的部署拓扑如下：

  核心特征： 单一进程、单一部署单元、共享数据库实例、共享内存空间。

上图展示了典型的水平扩展模式：通过负载均衡器将流量分发到多个无状态单体实例，所有实例共享同一个数据库。这种模型在 Go 中通常对应一个 main.go 入口，编译为单一可执行文件。

2.2 优缺点分析

维度	优点	缺点
开发效率	单一代码仓库，IDE 支持好；Go 编译速度快，调试简单；跨模块调用无需 RPC/网络开销。	代码耦合度高，合并冲突频繁；大型项目编译时间增长；无法按模块独立迭代。
部署运维	单一部署单元，CI/CD 流程简单；只需管理一个进程；日志、监控集中。	任何模块变更都需全量部署；启动/重启时间长；无法按模块独立扩缩容。
性能	进程内调用，无网络延迟；共享缓存和连接池；Go 的 goroutine 可高效利用单进程资源。	资源隔离差：一个模块的 OOM 或死锁会拖垮整个进程；无法针对热点模块单独分配 CPU/内存。
团队协作	小团队（1-5 人）沟通成本低；新人上手快；统一技术栈。	大团队（10+ 人）交付互相阻塞；代码所有权模糊；回归测试范围大。
技术演进	技术栈统一，依赖管理简单；Go 标准库 + 少量第三方包即可。	难以局部引入新技术；数据库 Schema 变更影响所有模块；无法独立升级依赖。

Go 单体实践提示： 使用 internal 包划分模块边界，配合 wire 或 fx 做依赖注入，可以在单体内部保持一定的模块独立性，为后续拆分做准备。

2.3 适合的场景

单体架构并非“过时”的代名词。在以下场景中，单体架构是最优选择：

初创项目 / MVP 阶段： 快速验证业务逻辑，避免分布式带来的复杂度。Go 单体可在 2-4 周内完成从零到上线。
内部工具 / 管理后台： 用户量小（< 1000 QPS），功能稳定，团队 1-3 人。例如：公司内部的权限管理系统、定时任务调度器。
高一致性要求的核心服务： 金融交易、库存扣减等场景，单体的事务 ACID 保证远优于分布式事务。Go 的 database/sql + 本地事务即可满足。
边缘计算 / IoT 网关： 资源受限的设备上，单体二进制体积小（Go 可编译为 5-15MB），启动快，无外部依赖。
团队规模 ≤ 5 人： 沟通成本低，单体架构的简单性远大于其局限性。

2.4 边界划分：在单体内部做领域隔离

即使采用单体部署，代码层面的领域边界划分仍然至关重要。这是未来向微服务演进的前提。推荐使用 Go 的 internal 目录结构实现逻辑隔离：

myapp/
├── cmd/
│   └── server/
│       └── main.go          # 单体入口，组装依赖
├── internal/
│   ├── user/                # 用户领域
│   │   ├── handler.go       # HTTP handler
│   │   ├── service.go       # 业务逻辑
│   │   ├── repository.go    # 数据访问
│   │   └── model.go         # 领域模型
│   ├── order/               # 订单领域
│   │   ├── handler.go
│   │   ├── service.go
│   │   ├── repository.go
│   │   └── model.go
│   └── payment/             # 支付领域
│       ├── handler.go
│       ├── service.go
│       ├── repository.go
│       └── model.go
├── pkg/
│   └── middleware/          # 共享中间件
├── go.mod
└── go.sum

关键原则： 即使在同一单体中，领域之间也禁止直接访问对方的内部 model 或 repository。领域间通信应通过接口（interface）或领域事件（domain event）进行。这样，当未来需要将某个领域拆为独立微服务时，只需将接口实现替换为 gRPC 调用，而无需修改调用方代码。

2.5 单体架构的发布策略

单体应用的发布拓扑虽然简单，但仍有几种常见的部署策略：

策略	操作方式	Go 实践	适用场景
滚动更新	逐个替换旧实例为新版本，保持服务不中断。	K8s Deployment 默认策略；Go 二进制热替换需处理信号（SIGTERM）优雅关闭。	生产环境标准发布，无重大 Schema 变更。
蓝绿部署	维护两套完整环境，切换流量至新环境。	Go 单体编译后直接部署到新环境；数据库需兼容双版本 Schema。	需要快速回滚的场景；大版本升级。
金丝雀发布	先让少量流量进入新版本，验证后再全量。	通过 LB 权重控制；Go 的 `expvar` 或 Prometheus 指标用于监控错误率。	高风险变更；新功能灰度验证。

  Go 单体发布最佳实践：
  使用 go build -ldflags="-s -w" 减小二进制体积，加速部署。
在 main.go 中注册 /healthz 和 /readyz 端点，配合 K8s 探针。
数据库迁移（migration）与应用发布解耦：先执行迁移，再发布新版本二进制。
使用 net/http 的 Shutdown() 方法实现优雅关闭，确保正在处理的请求完成。

2.6 何时应该考虑拆分？

单体架构并非永远适用。当出现以下信号时，应考虑向微服务架构演进：

部署频率瓶颈： 每周一次全量部署已无法满足业务需求，不同模块需要独立发布节奏。
团队规模增长： 超过 10 人协作同一代码库，合并冲突和回归测试成本急剧上升。
资源隔离需求： 某个模块（如报表导出）消耗大量 CPU/内存，影响其他模块的响应时间。
技术栈分化： 部分模块需要引入 Go 之外的语言或框架（如 Python 做 AI 推理）。
数据库瓶颈： 单一数据库实例无法承受所有模块的读写负载，需要按领域拆分数据库。

Go 单体拆分的推荐路径： 先按 internal 领域包拆分代码 → 提取领域接口 → 将接口实现改为 gRPC 客户端 → 将领域独立为单独的服务进程。每一步都保持向后兼容，避免“大爆炸式”重构。