企业官网建设流程全解析

1. 从一次环境事故说起：我为什么开始研究架构演进

事情发生在一个周五晚上，某公司的核心应用要上线一个新版本，代码在测试环境跑得好好的，结果一到生产环境就翻车。数据库驱动版本不对、操作系统底层库缺失、JDK小版本有差异，三个人排查了两个小时，最后发现是环境不一致导致的问题。

这次事故的直接后果是上线推迟到凌晨三点，间接后果是我开始认真思考一个问题：我们天天说技术架构演进，到底演进的是什么？如果连一个运行环境都没法保证一致性，那架构再花哨又有什么用？

后来我花了大半年时间，完整走了一遍从传统部署到容器化的过程，也在多个项目里实际落地了Docker相关的改造。回头看，整个技术架构演进之路，本质上就是一条不断解决"环境不可控、交付低效、资源浪费、扩展困难"这些痛点的路。而Docker之所以能在众多技术中脱颖而出，正是因为它精准地踩中了这些痛点。

这篇文章是我Docker系列的第一篇，我会先把架构演进的整体脉络讲清楚，说透每个阶段的核心问题和技术选型逻辑，然后重点拆解Docker到底解决了什么、它是怎么做到的、实操中又会遇到哪些坑。适合正在做架构升级或者刚接触容器化开发的读者参考。

2. 技术架构演进的四个阶段：每一代都在解决上一代的遗留问题

2.1 单体架构：最朴素但天花板最低的形态

单体架构是绝大多数项目的起点。一个应用就是一个完整的部署单元，前端页面、业务逻辑、数据访问层全打在一个包里，部署到一台服务器上就能跑。

这种架构的优点是显而易见的：开发简单，一个工程一个团队甚至几个人就能维护；部署简单，一个包拷到服务器上启动就行；排查问题也简单，日志都在一起，链路清晰。

但它的天花板也很明显。当业务规模上来之后，几个问题会同时爆发。

第一个问题是团队协作效率急剧下降。代码全部放在一个仓库里，多个团队同时开发，每天光合并代码就要花大量时间，稍有不慎就冲突。我见过一个老项目，一个版本迭代需要两周，其中一周都在处理代码合并和回归测试。

第二个问题是资源利用不均衡。单体应用里有的模块是CPU密集型的，有的是IO密集型的，但它们必须放在同一个进程里运行。扩容只能整台机器地扩，要么所有模块一起上，要么一起在那干等，没法按需分配资源。

第三个问题是故障隔离几乎不存在。一个模块内存泄漏，整个进程挂掉，所有业务全部不可用。更麻烦的是，有些问题只在特定流量下才会暴露，你在测试环境根本复现不了。

单体架构不是说不能用，而是它有明确的适用边界。项目规模小、团队人数少、业务逻辑耦合度高的时候，单体架构反而是最高效的选择。强行拆微服务只会把简单问题复杂化。

2.2 垂直拆分：第一轮"物理隔离"的尝试

当单体架构撑不住的时候，最常见的演进方向是垂直拆分。按业务模块把应用拆成几个独立的服务，比如用户服务、订单服务、支付服务，每个服务独立部署、独立维护、独立扩容。

垂直拆分解决了一部分问题：团队之间不再需要频繁合并代码，每个团队维护自己的服务；故障隔离也好了一些，订单服务挂了，用户服务还能继续跑。

但垂直拆分本质上还是一种"物理隔离"，它只是把问题切成小块，并没有改变部署和交付的模式。每个服务依然跑在自己的机器上，依然需要通过手工或者简单的脚本去部署，依然存在环境不一致的问题。我经历过一个项目，拆成了五个服务，结果每台机器上的环境都略有差异，部署脚本越写越复杂，最后变成了一个谁都不敢动的巨型Shell脚本。

而且垂直拆分还会引入新的问题，比如服务间通信。原来单体架构内部可以直接调用方法，拆开之后就要走网络通信，需要考虑超时、重试、序列化这些以前不需要碰的东西。有些团队在这个阶段会用一些轻量级的HTTP框架来解决，但通信稳定性和数据一致性又成了新的难题。

垂直拆分是架构演进路上几乎必经的一步，但它更多是管理维度的优化，技术维度的深层问题并没有被触及。

2.3 微服务与分布式：把复杂度从代码层转移到基础设施层

