騰訊廣告AMS的容器化之路

張煜，15年加入騰訊并從事騰訊廣告維護工作。20年開(kāi)始引導騰訊廣告技術(shù)團隊接入公司的TKEx-teg，從業(yè)務(wù)的日常痛點(diǎn)并結合騰訊云原生特性來(lái)完善騰訊廣告自有的容器化解決方案

項目背景

騰訊廣告承載了整個(gè)騰訊的廣告流量，并且接入了外部聯(lián)盟的請求，在所有流量日益增大的場(chǎng)景下，流量突增后如何快速調配資源甚至自動(dòng)調度，都成為了廣告團隊所需要考慮的問(wèn)題。尤其是今年整體廣告架構（投放、播放）的條帶化容災優(yōu)化，對于按需分配資源、按區域分配資源等功能都有著(zhù)更強的依賴(lài)。 在廣告內部，播放流系統承載了整個(gè)廣告播出的功能，這里的穩定性直接決定了整個(gè)騰訊廣告的收入，以下為架構圖：

業(yè)務(wù)特點(diǎn)：

• 請求量大，日均請求量近千億級別，機器量占了AMS自有機器量的60%以上，整體性能即使是少量的上下波動(dòng)都會(huì )涉及大量機器的變動(dòng)。

• 鏈路拓撲復雜及性能壓力極大，整個(gè)播放鏈路涉及40+的細分模塊。在100~200毫秒（不同流量要求有差異）的極短時(shí)間內，需要訪(fǎng)問(wèn)所有模塊，計算出一個(gè)最好的廣告。

• 計算密集型，大量的使用了綁核和關(guān)核能力，來(lái)面對上百萬(wàn)個(gè)廣告訂單檢索的壓力。

上云方案選型

在20年騰訊廣告已經(jīng)在大規模上云，主要使用的是 AMD 的 SA2 cvm 云主機，并且已經(jīng)完成了對網(wǎng)絡(luò )、公司公共組件、廣告自有組件等兼容和調試。在此基礎上，基于 CVM 的 Node 云原生也開(kāi)始進(jìn)行調優(yōu)和業(yè)務(wù)使用，彈性伸縮、Docker 化改造，大量使用各種 PAAS 服務(wù)，充分發(fā)揮云的高級功能。 以下為廣告使用的 TKE 架構：

• 前期資源準備（左上）：從騰訊內部云官網(wǎng)平臺申請 CVM 和 CLB 等資源，并且同時(shí)云官網(wǎng)申請 master，node，pods 所需要的 subnet 網(wǎng)段（ subnet 是區分區域的，例如深圳光明，需要注意 node 和 pods 在區域上的網(wǎng)段分配，需要一致）。CVM 和 CLB 都導入至 TKEx-teg 中，在選擇FIP模式的時(shí)候，產(chǎn)生的 PODS 從分配好的 subnet 中獲取自己的 EIP。

• 倉庫及鏡像的使用（右上）：廣告運維側提供基礎鏡像（mirrors.XXXXX.com/XXXXX/XXXXXXX-base:latest），業(yè)務(wù)在 from 基礎鏡像的同時(shí)，拉取 git 后通過(guò)藍盾進(jìn)行鏡像 build，完成業(yè)務(wù)鏡像的構建。

• 容器的使用模式（下半部分）：通過(guò) TKEx-teg 平臺，拉取業(yè)務(wù)鏡像進(jìn)行容器的啟動(dòng)，再通過(guò) clb、北極星等服務(wù)進(jìn)行對外使用。

容器化歷程（困難及應對）

困難一：通用性 （1）面對廣告84個(gè)技術(shù)團隊，如何實(shí)現所有業(yè)務(wù)的適配 （2）鏡像管理：基礎環(huán)境對于業(yè)務(wù)團隊的透明化 （3）騰訊廣告容器配置規范 困難二：CPU密集型檢索 （1）廣告訂單數量：百萬(wàn)級 （2）綁核：各個(gè)應用之間的 CPU 綁核隔離 （3）關(guān)核：關(guān)閉超線(xiàn)程 困難三：有狀態(tài)服務(wù)升級中的高可用 （1）廣告資源在容器升級過(guò)程中的持續可用 （2）在迭代、銷(xiāo)毀重建過(guò)程中的持續高可用

