AMS 新聞影片廣告的雲原生容器化之路

• 2022 年 5 月 25 日
• 筆記
• docker, istio, k8s, Kubernetes, Prometheus, TKE, 雲原生, 雲計算, 容器, 騰訊雲原生

作者

卓曉光，騰訊廣告高級開發工程師，負責新聞影片廣告整體後台架構設計，有十餘年高性能高可用海量後台服務開發和實踐經驗。目前正帶領團隊完成雲原生技術棧的全面轉型。

吳文祺，騰訊廣告開發工程師，負責新聞影片廣告流量變現相關後台開發工作，熟悉雲原生架構在生產實踐中的應用，擁有多年高性能高可用後台服務開發經驗。目前正推動團隊積極擁抱雲原生。

陳宏釗，騰訊廣告高級開發工程師，負責新聞影片廣告流量變現相關後台開發工作，擅長架構優化升級，有豐富的海量後台服務實踐經驗。目前專註於流量場景化方向的廣告系統探索。

一、引言

新聞影片廣告團隊主要負責騰訊新聞、騰訊影片、騰訊微視等媒體廣告流量的廣告變現提收工作，在媒體流量日益複雜，廣告變現效率逐步提升的背景下，團隊需要負責開發並維護的後台服務數量增長迅猛，服務維護成本與日俱增，傳統的基於物理機的部署以及運維方案已經成為了制約團隊人效進一步提高的瓶頸。

自2019年開始，公司鼓勵各研發團隊將服務遷移上雲，並對服務進行雲原生改造。為了響應公司的號召，在充分調研了服務上雲的收益後，我們決定將團隊維護的業務分批上雲，提升後台服務的部署及運維效率。

二、業務上雲「三步走」

圖2-1 新聞影片廣告後台整體架構圖

新聞影片廣告主要承接來自騰訊新聞、騰訊影片、片多多以及騰訊微視的廣告流量接入並負責提升流量的變現效率，具體包括流量接入、形態優化、ecpm 優化等等。如上圖所示，由於接入的業務需求複雜多樣，而且彼此之間有顯著差異，比如內容廣告、激勵廣告等，導致新聞影片廣告的後台服務具有如下特點：

1. 請求量大，線上服務需要承接來自流量方的海量請求，服務性能及穩定性要求高；
2. 服務數量眾多，不同服務之間負載差異大，同一服務不同時間段負載變化大，人力運維成本高；
3. 依賴的外部組件多，服務發布與運維的流程都與傳統的物理機模式深度綁定，歷史包袱重，平滑上雲挑戰大。

針對以上這些問題，我們在服務遷移上雲的過程中，訂製了」三步走「計劃：

1. 搭建上雲依賴的基礎組件並規範上雲流程；
2. 離線服務快速上雲；
3. 海量在線服務平滑上雲；

三、第一步——搭建基礎組件&規範上雲流程

為了提高服務上雲效率，方便各個服務負責人自行將服務遷移上雲，我們首先搭建了雲服務基礎組件，並輸出了服務上雲的規範，主要包括容器化 CI/CD 和服務平滑上雲兩部分。

3.1 容器化 CI/CD 配置

想要上雲，首先要考慮的問題就是如何將服務在雲平台上部署。我們對物理機和雲平台的部署情況做對比。

表3-1 物理機和雲平台的部署情況對比

可以看到，物理機和雲平檯面臨的情況完全不同。在物理機時代，我們採用織雲部署服務，在織雲平台手工配置伺服器目標，管理二進位和部署，而轉向雲平台後，大量 Pod 動態變化組成的集群，與假定管理對象都是固定 ip 的伺服器的織雲並不契合。因此，我們轉向採用藍盾實現自動化集成與部署。

藍盾將集成與發布流程整合併統一管理，程式碼合入即自動觸發編譯、回歸、審核和發布流程，無需額外人工。為了兼容已有的物理機服務的發布流程，保證混合部署服務的版本一致，二進位包仍然使用織雲管理，由藍盾流水線編譯產物後推送至織雲。藍盾流水線從織雲拉取二進位後和運維提供的包含必要 agent 的基礎鏡像打包，將環境與二進位標準化，模版化，以鏡像的方式作為最終產物發布，拉起即用，便於 pod 快速部署與擴容，減少了手工標準化伺服器的工作量。最終，我們達成了如下目標：