微服务架构是在垂直拆分基础上更进一步的设计思想：服务按照业务能力边界划分，每个服务可以独立开发、独立部署、独立扩展，服务之间通过轻量级的通信机制协作。

微服务架构带来的好处是实打实的：单个服务可以按需扩容，比如双十一期间订单服务压力大，可以给订单服务多扩几个实例；故障隔离更细粒度，一个服务出问题不会拖垮整个系统；团队自治程度更高，每个团队对自己服务的全生命周期负责。

但代价同样巨大。服务数量从几个变成几十个甚至上百个之后，原来单体架构下不需要考虑的分布式问题全部冒出来了：服务发现怎么做、负载均衡怎么做、配置怎么管理、日志怎么聚合、链路怎么追踪、分布式事务怎么处理。

也就是说，微服务架构把复杂度从代码层转移到了基础设施层。以前是写代码的人头疼，现在是维护基础设施的人头疼。这时候，如果部署方式还是老一套——每台机器手动配置环境，每个服务手动启动、手动维护进程——那运维成本会呈指数级上升。

我记得当时在某公司做微服务拆分的过程中，最痛的不是写代码，而是管理那些服务的部署。几十个服务，每个服务要配环境变量、要配数据库连接、要配日志目录，稍有不慎就部署错版本。有一个服务因为环境变量配错了，线上跑了整整三天才被发现，而回滚又因为环境不一致折腾了大半夜。

2.4 容器化：把"环境"本身变成可交付的资产

容器化的出现，解决的恰恰是微服务架构落地过程中最棘手的问题：如何让一套代码在任何环境中都能以完全相同的方式运行。

在容器化之前，环境一致性靠的是人，靠的是文档，靠的是运维同学的经验。但人总会出错，文档总会过时，经验总有盲区。容器化的思路是把运行环境连同应用一起打包成一个标准化的镜像，这个镜像在任何安装了容器引擎的机器上都能以完全相同的方式启动。

这意味着什么？意味着环境从"每台机器各不相同"变成了"每台机器可以运行完全相同的容器"。开发同学在本机用容器跑起来是什么样，测试环境、生产环境就是什么样。以前那些"在我机器上是好的啊"的问题，从根本上被消灭了。

容器化的另一个核心价值是资源利用效率的提升。传统部署方式下，一台机器上部署一个应用，这个应用可能只占用了机器10%的资源，剩下的90%都浪费了。通过容器，我们可以在一台机器上运行多个互相隔离的应用实例，把资源利用率拉高好几倍。

Docker作为容器化技术的代表，不是凭空出现的。它建立在Linux内核的namespace和cgroup机制之上，这些内核特性从Linux很早期版本就开始演进了。Docker真正做的是把这些底层的、面向内核开发者的能力封装成了面向普通开发者的工具，让"打包应用及依赖"变成一条简单的命令。

3. Docker登上舞台的底层逻辑：环境一致性带来的交付范式改变

3.1 镜像、容器、仓库：三个概念串起交付全链路

理解Docker，首先要把三个核心概念搞清楚：镜像、容器、仓库。

镜像（Image）是一个只读的模板，里面包含了应用代码、运行时环境、依赖库、配置文件等所有运行所需的东西。可以把镜像理解成"制作披萨的模具"，模具定了，做出来的披萨就是一样的。

容器（Container）是镜像运行时的实例，可以理解成"用模具压出来的那块披萨"。一个镜像可以同时运行多个容器，每个容器之间互相隔离，互不影响。

仓库（Registry）是存储和管理镜像的地方，类似代码的Git仓库。开发同学把镜像推送到仓库，部署时从仓库拉取镜像，这样"构建一次、到处运行"才能真正实现。

这三个概念串起来的链路就是：开发->构建镜像->推送仓库->拉取镜像->运行容器。对比传统部署方式，最核心的差异是：环境配置从"部署时的手工操作"变成了"构建时的一部分"。以前部署一个应用，要先安装JDK、配置环境变量、装数据库驱动、拉依赖包，这些步骤每台机器都要重复一遍；现在这些全部打进镜像里，拉下来直接就能跑。

3.2 Docker没有发明容器，但重新定义了容器的使用方式

很多人第一次接触Docker时会有个误区，觉得Docker是新技术，是某家公司发明的。实际上，容器技术本身已经有几十年历史了，Linux上的chroot、namespace、cgroup这些机制都是Docker存在之前就有的。

