從黑五13%請求報錯到零宕機：我們靠容器化部署省了60%服務器成本

去年黑五我們的地址解析接口直接炸了——13%的請求報429，客服後台收到300多封商家投訴，3個後端連軸轉24小時才把峰值扛過去。那時候我們的服務還跑在兩台固定配置的雲服務器上，擴縮容全靠手動改配置，等新實例起來流量高峰都過了。

先給你掰明白容器化部署到底是甚麼

說白了就是把你的代碼、依賴庫、配置文件全打包成一個幾MB到幾百MB不等的標準化「集裝箱」，不管在哪台服務器上跑，運行環境100%一致。我們最初打包的地址解析服務鏡像大小是187MB，拉取啓動全程不超過10秒。

我們實打實拿到的3個核心收益

• 自動擴縮容真的救大命：今年黑五流量漲了3倍，系統自動拉起27個容器實例，峰值過去之後自動縮到3個，全程沒人工乾預，錯誤率直接降到0.1%以下
• 環境不一致的bug徹底消失：之前本地跑沒問題、一上線就崩的玄學問題，佔我們bug總量的40%，遷到容器之後這類問題一個都沒再出現過
• 服務器成本直接砍半：之前我們為了扛峰值常年租8台高配服務器，平時利用率只有15%，現在按實際使用付費，全年算下來省了60%的服務器開支

別光看好處，這幾個坑我們踩得結結實實

剛上容器的時候我們圖省事，把日誌、臨時文件全存在容器里，結果一次實例自動銷毀，3天的請求日誌直接沒了，補數據花了整整兩天。還有一次鏡像里塞了太多沒用的依賴，啓動時間從10秒漲到2分鐘，突發流量上來的時候根本來不及擴容，差點又出故障。

最容易忽略的是權限問題：我們最早給容器開了root權限，後來被挖礦程序鑽了空子，佔了30%的CPU資源，過了一周才從監控里發現。

先想清楚你到底該不該用

如果你是幾個人的小團隊，做的是流量波動極小的內部工具，總共就1-2個服務，那真沒必要折騰，直接租個服務器跑最省事。

但如果你的服務流量波動大、需要頻繁上線更新、團隊裡不同人開發的環境經常打架，或者已經在為閒置的服務器資源心疼錢，那容器化部署絕對值得你花一周時間試一下。

給第一次上手的人的3個具體建議

• 別上來就搞K8S集群，先用Docker Compose跑單機部署，把打包、運行、日誌掛載的邏輯摸清楚，我們前3個月就是這麼過來的，完全夠用
• 第一次打包鏡像就遵循「最小原則」，只裝運行必須的依賴，用alpine基礎鏡像能把體積砍一半以上
• 所有產生的數據、日誌一定要掛載到容器外部的存儲卷，絕對不要存在容器本身里，這條寫在你團隊的操作規範最前面

常見小問題解答

問：我們團隊沒人懂容器，學習成本會不會很高？
答：就基礎使用來說，花2天看官方入門文檔就能跑通第一個服務，深一點的集群配置等你用到了再學完全來得及。

問：現有服務遷到容器會不會很麻煩？
答：我們的3個後端服務，花了一周時間就全遷完了，大部分時間花在梳理依賴上，真正寫Dockerfile的時間不到1天。