1. 自動化部署，節約人力；
2. 兼容物理機發布流程，便於混合部署；
3. 模版化環境，方便快速擴容。

圖3-1 藍盾實現 CI/CD 流水線

3.2 後台服務平滑上雲

3.2.1 基礎組件平滑上雲

新聞影片廣告後台服務依賴北極星、智研等基礎組件提供負載均衡、指標上報等基礎功能，然而在將這些基礎組件遷移上雲後，我們發現它們並不能如期提供能力，影響了服務正常運行。經過深入排查分析，我們發現，這些組件不能正常工作的原因主要包括以下2點：

1. 容器的 ip 不屬於 idc 網段，這些基礎組件在容器中的 agent 與它們的 server 無法連通；
2. 容器 ip 會隨著容器的升級和遷移而發生變化，組件註冊的 ip 頻繁失效。

而這2個問題都是由於 TKE 平台為容器配置默認的 Overlay 網路策略導致的。為了解決上述的問題，TKE 平台方建議我們採用「浮動 ip」和「刪除或縮容 APP 時回收」等高級網路策略。浮動 ip 策略不同於 overlay，分配由運維指定的 idc 網段的 ip，其他 idc 機器上的服務可以直接訪問；「刪除或縮容 APP 時回收」策略將 ip 與對應的 pod 綁定，即使 pod 更新與遷移，ip 也不會發生改變。

我們在新增工作負載時，在高級設置中配置浮動 ip 與刪除或縮容 APP 時回收的策略，保證增量負載的組件工作正常；同時修改已有負載的 yaml 配置，添加如下圖的配置項，將存量負載的配置對齊增量負載。雙管齊下，最終解決了網路策略對基礎組件的影響，促進基礎組件與雲平台的協同工作。

圖3-2 TKE 平台新增負載策略選擇

圖3-3 TKE 平台存量配置修改

3.2.2 流量平滑遷移

將服務成功部署上雲後，接下來就需要讓雲上集群承接外部流量，發揮職能。新聞影片流量當前都路由至物理機，若直接全量切換訪問雲服務，會面臨如下問題：

1. 雲上集群服務未經過流量考驗，可能導致未知的問題在線上暴露；
2. 新集群未充分預熱，可以承受的 QPS 較低。

可以想見，這樣激進的操作極其危險，容易引發事故甚至集群崩潰，因此我們需要將流量平滑的切至雲平台，留下充裕的時間應對上雲過程中出現的問題。

針對平滑切換的目標，我們提出了兩個上雲指導方針：

1. 小步慢跑。分多階段遷移流量，每一次僅將少量的流量切換至雲平台，切換後，觀察系統監控以及業務指標監控無異常後，再進行下一次的流量遷移。
2. 灰度驗證。對標物理機的發布操作，挪出部分資源搭建灰度集群，每一次流量切換前，先在灰度集群上面實驗，灰度集群驗證完成後，再在正式集群上執行對應的操作。

最終，我們在全量切換前提前發現問題並解決，保證線上服務的穩定，實現了流量平滑順暢的遷移。

四、第二步——150+離線服務的快速上雲

新聞影片廣告的離線後台服務數量眾多，服務總數150+；功能也很複雜多樣，既有影片特徵抽取等高計算量的服務，也有僅提供通知能力的低負載的服務。在上雲過程中，如何為紛雜繁多的離線服務，設計與之適應的資源選取、優化與調度方案？對於這個問題，我們總結出了一套符合新聞影片廣告離線業務特點的上雲方案。

4.1 離線服務資源分配方案

4.1.1 資源分配模板設計

為了提升 CPU 和記憶體的利用率，我們希望對不同種類的服務分配合適的資源，保證資源充分利用。在上雲過程中，我們總結出一套分配資源的方法。離線服務的單個 pod，CPU 限制在0.25核-16核之間，記憶體最小不能低於512M，在滿足下限的同時，最好與核數保持1：2的比例。遵循這套方法有什麼好處呢？下面是我們總結的原因：