Docker真正的贡献在于产品化和工程化。它做了三件以前没人做好的事：一是提供了一套简洁的API和命令行工具，让开发者不需要理解内核细节就能使用容器；二是定义了镜像的标准格式和构建方式，让"打包应用及环境"变成一件标准化的事情；三是构建了镜像分发体系，通过Docker Hub这类仓库让镜像的存储和流转变得和代码一样方便。

我常用一个比喻来解释Docker的价值：如果说容器技术是发动机，那Docker就是一辆完整的汽车。发动机本身早就有了，但Docker造出了方向盘、油门、刹车，还修了公路，让普通人也能开着上路。

3.3 容器与虚拟机的本质区别：共享内核与边界隔离

在选型容器方案时，几乎绕不开一个比较：容器和虚拟机到底有什么不同？为什么有了虚拟机，还需要容器？

虚拟机是通过Hypervisor虚拟化出来的完整操作系统，每个虚拟机里都有自己的内核、系统库和用户态进程。它的隔离性非常好，但代价是要为每个虚拟机单独维护一个操作系统，资源开销很高。

容器则不一样。容器和宿主机共享同一个内核，通过namespace做资源隔离，通过cgroup做资源限制。容器的启动实际上只是启动一个进程，只不过这个进程视角里的"操作系统"是完整的。所以容器的启动速度是毫秒级的，虚拟机则是秒级甚至分钟级。

用一个表格来看会更直观：

但"共享内核"这个特点也带来了限制：容器的隔离性不如虚拟机，尤其是内核级别的安全隔离。如果一个容器里的恶意代码利用内核漏洞逃逸出来，理论上可以影响到宿主机上的其他容器。所以在安全要求很高的场景下，依然需要在虚拟机里跑容器，做双重隔离。

3.4 技术选型的关键判断：什么项目适合容器化

不是所有项目都适合立刻容器化。我在实际工作中总结了几条判断标准，供大家参考。

首先要看应用的可移植性。如果你的应用强依赖某个特定版本的底层库，或者应用本身和操作系统耦合很深，那容器化的改造成本会比较大。反过来，如果你的应用是标准的Java、Python、Node.js服务，那容器化的收益非常明显。

其次要看团队的技术储备。容器化不只是引入Docker这一个工具，还牵涉镜像构建、仓库管理、编排调度、监控日志等一系列配套能力。如果团队没有余力做这些，过早容器化反而会变成负担。

最后要看业务的真实需求。如果业务规模还在早期，一台服务器就能跑完，那单体架构加传统部署完全够用，没必要为了"先进"而先进。架构演进不是赶时髦，而是解决实际问题。

4. Docker核心原理拆解：一条docker run背后发生了什么

4.1 Linux内核三件套：namespace、cgroup、UnionFS

Docker能实现"轻量级隔离"和"镜像分层构建"，靠的是Linux内核的三个核心机制。不搞懂这三个机制，你对Docker的理解就永远停留在会用不理解的层面。

第一个是namespace。它的作用是让容器里的进程只能看到自己所在的那个"视角"里的资源。比如PID namespace让容器里的进程认为自己是PID 1，但实际上它在宿主机上是其他PID；Network namespace让容器拥有自己独立的网络栈、IP地址和端口空间。每一个容器都是一个独立的"世界"，这就是通过namespace实现的。

第二个是cgroup（Control Groups）。namespace负责让容器"看到"隔离的资源，cgroup负责限制容器"使用"多少资源。你可以通过cgroup限制一个容器最多使用多少CPU、多少内存、多少个IO操作。没有cgroup，一个容器就能把宿主机的资源全部耗尽，其他容器就会跟着遭殃。

第三个是UnionFS（联合文件系统）。这是Docker镜像分层实现的技术基础。简单来说，UnionFS可以把多个只读层叠加在一起，对外呈现一个统一的文件系统视图。Docker镜像的每一层都是一个只读层，多个层叠加后就形成了一个完整的根文件系统。当容器运行时，会在这些只读层之上再挂载一个可写层，容器对文件的修改都发生在这一层。

4.2 镜像分层：为什么pull一个镜像会看到"分层下载"

用过Docker的应该都有印象，docker pull的时候会显示"Pulling layer"的进度条，很多层在同时下载。这就是镜像分层的实际表现。

分层的设计带来了两个巨大的好处。

第一个好处是存储复用。如果两个镜像基于同一个基础镜像构建，那这两个镜像可以共享底层的那些层，不需要重复存储。一台机器上拉取了十个基于同一个基础镜像的应用镜像，底层那几层只需要存一份就够了，节省大量磁盘空间。

