演進：從VM到容器的確定性之路)
千萬 QPS 架構(gòu)系列講到第 218 講話題落到“容器化從 VM 到容器”。很多人看到這個題目第一反應是“這還有什么好講的容器不就是比虛擬機更輕的虛擬化嗎”但如果你真的在千萬 QPS 的業(yè)務場景里做過架構(gòu)演進就會知道從 VM 到容器真正改變的不是部署形態(tài)而是整個系統(tǒng)的成本結(jié)構(gòu)、故障邊界和運維模型。我這里想先給出一個貫穿全文的判斷千萬 QPS 架構(gòu)下的容器化不是為了省幾臺機器而是為了獲得更高的確定性——讓調(diào)度更快、讓故障半徑更小、讓擴容從“采購流程”變成“一條命令”。如果你只是在小業(yè)務里用 Docker 跑幾個服務可能體會不到這種確定性有多重要但當你面對流量洪峰、發(fā)布頻率和故障恢復速度的壓力時容器化幾乎是必經(jīng)之路。這篇文章我不會只講“VM 和容器的十個區(qū)別”這類入門內(nèi)容。我會從架構(gòu)視角出發(fā)講清楚三件事第一VM 在高并發(fā)場景下到底卡在哪里第二容器為什么能解開這個結(jié)以及它的代價是什么第三真實業(yè)務做容器化改造時按什么順序、避開什么坑、需要補哪些工程能力。1. 先搞清楚千萬 QPS 場景下VM 架構(gòu)的瓶頸到底在哪里1.1 不是性能不夠而是“確定性與彈性”不夠很多團隊在沒有遇到大規(guī)模流量之前會覺得虛擬機用得很好。CPU、內(nèi)存、網(wǎng)絡(luò)隔離看起來都很完善穩(wěn)定性也不錯。那問題出在哪出在“峰值的不可預測性”和“擴容的線性成本”上。假設(shè)你的業(yè)務平時只有幾萬 QPS某天運營活動突然把流量推到千萬 QPS。這時候你面對的問題清單是這樣的現(xiàn)有 VM 集群的 CPU 水位還能扛多久需要新增多少臺 VM每臺 VM 從申請、初始化、部署代碼、掛載監(jiān)控到加入負載均衡需要多長時間如果擴容腳本寫得不夠自動化是不是需要運維同學半夜手動點一圈擴容之后流量回落這些 VM 是不是還得繼續(xù)付費從工程經(jīng)驗看虛擬機的擴容鏈路里最慢的環(huán)節(jié)通常不是機器啟動本身而是“初始化”和“接入”的過程。一個虛擬機實例創(chuàng)建之后要裝系統(tǒng)、配網(wǎng)絡(luò)、裝 Agent、拉代碼、啟動進程、跑健康檢查、注冊到服務發(fā)現(xiàn)這一串動作往往需要分鐘級甚至十分鐘級。而這種速度在流量曲線陡峭上揚的時候是跟不上的。更麻煩的是VM 的資源隔離是“硬隔離”一臺 VM 的規(guī)格往往在創(chuàng)建時就固定了。流量漲了你不能只給某個容量的進程加 200MB 內(nèi)存你得再開一臺機器或者遷移到更大規(guī)格的實例。這就導致資源利用率很難做得很滿。經(jīng)常出現(xiàn)的情況是每臺 VM 都預留了 30%-40% 的緩沖區(qū)但這些緩沖在大部分時間都是空閑的真正的流量峰值來了又覺得哪里都不夠。1.2 故障半徑一臺 VM 掛掉和幾十個進程優(yōu)先級掛掉處理方式完全不同還有一個容易被低估的點故障半徑。一臺物理機上如果跑了多個 VM某個 VM 出了故障物理機可能還能兜住。但 VM 里的故障往往是“整機不可用”——進程崩潰、內(nèi)核 panic、負載高到 SSH 都連不上你只能重啟或重建。重啟一臺 VM意味著上面的所有進程一起重啟恢復時間以分鐘計。在千萬 QPS 場景下故障恢復時間每多一分鐘損失都是巨大的。如果業(yè)務層沒有做好重試、降級和熔斷一次非預期的 VM 故障就可能引發(fā)雪崩。所以VM 時代的高并發(fā)架構(gòu)并不是不能支撐千萬 QPS而是支撐得“很累”。你需要在容量規(guī)劃上留足裕量在擴容速度上接受分鐘級延遲在故障處理上依賴更厚重的高可用設(shè)計。你可以用很多辦法把這種架構(gòu)做得很好但每加一層復雜度維護成本就會非線性上升。2. 容器到底改變了什么不是“輕量級 VM”而是一套新的運行哲學2.1 鏡像、進程隔離、命名空間容器比 VM 少了什么又多了什么先做一個最簡單的對比。虛擬機虛擬的是硬件所以每個 VM 里需要有一個完整的操作系統(tǒng)內(nèi)核容器虛擬的是操作系統(tǒng)多個容器共享宿主機的內(nèi)核只是通過 Namespace 和 Cgroups 做資源隔離和視圖隔離。這個差別的直接結(jié)果就是容器啟動非常快。因為啟動容器本質(zhì)上是啟動一個進程組而不是啟動一個系統(tǒng)。從實踐來看一個 Java 服務容器從拉取鏡像到 Ready通常也就是幾秒到十幾秒的狀態(tài)而一臺 VM 從冷啟動到業(yè)務就緒往往需要幾十秒到幾分鐘。不過這里必須說清楚容器不是“更輕的 VM”兩者不適合直接做替換式對比。容器的隔離級別比 VM 弱同一個宿主機上的多個容器共享內(nèi)核一旦內(nèi)核出問題影響的不是單個容器而是整個宿主機上的所有容器。這意味著在千萬 QPS 架構(gòu)里容器化之后反而需要更關(guān)注宿主機的穩(wěn)定性和內(nèi)核兼容性。容器真正多出來的東西是鏡像。鏡像把代碼、運行時、依賴、配置“打包”成了一個不可變單元。過去在 VM 上部署應用最怕環(huán)境漂移生產(chǎn)環(huán)境的 JDK 版本和測試環(huán)境不一致某個動態(tài)庫少裝了一個某條 cron 忘了配置。容器鏡像把這些問題基本抹平了。只要鏡像能在測試環(huán)境跑起來在任意一臺裝了容器運行時的機器上它都能以同樣的方式跑起來。2.2 容器調(diào)度從“人工找機器”到“聲明式地告訴集群我要跑什么”VM 時代你要部署一個服務基本流程是找運維要一臺機器SSH 上去裝環(huán)境拉代碼啟動進程然后記下 IP配到負載均衡或注冊中心里。容器時代尤其是用了 Kubernetes 之后你做的是“聲明式部署”你只需要描述清楚我要多少個副本、用什么鏡像、需要多少 CPU 和內(nèi)存、暴露哪些端口、健康檢查怎么探集群會自動把 Pod 調(diào)度到合適的節(jié)點上并持續(xù)保證期望狀態(tài)。這兩種模式的差異用一句話概括就是VM 時代是“找機器、裝環(huán)境、跑服務”容器時代是“描述需求、交給調(diào)度器解決”。在千萬 QPS 架構(gòu)里這個差異非常關(guān)鍵。因為你已經(jīng)不可能像管理幾十臺機器那樣一臺一臺地手工維護。你維護的是一個集群一個抽象的資源池。新增流量時你調(diào)整副本數(shù)宿主機故障時控制平面自動把 Pod 重新調(diào)度發(fā)布新版本時滾動更新的策略由平臺保證。整個過程的“可預期性”遠遠好于人工操作。2.3 容器化不等于 Kubernetes但千萬 QPS 通常繞不開編排單機版的 Docker只能解決鏡像分發(fā)和單機運行的問題解決不了跨機器的調(diào)度、服務發(fā)現(xiàn)、存儲編排、配置管理和故障自愈問題。要支撐千萬 QPS容器化通常要配套容器編排平臺。Kubernetes 是當前最主流的選擇但注意它不是一個開箱即用的高并發(fā)平臺。默認配置的 Kubernetes在千級 QPS 的流量下可能已經(jīng)夠用但到了萬級、十萬級、百萬級 QPS你需要調(diào)的東西就非常多了kube-proxy 模式、DNS 并發(fā)、etcd 性能、節(jié)點資源預留、Pod 數(shù)量上限、鏡像拉取策略、監(jiān)控指標采集頻率等等。這些細節(jié)后面我會專門展開講。所以在開篇我想先打破一個觀念很多人以為“容器化改造”就是把應用打成 Docker 鏡像再寫幾個 YAML 文件往集群里一扔。這種理解只完成了 20%剩下 80% 的工程量在穩(wěn)定性、可觀測性、安全性和運維體系上。3. 從 VM 到容器的底層機制鏡像、命名空間與上午架構(gòu)的關(guān)系3.1 鏡像分層為什么容器化能讓發(fā)布變得更快、更可控容器鏡像的分層設(shè)計可能比很多人想象中重要得多。一個典型 Java 服務鏡像大概分這么幾層基礎(chǔ)系統(tǒng)層比如帶有 glibc、時區(qū)信息、CA 證書的 Linux 根文件系統(tǒng)JRE 層應用依賴層jar 包應用配置層。打包時每一層都可能被緩存并被多個鏡像復用。這個設(shè)計帶來的好處很直接發(fā)布新版本時如果只改了應用代碼那其他層都不變構(gòu)建和推送只需要處理最上面的一層拉取時同理宿主機上如果已經(jīng)有基礎(chǔ)鏡像和依賴層只需要下載新增的那一小層。配合上鏡像加速器或離線鏡像倉庫發(fā)布速度會快很多。在千萬 QPS 架構(gòu)里發(fā)布速度意味著什么意味著你能更快地完成故障修復。線上出了問題你改了一行代碼理論上兩三分鐘內(nèi)新鏡像就能構(gòu)建完并滾動上線。而如果你還在用 VM 方式可能要先把包傳到所有機器再逐臺重啟進程整個過程不僅慢還容易因為機器環(huán)境差異出現(xiàn)“這臺成功、那臺失敗”的局面。3.2 Cgroups 與資源視圖為什么容器能更精細地裝箱Cgroups控制組是 Linux 內(nèi)核提供的資源限制能力可以限制、記錄和隔離一組進程對 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)的資源使用。容器的資源配額底層就是靠 Cgroups 實現(xiàn)的。在 VM 時代CPU 和內(nèi)存規(guī)格通常是固定的、不連續(xù)的你要么用 4C8G要么用 8C16G很少能精確到“這個服務只需要 1.5 個 CPU900MB 內(nèi)存以后還能動態(tài)調(diào)”。但容器化之后資源配額可以更細粒度地設(shè)置同一個宿主機上可以混布不同資源需求的容器裝箱率會比傳統(tǒng) VM 模式高很多。從成本角度看這可能是容器化為數(shù)不多能直接算出來的好處。但換一個角度看粒度變細也帶來了新的風險你以為限了 512MB 內(nèi)存實際 JVM 的堆外內(nèi)存、線程棧、Metaspace、Direct Memory 加起來可能輕松超過配額結(jié)果容器被 OOMKilled。應對辦法也很明確做容器化改造時不要只設(shè)置內(nèi)存上限還要配合 JVM 參數(shù)調(diào)整、HeapDump 采集和內(nèi)存監(jiān)控。3.3 網(wǎng)絡(luò)模型的變化IP 變得“不值錢”服務發(fā)現(xiàn)變得尤為重要VM 時代每臺 VM 有一個相對穩(wěn)定的 IP你的監(jiān)控系統(tǒng)、日志系統(tǒng)、白名單機制幾乎都是圍繞 IP 設(shè)計的。你可以通過 IP 快速判斷“這個請求是哪個機器處理的”也可以用 IP 來配置數(shù)據(jù)庫訪問白名單。但容器化的世界IP 是臨時資源。Pod 可以被銷毀、重建、被調(diào)度到其他節(jié)點上IP 會隨之變化。如果你還在容器里用“固定 IP 手動配置”的思維做網(wǎng)絡(luò)規(guī)劃會非常痛苦。所以容器化之后服務之間的調(diào)用關(guān)系不再依賴“知道對方的 IP”而是依賴“服務名 服務發(fā)現(xiàn)”。Kubernetes 內(nèi)部的 Service 和 DNS 解決了大部分流量路由問題服務之間的調(diào)用走的是 Service DNS 或 Service Mesh。過去那種“出問題我先看哪臺機器”的方式會變成“先看服務實例列表里有哪些副本日志集中在什么地方”。這個變化看著簡單實際影響深遠。如果你的團隊還停留在“SSH 到 VM 上 tail 日志”的排查習慣容器化之后會非常不適。日志必須集中采集指標必須按服務維度聚合鏈路追蹤必須成為標配。否則你面對幾百個隨時變化的 Pod根本沒有辦法做問題定位。4. 千萬 QPS 容器化的關(guān)鍵工程點從“能用”到“穩(wěn)如磐石”4.1 資源配額與 JVM容器世界里最容易翻車的地方很多從 VM 遷移到容器的 Java 團隊遇到的第一個坑就是內(nèi)存。在 VM 上跑得好好的 Java 應用放進容器里卻經(jīng)常被 OOMKilled。原因也不復雜JVM 默認的 MaxHeapSize 是根據(jù)宿主機內(nèi)存來算的不是根據(jù)容器配額。如果你不給 JVM 顯式設(shè)置 -Xmx它可能會申請超過容器限額的內(nèi)存。JVM 的堆外內(nèi)存包括 Metaspace、線程棧、Direct Buffer、JIT 編譯器內(nèi)存這些在容器里都屬于容器配額的一部分。解決思路是顯式設(shè)置 JVM 堆和容器內(nèi)存配額的關(guān)系通常建議 -Xmx 設(shè)置為容器內(nèi)存上限的 50%-70%。使用 Java 10對于較新的 JDK容器可以識別 CPU 限制如果你還在用 Java 8建議升級到 Java 8u191并配合 -XX:UseContainerSupport。預留 25%-30% 的內(nèi)存給非堆內(nèi)存避免因為 JVM 動態(tài)擴展或 JIT 編譯導致 OOM。如果原始業(yè)務的 QPS 比較高一定要先做一次壓測觀察容器在限制下的 Full GC 頻率、堆使用率和響應時間曲線再決定合適的配額和副本數(shù)。4.2 健康檢查、優(yōu)雅退出與滾動更新發(fā)布不再是玄學容器化對發(fā)布流程最大的改造在于發(fā)布變成了“聲明新的期望狀態(tài)等待集群自我調(diào)整”。但如果你沒有配置好健康檢查這個過程會變成災難。Kubernetes 里有三種探針啟動探針startupProbe、就緒探針readinessProbe和存活探針livenessProbe。在千萬 QPS 架構(gòu)里這三種探針的配置都不可省略啟動探針解決服務啟動慢的問題。如果你的應用啟動需要 60 秒但存活探針的 initialDelaySeconds 設(shè)成了 5 秒那容器還沒起來就被殺掉了。就緒探針決定流量是否進入 Pod。新 Pod 沒有 Ready 之前Service 不會把流量打進去。存活探針負責處理“進程活著但業(yè)務卡死”的情況比如死鎖、線程池耗盡的死循環(huán)。實際發(fā)布時如果你只做了“殺掉舊 Pod、啟動新 Pod”而沒有做優(yōu)雅退出可能出現(xiàn)存量請求被硬斷造成非常明顯的報錯率和服務不可用。嚴謹?shù)淖龇ㄊ桥渲?preStop讓容器在終止前先摘除流量等幾秒讓存量請求處理完然后再真正停止進程。注意不要把優(yōu)雅退出這一步省掉。千萬 QPS 場景下哪怕只有 0.1% 的請求在發(fā)布瞬間被斷開也會放大成大量業(yè)務報錯。4.3 鏡像倉庫、并發(fā)拉取與帶寬大集群擴容時的隱形瓶頸假設(shè)你有 1000 個節(jié)點某個大版本發(fā)布時所有節(jié)點需要同時拉新鏡像。如果鏡像很大比如 1GB而倉庫出口帶寬只有 1Gbps那理論上并發(fā)拉取會直接把帶寬打滿發(fā)布時間會被拉得非常長。常見的解法鏡像瘦身盡量使用 alpine 或精簡基礎(chǔ)鏡像Java 服務只帶 JRE 不帶 JDK。分層緩存把依賴較多的層盡量放在前面保證只有最上面的應用層需要變動。并發(fā)控制通過容器編排的配置限制集群內(nèi)同時拉取鏡像的節(jié)點數(shù)避免帶寬打滿。私有倉庫 就近部署在物理區(qū)域內(nèi)自建鏡像倉庫或者通過 P2P 分發(fā)組件減少源倉庫的壓力。這個問題平時不明顯但大促前擴容時經(jīng)常爆發(fā)。你會在控制臺看到一堆 Pod 處于 ImagePullBackOff 或者 ContainerCreating 狀態(tài)原因不是網(wǎng)絡(luò)不通而是拉取鏡像排隊太長。4.4 日志、監(jiān)控與鏈路追蹤排查問題的方式必須升級容器化之后應用日志不能在容器內(nèi)寫文件了。原因很簡單容器隨時可能被調(diào)度走宿主機上的日志文件會隨之丟失。而且多副本情況下你想看某個請求在某臺機器上的日志基本沒法手工“登上去找”因為實例本身可能是動態(tài)的。所以做容器化改造時日志方案必須改為“統(tǒng)一采集、集中存儲、檢索分析”。常見路徑是應用把日志寫到 stdout/stderr由日志采集 Agent比如 Filebeat、Fluent Bit采集到 Kafka再到 ES 或 ClickHouse或者在應用日志框架里配置為發(fā)送到統(tǒng)一日志服務比如 Loki、ELK 等。監(jiān)控和鏈路追蹤在這個階段也會變成剛需。在 VM 時代你還能通過 CPU 曲線和流量曲線大致猜出瓶頸在容器時代如果連調(diào)用鏈都沒有遇到跨服務的慢請求排查問題會非常痛苦。建議從改造的第一天就確定好監(jiān)控指標的最小集請求量、錯誤率、響應延遲P50/P95/P99、容器 CPU/內(nèi)存使用率、節(jié)點水位、發(fā)布變更記錄。5. 容器化改造的真實路徑不是“全量遷移”而是“分步驗證流量灰度”5.1 第一步先給業(yè)務做“容器化可行性畫像”不是所有業(yè)務都適合立刻容器化。我建議先做一個分類無狀態(tài)服務Web 服務、API 網(wǎng)關(guān)、RPC 服務、消息消費者。這類業(yè)務的容器副本之間沒有狀態(tài)關(guān)聯(lián)殺掉重啟任何副本都無所謂是最適合容器化的類型。有狀態(tài)服務MySQL、Redis、ES、Kafka。這類服務的數(shù)據(jù)和服務實例強綁定直接跑在普通容器里會有數(shù)據(jù)丟失風險通常需要使用 StatefulSet、PV/PVC、本地盤調(diào)度或者其他狀態(tài)化方案復雜度比無狀態(tài)服務高一個量級。定時任務CronJob 在 Kubernetes 里能跑但要注意并發(fā)策略和補跑機制不要多個副本同時執(zhí)行同一個任務。批處理任務適合用 Job 模式跑跑完即結(jié)束比常駐服務更靈活。從改造優(yōu)先級來看應該先挑無狀態(tài)、流量可灰度、故障容忍度高的業(yè)務跑通整套流程。不要一上來就把核心數(shù)據(jù)庫塞進容器里。5.2 第二步用“流量灰度”替代“機房整體切換”我見過很多團隊做容器化改造時喜歡采用“一刀切”的方式隔離出一個專門的新集群把應用整個遷移過去等穩(wěn)定了再切換流量。這種做法的風險在于如果遷移過程中出現(xiàn)一個你沒想到的問題切換不了影響的不是某個服務而是整條鏈路。更穩(wěn)妥的方式是“邊跑邊換”讓容器版本和 VM 版本并行運行一段時間通過網(wǎng)關(guān)逐步灰度流量。比如第一階段容器副本只接收 5% 的測試流量主要驗證基礎(chǔ)功能和鏈路連通性。第二階段放出 10% 的線上流量觀察錯誤率、延遲、GC、CPU、內(nèi)存等指標是否和 VM 版本一致。第三階段逐步擴大到 50%再 100%最后下線 VM 副本。這個思路的核心是不要用“徹底搬遷”的心態(tài)做改造要用“新老系統(tǒng)并存、逐步替代”的心態(tài)做改造。容器的調(diào)度、網(wǎng)絡(luò)、存儲、監(jiān)控體系都需要時間磨合灰度期間暴露的問題是成本最低的學習機會。5.3 第三步補齊容器化缺少的工程能力容器和編排平臺解決的是“調(diào)度和部署”問題但它不自動解決以下工程問題配置管理配置項應該用 ConfigMap / Secret 管理不能直接打進鏡像。否則每次改配置都要重新構(gòu)建鏡像。權(quán)限控制容器內(nèi)部不要以 root 用戶運行業(yè)務容器要有獨立的非 root 用戶Dockerfile 里需要用 USER 指令切換。安全掃描鏡像上線前要做漏洞掃描不信任的第三方鏡像不要直接拉進生產(chǎn)集群。鏡像安全和容器安全是兩個不同維度鏡像掃描解決的是打包階段的問題運行時安全解決的是逃逸和異常訪問的問題。資源隔離很多團隊在 Kubernetes 里只設(shè)置 requests不設(shè)置 limits。這種配置在流量低時看不出來流量高時一個 Pod 會把整臺節(jié)點打爆。合理做法是先做壓測再設(shè)置 requests 和 limits并且對 CPU 與內(nèi)存分別設(shè)置。備份與恢復對于有狀態(tài)服務如果最終還是決定容器化必須提前設(shè)計好持久化存儲和備份策略不能依賴“容器還在”這個狀態(tài)。6. 千萬 QPS 場景下的容器化調(diào)優(yōu)默認配置跑不出高并發(fā)6.1 kube-proxy 與 iptables/ipvs連接與負載均衡能不能扛住Kubernetes 默認的 kube-proxy 模式如果是 iptables在大規(guī)模高并發(fā)場景下會遇到兩個問題Service 數(shù)量、Endpoint 數(shù)量非常大時iptables 規(guī)則會非常龐大更新規(guī)則時可能造成連接閃斷。iptables 的規(guī)則匹配是順序匹配規(guī)則多了之后轉(zhuǎn)發(fā)性能會有明顯下降。生產(chǎn)環(huán)境通常建議改用 IPVS 模式。IPVS 在內(nèi)核態(tài)實現(xiàn)了負載均衡支持多種調(diào)度算法性能比 iptables 好很多而且規(guī)則同步更穩(wěn)定。切換后ClusterIP 對應的負載均衡轉(zhuǎn)發(fā)能力會有明顯提升。另外還有一個容易被忽略的點如果服務規(guī)模很大DNS 解析 QPS 也會非常高。Kubernetes 默認的 CoreDNS 配置在大量 Pod 并發(fā)解析時會成為瓶頸需要調(diào)整副本數(shù)、部署模式比如 daemonset和緩存參數(shù)。6.2 節(jié)點水位與調(diào)度策略不要讓任何一臺宿主機成為“落單熱點”容器化之后宿主機故障的影響面取決于這臺機器上跑了多少個業(yè)務 Pod。如果調(diào)度策略不關(guān)注 Pod 的“反親和性”某個核心服務的所有副本可能同時落在同一臺宿主機上那這臺機器一掛整個服務就瞬間不可用。在千萬 QPS 場景下調(diào)度策略至少要考慮核心服務多副本盡量打散到不同節(jié)點、不同可用區(qū)?；旌喜渴鸬蛢?yōu)先級任務與核心業(yè)務時要設(shè)置優(yōu)先級和搶占策略避免低優(yōu)先級任務搶占高優(yōu)先級業(yè)務的資源。設(shè)置節(jié)點資源預留kube-reserved、system-reserved不要把節(jié)點資源 100% 分配給業(yè)務容器防止宿主機自身系統(tǒng)和組件異常。6.3 大促擴容容器數(shù)量多了問題也會跟著變多千萬 QPS 的大促場景下系統(tǒng)會自動擴容出大量副本。這個時候出問題的往往不是應用本身而是容量側(cè)的基礎(chǔ)設(shè)施節(jié)點數(shù)增加容器集群控制面 API Server 的請求量會上升etcd 的寫入 QPS 也會漲。需要提前評估集群規(guī)格必要時拆分多個集群。Pod 數(shù)量增加后監(jiān)控 Agent 采集的指標數(shù)量也會增長監(jiān)控系統(tǒng)自身需要擴容。服務發(fā)現(xiàn)和注冊中心需要同步擴容尤其是如果你的服務仍然依賴注冊中心做 RPC 路由注冊中心會成為新的瓶頸。如果新的 Pod 需要掛載存儲存儲系統(tǒng)的并發(fā)能力也要提前壓測避免擴容后因存儲 IO 跟不上導致服務失敗。簡單說容器化把“機器維度”的擴容問題變成了“平臺維度”的擴容問題。機器不夠用變成集群不夠用帶寬不夠用變成倉庫或 DNS 不夠用連接數(shù)不夠變成 Service 轉(zhuǎn)發(fā)或注冊中心不夠用。你需要用新的視角去看容量規(guī)劃和壓測。7. 落地前的自檢清單一套可以直接拿走的容器化改造框架到這里我已經(jīng)把從 VM 到容器的架構(gòu)邏輯講得差不多了。但我知道大部分人看到最后真正需要的是一個能落地執(zhí)行的檢查表。下面這個清單是這套方法論的核心沉淀也是我建議你在動手改造前先逐條過一遍的東西。第一層服務畫像[ ] 服務是否有狀態(tài)數(shù)據(jù)是否存在本地文件、本地磁盤或內(nèi)存中[ ] 服務是否支持優(yōu)雅退出進程收到 SIGTERM 后能否在有限時間內(nèi)處理完存量請求[ ] 服務啟動時間是多少是否超過 90 秒是否需要啟動探針兜底[ ] 服務的內(nèi)存占用峰值是多少JVM 的堆內(nèi)和堆外內(nèi)存是否都統(tǒng)計過第二層鏡像與供應鏈[ ] 基礎(chǔ)鏡像是否精簡能否去掉編譯工具鏈、包管理器和緩存[ ] 鏡像中是否存在敏感信息密碼、密鑰、Token[ ] 是否用了私有鏡像倉庫鏡像上傳后是否做漏洞掃描[ ] 是否配置了鏡像拉取策略Always / IfNotPresent第三層編排與配置[ ] 配置是否已經(jīng)從鏡像中剝離能否用 ConfigMap / Secret 管理[ ] 是否設(shè)置了 requests 和 limits是否經(jīng)壓測驗證過[ ] 就緒探針、存活探針、啟動探針的閾值是否和服務真實啟動時間匹配[ ] 優(yōu)雅退出是否正確配置preStop 是否執(zhí)行第四層可觀測性[ ] 日志是否已改為集中采集能否在日志平臺按 traceId 串聯(lián)全部鏈路[ ] 監(jiān)控是否覆蓋請求量、錯誤率、P99 延遲、容器資源、節(jié)點水位和服務發(fā)現(xiàn)狀態(tài)[ ] 是否有按服務維度而不是機器維度的告警規(guī)則[ ] 鏈路追蹤是否已經(jīng)接入核心業(yè)務鏈路第五層穩(wěn)定性與容量[ ] 是否對核心服務做過容器資源限制下的壓測[ ] 是否對鏡像拉取并發(fā)、DNS 并發(fā)、Service 轉(zhuǎn)發(fā)能力和注冊中心容量做過評估[ ] 核心服務多副本是否配置了反親和性避免打到同一臺宿主機[ ] 大促擴容腳本是否演練過控制面是否撐得住流量洪峰這個清單看起來很長但每一項背后幾乎都有真實事故在支撐。你在小規(guī)模場景里可能感受不到它們的作用但一旦流量漲到千萬級任何一個“看起來不重要的配置項”都可能成為壓垮系統(tǒng)的最后一根稻草。8. 容器化之后架構(gòu)的長期方向平臺能力才是真正的分水嶺聊完了改造步驟和調(diào)優(yōu)細節(jié)我想把視野拉遠一點說一說容器化這件事對架構(gòu)演進的長期意義。從 VM 到容器起初看起來只是部署方式的改變。但真正堅持做下來的團隊會發(fā)現(xiàn)這件事的長期價值在于它逼著你把部署、配置、監(jiān)控、日志、安全、權(quán)限、容量管理和發(fā)布流程全部“產(chǎn)品化”和“平臺化”。當這些能力沉淀為平臺服務之后任何團隊上線新服務時不再需要重復造輪子而是直接通過平臺申請資源、配置流水線、選擇監(jiān)控模板。到了這個階段業(yè)務系統(tǒng)的性能瓶頸已經(jīng)不完全取決于單機或單服務的能力而是取決于平臺對資源的調(diào)度效率、對故障的恢復速度和對外部流量變化的響應速度。這也正是千萬 QPS 架構(gòu)能夠持續(xù)演進的關(guān)鍵不是靠一次性的性能優(yōu)化而是靠一套可以讓復雜系統(tǒng)穩(wěn)定運轉(zhuǎn)的機制。從工程經(jīng)驗看這個平臺化的過程通常不是一蹴而就的。先有一個小的容器集群跑幾個非核心服務然后慢慢擴大范圍接入網(wǎng)關(guān)、核心業(yè)務、存儲層最后再建設(shè)多集群、多可用區(qū)、統(tǒng)一發(fā)布和彈性伸縮體系。每個階段都有各自的坑但只要方向是對的每走一步系統(tǒng)的響應能力和確定性都會上一個臺階?；氐轿恼麻_頭那個判斷容器化改造的核心價值不是“從 VM 換成容器”這件事本身而是通過容器和編排技術(shù)讓整個技術(shù)團隊擁有了更快的響應速度、更小的故障半徑和更確定的運維流程。如果你所在的業(yè)務已經(jīng)接近或超過百萬 QPS并且還在為擴縮容速度、發(fā)布效率和故障恢復時間焦慮那么容器化不是一道“要不要做”的選擇題而是一個“什么時候做、以什么順序做”的工程問題。希望這篇文章能給你一個相對完整的認知框架讓你在做技術(shù)決策時不至于被工具和概念牽著走。這也是我認為“千萬 QPS 架構(gòu)”系列里容器化這一講最值得沉淀下來的內(nèi)容。 千萬QPS架構(gòu)演進：從VM到容器的確定性之路
千萬 QPS 架構(gòu)系列講到第 218 講話題落到“容器化從 VM 到容器”。很多人看到這個題目第一反應是“這還有什么好講的容器不就是比虛擬機更輕的虛擬化嗎”但如果你真的在千萬 QPS 的業(yè)務場景里做過架構(gòu)演進就會知道從 VM 到容器真正改變的不是部署形態(tài)而是整個系統(tǒng)的成本結(jié)構(gòu)、故障邊界和運維模型。我這里想先給出一個貫穿全文的判斷千萬 QPS 架構(gòu)下的容器化不是為了省幾臺機器而是為了獲得更高的確定性——讓調(diào)度更快、讓故障半徑更小、讓擴容從“采購流程”變成“一條命令”。如果你只是在小業(yè)務里用 Docker 跑幾個服務可能體會不到這種確定性有多重要但當你面對流量洪峰、發(fā)布頻率和故障恢復速度的壓力時容器化幾乎是必經(jīng)之路。這篇文章我不會只講“VM 和容器的十個區(qū)別”這類入門內(nèi)容。我會從架構(gòu)視角出發(fā)講清楚三件事第一VM 在高并發(fā)場景下到底卡在哪里第二容器為什么能解開這個結(jié)以及它的代價是什么第三真實業(yè)務做容器化改造時按什么順序、避開什么坑、需要補哪些工程能力。1. 先搞清楚千萬 QPS 場景下VM 架構(gòu)的瓶頸到底在哪里1.1 不是性能不夠而是“確定性與彈性”不夠很多團隊在沒有遇到大規(guī)模流量之前會覺得虛擬機用得很好。CPU、內(nèi)存、網(wǎng)絡(luò)隔離看起來都很完善穩(wěn)定性也不錯。那問題出在哪出在“峰值的不可預測性”和“擴容的線性成本”上。假設(shè)你的業(yè)務平時只有幾萬 QPS某天運營活動突然把流量推到千萬 QPS。這時候你面對的問題清單是這樣的現(xiàn)有 VM 集群的 CPU 水位還能扛多久需要新增多少臺 VM每臺 VM 從申請、初始化、部署代碼、掛載監(jiān)控到加入負載均衡需要多長時間如果擴容腳本寫得不夠自動化是不是需要運維同學半夜手動點一圈擴容之后流量回落這些 VM 是不是還得繼續(xù)付費從工程經(jīng)驗看虛擬機的擴容鏈路里最慢的環(huán)節(jié)通常不是機器啟動本身而是“初始化”和“接入”的過程。一個虛擬機實例創(chuàng)建之后要裝系統(tǒng)、配網(wǎng)絡(luò)、裝 Agent、拉代碼、啟動進程、跑健康檢查、注冊到服務發(fā)現(xiàn)這一串動作往往需要分鐘級甚至十分鐘級。而這種速度在流量曲線陡峭上揚的時候是跟不上的。更麻煩的是VM 的資源隔離是“硬隔離”一臺 VM 的規(guī)格往往在創(chuàng)建時就固定了。流量漲了你不能只給某個容量的進程加 200MB 內(nèi)存你得再開一臺機器或者遷移到更大規(guī)格的實例。這就導致資源利用率很難做得很滿。經(jīng)常出現(xiàn)的情況是每臺 VM 都預留了 30%-40% 的緩沖區(qū)但這些緩沖在大部分時間都是空閑的真正的流量峰值來了又覺得哪里都不夠。1.2 故障半徑一臺 VM 掛掉和幾十個進程優(yōu)先級掛掉處理方式完全不同還有一個容易被低估的點故障半徑。一臺物理機上如果跑了多個 VM某個 VM 出了故障物理機可能還能兜住。但 VM 里的故障往往是“整機不可用”——進程崩潰、內(nèi)核 panic、負載高到 SSH 都連不上你只能重啟或重建。重啟一臺 VM意味著上面的所有進程一起重啟恢復時間以分鐘計。在千萬 QPS 場景下故障恢復時間每多一分鐘損失都是巨大的。如果業(yè)務層沒有做好重試、降級和熔斷一次非預期的 VM 故障就可能引發(fā)雪崩。所以VM 時代的高并發(fā)架構(gòu)并不是不能支撐千萬 QPS而是支撐得“很累”。你需要在容量規(guī)劃上留足裕量在擴容速度上接受分鐘級延遲在故障處理上依賴更厚重的高可用設(shè)計。你可以用很多辦法把這種架構(gòu)做得很好但每加一層復雜度維護成本就會非線性上升。2. 容器到底改變了什么不是“輕量級 VM”而是一套新的運行哲學2.1 鏡像、進程隔離、命名空間容器比 VM 少了什么又多了什么先做一個最簡單的對比。虛擬機虛擬的是硬件所以每個 VM 里需要有一個完整的操作系統(tǒng)內(nèi)核容器虛擬的是操作系統(tǒng)多個容器共享宿主機的內(nèi)核只是通過 Namespace 和 Cgroups 做資源隔離和視圖隔離。這個差別的直接結(jié)果就是容器啟動非常快。因為啟動容器本質(zhì)上是啟動一個進程組而不是啟動一個系統(tǒng)。從實踐來看一個 Java 服務容器從拉取鏡像到 Ready通常也就是幾秒到十幾秒的狀態(tài)而一臺 VM 從冷啟動到業(yè)務就緒往往需要幾十秒到幾分鐘。不過這里必須說清楚容器不是“更輕的 VM”兩者不適合直接做替換式對比。容器的隔離級別比 VM 弱同一個宿主機上的多個容器共享內(nèi)核一旦內(nèi)核出問題影響的不是單個容器而是整個宿主機上的所有容器。這意味著在千萬 QPS 架構(gòu)里容器化之后反而需要更關(guān)注宿主機的穩(wěn)定性和內(nèi)核兼容性。容器真正多出來的東西是鏡像。鏡像把代碼、運行時、依賴、配置“打包”成了一個不可變單元。過去在 VM 上部署應用最怕環(huán)境漂移生產(chǎn)環(huán)境的 JDK 版本和測試環(huán)境不一致某個動態(tài)庫少裝了一個某條 cron 忘了配置。容器鏡像把這些問題基本抹平了。只要鏡像能在測試環(huán)境跑起來在任意一臺裝了容器運行時的機器上它都能以同樣的方式跑起來。2.2 容器調(diào)度從“人工找機器”到“聲明式地告訴集群我要跑什么”VM 時代你要部署一個服務基本流程是找運維要一臺機器SSH 上去裝環(huán)境拉代碼啟動進程然后記下 IP配到負載均衡或注冊中心里。容器時代尤其是用了 Kubernetes 之后你做的是“聲明式部署”你只需要描述清楚我要多少個副本、用什么鏡像、需要多少 CPU 和內(nèi)存、暴露哪些端口、健康檢查怎么探集群會自動把 Pod 調(diào)度到合適的節(jié)點上并持續(xù)保證期望狀態(tài)。這兩種模式的差異用一句話概括就是VM 時代是“找機器、裝環(huán)境、跑服務”容器時代是“描述需求、交給調(diào)度器解決”。在千萬 QPS 架構(gòu)里這個差異非常關(guān)鍵。因為你已經(jīng)不可能像管理幾十臺機器那樣一臺一臺地手工維護。你維護的是一個集群一個抽象的資源池。新增流量時你調(diào)整副本數(shù)宿主機故障時控制平面自動把 Pod 重新調(diào)度發(fā)布新版本時滾動更新的策略由平臺保證。整個過程的“可預期性”遠遠好于人工操作。2.3 容器化不等于 Kubernetes但千萬 QPS 通常繞不開編排單機版的 Docker只能解決鏡像分發(fā)和單機運行的問題解決不了跨機器的調(diào)度、服務發(fā)現(xiàn)、存儲編排、配置管理和故障自愈問題。要支撐千萬 QPS容器化通常要配套容器編排平臺。Kubernetes 是當前最主流的選擇但注意它不是一個開箱即用的高并發(fā)平臺。默認配置的 Kubernetes在千級 QPS 的流量下可能已經(jīng)夠用但到了萬級、十萬級、百萬級 QPS你需要調(diào)的東西就非常多了kube-proxy 模式、DNS 并發(fā)、etcd 性能、節(jié)點資源預留、Pod 數(shù)量上限、鏡像拉取策略、監(jiān)控指標采集頻率等等。這些細節(jié)后面我會專門展開講。所以在開篇我想先打破一個觀念很多人以為“容器化改造”就是把應用打成 Docker 鏡像再寫幾個 YAML 文件往集群里一扔。這種理解只完成了 20%剩下 80% 的工程量在穩(wěn)定性、可觀測性、安全性和運維體系上。3. 從 VM 到容器的底層機制鏡像、命名空間與上午架構(gòu)的關(guān)系3.1 鏡像分層為什么容器化能讓發(fā)布變得更快、更可控容器鏡像的分層設(shè)計可能比很多人想象中重要得多。一個典型 Java 服務鏡像大概分這么幾層基礎(chǔ)系統(tǒng)層比如帶有 glibc、時區(qū)信息、CA 證書的 Linux 根文件系統(tǒng)JRE 層應用依賴層jar 包應用配置層。打包時每一層都可能被緩存并被多個鏡像復用。這個設(shè)計帶來的好處很直接發(fā)布新版本時如果只改了應用代碼那其他層都不變構(gòu)建和推送只需要處理最上面的一層拉取時同理宿主機上如果已經(jīng)有基礎(chǔ)鏡像和依賴層只需要下載新增的那一小層。配合上鏡像加速器或離線鏡像倉庫發(fā)布速度會快很多。在千萬 QPS 架構(gòu)里發(fā)布速度意味著什么意味著你能更快地完成故障修復。線上出了問題你改了一行代碼理論上兩三分鐘內(nèi)新鏡像就能構(gòu)建完并滾動上線。而如果你還在用 VM 方式可能要先把包傳到所有機器再逐臺重啟進程整個過程不僅慢還容易因為機器環(huán)境差異出現(xiàn)“這臺成功、那臺失敗”的局面。3.2 Cgroups 與資源視圖為什么容器能更精細地裝箱Cgroups控制組是 Linux 內(nèi)核提供的資源限制能力可以限制、記錄和隔離一組進程對 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)的資源使用。容器的資源配額底層就是靠 Cgroups 實現(xiàn)的。在 VM 時代CPU 和內(nèi)存規(guī)格通常是固定的、不連續(xù)的你要么用 4C8G要么用 8C16G很少能精確到“這個服務只需要 1.5 個 CPU900MB 內(nèi)存以后還能動態(tài)調(diào)”。但容器化之后資源配額可以更細粒度地設(shè)置同一個宿主機上可以混布不同資源需求的容器裝箱率會比傳統(tǒng) VM 模式高很多。從成本角度看這可能是容器化為數(shù)不多能直接算出來的好處。但換一個角度看粒度變細也帶來了新的風險你以為限了 512MB 內(nèi)存實際 JVM 的堆外內(nèi)存、線程棧、Metaspace、Direct Memory 加起來可能輕松超過配額結(jié)果容器被 OOMKilled。應對辦法也很明確做容器化改造時不要只設(shè)置內(nèi)存上限還要配合 JVM 參數(shù)調(diào)整、HeapDump 采集和內(nèi)存監(jiān)控。3.3 網(wǎng)絡(luò)模型的變化IP 變得“不值錢”服務發(fā)現(xiàn)變得尤為重要VM 時代每臺 VM 有一個相對穩(wěn)定的 IP你的監(jiān)控系統(tǒng)、日志系統(tǒng)、白名單機制幾乎都是圍繞 IP 設(shè)計的。你可以通過 IP 快速判斷“這個請求是哪個機器處理的”也可以用 IP 來配置數(shù)據(jù)庫訪問白名單。但容器化的世界IP 是臨時資源。Pod 可以被銷毀、重建、被調(diào)度到其他節(jié)點上IP 會隨之變化。如果你還在容器里用“固定 IP 手動配置”的思維做網(wǎng)絡(luò)規(guī)劃會非常痛苦。所以容器化之后服務之間的調(diào)用關(guān)系不再依賴“知道對方的 IP”而是依賴“服務名 服務發(fā)現(xiàn)”。Kubernetes 內(nèi)部的 Service 和 DNS 解決了大部分流量路由問題服務之間的調(diào)用走的是 Service DNS 或 Service Mesh。過去那種“出問題我先看哪臺機器”的方式會變成“先看服務實例列表里有哪些副本日志集中在什么地方”。這個變化看著簡單實際影響深遠。如果你的團隊還停留在“SSH 到 VM 上 tail 日志”的排查習慣容器化之后會非常不適。日志必須集中采集指標必須按服務維度聚合鏈路追蹤必須成為標配。否則你面對幾百個隨時變化的 Pod根本沒有辦法做問題定位。4. 千萬 QPS 容器化的關(guān)鍵工程點從“能用”到“穩(wěn)如磐石”4.1 資源配額與 JVM容器世界里最容易翻車的地方很多從 VM 遷移到容器的 Java 團隊遇到的第一個坑就是內(nèi)存。在 VM 上跑得好好的 Java 應用放進容器里卻經(jīng)常被 OOMKilled。原因也不復雜JVM 默認的 MaxHeapSize 是根據(jù)宿主機內(nèi)存來算的不是根據(jù)容器配額。如果你不給 JVM 顯式設(shè)置 -Xmx它可能會申請超過容器限額的內(nèi)存。JVM 的堆外內(nèi)存包括 Metaspace、線程棧、Direct Buffer、JIT 編譯器內(nèi)存這些在容器里都屬于容器配額的一部分。解決思路是顯式設(shè)置 JVM 堆和容器內(nèi)存配額的關(guān)系通常建議 -Xmx 設(shè)置為容器內(nèi)存上限的 50%-70%。使用 Java 10對于較新的 JDK容器可以識別 CPU 限制如果你還在用 Java 8建議升級到 Java 8u191并配合 -XX:UseContainerSupport。預留 25%-30% 的內(nèi)存給非堆內(nèi)存避免因為 JVM 動態(tài)擴展或 JIT 編譯導致 OOM。如果原始業(yè)務的 QPS 比較高一定要先做一次壓測觀察容器在限制下的 Full GC 頻率、堆使用率和響應時間曲線再決定合適的配額和副本數(shù)。4.2 健康檢查、優(yōu)雅退出與滾動更新發(fā)布不再是玄學容器化對發(fā)布流程最大的改造在于發(fā)布變成了“聲明新的期望狀態(tài)等待集群自我調(diào)整”。但如果你沒有配置好健康檢查這個過程會變成災難。Kubernetes 里有三種探針啟動探針startupProbe、就緒探針readinessProbe和存活探針livenessProbe。在千萬 QPS 架構(gòu)里這三種探針的配置都不可省略啟動探針解決服務啟動慢的問題。如果你的應用啟動需要 60 秒但存活探針的 initialDelaySeconds 設(shè)成了 5 秒那容器還沒起來就被殺掉了。就緒探針決定流量是否進入 Pod。新 Pod 沒有 Ready 之前Service 不會把流量打進去。存活探針負責處理“進程活著但業(yè)務卡死”的情況比如死鎖、線程池耗盡的死循環(huán)。實際發(fā)布時如果你只做了“殺掉舊 Pod、啟動新 Pod”而沒有做優(yōu)雅退出可能出現(xiàn)存量請求被硬斷造成非常明顯的報錯率和服務不可用。嚴謹?shù)淖龇ㄊ桥渲?preStop讓容器在終止前先摘除流量等幾秒讓存量請求處理完然后再真正停止進程。注意不要把優(yōu)雅退出這一步省掉。千萬 QPS 場景下哪怕只有 0.1% 的請求在發(fā)布瞬間被斷開也會放大成大量業(yè)務報錯。4.3 鏡像倉庫、并發(fā)拉取與帶寬大集群擴容時的隱形瓶頸假設(shè)你有 1000 個節(jié)點某個大版本發(fā)布時所有節(jié)點需要同時拉新鏡像。如果鏡像很大比如 1GB而倉庫出口帶寬只有 1Gbps那理論上并發(fā)拉取會直接把帶寬打滿發(fā)布時間會被拉得非常長。常見的解法鏡像瘦身盡量使用 alpine 或精簡基礎(chǔ)鏡像Java 服務只帶 JRE 不帶 JDK。分層緩存把依賴較多的層盡量放在前面保證只有最上面的應用層需要變動。并發(fā)控制通過容器編排的配置限制集群內(nèi)同時拉取鏡像的節(jié)點數(shù)避免帶寬打滿。私有倉庫 就近部署在物理區(qū)域內(nèi)自建鏡像倉庫或者通過 P2P 分發(fā)組件減少源倉庫的壓力。這個問題平時不明顯但大促前擴容時經(jīng)常爆發(fā)。你會在控制臺看到一堆 Pod 處于 ImagePullBackOff 或者 ContainerCreating 狀態(tài)原因不是網(wǎng)絡(luò)不通而是拉取鏡像排隊太長。4.4 日志、監(jiān)控與鏈路追蹤排查問題的方式必須升級容器化之后應用日志不能在容器內(nèi)寫文件了。原因很簡單容器隨時可能被調(diào)度走宿主機上的日志文件會隨之丟失。而且多副本情況下你想看某個請求在某臺機器上的日志基本沒法手工“登上去找”因為實例本身可能是動態(tài)的。所以做容器化改造時日志方案必須改為“統(tǒng)一采集、集中存儲、檢索分析”。常見路徑是應用把日志寫到 stdout/stderr由日志采集 Agent比如 Filebeat、Fluent Bit采集到 Kafka再到 ES 或 ClickHouse或者在應用日志框架里配置為發(fā)送到統(tǒng)一日志服務比如 Loki、ELK 等。監(jiān)控和鏈路追蹤在這個階段也會變成剛需。在 VM 時代你還能通過 CPU 曲線和流量曲線大致猜出瓶頸在容器時代如果連調(diào)用鏈都沒有遇到跨服務的慢請求排查問題會非常痛苦。建議從改造的第一天就確定好監(jiān)控指標的最小集請求量、錯誤率、響應延遲P50/P95/P99、容器 CPU/內(nèi)存使用率、節(jié)點水位、發(fā)布變更記錄。5. 容器化改造的真實路徑不是“全量遷移”而是“分步驗證流量灰度”5.1 第一步先給業(yè)務做“容器化可行性畫像”不是所有業(yè)務都適合立刻容器化。我建議先做一個分類無狀態(tài)服務Web 服務、API 網(wǎng)關(guān)、RPC 服務、消息消費者。這類業(yè)務的容器副本之間沒有狀態(tài)關(guān)聯(lián)殺掉重啟任何副本都無所謂是最適合容器化的類型。有狀態(tài)服務MySQL、Redis、ES、Kafka。這類服務的數(shù)據(jù)和服務實例強綁定直接跑在普通容器里會有數(shù)據(jù)丟失風險通常需要使用 StatefulSet、PV/PVC、本地盤調(diào)度或者其他狀態(tài)化方案復雜度比無狀態(tài)服務高一個量級。定時任務CronJob 在 Kubernetes 里能跑但要注意并發(fā)策略和補跑機制不要多個副本同時執(zhí)行同一個任務。批處理任務適合用 Job 模式跑跑完即結(jié)束比常駐服務更靈活。從改造優(yōu)先級來看應該先挑無狀態(tài)、流量可灰度、故障容忍度高的業(yè)務跑通整套流程。不要一上來就把核心數(shù)據(jù)庫塞進容器里。5.2 第二步用“流量灰度”替代“機房整體切換”我見過很多團隊做容器化改造時喜歡采用“一刀切”的方式隔離出一個專門的新集群把應用整個遷移過去等穩(wěn)定了再切換流量。這種做法的風險在于如果遷移過程中出現(xiàn)一個你沒想到的問題切換不了影響的不是某個服務而是整條鏈路。更穩(wěn)妥的方式是“邊跑邊換”讓容器版本和 VM 版本并行運行一段時間通過網(wǎng)關(guān)逐步灰度流量。比如第一階段容器副本只接收 5% 的測試流量主要驗證基礎(chǔ)功能和鏈路連通性。第二階段放出 10% 的線上流量觀察錯誤率、延遲、GC、CPU、內(nèi)存等指標是否和 VM 版本一致。第三階段逐步擴大到 50%再 100%最后下線 VM 副本。這個思路的核心是不要用“徹底搬遷”的心態(tài)做改造要用“新老系統(tǒng)并存、逐步替代”的心態(tài)做改造。容器的調(diào)度、網(wǎng)絡(luò)、存儲、監(jiān)控體系都需要時間磨合灰度期間暴露的問題是成本最低的學習機會。5.3 第三步補齊容器化缺少的工程能力容器和編排平臺解決的是“調(diào)度和部署”問題但它不自動解決以下工程問題配置管理配置項應該用 ConfigMap / Secret 管理不能直接打進鏡像。否則每次改配置都要重新構(gòu)建鏡像。權(quán)限控制容器內(nèi)部不要以 root 用戶運行業(yè)務容器要有獨立的非 root 用戶Dockerfile 里需要用 USER 指令切換。安全掃描鏡像上線前要做漏洞掃描不信任的第三方鏡像不要直接拉進生產(chǎn)集群。鏡像安全和容器安全是兩個不同維度鏡像掃描解決的是打包階段的問題運行時安全解決的是逃逸和異常訪問的問題。資源隔離很多團隊在 Kubernetes 里只設(shè)置 requests不設(shè)置 limits。這種配置在流量低時看不出來流量高時一個 Pod 會把整臺節(jié)點打爆。合理做法是先做壓測再設(shè)置 requests 和 limits并且對 CPU 與內(nèi)存分別設(shè)置。備份與恢復對于有狀態(tài)服務如果最終還是決定容器化必須提前設(shè)計好持久化存儲和備份策略不能依賴“容器還在”這個狀態(tài)。6. 千萬 QPS 場景下的容器化調(diào)優(yōu)默認配置跑不出高并發(fā)6.1 kube-proxy 與 iptables/ipvs連接與負載均衡能不能扛住Kubernetes 默認的 kube-proxy 模式如果是 iptables在大規(guī)模高并發(fā)場景下會遇到兩個問題Service 數(shù)量、Endpoint 數(shù)量非常大時iptables 規(guī)則會非常龐大更新規(guī)則時可能造成連接閃斷。iptables 的規(guī)則匹配是順序匹配規(guī)則多了之后轉(zhuǎn)發(fā)性能會有明顯下降。生產(chǎn)環(huán)境通常建議改用 IPVS 模式。IPVS 在內(nèi)核態(tài)實現(xiàn)了負載均衡支持多種調(diào)度算法性能比 iptables 好很多而且規(guī)則同步更穩(wěn)定。切換后ClusterIP 對應的負載均衡轉(zhuǎn)發(fā)能力會有明顯提升。另外還有一個容易被忽略的點如果服務規(guī)模很大DNS 解析 QPS 也會非常高。Kubernetes 默認的 CoreDNS 配置在大量 Pod 并發(fā)解析時會成為瓶頸需要調(diào)整副本數(shù)、部署模式比如 daemonset和緩存參數(shù)。6.2 節(jié)點水位與調(diào)度策略不要讓任何一臺宿主機成為“落單熱點”容器化之后宿主機故障的影響面取決于這臺機器上跑了多少個業(yè)務 Pod。如果調(diào)度策略不關(guān)注 Pod 的“反親和性”某個核心服務的所有副本可能同時落在同一臺宿主機上那這臺機器一掛整個服務就瞬間不可用。在千萬 QPS 場景下調(diào)度策略至少要考慮核心服務多副本盡量打散到不同節(jié)點、不同可用區(qū)?；旌喜渴鸬蛢?yōu)先級任務與核心業(yè)務時要設(shè)置優(yōu)先級和搶占策略避免低優(yōu)先級任務搶占高優(yōu)先級業(yè)務的資源。設(shè)置節(jié)點資源預留kube-reserved、system-reserved不要把節(jié)點資源 100% 分配給業(yè)務容器防止宿主機自身系統(tǒng)和組件異常。6.3 大促擴容容器數(shù)量多了問題也會跟著變多千萬 QPS 的大促場景下系統(tǒng)會自動擴容出大量副本。這個時候出問題的往往不是應用本身而是容量側(cè)的基礎(chǔ)設(shè)施節(jié)點數(shù)增加容器集群控制面 API Server 的請求量會上升etcd 的寫入 QPS 也會漲。需要提前評估集群規(guī)格必要時拆分多個集群。Pod 數(shù)量增加后監(jiān)控 Agent 采集的指標數(shù)量也會增長監(jiān)控系統(tǒng)自身需要擴容。服務發(fā)現(xiàn)和注冊中心需要同步擴容尤其是如果你的服務仍然依賴注冊中心做 RPC 路由注冊中心會成為新的瓶頸。如果新的 Pod 需要掛載存儲存儲系統(tǒng)的并發(fā)能力也要提前壓測避免擴容后因存儲 IO 跟不上導致服務失敗。簡單說容器化把“機器維度”的擴容問題變成了“平臺維度”的擴容問題。機器不夠用變成集群不夠用帶寬不夠用變成倉庫或 DNS 不夠用連接數(shù)不夠變成 Service 轉(zhuǎn)發(fā)或注冊中心不夠用。你需要用新的視角去看容量規(guī)劃和壓測。7. 落地前的自檢清單一套可以直接拿走的容器化改造框架到這里我已經(jīng)把從 VM 到容器的架構(gòu)邏輯講得差不多了。但我知道大部分人看到最后真正需要的是一個能落地執(zhí)行的檢查表。下面這個清單是這套方法論的核心沉淀也是我建議你在動手改造前先逐條過一遍的東西。第一層服務畫像[ ] 服務是否有狀態(tài)數(shù)據(jù)是否存在本地文件、本地磁盤或內(nèi)存中[ ] 服務是否支持優(yōu)雅退出進程收到 SIGTERM 后能否在有限時間內(nèi)處理完存量請求[ ] 服務啟動時間是多少是否超過 90 秒是否需要啟動探針兜底[ ] 服務的內(nèi)存占用峰值是多少JVM 的堆內(nèi)和堆外內(nèi)存是否都統(tǒng)計過第二層鏡像與供應鏈[ ] 基礎(chǔ)鏡像是否精簡能否去掉編譯工具鏈、包管理器和緩存[ ] 鏡像中是否存在敏感信息密碼、密鑰、Token[ ] 是否用了私有鏡像倉庫鏡像上傳后是否做漏洞掃描[ ] 是否配置了鏡像拉取策略Always / IfNotPresent第三層編排與配置[ ] 配置是否已經(jīng)從鏡像中剝離能否用 ConfigMap / Secret 管理[ ] 是否設(shè)置了 requests 和 limits是否經(jīng)壓測驗證過[ ] 就緒探針、存活探針、啟動探針的閾值是否和服務真實啟動時間匹配[ ] 優(yōu)雅退出是否正確配置preStop 是否執(zhí)行第四層可觀測性[ ] 日志是否已改為集中采集能否在日志平臺按 traceId 串聯(lián)全部鏈路[ ] 監(jiān)控是否覆蓋請求量、錯誤率、P99 延遲、容器資源、節(jié)點水位和服務發(fā)現(xiàn)狀態(tài)[ ] 是否有按服務維度而不是機器維度的告警規(guī)則[ ] 鏈路追蹤是否已經(jīng)接入核心業(yè)務鏈路第五層穩(wěn)定性與容量[ ] 是否對核心服務做過容器資源限制下的壓測[ ] 是否對鏡像拉取并發(fā)、DNS 并發(fā)、Service 轉(zhuǎn)發(fā)能力和注冊中心容量做過評估[ ] 核心服務多副本是否配置了反親和性避免打到同一臺宿主機[ ] 大促擴容腳本是否演練過控制面是否撐得住流量洪峰這個清單看起來很長但每一項背后幾乎都有真實事故在支撐。你在小規(guī)模場景里可能感受不到它們的作用但一旦流量漲到千萬級任何一個“看起來不重要的配置項”都可能成為壓垮系統(tǒng)的最后一根稻草。8. 容器化之后架構(gòu)的長期方向平臺能力才是真正的分水嶺聊完了改造步驟和調(diào)優(yōu)細節(jié)我想把視野拉遠一點說一說容器化這件事對架構(gòu)演進的長期意義。從 VM 到容器起初看起來只是部署方式的改變。但真正堅持做下來的團隊會發(fā)現(xiàn)這件事的長期價值在于它逼著你把部署、配置、監(jiān)控、日志、安全、權(quán)限、容量管理和發(fā)布流程全部“產(chǎn)品化”和“平臺化”。當這些能力沉淀為平臺服務之后任何團隊上線新服務時不再需要重復造輪子而是直接通過平臺申請資源、配置流水線、選擇監(jiān)控模板。到了這個階段業(yè)務系統(tǒng)的性能瓶頸已經(jīng)不完全取決于單機或單服務的能力而是取決于平臺對資源的調(diào)度效率、對故障的恢復速度和對外部流量變化的響應速度。這也正是千萬 QPS 架構(gòu)能夠持續(xù)演進的關(guān)鍵不是靠一次性的性能優(yōu)化而是靠一套可以讓復雜系統(tǒng)穩(wěn)定運轉(zhuǎn)的機制。從工程經(jīng)驗看這個平臺化的過程通常不是一蹴而就的。先有一個小的容器集群跑幾個非核心服務然后慢慢擴大范圍接入網(wǎng)關(guān)、核心業(yè)務、存儲層最后再建設(shè)多集群、多可用區(qū)、統(tǒng)一發(fā)布和彈性伸縮體系。每個階段都有各自的坑但只要方向是對的每走一步系統(tǒng)的響應能力和確定性都會上一個臺階?；氐轿恼麻_頭那個判斷容器化改造的核心價值不是“從 VM 換成容器”這件事本身而是通過容器和編排技術(shù)讓整個技術(shù)團隊擁有了更快的響應速度、更小的故障半徑和更確定的運維流程。如果你所在的業(yè)務已經(jīng)接近或超過百萬 QPS并且還在為擴縮容速度、發(fā)布效率和故障恢復時間焦慮那么容器化不是一道“要不要做”的選擇題而是一個“什么時候做、以什么順序做”的工程問題。希望這篇文章能給你一個相對完整的認知框架讓你在做技術(shù)決策時不至于被工具和概念牽著走。這也是我認為“千萬 QPS 架構(gòu)”系列里容器化這一講最值得沉淀下來的內(nèi)容。