1. 若 CPU 核數大於32，可能導致 TKE 平台在調度時，找不到空閑的核數足以滿足要求的節點，導致 Pod 擴容失敗；
2. 若 CPU 核數大於32，可能導致 TKE 平台的資源碎片化，降低集群的整體資源利用率；
3. 如果容器分配的 CPU 低於0.25核，或者記憶體低於512M，會導致北極星等公共組件的 agent 無法正常運行，容器無法正常拉起。

在實際的使用中，我們結合上雲的實戰經驗，總結出不同類型服務的推薦配置表格如下所示。

表4-1 不同類型服務的推薦配置

4.1.2 基礎鏡像簡化

按照推薦配置表格的設置，我們將離線服務部署在 TKE 平台上。一開始，服務能夠平穩的運行，然而，隨著時間的推移，公共鏡像中的 agent 越來越多，agent 佔用的資源越來越大，對於通知服務等分配資源較少的服務，agent 的資源佔用提升後，甚至超過服務本身使用的資源，導致 OOM 或容器無法拉起等異常表現。

我們既想要優化不斷增長的agent數量帶來的資源消耗提升，又想要享受公共鏡像的更新，有沒有兩全其美的辦法呢？答案是肯定的。我們在 CI/CD 流水線構建業務鏡像時，通過 RUN 命令新增刪除多餘 agent 的流程。在刪除 Agent 流程的內部，我們配置標記服務依賴的必要鏡像，反選其他無用的 agent，執行刪除。由於RUN命令新增了一層不可變文件層，不影響該層以前的公共鏡像文件層，公共鏡像更新 agent 時，也會作用到業務鏡像。通過這種方式，我們既節省了 agent 使用的資源，保證低資源分配的服務正常運行，又享受了公共鏡像自動更新 agent 帶來的便利。

圖4-1 鏡像瘦身示意圖

4.2 離線服務 HPA 配置方案

很多離線服務的負載並不是穩定不變的，白天與夜晚的負載往往會有較大差異，如果為這些服務分配恆定的資源，可能會導致服務負載高峰期資源過載，負載低谷期資源閑置。因此，我們希望分配給容器的資源，能夠隨著服務負載的變化而變化。為此，我們選擇使用HPA組件實現彈性縮擴容。

4.2.1 HPA配置模板設計

想要使用 HPA，首先需要選取觸發是否應該縮擴容的指標。選取衡量指標的核心思想，是盡量選取變化最大的指標，避免變化較小的指標限制 Pod 數量的變化，導致其他負載指標的變化超出資源限制。對於離線任務而言，一般來說，CPU 使用率更容易隨著任務的開啟和結束髮生變化，而記憶體一般存儲相對固定的上下文，比較穩定，選取 CPU 使用率作為判定標準比較合理。

圖4-2 選取 CPU 利用率作為 HPA 的衡量指標

其次，我們要指定 Pod 數量的上限和下限。上限可以避免不正確的配置造成大量 Pod 創建，空耗集群資源，影響集群穩定性。而下限有兩個作用，第一，確保 Pod 數量符合 HPA 組件的最小副本不為零的限制，避免組件採集不到 metrics，無法獲取縮擴容調整所依賴的指標後，失去調節副本數量的功能，從而使集群陷入 Pod 數量恆定為0，無 pod 可供服務的情況；第二，若少量 Pod 因故障陷入無法服務的狀態，保證一定數量的 Pod 可以減小故障對服務的衝擊。

圖4-3 設置 HPA 調整實例數量的上下限

最後，我們需要根據具體的負載變化曲線，決定彈性縮擴容的策略。

1. 如果負載曲線在每一天每一個時段下都高度一致，我們可以考慮使用 CronHPA 組件，人工指定不同時段的 Pod 數量，定期調度。
2. 如果負載曲線每天都在發生變化，不論趨勢還是數值，我們都可以使用 HPA 配置，設置 CPU 使用率參考值，要求集群在利用率超過或低於指定值時進行 Pod 數量的調整，將 Pod 的 CPU 使用率維持在容忍範圍內。
3. 如果負載曲線每天發生變化，但是存在定時發生的尖峰，為了避免集群自行調整的速度慢於負載增長的速度，導致集群被壓垮，我們可以結合 CronHPA 與 HPA 使用，平時將控制權交給 HPA，在尖峰到來前使用 CronHPA 提前擴容，既保證尖峰不會衝垮集群，又能享受集群自動調整 Pod 數量帶來的便利。