第二个好处是传输高效。升级应用版本的时候，只需要下载更新了的那些层，没有变化的层可以直接复用本地已有的。我实际遇到过的情况是，一个基础镜像原来的版本是200MB，新版本只是改了业务代码，需要下载的只有几十MB，按秒就能拉完。

但如果分层使用不当，也会踩坑。比如有些开发同学把所有依赖都塞进一个层里，那这个层就会特别大，每次改动都会重新传输。正确的做法是充分利用镜像缓存：把变化频率低的内容放在底层先构建，把变化频繁的业务代码放在高层后构建。这样业务代码改了，底层的那些层不用重新构建，能大幅缩短构建时间和上传下载时间。

4.3 Dockerfile最佳实践：从踩坑到相对规范

写Dockerfile看起来简单，实际上有很多细节。我把自己实践过程中的几条核心经验分享出来。

基础镜像一定要挑选合适的。有些同学习惯用latest标签，这是最典型的坑。latest会随着上游更新而变化，你今天build的镜像和明天build的镜像，底层可能是不同的操作系统版本，这个不稳定性会影响复现。正确做法是固定到具体版本，比如基础镜像加具体的标签。

每一条指令会生成一个镜像层，所以要把可以合并的指令合并起来。比如在CentOS里用yum安装多个软件包时，能合并成一条RUN指令就合并成一条，这样能减少镜像层数，缩小镜像体积。但也不是所有指令都要强行合并，需要平衡构建缓存利用和镜像体积之间的关系。

还有一个经常被忽视的点是容器中进程的PID 1问题。容器里PID 1的进程是容器的"根进程"，它的退出意味着整个容器结束。如果PID 1进程没有正确处理信号，比如没有转发SIGTERM给子进程，那docker stop的时候容器可能不能优雅退出。实际项目中我遇到过好多次这个问题，最后通过使用tini这类init进程作为PID 1来解决。

4.4 数据持久化的三条路径：volume、bind mount、tmpfs

容器默认情况下是"无状态"的，容器被删除后，容器内产生的数据也会一起消失。对于需要持久化保存数据的场景，必须使用Docker的数据管理机制来"保存"数据。

Docker提供了三种数据持久化的方式：volume、bind mount和tmpfs。实际用得最多的是前两种。

volume是Docker自己管理的存储空间，数据存放在Docker的安装目录下。推荐使用volume，因为它用起来最简单，跨主机迁移时也更方便。现在很多场景包括数据库这类有状态服务，都会建议使用volume来保存数据。

bind mount是把宿主机的一个目录挂载到容器里。这种方式的好处是可以直接修改宿主机上的文件，方便开发调试。但在生产环境用bind mount要慎重，因为这会让容器和宿主机的文件系统耦合在一起，容器在不同机器上运行时，宿主机目录的路径必须保持相同。

tmpfs是一个临时的内存文件系统，数据只存在于内存中，容器停止后数据就没了。这个一般用来存储一些敏感信息，比如密钥文件，确保数据不会写入磁盘。

关于数据持久化，我强烈建议在规划阶段就明确哪些数据需要持久化，而不是等容器跑起来之后再去补充。容器做无状态化改造之后，扩容缩容、故障迁移都会变得非常方便。

5. 实操复盘：某交易系统容器化改造的一次完整落地

5.1 改造前的问题清单与目标定义

我在某个项目里实际经历了一次比较有代表性的容器化改造。系统是一个交易类的核心服务，部署在物理机上，每次发布都是同学的噩梦。

改造前我们梳理了主要问题：

部署流程完全是手工的。发版同学要登录每台机器，拉代码、编译、停服务、替换包、启动服务，这些步骤都要手动执行，一台机器要花十几分钟，六台机器就是半个多小时。

环境不一致问题反复出现。因为每台机器的系统库版本、JDK环境、应用配置都有细微差异，同一个版本在这个环境是好的，在另一个环境就报错。

资源利用率极低。六台物理机，每台只跑一个服务实例，正常负载都不到10%，但为了高可用又不得不多搞几台机器。

改造前我们定了三个目标：一是部署流程规范化、标准化，从手工变成命令式；二是实现多环境状态一致；三是提升资源利用率。

5.2 分批改造的三阶段节奏

整个改造我们分了三批走，这个节奏非常关键，实际效果比我们预期顺利得多。

