在上周的 Cloud 干貨中我們從谷歌的基礎(chǔ)架構(gòu)入手，分析了其在游戲場景中的幾大獨(dú)特優(yōu)勢：優(yōu)質(zhì)層級的網(wǎng)絡(luò)服務(wù)、全球 VPC、負(fù)載均衡等（點(diǎn)此復(fù)習(xí)）

那我們今天的文章繼續(xù)來聊聊如何借助 Google Cloud來打造靈活可擴(kuò)縮的游戲解決方案，簡單來說主要分為三個(gè)層面：游戲接入層、服務(wù)器、數(shù)據(jù)庫的擴(kuò)展方案。

下面我們逐一展開.....

游戲接入層的擴(kuò)展

正式開始之前我們先來看一個(gè)短視頻：

這里主要有四個(gè)數(shù)字需要關(guān)注

一、隨著玩家的不斷加入，請求新開服務(wù)器的數(shù)量

二、實(shí)際開起來的服務(wù)器的數(shù)量

三、正在運(yùn)行的服務(wù)器的數(shù)量

四、同時(shí)在線的玩家數(shù)量

我們會(huì)發(fā)現(xiàn)，一和二是完全匹配的，且游戲服務(wù)器的數(shù)量跟隨玩家數(shù)量呈正向變化。這就是我們經(jīng)常會(huì)聽到的 Google Cloud 的自動(dòng)、按需擴(kuò)展。

且注意，Google Cloud 的自動(dòng)擴(kuò)展是不需要預(yù)熱的。

那么，什么是預(yù)熱呢？

在實(shí)際情況下，游戲廠商不只會(huì)有一臺(tái)主機(jī)，會(huì)同時(shí)有很多游戲服務(wù)器，在這些服務(wù)器按之前還會(huì)有一個(gè)類似于負(fù)載均衡 Load Balancer 的服務(wù)，負(fù)責(zé)接受玩家請求，并將其分配給某臺(tái)游戲服務(wù)器。這里的負(fù)載均衡本身可能是一個(gè)虛擬機(jī)（也可能是一臺(tái)物理設(shè)備），當(dāng)數(shù)以萬計(jì)的玩家涌入時(shí)，同樣需要對其擴(kuò)展，否則會(huì)成為服務(wù)的瓶頸。

負(fù)載均衡的擴(kuò)展即預(yù)熱，需要時(shí)間和人工進(jìn)行干預(yù)。

那么 Google Cloud 如何做到無需預(yù)熱、按需擴(kuò)展？

事實(shí)上，Google 的 Load Balancer 并不依賴某一臺(tái)物理設(shè)備，甚至不依賴于某一機(jī)器集群，也不是單一的一個(gè)服務(wù)，而是由一組服務(wù)組成的一個(gè)遍布全球的分布式系統(tǒng)。從2008年開始，Google Cloud Load Balancer的很多關(guān)鍵服務(wù)，就一直在支持Google Search / Map / Adwords等多個(gè)業(yè)務(wù)的全球擴(kuò)展。

另外，在之前的文章中，我們說到的“就近接入”，Google 的 Load Balance 并不在云的 VPC 里面，而是遍布在全球144個(gè) POP 節(jié)點(diǎn)上，而且，在將用戶請求負(fù)載均衡到位于 Google Cloud 的應(yīng)用之前，會(huì)在靠近用戶的邊緣站點(diǎn)處終止用戶的 TCP 連接。它還為 SSL 連接提供證書。這樣做的好處之一，就是可以利用Google 的骨干網(wǎng)絡(luò)，加速用戶訪問的速度。

游戲服務(wù)器的擴(kuò)展

游戲服務(wù)器到底應(yīng)該放在虛擬機(jī)還是容器上?

這個(gè)問題其實(shí)并沒有標(biāo)準(zhǔn)答案,完全取決于業(yè)務(wù)情況以及團(tuán)隊(duì)的技術(shù)能力。

但是我們需要注意的是，每臺(tái)虛擬機(jī)都有獨(dú)立的操作系統(tǒng)，彼此之間隔離性較好。同一個(gè)宿主機(jī)上，當(dāng)一臺(tái)虛擬機(jī)癱瘓之后不會(huì)影響其他虛擬機(jī)，持久性也會(huì)更好。如果之前您的游戲是運(yùn)行在物理機(jī)上的，遷移至虛擬機(jī)時(shí)要比到容器上的學(xué)習(xí)成本更低一些。