通用性

1. 廣告基礎鏡像介紹

廣告運維側提供了一套覆蓋大部分應用場(chǎng)景的基礎鏡像，其中以 XXXXXXX-base:latest 為基礎，這里集成了原先廣告在物理機上面的各個(gè)環(huán)境配置、基礎 agent、業(yè)務(wù) agent 等。 并且基于這個(gè)基礎鏡像，提供了多個(gè)業(yè)務(wù)環(huán)境鏡像，鏡像列表如下：

mirrors.XXXXX.com/XXXXX/XXXXXXX-base:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-nodejs:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-konajdk:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-python:3 mirrors.XXXXX.com/XXXXX/XXXXXXX-python:2 mirrors.XXXXX.com/XXXXX/XXXXXXX-tnginx:latest

具體鏡像使用情況如下：

在廣告的基礎鏡像中，由于權限集設置未使用到 systemd，所以使用啟動(dòng)腳本作為1號 PID，并且在基礎鏡像中內置了一份通用的騰訊通用 Agent & 廣告獨有 Agent 的啟動(dòng)腳本，在業(yè)務(wù)鏡像啟動(dòng)過(guò)程中，可以在各自的啟動(dòng)腳本中選擇是否調用。

2. 容器化CI/CD

原先大量使用了其他平臺的 CD 部分，但現在使用 TKE 后，其他平臺已經(jīng)無(wú)法使用。而 TKEx-teg 上的持續化集成部分對于自動(dòng)化流水線(xiàn)實(shí)現較弱，需手動(dòng)參與，所以在廣告內部引入的 CI/CD 方案是騰訊內部的持續化集成和持續化部署方案：藍盾。

這里全程實(shí)現流水線(xiàn)發(fā)布，除了審核外無(wú)需人工參與，減少人為因素的問(wèn)題影響。

stage1 ：主要使用手動(dòng)觸發(fā)、git 自動(dòng)觸發(fā)、定時(shí)觸發(fā)、遠程觸發(fā)

• 手動(dòng)觸發(fā)：容易理解，需要手動(dòng)點(diǎn)擊后開(kāi)始流水線(xiàn)。

• 自動(dòng)觸發(fā)：當 git 產(chǎn)生 merge 后，可自動(dòng)觸發(fā)該流水，適用于業(yè)務(wù)的敏捷迭代。

• 定時(shí)觸發(fā)：定時(shí)每天某個(gè)時(shí)間點(diǎn)開(kāi)始整個(gè)流水線(xiàn)的觸發(fā)，適用于 oteam 協(xié)同開(kāi)發(fā)的大型模塊，預定多少時(shí)間內迭代一次，所有參與的人員來(lái)確認本次迭代的修改點(diǎn)。

• 遠程觸發(fā)：依賴(lài)外部其他平臺的使用，例如廣告的評審機制在自己的平臺上（Leflow），可以在整個(gè)發(fā)布評審結束后，遠程觸發(fā)整個(gè)流水線(xiàn)的執行。

stage2 & stage3 ：持續化集成，拉取 git 后進(jìn)行自定義的編譯

藍盾提供了默認的CI鏡像進(jìn)行編譯，不進(jìn)行二進(jìn)制編譯的可以選擇默認（例如 php、java、nodejs等），而后臺業(yè)務(wù)騰訊廣告內部大量使用 blade，通常使用 mirrors.XXXXXX.com/XXXXXX/tlinux2.2-XXXXXX-landun-ci:latest 作為構建鏡像，此鏡像由騰訊廣告效能團隊提供，內部集成了騰訊廣告在持續化集成過(guò)程中的各種環(huán)境和配置。 編譯完成后通過(guò)鏡像插件，依賴(lài) git 庫中的 dockerfile 進(jìn)行鏡像 build，然后推送至倉庫中，同時(shí)保留一份在織云中。

stage4 ：線(xiàn)上灰度 set 發(fā)布，用于觀(guān)察灰度流量下的數據表現。通過(guò)集群名、ns 名、workload 名來(lái)對某個(gè)工作負載進(jìn)行鏡像 tag 的迭代，并且使用一份 TKEx-teg 內部的 token 進(jìn)行認證。

