傳統軟件部署的痛點
這是對之前《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 版本差異導致支付接口超時，影響交易）。
配置文件和依賴路徑差異
典型場景
開發本地的數據庫地址為 ，文件存儲路徑設為 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 容器化 - 貪婪的君子 - 博客園》閱讀。
本文首發于，公眾號訂閱請關注：