當(dāng)然，容器的好處在于同一臺(tái)主機(jī)上，共享同一個(gè)操作系統(tǒng)內(nèi)核，可以更快更輕啟動(dòng)。另外在同一臺(tái)宿主機(jī)上，可以比虛擬機(jī)裝更多的容器，充分利用機(jī)器的資源。同時(shí)，容器的打包部署速度比較快，也比較簡單，可以給予用戶持續(xù)集成和持續(xù)部署的能力。

但是就像微服務(wù)給我們帶來好處的同時(shí)把這個(gè)復(fù)雜性甩給了網(wǎng)絡(luò)一樣。那么容器也給我們帶來很多新的挑戰(zhàn)。比如：

為了解決這些問題，Google 開源了容器編排管理工具 Kubernates （Google在其多個(gè)核心業(yè)務(wù)中，使用容器技術(shù)已超過十年，每周都會(huì)發(fā)布將近20億個(gè)新容器）可以解決的問題包括：

-編排: 決定在哪兒運(yùn)行容器

-健康檢查: 確保容器運(yùn)行在期望的狀態(tài)

-擴(kuò)展: 增加或者減少容器數(shù)量

-發(fā)現(xiàn): 尋找某個(gè)容器的位置

-負(fù)載均衡: 在多個(gè)容器之間分發(fā)流量

-存儲(chǔ): 保存數(shù)據(jù)

-日志與監(jiān)控: 追蹤容器的事件、指標(biāo)

-調(diào)試: 定位問題

-驗(yàn)證與授權(quán): 控制誰可以對哪個(gè)資源做什么操作

針對游戲領(lǐng)域，在2019年 Google Cloud 聯(lián)手 UBISOFT 打造了一款叫做Agones 的開源項(xiàng)目。

Agones 被設(shè)計(jì)用來托管和擴(kuò)展游戲服務(wù)器， 它構(gòu)建在 Kubernetes 之上，靈活性非常好，可根據(jù)多人游戲需求進(jìn)行定制。

相較于直接在 Kubernetes 上直接搭載游戲服務(wù)器，Agones 的好處主要有以下幾點(diǎn)。

首先 Agones 在 Kubernetes 之上，使用游戲開發(fā)者熟悉的語言和概念，又做了一層封裝，例如：Game Fleet、Game Server等，會(huì)大大縮短了游戲開發(fā)者的學(xué)習(xí)時(shí)間，降低了入門門檻。

其次，也是非常重要的一點(diǎn)，Kubernetes 并不知道集群里某一個(gè) POP 上正在有人打游戲。那么在 Scale in 的時(shí)候，可能會(huì)誤刪正在運(yùn)行的游戲服務(wù)器，給玩家?guī)矸浅Ｔ愀獾挠螒蝮w驗(yàn)。

另外，Agones 還提供了更加豐富的SDK，如：Unreal 、Engine 、Unity、 C++、 Node.js、 Go Rust、REST 。

通過上方的架構(gòu)圖可以看到當(dāng)更多的玩家加入請求對戰(zhàn)時(shí)，他們的請求會(huì)被發(fā)到 Matchmaker，即匹配服務(wù)。

我們注意這個(gè)服務(wù)，并不是 Agones 提供的一個(gè)功能，你可以使用自己任意喜歡的匹配服務(wù)。匹配好了以后，通過 Kubernetes 來請求分配給玩家一臺(tái)游戲服務(wù)器。

這時(shí)Agones會(huì)去調(diào)用 Agones Controller， Agones Controller 會(huì)從圖片下方 Fleet 里面找出一臺(tái)游戲服務(wù)器，然后把這臺(tái)游戲服務(wù)器的端口的 IP 地址返回到游戲客戶端，然后游戲客戶端就可以連上來，進(jìn)入愉快的游戲時(shí)間。

百聞不如一見，下面我們來看一段 demo，看一看如何在這個(gè)通過 Agones 來創(chuàng)建一臺(tái)及一組服務(wù)器。

