​TGDC | 搭建雲端遊戲的腳手架

2020年12月9日，由騰訊遊戲學院舉辦的第四屆騰訊遊戲開發者大會（Tencent Game Developers Conference，簡稱TGDC）於線上舉行。來自騰訊雲的遊戲行業架構總監宋永周先生，分享了騰訊雲產品的技術與方案例項。以下是分享視訊和文字實錄：


各位遊戲行業的從業者朋友們，大家好。我是來自騰訊雲團隊的遊戲解決方案架構師宋永周，很高興今天能夠在TGDC上與大家分享，我對遊戲技術架構的一些理解和思考。我今天分享的題目叫《搭建雲端遊戲的腳手架》，為什麼選擇用“腳手架”這個詞呢？在我看來，構建遊戲後臺的技術架構和我們工地上去修建高樓大廈是有些相通性的。


很多人問我的職業經歷，我一般會這樣解釋：大家應該都見過建築工地吧，過去我做了十年的遊戲運維工程師，就像是工地上搬磚的小工，而我現在做遊戲解決方案的架構師，更像是工地上負責搭建腳手架的。我的工作就是幫助客戶，構建一個穩定安全的環境，讓他們能夠放心的去搬磚。

所以今天我將以腳手架工的身份，和大家一起分析，遊戲業務的架構在雲上搭建會遇到哪些問題，如何在雲端去構建遊戲後臺的這個高樓大廈。


我今天分享的內容主要有四個方面：

第一塊，整個行業的問題分析。我會結合過去我們支援遊戲客戶的一些經驗，給大家分享我們從客戶的視角，看到遊戲架構上雲會遇到哪些問題。

第二塊，整個遊戲架構上雲的一些技術結構是什麼樣子的。具體到環境搭建的環節裡面，其實就是圖紙怎麼畫的一個問題。

第三塊，我們給客戶做了一些架構優化的案例。大家可以理解為如何去改造一個危樓。

第四塊，我們在雲時代有哪些先進的生產力和工具，能夠幫助我們遊戲客戶能夠更快速高效的去構建遊戲的技術架構。


結合這兩年我們支援遊戲客戶的一些經驗，總結下來，遊戲客戶上雲所關注的點，主要有三方面：

第一塊是成本，因為客戶選擇遷移上雲，一般是從IDC或者是從其他的友商遷移過來。如果要選擇我們雲的話，首先要考慮你的成本有沒有優勢，這是一個很關鍵的考量點。

第二塊，客戶希望通過上雲，做到業務研發和運營效率的提升。雲提供給客戶的環境，除了基礎的風和水電之外，還有一些工具，幫助他提升業務研發和運營的效率。

第三塊，用雲這個環境去做彈性的保障。對他業務來說，在一個時間週期內，業務是有高峰和低谷的，如果用雲的話，能夠更好地去利用雲的彈性，更充分的利用資源。


瞭解了客戶上雲所面臨的具體問題之後，我們給客戶輸出解決方案的時候，會從以下四個方面去做考量：

第一是穩定性。我們會提供一些高可用SLA和業務的指標保證，讓客戶在雲上的業務能夠穩定地執行，有一個基礎的保障。

第二是擴充套件性。我們給客戶提供彈性伸縮和資源排程的能力，幫助客戶在他業務有彈性需求的時候，能夠快速地滿足他的資源需求。

第三是生產效率的提升。我們會通過一些PaaS和SaaS類的產品能力，對整個產品技術堆疊做彌補，幫助客戶提升他在研發和運營過程中的一些效率問題。

最後是安全性。我們會通過主機安全和業務安全兩個維度，保障客戶的業務執行在雲上是安全穩定的。


我們一起分析一下，遊戲業務架構上雲整個過程是什麼樣的？我們作為一個腳手架工，如何去幫助遊戲客戶去構建在雲上的業務環境？


正式聊這個內容之前，我想和大家一起看兩款大家熟知的國民級網遊。第一款是《王者榮耀》，它的特點是多人對戰、強PVP屬性。同一個對局裡面的玩家，是需要實時知道彼此的位置和操作的。這種型別的遊戲，對於網路的要求是非常高的，你所有的操作都是需要通過網路和伺服器同步給彼此，所以這類遊戲，我們把它叫做匹配競技類。