第一批是技术改造验证。先选一个非核心服务，编写Dockerfile，构建镜像，在容器里运行，验证功能是否正常。这一步的目标不是规模化，而是让团队熟悉Docker的操作方式和排查问题的基本方法。

第二批是核心服务改造。把交易服务的部署方式改为容器化部署，同时配套上了通过docker-compose管理服务、通过私有仓库管理镜像。这个阶段开始碰到一些真实环境下的问题，比如网络配置、日志收集、健康检查。

第三批是全量推广和优化。所有服务完成了容器化改造后，我们把重点放在性能调优和稳定性建设上，包括镜像瘦身、启动加速、核心服务的容器编排。

5.3 一份可复用的Dockerfile示例与关键参数解读

以我们的一个Java交易服务为例，改造后的Dockerfile核心内容大概是这样：

FROM eclipse-temurin:8-jre MAINTAINER devops@example ENV APP_HOME=/opt/app ENV JAVA_OPTS="-Xms512m -Xmx512m -Djava.security.egd=file:/dev/./urandom" WORKDIR $APP_HOME COPY target/mall-trade-service.jar app.jar EXPOSE 8080 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

这个Dockerfile里我重点解释几个关键参数的意图。

FROM指定的是Eclipse Temurin的JDK 8 JRE镜像。这里不用完整的JDK镜像而用JRE镜像，是一个明显的瘦身选择。我们的服务运行时只需要执行Java字节码，不需要编译代码，用JRE体积能小很多。选择eclipse-temurin是因为这个项目有较好的社区维护和更新记录，并且在多平台上有较好的支持。

ENV里设置JAVA_OPTS，是把JVM参数通过环境变量预设好。在容器环境里显式指定堆内存大小很重要，如果任由JVM自动计算，它往往会把宿主机总内存当成可用内存来设置，一台大内存的宿主机上部署多个容器时就会出现内存竞争。这里固定成512MB，可以让每个容器都根据自己的限额来使用内存。

EXPOSE 8080是一条声明，它并不会真的发布端口，只是告诉使用这个镜像的人，这个应用默认监听的是8080端口。真正发布端口需要在运行容器时通过-p参数指定，或者使用网络驱动来映射。

ENTRYPOINT决定了容器的启动命令。用sh -c包一层，目的是让JVM进程成为容器的PID 1，并且让JVM能够正确接收信号。如果不加sh，Java进程的启动方式可能会有二义性，信号接收也会有问题。

5.4 三个最容易被忽略的配置细节

容器化改造过程中，有三个细节特别容易被忽略，但影响非常大。

第一个是时区问题。官方很多基础镜像默认使用UTC时区，业务代码打印日志、定时任务执行时用的都是UTC时间，和业务本地时间差了八个小时。我们第一次上线后排查一个定时任务异常，最后发现是时区配置缺失。解决办法是在Dockerfile里设置时区，或者启动容器时通过环境变量指定TZ。

第二个是JVM参数与容器资源限额的配合。如果宿主机有32GB内存，JVM启动时默认会认为可用内存是32GB，哪怕你通过docker run限制了这个容器只能用1GB。这种情况下，JVM会频繁触发垃圾回收甚至内存溢出。现在的JDK版本已经能自动感知cgroup限制，但如果是老版本JDK，还是需要手动通过JAVA_OPTS明确指定堆内存大小。

第三个是日志输出策略。很多开发同学习惯让应用把日志写到目录文件里，方便检索。但容器里文件日志有一个问题：容器被删除时日志也会跟着丢失，而且在多副本的场景下，日志分散在各个容器中，排查问题时的体验会不太好。正确的做法是让应用把日志写到标准输出，由Docker统一收集，再通过日志采集组件汇聚到集中日志平台。

5.5 改造后的效果：一组值得参考的数据

改造完成后的效果非常直观，这里给出我们实际记录的一组数据作为参考。

改造前六台物理机跑六个服务实例，CPU平均利用率大约7%，内存平均利用率大约15%。改造后我们把服务数量扩充到了十六个实例，只用了三台物理机，CPU平均利用率到了25%左右，内存平均利用率到了40%左右。同样规模的业务量，资源使用量反而下降了，服务实例数还多了近两倍，可用性提升了至少一个量级。

