1. 课程导论：为什么需要模块边界拆分？
当企业将单体应用直接迁移到 Kubernetes 时，往往只是完成了“容器化打包”和“YAML 堆砌”，并未真正解决架构层面的耦合问题。这种“换壳不换芯”的做法，会在集群规模增长后暴露出一系列系统性痛点。
1.1 单体架构在 K8s 中的典型痛点
单体应用在 Kubernetes 中运行，本质上是用编排工具管理一个巨大的进程。下表对比了单体架构与微服务架构在 K8s 环境下的关键差异：
| 维度 | 单体架构在 K8s 中的表现 | 微服务架构在 K8s 中的表现 |
|---|---|---|
| 扩缩容粒度 | 必须整体扩缩，无法针对热点模块单独扩展 | 按服务维度独立扩缩，资源利用率高 |
| 故障隔离 | 一个模块 OOM 或死锁，导致整个 Pod 重启 | 故障被限制在单个服务内，不影响全局 |
| 发布频率 | 全量发布，一次变更影响所有功能 | 独立发布，每次只影响一个服务 |
| 资源规格 | 必须为最重模块配置资源，造成浪费 | 按需配置 CPU/内存，精细化管理 |
| 启动时间 | 大型单体启动可达数分钟，滚动更新慢 | 小服务秒级启动，更新速度快 |
关键指标： 某电商平台在单体迁移至 K8s 后，未做拆分，导致每次大促时整体扩容 3 倍资源，但实际只有订单和库存模块需要扩容。拆分后，资源消耗降低 40%，扩容时间从 8 分钟缩短至 45 秒。
1.2 配置管理面临的三大挑战
在 Kubernetes 中，配置管理不再是简单的“改配置文件重启”。单体架构的配置方式与云原生理念存在结构性冲突：
- 配置与代码强耦合：单体应用将数据库连接、第三方密钥、业务开关等配置硬编码在代码仓库中，每次环境变更都需要修改代码并重新构建镜像，违背了“不可变基础设施”原则。
- 环境差异扩散：开发、测试、预发、生产环境的配置散落在不同分支或部署脚本中，经常出现“测试环境正常，生产环境报错”的配置漂移问题。
- 动态更新能力缺失：K8s 原生 ConfigMap/Secret 更新后，Pod 不会自动热加载。业务模块需要额外开发监听逻辑或依赖 Sidecar 工具，否则只能通过滚动重启生效。
常见误区： 很多团队将 ConfigMap 当作“远程配置文件”直接挂载，却忽略了配置变更后的生效机制。在一次生产事故中，运维修改了 ConfigMap 中的限流阈值，但业务进程未监听变更，导致限流策略失效，引发雪崩。
1.3 模块边界拆分与配置管理的关联
模块边界拆分不仅仅是代码层面的解耦，更是配置边界的重新划分。下图展示了单体架构与拆分后架构在配置管理上的本质区别：
1.4 本课程的核心解决路径
本课程将围绕“边界拆分”与“配置管理”两条主线，提供一套可落地的实战方法论：
- 业务模块拆分原则：基于 DDD（领域驱动设计）的限界上下文识别，结合 K8s 资源模型（Deployment、Service、Ingress）进行服务粒度设计。
- 配置管理优化策略：从 ConfigMap/Secret 的规范化命名、环境隔离、版本管理，到动态热加载方案（Reloader、Sidecar 模式）的选型与实施。
- 持续演进机制：通过可观测性（Metrics、Tracing、Logging）验证拆分效果，建立配置变更的审计与回滚能力。