第二類，比如說《魔獸世界》，一個PVE屬性的遊戲，使用者在大部分的時間內，是不需要知道彼此的位置和狀態的。只是在少量的，比如說同屏或者是同一個副本里面的玩家，是需要知道彼此的一些狀態。這一類遊戲，對於網路的延遲要求是相對較低的。它的部署上，一般選擇分割槽的方式，即單個區是有容量上限的。這樣能夠保證使用者，比如說排行榜單或者社交關係上是合理的。

回顧一下雲上的遊戲，我們把它分為匹配競技類和大世界類，這兩種主流的技術架構，其實我們可以把市面上一些主流的架構往兩種大類裡面靠。

比如說MOBA類的、FPS類的，會屬於匹配競技類遊戲，像MMORPG或者是戰爭塔防、城防類的SLG類、沙盒類的，可能會把它歸類為虛擬大世界類，以強PVP和強PVE這兩種屬性，對遊戲技術架構做一個大的拆分。


我們找一組資料來驗證一下，這樣拆分是否合理。這是伽馬資料做的2020年上半年Top10的遊戲榜單，按照剛才的理論它是成立的，就是說，可以把它分為匹配競技類遊戲和大世界類這兩種型別。


搞清楚遊戲的技術架構型別之後，我們來分別看一下，要搭建這兩種型別遊戲的技術架構，會有什麼區別。首先我們來看一下匹配競技類的遊戲：


在整個技術架構上看，我們可以把它理解為像一個農貿市場的架構。我們把每一個正在進行中的對局比作一個交易，大廳可以認為是整個交易的一個管理機構，構建這麼一個大區，我可以讓更多的使用者在我自由市場裡面去做交易。我要考慮的首要問題是，如何去支援架構的無限擴充套件，能夠讓所有一起玩的玩家在一個區裡面，做一個不分割槽服的架構。

相對於匹配競技類遊戲的架構，我們看一下大世界類遊戲的架構：


大世界類的遊戲，可以理解為一個大型商場的架構。每一個區，可以理解為是一個商場裡面的專賣店，但每一個專賣店能夠容納的交易量是有上限的，所以在整個架構上是做分割槽分服的，就是說，區和區之間相對是隔離的。

在這種技術架構下，運營要去考慮更多的問題是如何去批量管理這些專賣店。可能後期有一些專賣店運營的不好，要把它關掉或者是要騰出新的位置來，要去擴容，要去引更多新的店進來，對遊戲運營來講就是開區。

基於上述內容，我們在遊戲技術架構的分類上，就是匹配競技類遊戲和大世界類遊戲，我們主要把它分成六種架構型別。


針對於匹配競技類遊戲，因為它可以選擇分割槽和不分割槽，也可以選擇集中部署和分佈部署，所以這裡有四種架構。對於大世界類的遊戲，因為預設是分割槽的，所以我們就有集中部署和分散式部署兩種架構。

如果我把整個架構圖畫出來，會是什麼樣子的？這裡列舉了一個匹配競技類遊戲集中分佈的架構。大家可以看一下：


使用者從客戶端進入到遊戲對局，大概經歷了有這麼幾個過程：

首先，客戶端開啟之後，做版本校驗，通過CDN獲得到客戶端的更新包，讓使用者的客戶端到達最新，通過登入模組連線到遊戲大廳上，當使用者需要開啟對局的時候，這時候在大廳上的匹配模組會撮合一個對局，把撮合成的對局的使用者傳送到一組空閒的戰鬥服上，完成戰鬥的對局。

這是一個集中式的架構。意思是，所有的服務是部署在一個地方的，使用者可以從不同地方連到服務，完成遊戲的對局。這種架構其實是有缺陷的。對於延時要求很高的遊戲，是沒法在這種架構底下的。


所以相對於集中式的部署的話，就會有分散式部署的架構。這個架構，它的區別在後端的戰鬥服環節，除了可以把它放在一起之外，也可以把它放在不同的VPC底下，放在不同的區域底下，再通過騰訊雲提供的VPC互通專線組成一個內網，這樣的話，使用者可以連到就近伺服器，讓遊戲體驗的延遲更低。