圖4-5 結合 CronHPA 與 HPA 共同使用

由此，我們完成了 HPA 的設置，通過多樣的策略，實現了集群分配資源隨著服務負載變化。

4.2.2 IP 白名單自動變更

服務 Pod 數量動態變化，會導致部分服務運行的環境中，IP 地址經常改變。而廣告業務服務訪問下游介面時，大多需要通過靜態的 IP 白名單校驗。靜態的 IP 白名單不再適合雲原生環境下部署的服務，我們希望推動下游的 IP 白名單支援動態添加容器 IP，擁抱雲原生。為此，我們根據下游許可權的敏感等級，使用不同的處理方式完成改造。

1. 對於敏感等級較低的介面，我們推動介面作者提供 IP 自動上報的介面，為每一位用戶下發憑證，服務啟動前使用調用介面，上報當前的 IP 地址加入白名單。例如北極星為我們提供了上報腳本，我們僅需要在容器的啟動腳本內調用上報腳本即可完成上報。由於服務運行期間，IP 將不再變更，因此僅需要上報 Pod 拉起時的 IP，即可保障服務的穩定運行。
2. 對於敏感等級高的介面，作者不信賴來自用戶的操作，擔心用戶的錯誤操作擊穿白名單保護，例如 CDB 團隊就擔心廣告隱私數據泄漏。我們推動這些團隊與 TKE 平台方合作，開放授權給 TKE 平台，用戶申請鑒權憑證後託管在 TKE 平台上，由 TKE 平台拉起容器的時候負責上報新的 IP。

圖4-6 TKE 平台配置授權

最終，我們實現了下游介面對容器縮擴容的感知，自動化更新白名單，保障服務在彈性縮擴容生效的情況下正常工作。

五、第三步——海量在線服務的平滑上雲

新聞影片廣告系統承載百億級別的流量，後台在線服務的QPS最高可以達到幾十萬的級別，在遷移上雲後同樣需要保證服務的高性能、高可用以及可擴展等。為了滿足這個要求，我們與運維、TKE平台方共同合作，解決上雲過程中所遇到的問題，保障海量在線服務順利平滑上雲。

5.1 計算密集型服務延時毛刺優化

廣告系統中，在線服務大多屬於計算密集型，需要較高的性能保證計算按時完成。如果相關的計算邏輯在不同的 CPU 核間頻繁調度，會引發 cache miss 頻率的提升，程式性能降低，請求時延經常出現毛刺。因此，部署在物理機器上的服務大量使用綁核能力，手工指定服務運行的 CPU，提升局部性，提升程式性能。

然而上雲後，平台對 CPU 資源進行虛擬化管理，服務在容器內通過「/proc/cpuinfo」獲取到的是分配隔離和重排序後的虛擬 CPU 列表，與節點實際的 CPU 列表大相徑庭。使用虛擬的 CPU 列表進行綁核操作，不僅可能綁定到未分配的 CPU，性能不符合預期，甚至會綁定到不存在的 CPU，引發程式錯誤。

圖5-1 96核機器節點上，某容器內虛擬化的 CPU 列表

因此，需要找到一種在雲平台上獲取實際 CPU 列表的辦法。我們考慮到雲平台通過 cgroup 管理並隔離資源，可以嘗試在 cgroup 中尋找獲取實際 CPU 列表的介面。於是我們查找資料發現，cgroup 提供「/sys/fs/cgroup/cpuset/cpuset.cpus」子系統，可以獲取到虛擬 CPU 列表在物理列表上的實際映射範圍，符合我們的要求。我們修改綁核功能中獲取 CPU 列表的程式碼，將讀取 proc 子系統的部分改為讀取 cgroup 子系統，從而成功實現雲上服務的綁核功能。

圖5-2 cgroup 實際分配的 CPU 列表

5.2 在線服務的高可用性保障