在這個(gè) Demo 中我們看到的是手工擴(kuò)展的方式，那么有沒有自動(dòng)擴(kuò)展的方式呢？

有，且有兩種。

其一是 Buffer Size ，即在任何時(shí)候，需要有多少臺(tái)機(jī)器被分配出去，通過 bufferSize 可以直接進(jìn)行指定，如在下圖中指定了永遠(yuǎn)有兩臺(tái) ready 狀態(tài)的服務(wù)器可以用于分配，當(dāng)然通過 minReplicas 和 maxReplicas 可以指定用于分配的服務(wù)器數(shù)量的上下限。

另外一種方式是 Webhook ，通過Webhook 我們可以自定義一個(gè) Webhook Service ，進(jìn)行指標(biāo)自定義及觸發(fā)擴(kuò)展或收縮的動(dòng)作。

當(dāng)然，為了讓游戲開發(fā)者更加專注于游戲開發(fā)而不是底層資源管理，2019年 Google Cloud 還推出了一個(gè)托管服務(wù)：Game Sever，使用它的好處在于：

-選擇 可管理運(yùn)行在GKE上的游戲服務(wù)器集群，未來還將支持混合云 / 多云的管理。

-靈活性 可以跟包括Open Match在內(nèi)的多種匹配服務(wù)結(jié)合使用。

-可視化 可視化的管理界面和監(jiān)控界面。

-簡化 發(fā)布之前可以先Preview。支持在全球范圍內(nèi)統(tǒng)一發(fā)布，也可以在不同區(qū)域定制化部署。

其中簡化管理非常重要，Agones 更適合于一個(gè) Region ，即一個(gè)區(qū)域管理一個(gè)集群，如果您的游戲是跨多個(gè)區(qū)域的，每個(gè)區(qū)域有多個(gè)集群，甚至在不同的集群上跑著不同的游戲。這個(gè)時(shí)候 Game Sever 就會(huì)派上用場了，首先這里我們要明確兩個(gè)重要的概念：

發(fā)布， Game Sever 的一次發(fā)布即游戲的一個(gè)版本。

Clusters，即配置，這里可以全球同一個(gè)配置，也可以不同區(qū)域不同配置，如下圖。

游戲數(shù)據(jù)庫的擴(kuò)展

數(shù)據(jù)庫的擴(kuò)展應(yīng)該是三個(gè)部分中最難的，這是因?yàn)閭鹘y(tǒng)的數(shù)據(jù)庫往往會(huì)成為限制游戲性能的瓶頸。

因?yàn)閺牡谝惶扉_始，它就被設(shè)計(jì)為一個(gè)單點(diǎn)，很容易出現(xiàn)單點(diǎn)故障。

那么解決方法之一就是對傳統(tǒng)數(shù)據(jù)庫進(jìn)行分片，思路就是把數(shù)據(jù)分成很多份。然后每一份數(shù)據(jù)扔到不同的數(shù)據(jù)庫服務(wù)器上，比如下圖左邊所示，根據(jù)玩家的id 進(jìn)行分片，a 到m 開頭的玩家，分配到數(shù)據(jù)庫服務(wù)器一，剩下的分配到數(shù)據(jù)庫二。同理，我們也可以根據(jù)玩家地理位置或者玩家使用的設(shè)備類型進(jìn)行分片。

分片雖好，但是也帶來了很多的問題。

比如說維護(hù)成本很高。舉個(gè)例子，一臺(tái)數(shù)據(jù)庫可以支持最多一萬個(gè)玩家的請求。那么如果有一百萬的玩家，就需要一百臺(tái)數(shù)據(jù)庫服務(wù)器。

第二就是可升級性、維護(hù)性較差。我們知道游戲的玩家是來自于五湖四海，游戲的時(shí)間也會(huì)比較分散。很難找一個(gè)合適的時(shí)間對數(shù)據(jù)庫 Shutdown 來進(jìn)行升級維護(hù)或者打補(bǔ)丁。