剛才講了遊戲的技術架構，接下來我想分享我們做的，針對於大世界類遊戲的分割槽分服架構優化的一個案例。

首先統一一下區和服的概念，遊戲的分割槽分服，其實有很多種講法。我們主流的分法是這麼講的：


一款遊戲可以通過我的發行區域、發行平臺或者發行渠道，把它分成若干個服，每一個服之間相對是獨立的，甚至用了不同的帳戶體系，在一個服底下，因為我是一個大世界類遊戲，我要分割槽可能會把它分成若干個區，一區、二區、三區，上圖是騰訊的《火影忍者》和《鴻圖之下》。一個服底下，這些區之間是可以共享帳戶甚至是充值餘額的，這是分割槽分服的架構整體的一個概念。

在雲上怎麼部署呢？我們的客戶大部分是這樣做的：


一個平臺的服務會有若干組遊戲大區的服務，其實對每一個遊戲大區來講的話，它就是一臺物理的機器，我們會在物理機器上部署它的程式和資料庫，當然這種部署也是一個典型的部署方式，維護起來當然也不是很麻煩，但是它會有些問題。

如果這臺伺服器掛了，這個區可能就丟掉了，資料是不可以恢復的，或者要恢復的時候，會有一些故障期間的資料就沒有了。

還有，區和區之間的使用者數量是不均衡的，有可能會一區的人特別多，二區的人特別少。這樣單機的承載是不合理的，一區有風險；二區很空閒。

針對這種架構我們怎麼做優化呢？


首先，我們引入了一個架構分層的概念。我們建議客戶在業務邏輯上，把剛才的所有業務邏輯糅在一起的架構，拆分為三層。

一個是接入層，接入層包括區服導航、負載均衡以及連線管理、登入等這些邏輯，我把它放在接入層。在業務邏輯層，我把它拆為小區，每個區自己的業務邏輯的模組。在儲存層的話，我會建議客戶把遊戲的資料快取，日誌把它單獨去存放。基於架構的優化之後，我們會把這個架構優化成這個樣子：


玩家通過高防流量之後， 我會通一個LB把它連線到遊戲服務裡面，這裡我放一個LB的好處是，一方面可以做一些公網IP的收斂；另外也可以針對LB去做一些流量上的防護，保證後端的區不會被攻擊掉，不會像之前的架構一樣，部署很多的IP流量防護。

如果是各個區之間會有跨服的戰鬥操作的話，我會通過一個跨服的模組去完成，資料層我會把它單獨剝離出來，通過雲上的資料庫去實現。這樣如果我的遊戲邏輯掛掉了，我的資料邏輯是還在的，只要通過CVM的一個熱遷移，就會很快的把這個區恢復起來，使用者的影響就會變得更低。

這是一個終極的優化架構嗎？其實並不是，我們還可以針對這個架構再做進一步的優化。


我們可以看到，剛才在每個小區邏輯裡面，會有些公共的邏輯，比如說像郵件、商城、聊天、戰鬥、工會等這些公共模組。

其實在每一個區裡面都是有的，如果說業務架構是一款爆款遊戲的話，其實對應的區服是非常多，相當於在每一個區裡面都要管理對應的公共模組。我們建議第二層客戶區，可以把這些公共模組拆分出來再做一層，通過一個路由轉發的方式，去給單個大區的這些遊戲伺服器去做服務。這樣的話，會把和使用者承載相關的這部分容量，把它切到Gamesvr模組上來，讓這邊作為實時的針對於使用者訪問量的擴容或縮容。


第四塊我想和大家來去分享，在雲時代，業務架構上雲的話，會面臨哪些問題，以及我們騰訊雲作為整個雲資源的提供方，能夠給客戶提供哪些東西，幫助客戶去解決這些問題。


第一個問題是圖紙複用的問題。可以看到這裡有個業務架構，遊戲這種運營場景底下，其實這個架構在不斷做變化。比如說，你開一個新區或者做老區的一些合併，相當於是這組架構在和其他的區之間做一些相互的操作，如果說客戶要去雲上開一個新區的時候，他需要去雲上把所有對應的資源都買回來，再去開新區的話，這樣其實他的操作是比較複雜的。


所以基於這種需求，我們給客戶提供一個工具叫TIC，就是一個基礎設施，通過程式碼去描述基礎設施這麼一個工具。