stage5 ：確認 stage4 沒(méi)問(wèn)題后，開(kāi)始線(xiàn)上的全量，每次都經(jīng)過(guò)審核確認。

stage6 & stage7 ：數據統計。

另外有一個(gè)藍盾中機器人群通知的功能，可以自定義把需要告知的流程信息，推送到某個(gè)企業(yè)微信群中，以便大家進(jìn)行確認并審核。

3. 騰訊廣告容器配置規范

廣告內部的母機都是用的騰訊云星星海 AMD（SA2），這里是90核超線(xiàn)程 cpu+192G 內存，磁盤(pán)使用的是高速云硬盤(pán)3T，在日常使用中這樣的配置這個(gè)機型是騰訊云現階段能提供的最大機型（已經(jīng)開(kāi)始測試SA3，最高機型配置會(huì )更大）。

• 所以業(yè)務(wù)在使用的時(shí)候，不建議 pods 核數太大（例如超過(guò)32核），由于TKE親和性的默認設置會(huì )盡量在空閑的母機中拉取各個(gè)容器，這樣在使用到中后期（例如集群已經(jīng)使用了2/3）導致的碎片化問(wèn)題，會(huì )導致超過(guò)32核的 pods 幾乎無(wú)法擴容。所以建議用戶(hù)在拉取容器的時(shí)候如果可以橫向擴容，都是把原有的高核服務(wù)拆分成更多的低核 pods（單 pods 核數減半，整體 pods 數兩倍）。

• 在創(chuàng )建 workload 的時(shí)候，對日志目錄進(jìn)行 emptyDir 臨時(shí)目錄的掛載，這樣可以保證在升級過(guò)程中該目錄不會(huì )丟失數據，方便后續的問(wèn)題排查。(銷(xiāo)毀重建仍舊會(huì )刪除該目錄下的所有文件)

如果是已經(jīng)上線(xiàn)的 workload，則可以通過(guò)修改 yaml 來(lái)增加目錄的掛載：

        - mountPath: /data/log/adid_service


          name: adid-log


      volumes:


      - emptyDir: {}


        name: adid-log

• 在騰訊廣告內部，大量使用了條帶化功能，也就是服務(wù)不在受限于上海、深圳、天津這樣的范圍。條帶化可以做到更細化的區分，例如上海-南匯這樣以機房為單位的部署，這樣可以實(shí)現容災的實(shí)現（大部分的網(wǎng)絡(luò )故障都是以機房為單位，這樣可以快速切到另一路）。也可以實(shí)現條帶化部署后的耗時(shí)減少，例如同上海的兩個(gè)機房，由于距離的原因自帶3ms的耗時(shí)，在大包傳輸的過(guò)程中，跨機房部署的耗時(shí)問(wèn)題會(huì )被放大，在廣告內部有出現10ms的 gap 出現。

所以在廣告的 TKE 條帶化使用過(guò)程中，我們會(huì )去通過(guò) label 的方式來(lái)指定機房選擇，騰訊云對各個(gè)機房的 CVM 都默認打了 label，可以直接調用。

存量的 workload 也可以修改 yaml 來(lái)進(jìn)行強制的調度。

      spec:


      affinity:


        nodeAffinity:


          requiredDuringSchedulingIgnoredDuringExecution:


            nodeSelectorTerms:


            - matchExpressions:


              - key: failure-domain.beta.kubernetes.io/zone


                operator: In


                values:


                - "370004"

• 廣告內部后臺都是建議使用4~16核的容器配置，前端平臺大多使用1核，這樣可以保證在集群使用率偏高的場(chǎng)景下，也可以進(jìn)行緊急擴容。并且如果希望親和性強制隔離各個(gè) pods，也可以使用如下配置進(jìn)行隔離（values 為具體的 workload 名稱(chēng)）：

         affinity:


        podAntiAffinity:


          preferredDuringSchedulingIgnoredDuringExecution:


          - podAffinityTerm:


              labelSelector:


                matchExpressions:


                - key: k8s-app


                  operator: In


                  values:


                  - proxy-tj


              topologyKey: kubernetes.io/hostname


            weight: 100