另外就是服務(wù)可用性的保障。最重要的是數(shù)據(jù)分片以后，數(shù)據(jù)的管理就會(huì)變得異常復(fù)雜，容易出現(xiàn)問題。舉個(gè)例子，我們需要統(tǒng)計(jì)某款游戲中哪一個(gè)角色被使用的最多。數(shù)據(jù)庫服務(wù)器一統(tǒng)計(jì)出來是角色一，服務(wù)器二統(tǒng)計(jì)出來的是角色二。但是有一種可能，角色三，在每一臺(tái)數(shù)據(jù)庫服務(wù)器上統(tǒng)計(jì)出來的都不是 Number One，但是加在一起它就是最受歡迎的角色。這就是數(shù)據(jù)匯總的問題，但涉及到數(shù)據(jù)匯總背后又會(huì)牽扯到很多復(fù)雜的事情，如數(shù)據(jù)如何跨節(jié)點(diǎn)輸出、如何保持?jǐn)?shù)據(jù)一致性等等。

針對這些問題，Cloud Spanner 可以很好解決，這是一個(gè)關(guān)系型數(shù)據(jù)庫，支持 Schaema、ACID、標(biāo)準(zhǔn)的SQL。具備 NoSQL 數(shù)據(jù)庫橫向擴(kuò)展的能力，全托管，沒有計(jì)劃內(nèi)停機(jī)的時(shí)間，還提供高達(dá)99.999%的服務(wù)可用性保障。

來自于第三方調(diào)研機(jī)構(gòu) Enterprise Strategy Group，一個(gè)為期三年的對數(shù)據(jù)庫成本分析。經(jīng)過分析發(fā)現(xiàn) Cloud Spanner 對比數(shù)據(jù)庫本地分片。三年之內(nèi)，整體擁有成本節(jié)約了78%，對比其他云廠商的類似的方案，也有37%的成本的節(jié)約。

最后我們來看一個(gè)客戶案例。

Dragon Quest Wolk，勇者斗惡龍系列的 AR 版本。2019年9月發(fā)布的首周就有五百萬的下載量，至今仍然每秒都有數(shù)億好幾千次的這種數(shù)據(jù)庫的查詢，運(yùn)行在上百個(gè)這個(gè)cloud spanner 節(jié)點(diǎn)上。

為什么使用cloud spanner呢？

根據(jù)該客戶自己的總結(jié)，主要是以下幾點(diǎn)。

首先是從擴(kuò)展性的方面，過去通過手工擴(kuò)展，往往需要幾個(gè)小時(shí)，甚至幾天，現(xiàn)在只需鼠標(biāo)點(diǎn)一點(diǎn)幾分鐘就可以擴(kuò)展。

其次，穩(wěn)定性。過去每個(gè)月至少有一次數(shù)據(jù)庫停機(jī)，現(xiàn)在偶爾會(huì)有，但是也不是因?yàn)?Cloud Spanner 的問題。

最后，從開發(fā)者的角度。過去除了開發(fā)游戲還要負(fù)責(zé)處理多個(gè)數(shù)據(jù)庫節(jié)點(diǎn)之間復(fù)雜的分布式事務(wù)，，以及數(shù)據(jù)一致性的問題。寫出來的代碼很難看懂?，F(xiàn)在這些事情可以交給 Cloud Spanner 去做。開發(fā)者可以將更多的精力 Focus 在自己的游戲上，寫出來的東西更加的簡潔和易于維護(hù)。

下圖是Dragon Quest Wolk 的架構(gòu)圖。我們看右邊的數(shù)據(jù)部分，用 Cloud Spanner 管理存儲(chǔ)用戶的數(shù)據(jù)，BigQuery 進(jìn)行數(shù)據(jù)分析，一主多從的 My SQL 用來master 信息，即游戲中怪獸、道具的信息。用這個(gè) Memorystore 即內(nèi)存數(shù)據(jù)庫將經(jīng)常用到的查詢 Cash 到里面，從而提高數(shù)據(jù)庫的數(shù)據(jù)訪問速度。

以上為今天的內(nèi)容，下一次我們來聊一聊如何借助數(shù)據(jù)分析+AI 來進(jìn)行游戲營銷，掌控玩家行為。

如果大家關(guān)于今天的內(nèi)容有什么問題，歡迎在評論區(qū)與我們交流互動(dòng)~

想獲取更多谷歌云相關(guān)資訊及干貨內(nèi)容？

趕緊關(guān)注我們吧！