業(yè)務介紹
自2019年，騰競整個電競賽事數(shù)據(jù)服務完全由騰訊云TKE容器服務承載。騰競賽事數(shù)據(jù)開放平臺目前主要提供職業(yè)賽事數(shù)據(jù)的授權(quán)與查詢，隨著斗魚、虎牙、企鵝、掌盟、微信直播、微博等平臺的相繼接入，平臺整體流量有了爆發(fā)式的增長。
此前2021英雄聯(lián)盟全球總決賽（以下簡稱S11）期間更是創(chuàng)下了平臺流量新高，達到了百萬級QPS、百億級調(diào)用量。面對電競賽事此類周期性強、并發(fā)高的業(yè)務場景，有效快速的自動擴縮容、提升資源利用率，是滿足業(yè)務高速發(fā)展、合理控制成本的關(guān)鍵所在。
這里將介紹LOL S11賽事期間，騰競賽事數(shù)據(jù)開放平臺如何通過虛擬節(jié)點彈性調(diào)度+VPC-CNI架構(gòu)，輕松應對爆發(fā)的百萬流量。
業(yè)務特性
電競賽事具備明顯的業(yè)務特性，其對服務的自動伸縮能力有非常高的要求。
·周期性
電競賽事具有明顯的周期性，比賽時段是流量高峰期，其余時間流量驟減，流量相差數(shù)百倍，需要通過彈性擴縮能力，減少波谷時的冗余資源，降低成本。
·高并發(fā)
比賽期間，服務需要承載百萬級QPS，需要快速的擴容時間、及庫存充足的資源池。
·突增快
比賽開始時，玩家開始大量涌入直播間，需要保證服務穩(wěn)定性，避免突增流量過大引發(fā)集群雪崩。
架構(gòu)介紹
整體架構(gòu)
集群采用Istio作為服務網(wǎng)格框架進行微服務治理，流量經(jīng)由多條CLB（解決單條CLB帶寬上限）進入Istio Ingress（直連Pod)后進行流量分發(fā)，依托于Istio的Sidecar模式，能夠?qū)Ω鞣罩g進行非常精細化的流量管理，例如：灰度、限流、熔斷等等。
普通節(jié)點+虛擬節(jié)點
開啟VPC-CNI采用直連Pod模式后，集群不再受NodePort網(wǎng)絡轉(zhuǎn)發(fā)能力的限制，少量常規(guī)節(jié)點應對業(yè)務日常低負載場景，利用虛擬節(jié)點彈性擴縮容能力應對賽事期間業(yè)務超高負載場景。
DevOps
基于Docker的CI/CD服務，支持多環(huán)境（云端、本地）、多集群編排服務，滿足業(yè)務的不同部署需求。
彈性擴容方案演變
基于上述的業(yè)務特性，針對彈性擴容的方案，經(jīng)歷了【手動擴容=>節(jié)點池=>虛擬節(jié)點】的一系列演變歷程，目前的彈性擴容方案可以完美滿足業(yè)務需求。
業(yè)務初期：手動擴容
業(yè)務初期，負載較低，根據(jù)業(yè)務特征，手動擴縮容基本可以滿足需求。
由于手動擴縮容需要一定的時間窗口，因此需要放置一定數(shù)量的冗余資源應對突增流量，資源利用率較低，只有6%左右。
業(yè)務發(fā)展中：節(jié)點池
隨著業(yè)務發(fā)展，周期性的高低峰流量特征愈發(fā)明顯，面對高頻的擴縮容需求時，手動擴縮容不僅人力成本較高，而且無法避免人為失誤。
在突增流量速度較慢的場景下，節(jié)點池可以較好滿足業(yè)務需求，不過需配置服務器，擴容速度較慢，冗余資源仍存在，資源利用率較低。另外，縮容時對節(jié)點進行封鎖、驅(qū)逐等操作，不利于服務的穩(wěn)定性。
業(yè)務高速發(fā)展：虛擬節(jié)點，秒級擴容，節(jié)省30%成本
業(yè)務高速發(fā)展階段，高低峰流量相差懸殊、并發(fā)逐漸增高、突增流量時間達到秒級，節(jié)點池的擴容速度不足以滿足業(yè)務需求，還有購置服務器時庫存不足的風險。
虛擬節(jié)點是TKE提供的一種彈性調(diào)度能力，提供了近乎無限資源的擴容能力，可以直接將Pod調(diào)度至彈性容器服務EKS維護的云上資源中，無需擴容節(jié)點。相比節(jié)點池，虛擬節(jié)點的擴容、縮容流程簡化了購買、初始化、退還服務器的流程，大大提升了彈性的速度，盡可能降低在擴容流程中可能出現(xiàn)的失敗，使得彈性更快、更高效、更節(jié)省成本。
在彈性效率層面，虛擬節(jié)點可在數(shù)十秒內(nèi)啟動數(shù)以百計的Pod，能夠很好的應對S11這類高爆發(fā)業(yè)務場景。在成本層面，避免了普通節(jié)點由于無法完美分配Pod申請的資源而產(chǎn)生的buffer資源，節(jié)省了資源成本。
在此基礎上，我們結(jié)合業(yè)務側(cè)數(shù)據(jù)，采取自動化資源預熱的方式應對高頻的突增流量場景；運營類業(yè)務場景則需要和運營部門緊密結(jié)合做好手動擴容的準備。
網(wǎng)絡轉(zhuǎn)發(fā)方案優(yōu)化
存在的問題
集群提供公網(wǎng)訪問入口時，默認情況下外部流量經(jīng)由集群節(jié)點NodePort轉(zhuǎn)發(fā)至集群內(nèi)部，當虛擬節(jié)點中部署的Pod數(shù)量較少，集群整體負載較低時，該模式不會有網(wǎng)絡轉(zhuǎn)發(fā)性能瓶頸。不過隨著部署在虛擬節(jié)點中的Pod數(shù)量增大，集群整體負載升高，就需要添加更多的節(jié)點用于網(wǎng)絡轉(zhuǎn)發(fā)，這與自動伸縮、快速擴容、降低成本的目標背道而馳。
優(yōu)化方案
開啟VPC-CNI后采用直連Pod模式，容器與節(jié)點分布在同一網(wǎng)絡平面，每個Pod分配有固定IP，網(wǎng)絡直接由CLB轉(zhuǎn)入Istio Ingress，不再經(jīng)由NodePort轉(zhuǎn)發(fā)，提高了網(wǎng)絡轉(zhuǎn)發(fā)效率，集群也不在需要網(wǎng)絡轉(zhuǎn)發(fā)節(jié)點，大大提高了集群的擴容能力。該模式下，集群擴容上限受到集群所分配網(wǎng)段可用IP數(shù)的限制，因此需要提前做好規(guī)劃，避免集群擴容受限。
最終效果
通過虛擬節(jié)點和VPC-CNI模式下直連Pod的結(jié)合，目前集群整體承載能力有了很大的提升，在成本控制方面也有了長足的進步。
秒級擴縮容
通過虛擬節(jié)點+K8s HPA能力，集群可在數(shù)十秒內(nèi)啟動數(shù)以百計的承載百萬級流量的Pod，可以輕松應對快速擴縮容需求。再結(jié)合業(yè)務側(cè)數(shù)據(jù)，自動化進行資源預熱，提升集群抗突增流量能力。縮容時也不再需要對節(jié)點進行封鎖、驅(qū)逐等操作，提高了服務的穩(wěn)定性。
百萬承載
VPC-CNI直連Pod解決了NodePort流量轉(zhuǎn)發(fā)瓶頸的問題，加上虛擬節(jié)點近乎無限資源的擴容能力大大提高了集群水平擴容的上限，像騰競賽事數(shù)據(jù)開放平臺這樣大量讀的場景能輕松擴容至百萬乃至千萬級QPS。
降低成本
虛擬節(jié)點的高效擴縮容，配合K8s的HPA自動伸縮機制，減少了資源的準備和閑置時間，避免普通節(jié)點中的碎片化資源問題，有效的提高了資源利用率，最終為業(yè)務節(jié)省了30%的成本。
參考文檔
容器服務TKE：
【https://cloud.tencent.com/document/product/457/6759】
虛擬節(jié)點概述：
【https://cloud.tencent.com/document/product/457/53027】
彈性集群：
【https://cloud.tencent.com/document/product/457/39804】
VPC-CNI模式介紹：
【https://cloud.tencent.com/document/product/457/50355】
騰訊云
專欄
閩公網(wǎng)安備 35010202001226號