4. HPA設置

在容器化的使用過(guò)程中，有兩種方式可以面對業(yè)務(wù)流量的突增。

• 設置容器的request和limit，request資源可以理解為確定100%可以分配到業(yè)務(wù)的，而Limit則是超賣(mài)的資源，是在buffer池共享的資源部分。這樣的好處在于每個(gè)業(yè)務(wù)可以配置平時(shí)正常使用的request資源，當發(fā)生流量突增時(shí)由limit部分的資源來(lái)承擔超過(guò)request之后的性能問(wèn)題。

注：但這里的超賣(mài)并不是萬(wàn)能的，他有兩個(gè)問(wèn)題也非常明顯：

• 在當前node剩余使用的資源如果小于limit設定的值，會(huì )發(fā)生PODS自動(dòng)遷移到其他node。2）如果需要使用到綁核功能，是需要qos的功能，這里強制request和limit必須設置一樣的配置。

• 設置自動(dòng)擴容，這里可以根據大家各自的性能瓶頸來(lái)設置閾值，最后來(lái)實(shí)現自動(dòng)擴容的功能。

大部分的業(yè)務(wù)都是cpu的性能為瓶頸，所以通用方式可以針對cpu的request使用率來(lái)設置擴容

百萬(wàn)廣告訂單檢索

1. 廣告核心檢索模塊

廣告對于每個(gè)流量都存在一個(gè)站點(diǎn)集的概念，每個(gè)站點(diǎn)集分了不同的 set，為了區分開(kāi)各個(gè)流量之間的影響和不同的耗時(shí)要求。在20年我們對每個(gè)模塊都拆出了一個(gè) set 進(jìn)行了 CVM 的上云，在此基礎上，21年我們針對核心模塊 sunfish 進(jìn)行了容器化的上云。這個(gè)模塊的特點(diǎn)就是 CPU 高度密集型的檢索，所以他無(wú)法使用超線(xiàn)程（超線(xiàn)程的調度會(huì )導致耗時(shí)增加），并且內部的程序都進(jìn)行了綁核處理（減少多進(jìn)程之間的 CPU 調度）。

2. 容器綁核

這里是廣告最大的一個(gè)特性，而且也是 TKE 和 CVM/物理機的最大區別。

在 CVM/物理機的場(chǎng)景中，虛擬化技術(shù)是可以從 /proc/cpuinfo 中獲取到正確的 cpu 單核信息，所以在原先的業(yè)務(wù)綁核過(guò)程中，都是從 /proc/cpuinfo 中獲取 cpu 的核數和信息，進(jìn)行每個(gè)程序的綁核操作。

但在容器中 cpu 信息產(chǎn)生了很大的偏差，原因是 /proc/cpuinfo 是根據容器自身的核數進(jìn)行的排序，但這個(gè)順序并不是該容器在母機上的真實(shí)cpu序列，真實(shí)的 cpu 序列需要從 /sys/fs/cgroup/cpuset/cpuset.cpus 中獲取，例如下圖兩個(gè)舉例：

/proc/cpuinfo 中的 CPU 序號展示（虛假）：

/sys/fs/cgroup/cpuset/cpuset.cpus 中的 CPU 序號展示（真實(shí)）：

從上面兩張圖中可以看到，/proc/cpuinfo 中只是按照分配到的 cpu 核數進(jìn)行了一個(gè)排序，但并不是真正對應母機的核數序列，這樣在綁核的過(guò)程中，如果綁定了15號核，其實(shí)是對母機的15號核進(jìn)行綁定，但母機的第15個(gè)CPU并不是分配給了該容器。

所以需要從 /sys/fs/cgroup/cpuset/cpuset.cpus 中獲取在母機中真正對應的 cpu 序列，才能實(shí)現綁核，如上圖2。并且可以通過(guò)在啟動(dòng)腳本中加入下面的命令，可以實(shí)現對 cpu 真實(shí)核數的格式轉換，方便綁定。

cpuset_cpus=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)


cpu_info=$(echo ${cpuset_cpus} | tr "," "\n")