发布效率的提升更明显。改造前一次发版需要提前一小时准备，发版过程中要人工操作多台机器，时间不可控，经常出现一台机器成功、一台机器失败的情况。改造后通过容器化部署，一次发版只需要执行的流程就是构建新版本镜像、推送镜像、滚动更新容器，整个过程可以做到分钟级完成，而且所有实例的部署结果是一致的。

团队协作方式也在这次改造后发生了变化。开发同学可以在本机直接用容器跑整套环境，不需要再等运维同学搭环境；测试环境、预生产环境、生产环境的运行环境保持一致，很多环境和配置相关的问题，在开发阶段就能提前暴露和解决。

6. 从Docker到容器编排：为什么单机Docker只是起点

6.1 单机Docker解决了部署，但还没解决调度

Docker解决了"怎么跑"，但没有解决"跑在哪、跑多少个、挂了怎么办"。当服务数量到达几十个以上时，单机Docker就暴露出了明显的局限。

首先是调度问题。服务A适合跑在高性能机器的CPU上，服务B需要大内存，服务C要保持和数据库同机部署，这些调度逻辑单机Docker解决不了，需要人工判断并分配合适的机器。

其次是高可用问题。单机模式下，宿主机挂了，上面跑的所有容器就都挂了，需要人工去其他机器上重新启动。对于核心服务来说，这个恢复时间是不可接受的。

再次是扩展性问题。流量上涨时，你需要为某个服务增加实例数，手动操作还可以，但如果需要根据负载自动扩缩容，单机Docker完全无能为力。

容器编排平台解决的就是这些问题。以实际生产中使用最广泛的Kubernetes为代表，它提供了服务发现、负载均衡、自动扩缩容、故障自愈、滚动发布等一系列能力。Docker和容器编排是配套关系：Docker负责打包和运行，容器编排平台负责大规模管理和自动化运维。

6.2 Docker Compose：单机编排的正确打开方式

在引入完整的容器编排平台之前，docker-compose是一个非常合适的中间步骤。它用声明式的YAML文件来定义一组服务之间的关联关系、依赖关系、网络配置、资源限制等，一条命令就能把整个服务栈启动起来。

我们在那个交易系统改造的初期就是用docker-compose来管理核心服务栈的。一个compose文件里定义了服务、数据库、缓存、消息中间件等，本地开发环境、测试环境、CI环境共用同一个文件，最终做到的是环境的一致性可以高度复现。

docker-compose的使用约束在于它只适用于单台宿主机，无法跨多台机器调度。但它作为学习和小规模部署的工具，投入产出比非常高。

6.3 服务编排平台的下一步：Kubernetes登场

当服务规模从十几个扩展到几十个上百个时，下一步基本就是Kubernetes了。

Kubernetes的核心思想是把一组服务器抽象成一个资源池，通过调度器把容器合适地分配到这些机器上。它通过声明式的方式表达期望状态：比如"这个服务要跑3个副本"，平台会自动保证实际状态与期望状态一致，某个副本挂了就自动拉起一个新的。

在容器编排方案选型时，不少人会把Kubernetes和Docker Swarm做对比。从技术成熟度和生态丰富度来看，Kubernetes已经占据了绝对优势。现在新启动的项目，几乎不会再去考虑其他编排方案。但对于个人学习或者小团队小规模场景，直接从Docker跳到Kubernetes也可能过度设计，docker-compose仍然是一个轻量级的合适选择。

6.4 从Docker到Kubernetes的路线图与经验建议

从Docker到Kubernetes的演进，我的建议是分三步走，不要一步跨过去。

第一阶段是把Docker本身的实践做扎实，包括镜像构建规范、数据持久化方案、日志收集方式、网络模型理解。这一阶段的目标是让团队对容器化部署有肌肉记忆。

第二阶段是引入docker-compose做单机编排，同时把CI/CD流程跑通。代码提交后自动构建镜像、自动推送到镜像仓库、自动在测试环境更新服务，这些自动化能力在编排阶段能省下大量人工操作。

第三阶段才是引入Kubernetes。这个阶段的重点不是把docker-compose配置翻译成Kubernetes的YAML，而是重新理解以Kubernetes为平台的应用部署范式：Pod和Service的关系、配置中心与密钥管理、存储卷和持久化方案、灰度发布和流量切换机制。这些概念在docker-compose里没有对应的东西，需要在新的概念框架里重新梳理。

