騰訊計費：億萬級大促活動自動化保障體系

2019 年 10 月 11 日
筆記

9月14-15日，GOPS全球運維大會上海站圓滿舉行，為期兩天的運維盛宴，為各位運維人帶來了相互交流和學習的絕佳平台，來自騰訊技術工程事業群（TEG）計費平台部的黃宇給大家帶來了「億萬級大促活動自動化保障體系」的主題分享。

我們同步了嘉賓現場沙龍分享影片（內含高清PPT），請點擊下方「騰訊技術課小程式」卡片即可查看：

同時附上整理好的演講稿：

黃宇，來自騰訊技術事業群的計費平台部，在鵝廠長期從事虛擬支付、多終端支付、賬戶存儲、風控、結算等領域的工作，帶領團隊負責騰訊千億級計費大盤的整體運營和品質，目前主要專註於運營自動化、私有雲運維、智慧監控等相關建設。

騰訊計費是做什麼的

騰訊計費平台是產品端到端在線交易平台，其核心是幫助用戶與產品安全、便捷的完成支付和收款，在交易過程中幫助產品盈收最大化。平台承載了公司每天數億收入大盤，為180+個國家(地區)、萬級業務程式碼、100+W結算商戶提供支付渠道、營銷、賬戶託管、風控、結算以及推薦等服務。

如果把騰訊比喻為一個飯店，騰訊計費就相當於門口櫃檯的收費平台，您可以用微信支付、銀行卡、蘋果支付、QQ錢包、充值卡抵扣券或其他方式支付你在飯店的消費；這裡包括了ToC場景，比如用戶往自己的QB賬戶充值，或者在遊戲終端購買道具、遊戲幣；也包括ToB場景，比如廣告主、網紅主播、騰訊雲客戶的扣款收費，都是通過騰訊計費這套平台提供服務。

從收入統計來看，目前在賬戶託管方面，覆蓋了絕大部分ToC ToB業務的有價賬戶的託管，有價賬戶的規模現在是360+億的賬戶體量；實時交易方面，覆蓋了90%以上的內部實時交易；結算出賬是全覆蓋。

大促營銷活動

大促營銷活動是騰訊計費對內提供的一個核心服務，公司業務可以在計費平台上設置各種各樣的營銷活動，比如首次充值贈送、購買滿贈、累計贈送、打折、抽獎、團購、砍價等等，支援的營銷活動量級每年有幾萬個（2018年支援活動4.2W個）。

大家可以看到，像王者榮耀、CF、飛車這些頭部遊戲，或者騰訊影片、QQ會員這些包月VIP等產品都有幾千萬甚至上億的活躍用戶量級；如果通過活動進行推廣宣傳，全量用戶的觸達後，活動收入會呈現爆髮式增長。

營銷活動很多彩，然而現實很殘酷，活動也有出故障的時候。作為負責公司收入大盤的計費平台，在支援業務營銷活動中的風險和壓力都是非常大的。尤其是在營銷活動保障體系構建完善之前，時常會出現服務容量過載、平台擴容效率低、變更影響等平台問題。

那麼為什麼會出現各種類型的問題，這裡分析總結了騰訊計費大促營銷活動的幾個特點：

1.活動鏈路很長，比如一個遊戲中QB首充值贈送組合禮包的活動，用戶一進來，要進行登錄校驗、大區查詢、角色查詢、風控檢查、活動資訊拉取、下單、支付、組合禮包中物品發貨等一連串的調用；由於我們是公司支撐型平台，需要對接那麼多業務和平台，單是外部介面就是280+個，所以一個不起眼的環節都可能成為大盤容量瓶頸。

2.業務大促活動峰值與平時流量都是幾十倍的差異，而且業務間的流量此起彼伏。公共平台的資源是有限的，不可能對不同業務每種活動類型不計成本的堆積設備資源。

3.現網變更頻繁，前端版本、後端版本發布，系統配置調整、營銷活動規則調整等各種變更每天加起來平均350+次，大家都知道，變更帶來的故障通常佔到了現網故障的75%以上，所以在這麼變更頻發的平台上進行營銷活動資源擴縮容，高一致的精準度是很難保證的。

4.業務不能徹底隔離：計費平台支援了成千上萬個業務，不可能為每個業務做一套隔離的環境。業務大促活動期間，是存在相互干擾的，如果控制不當，單個業務的爆髮式流量甚至會帶來整個大盤的雪崩效應，這又該如何防範。

如何評估大盤的容量瓶頸

說到大盤容量，大家都會想到春節紅包或者雙十一大促這樣的大流量場景，都需要提前壓測的方式來評估容量的瓶頸。

壓測的方式一般有幾種，一種是把服務組合為一個個SET，或者叫一個個桶，就跟生產車間一樣，對每個set提前壓測好性能，等需要的時候再按set一個個添加到集群中，這種方式適合於比較標準化、模組關係不複雜，大批量的可擴展場景；

第二種方式是根據現網既有規模，按比例縮小規模進行壓測，從而估算現網環境的容量，一般測試或者預發布環境就是這麼乾的。

第三種方式就是模擬用戶構造模擬數據，直接對現網大盤進行壓測。前面也介紹了，騰訊計費的場景存在鏈路長、對接廣等複雜性，所以採用第三種壓測方式。