在線服務的生命周期分為三個階段，服務啟動，準備就緒，服務銷毀。服務只有處於準備就緒階段才對外可用。而集群的可用性，取決於加入負載均衡的服務中準備就緒的比例。因此，要想提高服務的可用性，可以從兩個方向努力：

1. 降低服務啟動的時長，提升準備就緒狀態在服務生命周期的佔比。
2. 降低訪問服務的失敗率，保證載入和銷毀階段的服務不加入負載均衡。

5.2.1 降低服務啟動時長

想要服務的啟動時長，需要分析服務啟動過程中，有哪些耗時佔比高的操作。經過分析，我們發現，廣告服務在服務啟動的過程中，其中有一個步驟是通過文件同步服務 byteflood，訂閱同步廣告、素材、廣告主等數據的文件到容器本地。這個步驟非常耗時，占上下文載入階段的耗時大頭。有沒有什麼辦法能夠降低這個步驟的耗時呢？

深入探索後，我們找到了優化的空間。原來，byteflood 每次都需要拉取全量的數據文件。為什麼不能增量拉取呢？因為 byteflood 組件在容器中同步到本地的文件，存儲在容器的可變層，一旦容器由於升級或者遷移觸發重建，則數據文件全部丟失，必須重新拉取全量文件。看來，只需要持久化存儲數據文件，我們就可以避免文件丟失，採用增量拉取的方式更新數據，從而降低數據訂閱步驟的耗時，縮短上下文的載入時長，提高服務的可用性。

我們採用掛載外部數據卷(volume)的方式存儲數據文件。外部數據卷獨立於容器文件系統，容器重建不會影響外部數據卷中的文件，保證了數據文件的持久化。

圖5-3 使用掛載點持久化訂閱數據文件

然而，使用 volume 掛載後，我們遇到了路徑不一致的新問題。由於TKE平台規範限制，掛載的路徑和物理機上不一致，為了保持雲服務和物理機的服務配置一致，我們想要通過軟鏈將配置路徑指向掛載路徑。但是掛載的行為發生在容器拉起時，而服務進程啟動前，即需要保證配置路徑包含數據文件。如果需要在pod啟動後手工維護軟鏈，不僅生效時間可能在服務進程執行讀取操作後導致服務讀不到數據，而且生成的軟鏈同樣面臨容器重建後被丟棄的問題。為此，我們將容器的entrypoint，即容器啟動時調用的命令，替換為自行實現的啟動腳本，在腳本內加入生成軟鏈的語句，服務啟動語句放在軟鏈的後面。容器啟動即執行軟鏈操作，無需手工處理，重建也能保證再次執行，解決了配置路徑的問題。

圖5-4 軟鏈指向實際掛載路徑，對齊配置路徑

最終，我們成功的外掛了數據文件，將服務啟動時長從5分鐘降低到10秒鐘，效果顯著。

5.2.2 降低訪問服務的失敗率

容器內服務的狀態若處於載入中或者已銷毀，將無法處理請求，如果這些無法處理請求的容器的 IP 處於負載均衡的列表中，就會降低集群可用性。想要降低請求訪問服務的失敗率，必須保證負載均衡關聯的服務均處於準備就緒的狀態，而保證負載均衡關聯的服務均處於準備就緒的狀態，關鍵在於將負載均衡的關聯狀態納入服務的生命周期管理，服務脫離載入狀態前，不允許容器加入負載均衡，服務如果需要變更至銷毀狀態，需要在變更前將容器地址從負載均衡服務中剔除。

平台側已經將公司的負載均衡服務——北極星——納入容器的生命周期，不將 Not Ready 的容器加入北極星，容器銷毀時將容器地址從北極星剔除。然而，由於容器的生命周期不同於服務生命周期。容器進入 Ready 狀態時，服務可能仍在載入上下文，被加入北極星卻無法提供服務；容器銷毀時，平台發起剔除的請求，但是北極星組件內部狀態並非即時更新，可能在容器銷毀後，依然轉發流量到已銷毀的容器。需要找到合適的方法，使北極星感知服務生命的周期，避免流量轉發至載入或銷毀狀態的服務。