我在实践中的体会是：从Docker到Kubernetes最难的转换不是技术学习，而是思维方式的转换。docker-compose解决的是"一个服务栈"的问题，Kubernetes解决的是"一个服务网格"的问题，两者对服务的粒度、配置的方式、故障处理的视角都完全不同。

7. 容器化实践中的避坑清单与经验沉淀

7.1 镜像构建常用的排查和优化技巧

镜像体积是容器化后第一个要关注的问题。镜像体积过大，会拖慢构建、上传、拉取、启动的全链路。

我常用的排查手法是先看每一层的大小：

docker history <镜像名>

如果发现某一层特别大，就可以定位是哪一条指令、哪个操作引入的。最常见的镜像体积超标原因：一是使用了大而全的基础镜像，比如用带构建工具链的镜像跑线上服务；二是在同一层内复制了大量不需要的文件进来；三是包管理工具留下了缓存没有清理。

镜像瘦身方面，几个方向按优先级排列：换更精简的基础镜像；清理软件包安装缓存；合并RUN指令减少层数；使用多阶段构建，在构建阶段保留编译工具链，在运行阶段只保留运行库。多阶段构建尤其适合Java、Go、Node.js这类有编译或安装步骤的应用，构建产物只需要拷贝到一个小的基础镜像里即可。

7.2 容器运行时常见的排障思路

容器服务"启动失败"是新手的常见困境。我建议按照固定顺序排查。

第一步先看容器状态和启动日志。docker logs可以拿到应用自身的标准输出来，大部分启动失败的问题在日志里就能看到原因，比如端口被占用、配置读取失败、依赖服务连不上。

第二步检查镜像构建的内容是否正确。进到容器里看一下实际运行环境，通过docker exec进容器执行一些排查命令，确认文件确实是拷进去了、启动命令确实能手动执行。

第三步看宿主机的资源情况。有些容器启动失败不是应用本身的问题，而是宿主机内存不足、磁盘空间耗尽导致的。用docker stats可以看到容器的实时资源占用情况。

还有一个容易被忽略的坑是容器内的DNS配置。容器默认使用Docker内置的DNS配置，如果宿主机网络环境比较特殊，比如通过代理访问外网、或者内网有独立的DNS服务，容器内可能无法正确解析域名。这种问题排查起来比较隐蔽，日志上没有明确报错，只是请求不通，需要重点检查网络配置。

7.3 安全基线：容器化不是自动等于安全

容器化带来的便利很容易让人放松对安全的警惕。有几点安全实践我建议每个团队都要落实。

基础镜像要定期更新，最好通过自动化方式扫描镜像中的已知漏洞。镜像仓库里堆了很多年前的旧镜像，这种场景很常见。这些旧镜像可能包含已被修复的漏洞版本组件，再被拉取到时风险非常大。

容器运行时的权限要最小化。不要默认以root身份运行容器，尤其是面向外网的服务，更应该在镜像里创建一个低权限用户，并用这个用户来跑应用进程。Dockerfile里可以用USER指令指定运行用户。

私有镜像仓库的访问权限也要控制。镜像里往往包含应用代码、配置文件甚至一些敏感信息，如果仓库权限配置不当导致镜像泄露，等于把应用的核心信息直接暴露给了攻击者。我见过一些小型团队把私有镜像直接推到公共仓库，这是一个需要严格避免的失误。

7.4 关于推进容器化改造的团队协作经验

最后说点和技术无关但很重要的经验。

容器化改造如果只是运维或者某个开发同学自己推进，大概率会失败。因为改造涉及研发流程、交付方式、排查手段的整体变化，需要开发、测试、运维三方都愿意配合。我在某公司的经验是，先从某个痛点最明显的服务做起，用实际的效率提升来赢得团队信任，再逐步扩大范围，比自上而下一刀切要顺利得多。

团队的学习曲线也要考虑。Docker本身不难，但配套的概念和工具体系比较复杂。可以安排固定的内部分享时间，大家轮流讲自己负责模块的容器化实践和踩过的坑，这种方式比外部培训的效果好很多。因为案例都是真实的，场景都是大家要面对的，参与感强，学到的东西也更能用得上。

回看整个技术架构演进之路，从单体到微服务再到容器化，每一个阶段都是被真实问题驱动的。Docker能成为主流，不完全是技术上的胜利，更是工程效率上的胜利：它让环境的构建和分发变得像代码一样可版本管理、可复现、可自动化。这个系列下一篇我会深入讲Dockerfile的编写细节和镜像瘦身实战，欢迎持续关注。