為了達到盡量模擬的壓測效果，不能針對活動入口進行簡單的並發重複執行相同用例，這樣無法實現接近現網的模擬效果。前面也提到，不同的渠道、不同的業務或者活動模式，交易經過的內外部鏈路都不同，所以這裡很重要的一點就是構建盡量逼真的壓測場景。

根據現網平台入庫到TDW的歷史流水數據，按活動入口、登陸態、業務程式碼、支付渠道、版本號等資訊，構建出百萬級的用例組合。

TDW: Tencent distributed data warehouse 騰訊分散式數據倉庫

Cmdb：config manage database 系統及業務配置管理系統

FlowSvr：流量管理系統

深度模擬壓測還要模擬用戶端從不同區域和網路進行測試，所以在深圳、上海、天津、成都等不同城市的多個機房各地部署了用例分發SVR和agent，將一個大的壓測任務分解到不同機房並行發起執行。

如果用少量的號碼壓測，很容易命中現網的限頻攔截或風控策略，而且有些業務場景測試需要提供號碼真實的遊戲大區、綁定或者好友關係等資訊，所以平台構建了十萬級的號碼資源庫，不同測試號碼滿足不同的場景條件，用於壓測過程輪詢使用。

那麼壓測用例在執行的時候，就會根據測試場景，自動匹配不同的業務資源和號碼資源，替換執行。

關於現網壓測還有一點值得注意，因為在直接對現網進行全流程壓測，所以一定一定是不能壓出問題的，一旦壓上去的量級過大肯定會造成現網損失，所以壓測速率從0提升到指定速率，建議採用勻速爬坡式提升，過程中一旦發現報錯、超時可以立即停止壓測。

按需動態分配營銷活動資源

通過壓測知道了大盤的容量，那麼為了安全起見，是不是按最大最全的體量囤積資源就好了？

肯定不能這樣，如果您是老闆的話，也不會同意這樣干是吧。大盤中不同業務場景在不同環節和時段的資源消耗是有差異的，在錯峰情況下如何最大限度復用資源非常重要。

在這裡的自動化擴縮容設計里，現網大盤由服務組成，服務由系統實例組成，而實例承載的基礎是騰訊計費自研的TDF程式框架；擴縮容的核心大腦就是TSM自動化管理平台，壓測平台周期性壓測現網容量，現網記憶體、負載、時耗、流量等指標也會分鐘級採集匯總，這些數據都會匯總到TSM管理平台，這個大腦再根據策略下達擴容、或者縮容的指令。

這裡採用KVM虛擬機構建用於自動擴縮容的資源池，共享資源池會在日常擴容中出庫消耗，在縮容中退庫，這樣持續的循環。資源池分成共享資源池和緊急資源池兩個部分，緊急資源池一般是不動用的，就像一個國家的戰略物質儲備一樣，只有在共享資源池出現補給不上的緊急情況才使用。

那麼具體什麼時候啟動自動擴容呢，這裡主要採用了多級閥值和趨勢預判兩種策略，所謂分級閥值就是當服務負載突發突破不同檔位時，平台設置了不同的擴容比例和力度。趨勢預判策略是根據逐步上升的容量指標，對下一時段的容量水平進行提前趨勢斜率分析，並預判提前擴容。

具體的快速擴容操作，像TDF框架和相關基礎庫文件包，在資源標準化的時候就進行預安裝，所以這個環節是不算耗時的；APP程式包按服務中的參照子節點進行發布，特別是許可權方面，由於涉及的內外部許可權非常多，所以也要參照原節點進行克隆。這個執行過程可以做到分鐘級控制。

這裡的擴容發布依賴的基礎是一個全球發布平台，它通過公司級TSC操控通道向中國和海外，包含自建機房和AWS上的資源進行控制，它支援串列、並行不同的發布模式；具有適配廣，高可用和可擴展的特點。

如何確保擴縮容變更精準無誤

一開始有提到，在日常頻繁變更的現網大盤上進行擴縮容操作，故障風險是非常高的，那麼怎麼確保這裡的變更準確性呢？也就是怎麼確保擴容上去的資源服務沒有問題。

針對這個問題，這裡採用了三種檢測機制，一是對新節點通過工具demo進行功能探測，第二是將新擴容節點相對於服務原有節點進行橫比掃描分析，第三是對實時監控告警資訊的自動化關聯。

這裡要重點說下掃描檢查機制，將擴縮容變更和版本變更等等都收攏到一個變更管控平台，這個平台再針對不同的變更場景發起掃描檢查和播測驗證；掃描檢查是基於監控採集的海量數據，進行細粒度同比以及節點間橫比，包括成功率、時耗、錯誤碼等對比分析；撥測驗證也就是之前有講到的業務場景撥測；那麼管控平台就是將掃描和撥測兩方面的結論綜合起來，判斷這次擴容變更是否準確，並提交給TSM大腦進行決策。

如何防止大盤雪崩風險

以上介紹了自動化決策和自動化擴縮容的機制，那麼是不是有了這些自動化機制就萬無一失了呢？

自動化也不能100%的信任，如果極端情況，自動化擴容不能有效工作，我們的現網大盤會不會有被大促營銷活動衝垮，進而導致雪崩的風險，這種情況一定不允許發生。