想要禁止載入狀態的服務加入負載均衡，可以藉助平台方提供的就緒檢查功能。就緒檢查通過定期檢查業務的 tcp 埠狀態，判斷服務是否已經載入完成，若未載入完成，則將 Pod 狀態設置為 Unhealthy，同時禁止上游的北極星將流量轉發到這個容器，直到載入完成。通過就緒檢查，我們保證在服務載入完成前，不會有請求發送至服務所在的 Pod。

圖5-5 配置就緒檢查

想要保證服務變更至銷毀狀態前將服務地址踢出負載均衡，同樣需要藉助 TKE 平台的功能——後置腳本。平台側允許業務方指定一段腳本，該腳本將在容器銷毀前執行。我們在該腳本內執行等待一段時間的操作，保證上游的負載均衡器更新狀態後，再銷毀容器。通過後置腳本，我們保證容器在銷毀前，負載均衡不再向該容器轉發任何請求。

圖5-6 後置腳本示例

5.3 高並發服務連接失敗優化

新聞影片流量大部分在線服務需要承載海量請求，同時處理大量的並發，例如品效合一後台服務。在這些服務遷移到 TKE 平台的過程中，隨著流量的逐步增長，系統失敗量顯著增加，特別的，一些使用短連接的服務出現了大量連接失敗的情況。為此，我們和運維以及 TKE 平台方的同學共同合作，排查並解決了問題，順利推進新聞影片團隊業務在線服務全部上雲，同時也增加了大家將海量服務遷移上雲的信心。

經過排查，我們發現錯誤率的提升主要由兩點導致。

• 1. 內核的流量統計功能長期佔用 CPU 導致網路處理延遲。 kubernetes 通過 ipvs 模組管理 NAT 規則控制流量轉發容器，而 ipvs 默認開啟流量統計功能，他向內核註冊計時器觸發統計操作。計時器觸發時，通過自旋鎖佔用 CPU，遍歷規則統計。一旦節點上 Pod 數量較多，規則數量多，則計時器長期佔用 CPU，影響服務進程處理回包。
• 2. 連接數超出 NAT 連接追蹤表的上限導致新連接被丟棄。 kubernetes 通過 nf_conntrack 模組記錄連接資訊，而 nf_conntrack 的實際實現為固定大小的哈希表。一旦表被填滿，新增的連接會被丟棄。

圖5-7 服務日誌展示的連接表容量已滿的錯誤

針對第一點，我們希望關閉內核模組 ipvs 的流量統計功能。然而集群的 tlinux 版本與外網版有區別，缺少流量統計功能的開關。平台方推動新增集群 tlinux 修補程式同步機制，將外網版本的修補程式應用在集群節點上，新增流量統計開關的內核參數。我們配置關閉統計功能後，錯誤數量下降顯著。

圖5-8 安裝修補程式並關閉統計功能後的效果

針對第二點，我們希望增大連接追蹤表的大小，避免連接丟棄的問題。平台方及時響應，調整內核參數，保證追蹤表大小大於當前連接數。修改配置後，服務日誌不再列印「table full」，錯誤數量也大為降低。

圖5-9 提升 tke 流量權重後錯誤數飆升

圖5-10 調整哈希表大小後錯誤數幾乎跌零

在 TKE 平台方的幫助下，我們共同解決了業務上雲過程中存在的高並發環境下連接失敗問題，成功的將新聞影片流量的在線服務都遷移至 TKE 平台。

六、成果展示

圖6-1 上雲成果

表6-1 上雲前後情況對比

新聞影片廣告團隊積極擁抱雲原生，在 TKE 平台以及運維團隊的協作與支援下，推動150+後台服務全部上雲，上雲負載累計核心達到6000+，大大提升了運維效率和資源利用率。資源利用率最高提升至原來的10倍，運維效率提升超過50%，上雲過程中，針對服務的特點訂製化改造適配雲原生，沉澱了針對海量服務、離線服務等多套上雲實踐方案，有效提高了服務上雲效率。

關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

福利：

①公眾號後台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後台回復【系列】，可獲得《15個系列100+篇超實用雲原生原創乾貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列。

③公眾號後台回復【白皮書】，可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》

④公眾號後台回復【光速入門】，可獲得騰訊雲專家5萬字精華教程，光速入門Prometheus和Grafana。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！