這個工具它也是基於我們公有云通用的資源編排的工具叫Terraform。我們是基於Terraform的裸介面上做了一些使用者使用場景的封裝。

舉一個例子，比如說我們現在左側有一個這是一個簡單的Web server架構，這個架構底下可能有幾臺機器，可能會有LB，可能會有幾個資料庫，這個架構我會以一段程式碼，把它描述下來，我有這個程式碼之後，其實我只需要在我的TIC平臺上去執行下這個程式碼，對應的業務架構就可以生產下來。

這麼做會有一個好處，比如說你要開一個新區，我可能是隻需要把老區的一個技術架構把它的程式碼摳出來，只需要把它的可用區改成另外一個區，在另外一個區執行一下整個區的環境就會生產下來。


我們結合整個客戶的運維流程我們來看一下，如果使用TIC之後能夠幫助客戶解決哪些問題。

其實傳統的客戶在去用雲上運維的時候，會有一個環節叫CMDB，就是說把雲上提供的基礎設施資源去管理到業務自己的配置中心裡面去，再通過你的配置中心去做運維的操作。如果我們通過TIC來去做這個事情，相當於在CMDB前置有一個步驟，這個步驟可以幫助客戶快速地去通過程式碼去雲上獲取或者是回收你的這些資源。業務側的運維就可以通過這個環節，讓整個從雲上獲取資源到搭建環境的程就在雲上閉環了。能夠讓客戶更快速地去獲取到你的基礎設施提升整個運維自動化的程度。


第二個問題是彈性伸縮問題。我們可以看到在匹配競技類的遊戲戰鬥服模組，因為戰鬥服是整個遊戲架構核心算力的一個消耗，尤其像我們對於《和平精英》和《王者榮耀》這樣級別的遊戲的話，其實它的戰鬥服的資源比例已經佔到整個遊戲後臺相當大的一個比例。

假如說這個遊戲是一款爆款，經常會做一些運營活動，做運營活動和不做運營活動，帶來的基礎施的彈性優化空間是非常大的。

這裡就引用SQLServer的首席架構師有一次分享裡面的一個梗：所有的運維人員都希望自己維護的這一群機器，是一群牛而不是嬌貴的寵物。從客戶的運維思維來講，只希望我想用伺服器的時候就有，而不是說我要實時去照顧到，我的環境底下有多少容量，我需要什麼時候來做擴容。

所以我們針對這個場景，有一個專屬的產品方案叫GSE。GSE幫助客戶去針對性的解決匹配競技類遊戲的戰鬥服上雲的問題。可以簡單看一下GSE業務流程：


遊戲客戶端連到大廳之後，匹配到對局，匹配到對局之後要給它分配一個房間去完成戰鬥，這是傳統的業務邏輯。在GSE底下會把戰鬥服的管理事情託管到雲上，客戶的業務邏輯只需要在你的大廳裡面去提成GSE排程的一些服務，當你的對局需要做分配資源的時候，這時候是調雲上API去完成資源分配。

具體資源怎麼去監管？

我們會在我們託管在雲上執行的DSPod相當於是客戶自己戰鬥服的程式，在戰鬥服程式裡面整合一個很輕量的SDK，SDK可以把你的房間的一些資源使用情況上報給我的GSE，通過這樣分配到對局之後，會把執行的房間IP和埠再返回給這一組對局的玩家，讓玩家能夠連到對局上去完成遊戲，是這麼一個邏輯。當然託管上雲之後的話，對客戶來講它可能會成為一個黑盒子，這樣我們也是為了方便客戶能夠去看到，託管在雲上的這些服務的執行的情況。我們在控制檯上其實是有對應的一些操作介面，我們有個Agent會給客戶去實時上報你託管在雲上的一些服務執行的一些狀態，包括他的監控指標。客戶也可以通過雲的控制檯去做登入和除錯。

我們看一下成本的對比，這裡有兩張圖：


一張圖是在傳統的人工運維時代，做一個包月的容量監測，它對應的成本模型是什麼樣子的，這個圖裡面的波浪線大家可以理解為一段時間週期內的業務的最高線上人數；上面這個折線可以理解為它整個業務需要做的建設容量。