for cpu_core in ${cpu_info};do


  echo ${cpu_core} | grep "-" > /dev/null 2>&1


  if [ $? -eq 0 ];then


    first_cpu=$(echo ${cpu_core} | awk -F"-" '{print $1}')


    last_cpu=$(echo ${cpu_core} | awk -F"-" '{print $2}')


    cpu_modify=$(seq -s "," ${first_cpu} ${last_cpu})


    cpuset_cpus=$(echo ${cpuset_cpus} | sed "s/${first_cpu}-${last_cpu}/${cpu_modify}/g")


  fi


done


echo "export cpuset_cpus=${cpuset_cpus}" >> /etc/profile

source /etc/profile 調用環(huán)境變量，轉換后的格式如下： 注意：綁核依賴(lài) qos 配置（也就是 request 和 limit 必須設置成一致)

3. 關(guān)閉超線(xiàn)程

超線(xiàn)程在大部分場(chǎng)景下都是打開(kāi)的，但在計算密集型的場(chǎng)景下需要關(guān)閉，此處的解決方法是在申請CVM的時(shí)候就選擇關(guān)閉超線(xiàn)程。

然后對關(guān)核的母機做污點(diǎn)并打上 label，讓普通的拉取不會(huì )拉到關(guān)核母機，在需要分配關(guān)核資源的時(shí)候，在 yaml 中打開(kāi)容忍和設置 label，就可以獲取到相應的關(guān)核資源。

yunti 資源申請時(shí)的關(guān)核配置：

有狀態(tài)服務(wù)升級中的高可用

無(wú)狀態(tài)容器的升級最為簡(jiǎn)單，業(yè)務(wù)端口的可用即為容器的可用。

但有狀態(tài)業(yè)務(wù)的啟動(dòng)較為復雜，需要在啟動(dòng)腳本中完成狀態(tài)的前期準備工作。在廣告這里主要涉及在廣告訂單資源的推送和加載。

1. 廣告資源在容器升級過(guò)程中的持續可用

容器的升級較于物理機最大的區別就在于容器會(huì )銷(xiāo)毀原有的容器，然后從新的鏡像中拉起新的容器提供服務(wù)，原有容器的磁盤(pán)、進(jìn)程、資源都會(huì )被銷(xiāo)毀。

但廣告這里的廣告訂單資源都是百萬(wàn)級別，文件如果在每次升級都需要重新拉取，會(huì )直接導致啟動(dòng)過(guò)慢，所以我們在容器中都加入了臨時(shí)掛在目錄。

這樣的掛載方式，可以讓容器在升級過(guò)程中保留上述目錄下的文件，不需要重新拉取。但 emptyDir 只能在升級場(chǎng)景下保留，銷(xiāo)毀重建仍舊會(huì )銷(xiāo)毀后重新拉取，以下為存量服務(wù)直接修改 yaml 的方法：

              volumeMounts:


        - mountPath: /data/example/


          name: example-bf


      volumes:


      - emptyDir: {}


        name: example-bf

2. 升級過(guò)程中的業(yè)務(wù)高可用

在業(yè)務(wù)迭代的過(guò)程中，其實(shí)有兩個(gè)問(wèn)題會(huì )導致業(yè)務(wù)提供了有損服務(wù)。

• 如果針對 workload 關(guān)聯(lián)了負載均衡，這里容器在執行啟動(dòng)腳本的第一句話(huà)就會(huì )變成 running 可用狀態(tài)，這時(shí)候會(huì )幫大家投入到關(guān)聯(lián)過(guò)的負載均衡中，但這時(shí)候業(yè)務(wù)進(jìn)程并未就緒，尤其是有狀態(tài)服務(wù)必須得完成前置的狀態(tài)后才可以啟動(dòng)。這時(shí)候業(yè)務(wù)就會(huì )由于加入了不可用的服務(wù)導致業(yè)務(wù)報錯。

