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