从单体到云原生：一次微服务容器化改造的落地复盘

一、为什么做容器化改造

单体应用在业务早期效率很高，但当发布频率上升、团队规模扩大后，问题会集中暴露：一次发布影响全站、环境不一致导致"本地能跑线上不行"、扩容只能整机复制、回滚依赖手工操作。容器化改造的目标不是"为了微服务而微服务"，而是让构建、发布、扩缩容、回滚这四件事变得可预期。

二、改造节奏：先容器化，再拆分

常见的错误是一上来就按业务拆成十几个微服务，结果治理成本陡增。更稳的路径是两阶段：

1. 先容器化单体：把应用打成镜像，统一"构建产物 = 镜像"的交付物，打通 CI/CD、日志与监控。此阶段不改业务架构，风险最低。
2. 再按边界拆分：识别变更频率高、资源占用差异大的模块（如报表、消息推送），优先拆出为独立服务，其余仍留在单体里。

三、容器化的关键落地项

1. 镜像：小、可复现、非 root

• 用多阶段构建，运行时镜像只放必要产物与依赖，避免把构建工具带进生产镜像；
• 固定基础镜像版本，避免"今天的构建和上周不一样"；
• 以非 root 用户运行，减小攻击面。

2. 配置与密钥外置

不要把数据库口令、第三方密钥打进镜像。用 ConfigMap 管理普通配置、Secret 管理敏感信息，镜像本身做到"环境无关"。

3. 健康检查与优雅退出

就绪探针（readiness）让流量只在实例真正可用时才进入；存活探针（liveness）用于剔除僵死实例。应用要正确处理 SIGTERM，在退出前停止接收新请求并把在途请求处理完，否则滚动发布时会出现零星 502。

4. 资源请求与限制

明确 requests/limits，避免"没有 requests 导致调度不均衡，没有 limits 导致单实例吃满节点"两类典型问题。

四、上线前必须想清楚的两件事

可观测性

容器里的进程会漂移，日志必须集中采集；同时保留关键指标（QPS、延迟、错误率）与链路追踪。没有可观测性的微服务，排障成本会指数级上升。

回滚策略

发布采用滚动或灰度，保证任意时刻都有可用副本；并确保"回滚 = 切回上一个镜像版本"这样简单可靠，而不是靠重新构建。

五、避坑清单

• 不要用镜像 tag latest 部署，用不可变版本号；
• 不要把状态放在容器本地磁盘，无状态化后再谈弹性伸缩；
• 数据库连接池要按"实例数 × 单实例连接数"重新评估，避免扩容后打满数据库连接；
• 拆分服务时先定义清晰接口，再谈部署，接口契约是拆分的真正边界。

六、小结

微服务不是目标，可持续的交付节奏才是。先把单体容器化并跑顺 CI/CD 与可观测性，再按业务边界小步拆分，才能把改造的收益真正兑现，而不是把单体的问题变成分布式的问题。