传统软件部署的痛点

这是对之前《Docker 容器化》文章的一个补充

在 Docker 等容器技术普及前，开发、测试、运维团队常被环境不一致、部署复杂、资源浪费、扩容低效为典型的问题困扰，这些问题不仅可能导致项目的交付周期的延后，还会引发跨团队协作矛盾，甚至导致线上故障，我们逐一来看每个问题。
环境不一致

“在我这里好的，怎么到你那里就崩了”

这是开发团队最高频的矛盾点，也是开发团队和测试团队之间协作的争论点，这个问题的本质是 “开发环境、测试环境、生产环境的配置差异”，可以分为：

• 系统和工具版本差异
  
• 配置文件和依赖路径差异
  

系统和工具版本差异

典型场景
开发人员本地用 Windows 10 系统，Python 3.8 版本，依赖的requests库是 2.25.1 版。
测试环境是 CentOS 7 系统，Python 3.6 版本，requests库是 2.20.0 版。
生产环境是 Ubuntu 18.04 系统，Python 3.7 版本，requests库是 2.22.0 版。
开发写的代码在本地能正常调用接口，到测试环境却因 “Python 3.6 不支持 f-string 格式化的某语法” 报错，到生产环境又因 “requests库版本不同导致参数解析逻辑变化” 出现数据异常。

产生原因

• 缺乏统一的环境配置标准，团队成员选择系统、工具版本过于自由；
  
• 依赖库管理混乱，开发时未锁定依赖版本（如未生成requirements.txt或package.json），测试 / 生产安装时默认拉取最新版，导致版本不兼容。
  

影响

• 问题排查困难：明明本地跑通的代码，到其他环境却崩了，明确的知道是环境的问题，但是仍需要花时间对比系统版本、库版本，甚至逐行调试语法兼容性，严重占用开发时间。
  
• 测试团队协作：部分测试过程中发现的 “问题” 并非代码逻辑错误，而是环境差异导致，对于以 bug 进行研发质量评估的团队，容易在问题上进行反复拉扯，消耗各个团队的精力。
  
• 线上风险隐患：跑通了测试的用例，但若生产环境存在未被测试覆盖的版本差异，可能导致上线后突发故障（如某电商平台因 Java 版本差异导致支付接口超时，影响交易）。
  

 
配置文件和依赖路径差异

典型场景
开发本地的数据库地址为 localhost:3306，文件存储路径设为 D:/data。
测试环境数据库地址是test-db:3306，文件路径是 /opt/data。
生产环境数据库地址是prod-db:3306，文件路径是/data/app。
开发打包代码时未区分环境配置，直接将本地配置文件上传，导致测试环境连不上数据库，生产环境找不到文件存储目录。

产生原因

• 配置文件未做“环境隔离”，硬编码本地路径或地址。
  
• 缺乏统一的配置管理工具，测试/运维需手动修改配置文件，容易漏改或改错（如少改一个 IP 地址符号）。
  

影响

• 线上风险隐患：如果测试环境未拦截到该问题（测试环境与本地环境一致），将有问题的文件路径发布到生产，则会出现生产事故。
  

 
部署复杂

……又要重新配置一遍

传统部署需手动配置依赖、环境变量、权限等，步骤繁琐且易出错，尤其在多组件依赖场景下，部署成本极高，这在初期部署及后续升级带来了不小的运维成本。
多依赖场景

装 A 要先装 B，装 B 要先装 C，一步错可能会导致我们重头开始。
典型场景
部署一个 Java Web 应用，通常需要经历以下步骤：

• 安装 JDK（需先判断系统架构，选择 32/64 位，配置 JAVA_HOME 环境变量，验证java-version是否生效）
  
• 安装 Tomcat（解压压缩包，修改 server.xml 配置端口，设置 Tomcat 用户权限，避免端口冲突）
  
• 安装 MySQL（配置数据库用户名密码，创建数据库和表，授权远程访问，可能遇到“root 用户无法远程登录” 的权限问题）
  
• 部署应用（将 WAR 包放到 Tomcat 的webapps目录，重启 Tomcat，可能遇到 “WAR 包解压失败”“数据库连接池配置错误” 等问题）
  

若其中一步出错（如 JDK 环境变量配置错误、MySQL 授权语句写错），整个部署流程需从头排查，新手可能花 1-2 天才能完成一次成功部署。

产生原因

• 应用依赖的基础组件（如 JDK、数据库、中间件）需单独部署，且各个组件有自己的配置要求
  
• 所有步骤依赖人工操作，容易因操作失误（如输错命令、漏配参数）导致失败。
  

 
资源占用率高

“哪位大哥有资源，释放一些出来”

