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

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

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

游戲接入層的擴展

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

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

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

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

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

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

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

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

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

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

負載均衡的擴展即預(yù)熱，需要時間和人工進行干預(yù)。

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

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

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

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

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

這個問題其實并沒有標準答案,完全取決于業(yè)務(wù)情況以及團隊的技術(shù)能力。

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

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

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

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

-編排: 決定在哪兒運行容器

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在這個 Demo 中我們看到的是手工擴展的方式，那么有沒有自動擴展的方式呢？

有，且有兩種。

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

另外一種方式是 Webhook ，通過Webhook 我們可以自定義一個 Webhook Service ，進行指標自定義及觸發(fā)擴展或收縮的動作。

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

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

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

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

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

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

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

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

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

數(shù)據(jù)庫的擴展應(yīng)該是三個部分中最難的，這是因為傳統(tǒng)的數(shù)據(jù)庫往往會成為限制游戲性能的瓶頸。

因為從第一天開始，它就被設(shè)計為一個單點，很容易出現(xiàn)單點故障。

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

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

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

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

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

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

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

最后我們來看一個客戶案例。

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

為什么使用cloud spanner呢？

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

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

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

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

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

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

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

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

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