• 在升級的過(guò)程中，除了 deployment 模式的升級外，其他都是先銷(xiāo)毀原有的容器，再拉取新的容器服務(wù)。這時(shí)候就產(chǎn)生了一個(gè)問(wèn)題就是，我們在升級的時(shí)候是先從關(guān)聯(lián)過(guò)的負載均衡里剔除，然后立馬進(jìn)入到銷(xiāo)毀階段。如果上游是L5調用那其實(shí)并不能快速同步到該 pods 已經(jīng)剔除，會(huì )繼續往下游已經(jīng)銷(xiāo)毀的容器中發(fā)送請求，這時(shí)候整個(gè)業(yè)務(wù)就會(huì )報錯。

所以我們這里的一個(gè)最主要的思路就是：

• 如何把業(yè)務(wù)的狀態(tài)，和容器狀態(tài)進(jìn)行綁定。

• 在升級/銷(xiāo)毀重建的過(guò)程中，是否可以做一個(gè)后置腳本，在銷(xiāo)毀之前我們可以做一些邏輯處理，最簡(jiǎn)單的就是sleep一段時(shí)間。

這里我們引入業(yè)務(wù)的兩個(gè)升級的概念：

• 探針就緒

• 后置腳本

  1 ）探針就緒 需要在workload創(chuàng )建的時(shí)候，選擇針對端口進(jìn)行做就緒探測，這樣在業(yè)務(wù)端口啟動(dòng)后才會(huì )投入到關(guān)聯(lián)好的負載均衡里。

  也可以在存量的workload中修改yaml

      readinessProbe:


          failureThreshold: 1


          periodSeconds: 3


          successThreshold: 1


          tcpSocket:


            port: 8080


          timeoutSeconds: 2

出現類(lèi)似的unhealty，就是在容器啟動(dòng)后，等待業(yè)務(wù)端口的可用的過(guò)程

 2 ）后置腳本

后置腳本的核心功能就是在從關(guān)聯(lián)的負載均衡中剔除后，到銷(xiāo)毀容器之間，可以執行一系列業(yè)務(wù)自定義的動(dòng)作。

執行順序是：提交銷(xiāo)毀重建/升級/縮容的操作 → 剔除北極星/L5/CLB/service → 執行后置腳本 → 銷(xiāo)毀容器

最簡(jiǎn)單的一個(gè)功能就是在上游使用L5調用的時(shí)候，在剔除L5后sleep 60s，可以讓上游更新到該pods剔除后再進(jìn)行銷(xiāo)毀操作。

           lifecycle:


          preStop:


            exec:


              command:


              - sleep


              - "60"

  lifecycle:


          preStop:


            exec:


              command:


              - /data/scripts/stop.sh

長(cháng)期的使用經(jīng)驗來(lái)看，主要問(wèn)題在L5這方面，如果是大流量的服務(wù)，那sleep 60s 內就行，如果是請求量較小的，希望一個(gè)報錯都沒(méi)的，需要 sleep 90s。

成果展示

CVM 和 TKE 的使用率和耗時(shí)對比

這里在相同配置下，對比了普通機器 CVM 和 TKE 容器之間的 CPU 和耗時(shí)，可以看到基本沒(méi)太大差異，耗時(shí)也無(wú)變化。

CVM： TKE：

整體收益

結語(yǔ)

不同于其他從底層介紹云原生的分享，本文主要從業(yè)務(wù)角度，來(lái)介紹云原生在大型線(xiàn)上服務(wù)中的優(yōu)勢和使用方法，并結合騰訊廣告自有的特點(diǎn)及策略，來(lái)實(shí)現騰訊廣告在高并發(fā)、自動(dòng)化等場(chǎng)景下的容器化實(shí)踐。 對于業(yè)務(wù)團隊來(lái)說(shuō)，任何的工作都是從質(zhì)量、效率以及成本出發(fā)，而云原生則是能從這三個(gè)方面都有所提升，希望未來(lái)能有更多來(lái)自于我們騰訊廣告的分享。

---

> 容器服務(wù)（Tencent Kubernetes Engine，TKE）是騰訊云提供的基于 Kubernetes，一站式云原生 PaaS 服務(wù)平臺。為用戶(hù)提供集成了容器集群調度、Helm 應用編排、Docker 鏡像管理、Istio服務(wù)治理、自動(dòng)化DevOps以及全套監控運維體系的企業(yè)級服務(wù)。