導語 | “雲上生長，降本增效”是 2020 年騰訊 AMS (廣告營銷服務線)上雲的主題，希望通過對騰訊雲新技術的應用，及自研上雲重構部署的機會，實現成本大幅下降，性能提升的雙重目標。通過上半年實踐，在騰訊雲團隊及運營管理部的支持下，整體效果超出預期。本文將講述期間遇到過的困難及優化歷程，希望與大家一同交流。文章作者：凌飛，騰訊運維開發工程師。
一、業務架構
本階段上雲的主要鏈路爲上圖中紅框部分，這條鏈路爲廣告播放鏈路，是整個廣告業務中最核心，也是性能要求最高的鏈路，有以下特點：
1. 請求量大
日均請求量近千億級別，機器量佔了AMS自有機器量的絕大部分，整體性能即使是1% 的上下波動都會涉及幾百臺機器的變動。
2. 鏈路拓撲復雜及性能壓力極大
整個播放鏈路涉及 40+ 的細分模塊。在 100~200 毫秒（不同流量要求有差異）的極短時間內，需要訪問所有模塊，計算出一個最好的廣告。
###3. 數據量大
大量的廣告數據及迴流訓練數據在整個網絡中流轉，對帶寬及存儲帶來了極大的壓力。
二、上雲方案選型
當前上雲的主流路線主要是 CVM 或 TKE，在考慮 AMS 的上雲路線時，我們主要考慮了以下兩點:
第一： 本次 AMS 上雲的核心模塊，物理機機型 90% 均爲 80 core 以上機型，上雲後單機必須在 80 core 以上，已經將一臺 CVM 所有 core 都使用完，再從資源管理角度考慮 TKE ，基本沒有收益了。
第二： AMS 當前的 CI/CD 流程及業務運營系統無法完全對接 TKE 平臺，強行切換的成本/風險與預期的收益無法對等。
基於以上考慮，AMS的上雲策略爲前期 CVM 爲主，TKE 爲輔，繼續完善 TKE 管理系統的流程對接。
上雲三大階段
（1）基礎設施上雲
大量使用雲服務器，此階段最主要的是把自研 IDC 的流量上雲，同時試用雲數據庫，雲負載均衡等各種 PaaS 服務。
| 業務規劃 | 灰度方案 | 環境適配 | 流量遷移 | 監控告警 |
| 容量規劃 | 回滾方案 | 功能測試 | 流量驗證 | 持續運營 |
| 組件規劃 | 風險評估 | 性能測試 | 灰度驗證 | |
| 機房規劃 | 放量方案 | 壓力測試 | 放量遷移 | |
| 預算規劃 |
（2）架構升級，大量使用 PaaS 服務
彈性伸縮、Docker 化改造，大量使用各種 PaaS 服務，充分發揮雲的高級功能。
（3）基於雲生態的研發運維體系
建設基於雲生態的研發運維體系，全面擁抱雲生態。
三、優化歷程
雖然名爲優化歷程，但更多是 AMS 技術團隊與騰訊雲團隊相互磨合，共同進步的歷程。提到的一些坑或者優化點，後面上雲的同學可能再也不會碰到了，因爲大多數已經通過產品化的方式固化在騰訊雲服務中。這也算是騰訊推動“開源協同，自研上雲”目的之一。
1. 基礎環境適配
2. CVM性能調優
（1）廣告播放性能要求
- 接入方式多種多樣，流量方衆多，耗時要求各不相同，耗時容忍度不同
- 每種流量訪問的下游數量不同導致耗時不同，每個都影響最終的耗時，耗時增加直接影響收入
- 各流量之間請求相差懸殊，超時比例即使相同但絕對值不同
（2）如何評估CVM與物理機的性能差異？
採用 percentile 百分位統計：
將一組數據從小到大排序，並計算相應的累計百分位，則某一百分位所對應數據的值就稱爲這一百分位的百分位數。可表示爲：一組 n 個觀測值按數值大小排列。如，處於 p% 位置的值稱第 p 百分位數。
相對於平均值統計，百分位統計區間更大，反應更靈敏，可以更好更及時反應業務質量的變化。
（3）優化目標
（4）主要耗時表現
耗時：雲主機在廣告檢索模塊上 99p 耗時比物理機 CG1 高 8-10ms。
| 平臺 | 配置 | |
|---|---|---|
| CG1 | intel | 2個20核CPU(6133)，256G內存，6*480G SSD，RAID，2*10G網口 |
| 雲主機 | Intel | 80或者76邏輯核，256G內存，硬盤爲CBS，網卡限速爲萬兆 |
（5）雲主機ping抖動
現象：使用 CVM 時發現 99p 時延抖動嚴重，定位發現是雲主機之間存在 ping 抖動問題。
排查過程：
第一步：查看 ping 抖動是否由網絡造成？
採用同一個 VPC 的 CVM，排除網絡影響。 ping 的同時進行 tcpdump 抓包，確認網絡 ping 抖動來源於母機或者 CVM。
第二步：母機查看各種指標，暫時未發現異常。
第三步：查看子機相關指標，OS、CPU、網卡流量，以及查看/proc/interrupts，最終發現是 tlinux1.2 OS 自帶的 ethtool 工具版本太老，設置網卡多隊列失敗。
第四步：升級 OS 後在大流量時故障復現，經過查看母機和子機 CPU 佔用率，懷疑子機vCPU 和母機線程爭搶 CPU 導致。
採取措施：
第一步：升級 ethtool 工具或者升級 OS 爲 tkernel2 內核、騰訊雲部署 QOS組件。
第二步：使用 DPDK（數據平面開發套件），母機隔離出4個邏輯核專門用於包轉發。
- 如何更新存量？
- 如何保證增量正常？
- 如何規範騰訊雲上架流程？
（6）CPU抖動引起雪崩
現象：經過 DPDK 優化的機型在某模塊上使用時在晚高峯不定時發生 CPU 抖動，失敗引發 L5 調度，進而引起該模塊雲主機雪崩。
定位過程：
發生CPU高時，使用率超過50%。
經過分析，發現 CVM 中的 CPU 和母機 CPU 並不是一一對應，在子機中的 CPU 使用率比較高時，由於母機側的自動負載均衡，會導致 CPU 跨核調度，發生 cache missing，由於沒有透傳 L3 cache，也使得不能使用 L3 cache，導致頻繁的上下文切換。
（7） AMD CPU 性能優化
AMD 使用表現如下：
同壓力時對比 intel 雲主機， AMD 物理機耗時抖動嚴重，無法應用於線上，轉而使用 AMD CVM（CVM配置：90邏輯 core，獨佔一 socket）。
定位與分析：
AMD 處理器單路 48 個物理核，雙路總計 192 個邏輯核（線程），兩個 NUMA 節點。NUMA 非一致內存訪問，經過分析廣告檢索模塊的內存佔用，結合 NUMA 的內存訪問統計，數據主要都位於 node 1 (N1) 上。而 sunfish 有一半的檢索線程運行在 node 0 的 core上，對這部分線程 node1 的內存屬於遠端內存，因此訪存速度緩慢。
收益：
採用單 node 的 AMD 雲主機經過測試耗時比 CG1 低 25% 以上，而成本經過測算AMD 單機成本是 intel CG1的60%，經過此次驗證也說明了硬件架構貼近業務架構特徵所帶來的收益，來加速 AMD 的落地。
3. 上雲對現網影響如何做到可控
（1）離線試錯
在不影響線上系統運行的前提下，克隆真實的在線請求到離線環境實現線下試錯，降低系統風險，無用戶體驗影響，快速支持新版本新環境上線。
（2）灰度方案設計
廣點通模塊衆多，不可能全部同時上雲，爲了服務切換的平滑穩定，做到用戶無感知，主要考慮到雲環境初期的各種風險，包括專線質量、服務延時、機型適配等諸多方面。
既要上雲，也不能無謂踩坑。既要保證業務平穩運行，維持高可用性，雲上環境有問題，可以隨時禁用，全部切回自研環境。
機器維度：
雲主機適配物理機配置，壓測後上線，如有異常及時剔除。
模塊維度：
針對 AMS 耗時要求嚴苛的情況，確定哪些模塊先上，哪些模塊後上，逐步上線各模塊。
SET維度：
一個 SET 具有完整的請求處理路徑，包含接入層+邏輯層，各個 SET 對請求的耗時要求不同，確定哪些 SET 先上雲，做到按 SET 回滾。
4. CBS存儲優化
CBS 的可用性主要通過網絡塊存儲方式提供服務，分佈式三副本提供保障。而 AMS 上雲模塊的數據應用模式採用大量的數據頻繁地實時更新。
網絡服務+三副本是在機制層面提高了可用性，可以減少我們很多運維的工作。但是新技術應用在一套磨合成熟的架構裏面，肯定會引出新的問題，我們不應該抗拒新技術，有問題解決問題。下文主要講一下新的問題及互相妥協的過程。
帶寬，通過網絡提供服務，大量數據的實時更新就意味着產生極大的網絡流量，那網絡帶寬有可能代替磁盤 IO 成爲了文件讀寫的瓶頸。
成本，頻繁的數據更新，意味着數據是類似 cache 性質的，那麼對於數據可用性的要求其實並不需要到達三副本的級別。
（1）帶寬問題
核心矛盾主要在帶寬指標上。業務側訴求是帶寬越大越好，物理機的寫入速度可以達到 300MB/s，而文件傳輸工具的峯值速度一般是 200MB/s（1.6Gb/s）。CBS 的訴求是小帶寬，默認帶寬是 100MB/s。由於雙方訴求相差過大，最終上線時是使用了個折中的速度 180MB/s。
CBS側操作：
由於高性能雲硬盤的上限帶寬達不到 180MB/s，最終使用了 SSD 雲硬盤（上限260MB/s）。然後再通過雲盤打標籤（APPID+硬盤空間大小）的方式來配置帶寬限速 180MB/s。
業務側操作：
帶寬=數據大小/傳輸時間。帶寬已經被限定，傳輸時間決定了數據加載速度，業務的需求是越小越好，爲了減少對業務的影響，能優化的主要方向就是數據大小。主要是通過了以下三個方式來減少雲盤的寫入量。
第一 ：每次傳輸的數據文件從全量文件修改爲增量文件，減少單次傳輸的數據大小，將傳輸時間打平。
第二 ：中間文件直接在內存操作，傳輸過來的文件會有一個解壓的中間狀態，這個操作放在 /dev/shm 目錄下操作，減少雲盤的寫入量。在使用大內存機型的條件下，這個操作可以減少幾十G文件讀寫壓力。
第三 ：減少災備數據的傳輸，雙數據源增加主備標識，備機判斷主機存活的情況下不做數據發佈的操作。由於原來雙數據源是無狀態互爲容災的架構，增加主備標識後，效果是數據寫入量直接減半，代價是故障時，數據更新會延遲一次文件傳輸的時間。
通過以上三招，將平均寫 I/O 從100+MB/s降到30MB/s，每30分鐘文件寫量從120GB降到50GB左右。
（2）成本問題
我們上雲的模塊基本都是接入層和邏輯層，機器上的數據也基本都是無狀態的 cache性質數據。這種類型的數據更多是要求性能，而對可用性的要求做到raid5級別就可以了，三副本的存儲成本太高了。但三副本是CBS的核心機制，這裏可操作的空間不是很大，期間我們也是考慮過一些別的方案，最終也沒有實現。
CFS方案：
我們的數據的讀寫模式本質是一寫幾千讀，CFS 在理論上也能支持，而且更合適。但是經過成本測算，CFS 的成本會比 SSD 雲盤成本更高，而且 CFS 的自研業務需求較少，不利於通過運營手段分攤並減少成本，最終該方案未實施。
單副本方案：
CBS 的同學也在考慮單副本的方案，由於最終方案尚未確定下來，不過多討論。主要列舉一下，我們業務對於單副本方案的需求或者關注點。
- 系統盤與數據盤分離；
- 故障率做到與物理盤壞盤率相同水平；
- 底層物理故障不應該影響大量CVM；
- 可以接受停機維護，但是如果因爲全盤目錄損壞導致需要重裝系統，以重新構建一些系統級目錄，運維成本過高，則意義不大。
綜合以上，由於CBS的高可用性保障及可根據業務形態調整配置的特性，業務側對 CBS 還是非常認可的。在運維效率提升及成本優化的過程中，起到了非常大的幫助。
5. 網絡時延優化
問題：雲主機至自研 IDC ping時延過高。
- 廣州到深圳 5ms；
- 上海寶信雲到自研 IDC 4-5ms。
主要措施：
- 部署 pvgw 設備；
- 直通車網絡優化項目。
6. TKE服務建設
由於 CVM 對於小核心業務提供能力不足，經常出現親和度不夠導致同業務下多個小核心 CVM 來自於同一臺宿主機，增大了業務風險和容災能力不足。所以開始接入公司的 TKE 服務，但由於 TKE 公有云沒有和騰訊內部的很多自研系統（監控運維）及賬號打通，所以對大多自研上雲業務並非最好選擇。
（1）平臺選擇
接觸了公司已有的兩款 TKE 平臺：STKE 和 TKEstack。
兩個平臺的相似點在於，都是以 TKE 爲基礎來提供容器化服務的方案。但差異在於 STKE 是專爲公司自研上雲提供的 TKE 服務，打通了更多的公司內部服務。
TKEstack 更多的則是面向私有化場景，但加入了適用於大數據計算的場景，並且和服務類型的應用混合部署。而在廣告內部存在着大量的離線模型計算，TKEstack 的場景更貼近廣告業務。
（2）TKEstack優勢
- 支持豐富的網絡模式，大幅拓展了容器應用場景，滿足複雜應用容器化的特殊需求；
- 提供全維度彈性資源限制，使得容器的穩定性、集羣資源利用率均得到提升；
- 實現了GPU卡、GPU顯存的虛擬化功能，可有效提升用戶GPU資源使用效率；
- 結合騰訊十多年海量運營經驗，全新設計出的一種全新的易用的應用類型；
- 自帶P2P分發功能的鏡像倉庫，可防止鏡像服務網卡流量被佔滿，並可顯著提升了拉取鏡像的速度。
在運維側，則實現了小核服務的按需分配（低負載管理）和快速擴容（自動擴容）等功能，在業務質量和成本管理中都有着顯著的提升。
（3）鏡像管理
鏡像可兼容 CSIGHUB，gaiastack 倉庫，藍盾和 mirrors 平臺，現基礎鏡像都以 mirrors 平臺管理爲主，已實現 AMS 廣告公共基礎鏡像的倉庫服務提供，已完成廣告自有基礎鏡像搭建並已提交至業務側使用。並已完成私有倉庫與平臺之間的憑證互通，可實現平臺拉取私有鏡像。
（4）容器化CI/CD
容器化的持續化集成區別於普通IDC業務的持續化集成，因爲容器化還增加一步鏡像構建的動作，這塊現有方案爲 csighub 的 hook 功能和藍盾的流水線功能，可以檢測某個 git 倉庫的地址，一旦發生 commit 動作就會觸發自動構建。
自動構建的鏡像爲運維側提供的基礎鏡像或者增加了業務基礎環境的業務鏡像（如PHP、jdk等）
容器化的持續化部署也與普通 IDC 業務有所不同，普通 IDC 業務是根據一個下發管道，來把代碼包下發到業務機器上，然後進行迭代後重啓（如織雲）。但容器化的 CD 是把原先提供服務的 pod 進行銷燬，再根據上述自動構建的鏡像進行重啓拉起，這樣就實現了一次自動化部署。
四、容錯容災部署
由於播放鏈路的機器是多年來逐漸部署起來的，有着比較重的歷史包袱。而早年間，整體鏈路的耗時壓力並沒有現在這麼嚴峻，所以在條帶化的部署架構設計時，只考慮了按業務流量性質的條帶化部署，各個模塊的機器部署在不同的 IDC 中。
隨着多年的發展，功能模塊越來越多，請求數據包大小逐漸增大（包大小增加60KB，同城跨 IDC 耗時就會增加 1ms 左右）。
再看業務架構中的特點二、鏈路模塊多+整體耗時控制嚴格。這導致整體鏈路中跨 IDC 訪問耗時佔比比較高，佔比在 10% 以上。所以這次自研上雲是一個很好的契機，重構業務部署架構，在保證可用性的前提下，儘可能通過就近部署減少網絡訪問耗時。
1. 部署原則
爲了達到這個目標，在進行新的 Set 劃分時主要是按照以下幾個原則：
- 每個地域選擇兩個容災 IDC 。
- 接入層混布，使用相同 L5/STGW，通過權重控制物理機與 CVM 間的流量對比，物理機後面接物理邏輯 Set，CVM 後面接雲 Set 。這樣流量在物理及雲之間切換時，對流量側就是無感知的。
- 邏輯層按 IDC 就近部署，這個會導致機器部署的碎片程度增加，管理單元數量大幅上漲，所以相應內部 Set 管理系統也得進行更新迭代。
- 數據在物理及雲各部署一套，由於部署一套在線數據的成本非常高，只能物理及雲各部署一套，無法做跨城容災部署主要也是受限於這裏。
2. 容災方案
容災設計的前提是接入層及邏輯層爲無狀態服務，三地的物理及雲數據均爲完備數據。
按 IDC 部署的雲 Set上 線，耗時大幅下降，相比混布的物理 Set ，耗時下降 26%~35% 。
平均時延先後對比
五、收益
本文轉載自公衆號雲加社區（ID：QcloudCommunity）。
原文鏈接：