传统虚拟化技术（如 VMware、VirtualBox）通过 “模拟完整操作系统” 实现隔离，这种方式资源利用率极低，硬件成本居高不下。
资源预分配

典型场景
某公司用虚拟机部署 3 个应用，虚拟机本身有6核12GB资源，每个应用的虚拟机分配 2 核 4GB 内存，实际应用运行时仅占用 1 核 2GB 内存，剩余 1 核 2GB 内存被虚拟机 “闲置占用”，无法分配给其他应用。若要部署第 4 个应用，需额外采购服务器，增加硬件成本。

实际上，6核12GB只是这里方便计算的提供的一个参考值，实际由于管理应用虚拟机，资源虚化等，宿主机还需要额外的资源。

产生原因

• 资源预分配导致浪费：虚拟机启动前需固定分配 CPU、内存、磁盘，即使应用实际占用低，这些资源也无法被其他虚拟机使用；
  
• 操作系统开销大：每个虚拟机都有独立的操作系统内核（如 Windows Server、CentOS），仅操作系统自身就需占用数百 MB 内存（如 CentOS 7 最小化安装后占用约 500MB 内存），进一步挤压应用可用资源。
  

例如：在一台 8 核 16GB 内存的服务器上创建虚拟机，每个虚拟机需分配至少 2 核 4GB 内存（保证基本运行），且需占用独立的磁盘空间（如每个虚拟机分配 20GB 磁盘）。理论上可以跑4台虚拟机，但是实际上，宿主机本身也需要占用资源，同时也需要管理维护虚拟机，所以跑不满4台虚拟机。
对于中小企业来说，服务器数量有限，若用虚拟机部署，可能出现 “想加应用却无资源” 的困境：例如一台服务器最多跑 3 个虚拟机，若有 5 个应用需部署，需采购 2 台服务器，硬件成本翻倍；而若用 Docker，相同服务器可跑 20 + 容器，资源利用率提升 5-10 倍。
 
扩容效率低

吃x都赶不上热乎的

传统虚拟化启动慢、扩容流程长，无法应对突发流量（如微博热搜），容易导致系统卡顿或崩溃。
 
典型场景
某电商平台大促前，发现 “商品详情页” 服务压力过大，需紧急扩容 2 台虚拟机，从发起扩容请求到虚拟机启动、应用部署完成，需至少 10 分钟，而此时流量已开始上涨，可能导致前 10 分钟内用户访问卡顿。

产生原因

• 虚拟机启动慢：加载操作系统内核→初始化硬件驱动→启动系统服务→启动应用，整个过程需 3-5 分钟，如果硬件性能够强，还可以更快一些。
  
• 扩容流程繁琐：需要申请资源，如果资源不足了，要么采购，要么从其他虚拟机上抢资源；再进入新的虚拟机中进行环境配置环境，部署应用，每一步都要走一遍；等完成这些工作，泼天的流量，也只能眼巴巴的看着溜走。
  

 
小结

上文的场景设计是比较直白直接的，在 Docker 出现前的技术持续迭代过程中，也或多或少的解决了相关的问题，所以你在大厂里，未必会遇到这么极端的场景设计，但是避免不了遇到一些隐形的问题，比如：

• 在配置上，开发及测试环境由于网络速率的问题，通常我们会在开发环境中设置一个长等待的时间，如 60s 等待 HTTP 请求返回结果，但是生产环境中则设置 5s 等待时间，此时在生产环境中遇到一个请求失败，则很可能是速度慢导致的超时。
  
• 在生产环境中，为了优化用户体验，会接入 CDN 进行加速，而本地及测试环境则是直连服务，如果没处理好 CDN 配置，也会遇到同类的问题，这就是环境不一致带来的问题。
  
• 即使开发测试环境的部署都没有问题，但是部署生产时，由于生产环境具有严格的防火墙及端口访问机制，也会出现服务访问不了的情况。
  
• 部署扩容都是小事，技术的发展过程中肯定是会优化的，但是升级应用的时候就会很痛，比如公安的安全扫描中发现我们的服务存在问题，解决方案很简单，升级一下系统和相关软件就可以了，但事实却是，这个服务百年未有过更新，随便升级底层的依赖，都有可能是破坏性更新，太痛了。
  

以上就是传统虚拟机部署的痛点问题，那么 Docker 对于这些问题，有什么更好的解决方案吗？
 
Docker 的解决方案

Docker 的核心是：容器、镜像。再加上一个仓库，便是 Docker 的三板斧了。

• 通过镜像固化环境配置
  
• 通过容器减少资源消耗
  
• 通过仓库进行版本管理
  

具体可以再回到《Docker 容器化 - 贪婪的君子 - 博客园》阅读。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！