在接入GSE之後相當於業務實際使用的容量會比實際的線上人數會稍微高一點點，因為它是實時彈性伸縮的，所以兩條紅線下面的面積差就是整個GSE能夠給客戶帶來的算力優化的一些空間。


這裡有一個具體的業務模型，底下這條不規則的線是以我們一款具體的業務全年線上人數的曲線。如果說我走包月和包年這兩種模式的話，有兩種成本模型，根據包月和包年兩種成本，我們詳細算過整個成本的消耗，GSE能夠去幫客戶節省到20%到30%的成本。這還是一個常規的業務模型，其實它的最高線上點和平時相比，並沒有高出很多。如果說在暑期期間，它做了一個週年慶的活動，可能它線上會高出更多，這時候其實GSE能夠優化的成本空間可能會更大。


另外，除了能夠做成本優化之外，我們也能夠通過GSE去完成一些多地部署和容災場景。

比如說業務的戰鬥服，通過託管GSE之後它是部署在不同的區域的，如果第一個區域出現了網路故障，其實在伺服器的佇列裡面只需要把第一個區直接踢掉，相當於說新來的玩家對局就不會分配到第一個區域裡面去，這樣可以更好地去保障不會因為網路的故障影響了線上的玩家。


第三個問題是模組外包的一個問題。我們可以看到，在匹配競技類遊戲的架構裡面，其實遊戲的資料庫是需要具備強的擴充套件性和高併發能力的，傳統的開源資料庫或者是單點部署的時候，因為它的容量使用是有上限的，沒法滿足我們在匹配競技類遊戲做不分割槽服架構的需求。

這裡必須使用到分散式資料庫，我們給客戶提供的方案是把我們騰訊遊戲在過去支援我們內部業務上的兩款資料庫方案推給線上的玩家。在這裡主要是我們的TcaplusDB和Redis混合儲存的版本。這兩款產品其實都是過去騰訊遊戲團隊內部研發的，也是經過我們多年的線上業務穩定的壓測的產品方案，接下來我會給大家分享一下這裡一些進展。


TcaplusDB我們內部是2011年開始研發，在內部已經支援了快400款線上遊戲，像大家知道的這些《王者榮耀》、《王者榮耀》等。基本上騰訊所有自研的手遊都用的是TcaplusDB，其實它已經經歷了大量的線上使用者的壓測，包括最近比較火的《王者榮耀》平均DAU一個億的事情，其實它後端都是我們TcaplusDB在做支援，我們在去年把這款產品搬到雲上，目前線上已經有四五家客戶在測我們的產品。

我們在2020年的6月份上線了一款Web類業務，從AWS DynamoDB 遷移到騰訊的TcaplusDB。

Tencent TcaplusDB。這裡我們主打幾個標籤，一個是我們專為遊戲而生，因為其實放眼行業裡面的話，TcaplusDB它應該是整個遊戲行業裡面同時承載人數最多的遊戲資料庫，所以穩定性是毋庸置疑的；第二個是我們做了一些相容遊戲場景的一些業務邏輯，比如說在遊戲整個運營過程中我們可能會考慮到高可用或者是單使用者回檔需求或者是一些易用性和安全性的訴求，其實在我們整個TcaplusDB裡面架構師都有做考慮，這是整個TcaplusDB的一些進展。


第二塊是我們把騰訊遊戲內部的TenDis，我們現在雲上叫Redis混合儲存版也遷移上雲，這裡主要是解決Redis記憶體資料庫，其實它的成本和安全性是有些問題的。

首先是記憶體的價格相對於SSD貴很多，另外因為是記憶體所以說它資料丟掉的話，它對業務是有影響的。我們是基於Redis架構Redis加RocksDB這樣一個架構，把資料做冷熱分離之後存在SSD裡面。這樣的話，我們能大幅去降低業務的一個成本，其實最高可能降掉80%，達到20%這麼一個成本優化的一個比例。


Redis混合儲存版在內部主要是服務我們遊戲社群、遊戲的助手等這樣一些周邊產品。我們在外部其實現在也有一些網際網路的客戶在測一些方案。

以上是我今天全部分享的內容。

來源：騰訊遊戲學院
原文：https://mp.weixin.qq.com/s/wYp1ZOlpx2FK9kwNsgFN1Q