Azure游戲部門：多人游戲后端參考體系結(jié)構(gòu)

這些參考體系結(jié)構(gòu)描述了各種具有不同替代方法的多人游戲后端用例和實現(xiàn)，讓您能夠構(gòu)建適用于您的游戲的云解決方案。

用例

在為游戲設(shè)計多人游戲后端時，有許多變量可供考慮。下面是一些示例：

管理級別-從將所有精力放在自己身上，到讓平臺處理一切事宜

操作系統(tǒng)-Windows或Linux

游戲會話的運行位置-專用服務(wù)器或?qū)Φ?P2P)

硬件-游戲會話的運行條件

處理時間-實時或非實時時間(NRT)

延遲-若出現(xiàn)滯后，玩家將處于不利情況

持久性-游戲世界繼續(xù)存在并在內(nèi)部發(fā)展，即使沒有玩家與之交互，或者每個會話都有自己的開始和結(jié)束

并發(fā)玩家數(shù)量-小、中、大規(guī)模

允許重新連接-如果一個或多個玩家斷開連接，他們是可以返回游戲，還是必須重新開始新的游戲會話

以下是一些多人游戲后端用例，供您瀏覽：

多人游戲Matchmaker

同步多人游戲

異步多人游戲

提示

如果您要尋找即時可用且可擴(kuò)展的多人游戲服務(wù)器解決方案，可以考慮PlayFab，這是一個具有多人游戲服務(wù)器支持的完整后端平臺，可用于構(gòu)建、發(fā)布和發(fā)展云連接游戲。

多人游戲設(shè)計

管理級別

計算服務(wù)因它們所提供的管理級別而異，包括從完全由您管理到完全由平臺管理：

原始虛擬機(jī)-一切均由您管理，它需要一個自定義擴(kuò)展解決方案

Azure容器實例(ACI)-一切均由您管理，但在容器中，它需要一個自定義擴(kuò)展解決方案

虛擬機(jī)規(guī)模集/批處理-根據(jù)您定義的規(guī)則，代表您管理虛擬機(jī)的擴(kuò)展

Service Fabric/Azure Kubernetes Service(AKS)-代表您管理容器的編排

PlayFab多人游戲服務(wù)器-代表您對在Azure上運行的游戲服務(wù)器進(jìn)行更高級別的編排。有關(guān)詳細(xì)信息，請參閱PlayFab多人游戲服務(wù)器。

操作系統(tǒng)

下表概述了不同Azure計算服務(wù)支持的操作系統(tǒng)。

*注意：多容器組目前僅限于Linux容器。

游戲會話在哪里運行？

專用服務(wù)器

玩家將其客戶端設(shè)備連接到服務(wù)器，以便玩游戲。

在考慮使用專用服務(wù)器時，請注意以下幾點：

它們可以提供連接性和可靠性優(yōu)勢。

它們非常易于進(jìn)行有效實現(xiàn)和擴(kuò)展。

玩家作弊更加困難。

其他玩家的Internet可能會影響游戲的幀同步情況。

根據(jù)游戲類型的不同，居住在專用服務(wù)器附近的玩家相比居住得較遠(yuǎn)的玩家可能會具有明顯優(yōu)勢。

對等(P2P)

在考慮P2P模型時，請注意以下幾點：

運營成本比利用專用服務(wù)器低。

相比專用服務(wù)器解決方案，更難完成真正成功的實現(xiàn)。

在很多地方，家庭Internet服務(wù)的上傳速度不夠快，只能應(yīng)對少數(shù)玩家。

一個玩家在游戲中出現(xiàn)網(wǎng)絡(luò)連接不佳可能會影響其他玩家的游戲體驗。

客戶端有時會由于NAT穿透問題而無法連接?？赡苄枰M(jìn)行端口轉(zhuǎn)發(fā)。

避免將每個玩家的IP地址直接交給其他玩家，否則玩家容易受到游戲中其他玩家的DDoS攻擊。

如果沒有一個中性服務(wù)器形式的中央機(jī)構(gòu)，就無法輕松防止作弊。

大廳

大廳系統(tǒng)相當(dāng)常見，這是玩家在實際開始游戲會話之前聚集的地方，因為他們需要從相同的初始狀態(tài)開始。從技術(shù)上講，實現(xiàn)后期加入支持是可行的，但由于這會顯著增加復(fù)雜性，因此很少見。大廳系統(tǒng)需要一個服務(wù)器，通常按如下方式工作：

玩家啟動大廳，并選擇性地設(shè)置游戲參數(shù)。

其他玩家可以通過游戲提供的任何查詢機(jī)制查看/搜索大廳。

其中一個玩家加入大廳。

當(dāng)有足夠的玩家（基于游戲和大廳（如果有）創(chuàng)建者制定的規(guī)則）時，大廳會安全地分發(fā)每個在大廳等待的玩家的詳細(xì)信息，此時它的工作便已完成。

然后，玩家開始以分散的方式發(fā)送數(shù)據(jù)包。

監(jiān)視和警報

除了您首選的遙測解決方案，您還可以利用Azure Monitor公開您在后端解決方案中使用的Azure服務(wù)中的指標(biāo)，以及診斷和活動日志。Azure Monitor還可幫助您確定影響游戲的問題?？紤]針對以下方面啟用警報：

CPU使用情況–您需要在主機(jī)的CPU即將達(dá)到飽和狀態(tài)的情況下收到通知。

磁盤I/O-設(shè)置在以下情況下發(fā)出的警報：游戲從磁盤讀取或向磁盤寫入的頻率超出預(yù)期。

內(nèi)存利用率-當(dāng)內(nèi)存分頁過多時，您應(yīng)該收到警報。

網(wǎng)絡(luò)流量-當(dāng)網(wǎng)絡(luò)流量接近飽和或突然驟降時，您應(yīng)考慮生成警報。

您可以使用Azure資源管理器自動配置Azure Monitor。有關(guān)Azure Monitor的詳細(xì)信息，請參閱使用Azure Monitor進(jìn)行完整堆棧端對端監(jiān)視。

硬件

充分了解運行游戲會話所需的處理能力、存儲、內(nèi)存和網(wǎng)絡(luò)流量，因為它與多人游戲后端所需的虛擬機(jī)類型直接相關(guān)。

有一些數(shù)據(jù)點與決策過程相關(guān)，并且超出了運行游戲會話所需的CPU：

游戲需要多少線程？

游戲會話需要多少RAM？

用戶玩游戲需要多大帶寬？

一個游戲會話將包含多少位用戶？

游戲是否需要超線程？如果您的游戲服務(wù)器依賴于超線程，則需要使用超線程內(nèi)核。

什么是內(nèi)存與核心比率？

通過收集此信息，您可以確定：

一次會話需要多少個內(nèi)核？

如果游戲服務(wù)器在一個線程中運行，則只需一個內(nèi)核。如果游戲服務(wù)器在1.5個線程中運行，則需要兩個內(nèi)核。

如果您想要在一個服務(wù)器中托管5個游戲會話，并且每個游戲會話需要一個線程，則需要至少5個內(nèi)核。如果您想要在一個服務(wù)器中托管5個游戲會話，并且每個游戲會話需要1.5個線程，則需要至少8個內(nèi)核。

考慮操作系統(tǒng)消耗量。經(jīng)驗法則是，為虛擬機(jī)超額配置1或2個內(nèi)核。

將產(chǎn)生多少出站流量？

這是一個重要數(shù)據(jù)，因為它具有經(jīng)濟(jì)影響。此外，如果一臺虛擬機(jī)中的玩家過多，您可能會面臨網(wǎng)絡(luò)限制，尤其是當(dāng)您嘗試在一個NIC中納入數(shù)千個用戶時，可能會出現(xiàn)瓶頸現(xiàn)象。

綜合考慮這些因素，您可以確定將需要的虛擬機(jī)以及需為其所支付的金額。不同的虛擬機(jī)類型具有不同的帶寬吞吐量。您需要確保網(wǎng)絡(luò)接口能夠處理需求。將每臺虛擬機(jī)的玩家數(shù)量乘以每個玩家消耗的帶寬。計算出的值不能大于針對每個虛擬機(jī)大小記錄的最大NIC/預(yù)期網(wǎng)絡(luò)帶寬(Mbps)：

Azure中Linux虛擬機(jī)的大小

Azure中Windows虛擬機(jī)的大小

值得一提的是，您可能想要利用高級存儲來提高單實例虛擬機(jī)的可用性。使用高級存儲，虛擬機(jī)的SLA為99.9%。

延遲的影響

在某些游戲中，需要瞬間反射，而且當(dāng)您將玩家的反應(yīng)時間和延遲相加時，游戲體驗可能會受到負(fù)面影響。

要減少或縮短延遲，需要考慮幾個問題。從實現(xiàn)角度來看，相當(dāng)標(biāo)準(zhǔn)的做法是，在客戶端啟用預(yù)測，“搶先一步”了解玩家將執(zhí)行的操作，但代價是玩家在屏幕上看到的內(nèi)容與游戲中實際發(fā)生的內(nèi)容之間偶爾會出現(xiàn)不一致。要減少這種不一致情況，可以使用外推或內(nèi)插等機(jī)制來確定游戲?qū)ο蟮娘@示位置，從而應(yīng)用對延遲的補(bǔ)償。

從基礎(chǔ)結(jié)構(gòu)角度來看，玩家到游戲服務(wù)器的距離越遠(yuǎn)，最終的延遲時間就越長。將玩家連接到距離其最近的游戲服務(wù)器會產(chǎn)生積極影響。Azure具有比任何其他云提供商更多的全局區(qū)域，提供可使您與世界各地的玩家更接近的規(guī)模。加速網(wǎng)絡(luò)可以減少服務(wù)器端的延遲，但請記住，它只有在具有至少4個vCPU的虛擬機(jī)中才能啟用。此外，如果您打算使用Linux虛擬機(jī)，當(dāng)同一虛擬機(jī)中有大量玩家時，您可以考慮使用DPDK來優(yōu)化延遲和吞吐量。

對于支持組群的游戲，需要處理組群中不同成員之間距離較遠(yuǎn)的情況。在游戲中，添加手動選擇要連接到的區(qū)域的功能，或添加最低延遲的公分母算法。

在緩解措施無效的情況下，網(wǎng)絡(luò)延遲可能會達(dá)到無法控制的水平。當(dāng)發(fā)生這種情況時，需要采取更有力的措施，例如將延遲時間最長的玩家斷開連接。

提示

最佳做法是，啟用遙測功能來測量玩家的延遲情況，并將其與QA團(tuán)隊或Beta版測試人員的反饋機(jī)制相結(jié)合，這樣在他們遭遇延遲時您可以即時了解相關(guān)情況（例如：組合鍵、游戲手柄按鈕組合、屏幕上的圖標(biāo)）。通過這兩種方法，將更容易找出導(dǎo)致玩家感到延遲的原因。

協(xié)議

對于需要實時通信的游戲，最佳做法是通過用戶數(shù)據(jù)報協(xié)議(UDP)進(jìn)行傳輸。與傳輸控制協(xié)議(TCP)相比，該協(xié)議的實現(xiàn)往往更為復(fù)雜，但在性能方面有顯著改善。

對于異步或回合制通信，通過HTTPS利用JSON就足夠了。

每個游戲會話的并發(fā)玩家數(shù)

從只有2個玩家的井字游戲運動，到100個玩家決戰(zhàn)到最后一人的大逃殺游戲，再到成千上萬的玩家參與的一些持久性的世界游戲，同一游戲會話的并發(fā)玩家數(shù)會影響要使用的體系結(jié)構(gòu)和服務(wù)。這些用例中考慮的三個范圍是：

小-10個或更少的并發(fā)玩家。

中-11到50個之間的并發(fā)玩家數(shù)。

大-超過50個并發(fā)玩家。

最佳做法

容量規(guī)劃至關(guān)重要

與任何擴(kuò)展服務(wù)一樣，花費時間來規(guī)劃所需的適當(dāng)實例數(shù)是至關(guān)重要的一步。如果使用的實例太少，性能將下降。如果使用過多，則會帶來不必要的費用。

盡早測試并為您自己提供時間。在發(fā)布游戲之前，盡早運行概念證明以及一個或多個測試版，以了解您的玩家在一天中何時使用最多，以及您將使用多少容量來提供支持。

確保您的軟件具有可擴(kuò)展性，并且一切準(zhǔn)備就緒，讓玩家在從登錄和匹配到游戲服務(wù)器本身開始就能享受游戲的樂趣。在每次并發(fā)玩家數(shù)增加零時，在不同的玩家并發(fā)級別（100、1,000、10,000、100,000等）進(jìn)行測試，您可能會發(fā)現(xiàn)新的瓶頸，并且必須對此進(jìn)行一些調(diào)整。

部署方法

如果您利用了虛擬機(jī)規(guī)模集、Service Fabric或批處理，請使用單個群集、多個虛擬機(jī)規(guī)模集以及每次按1-4個節(jié)點少量增加的規(guī)模。請記住，利用多個虛擬機(jī)規(guī)模集將加快擴(kuò)展速度，但會增加成本。

在早期測試中捕獲日常工作負(fù)載后，就可以使用這些信息來主動（在需要容量之前的一小時）規(guī)劃擴(kuò)展操作。

避免更改基礎(chǔ)結(jié)構(gòu)

充分利用Azure邏輯應(yīng)用，并盡量避免更改基礎(chǔ)結(jié)構(gòu)。保持運行實例的暖池將可以讓玩家立即進(jìn)入游戲，但也會增加您的成本。

故障防范

如果虛擬機(jī)出現(xiàn)故障，您的游戲會話會發(fā)生什么情況？根據(jù)游戲類型和您希望在實現(xiàn)中增加的復(fù)雜程度，有幾種可供選擇的方案。

對于會話持續(xù)幾分鐘的快速簽入/簽出游戲，您可以考慮不進(jìn)行任何操作并讓玩家回到大廳重新開始，因為這對玩家的影響可能不會太糟。如果您面對的是一個持久的世界級游戲，虛擬機(jī)發(fā)生故障可能是一個更為嚴(yán)重的問題，您可能需要在保留玩家狀態(tài)的同時自動將他們移動到新服務(wù)器。

使用監(jiān)視服務(wù)確定節(jié)點是否已發(fā)生故障并啟用警報。您也可以考慮保留發(fā)生故障的虛擬機(jī)以查明出現(xiàn)環(huán)境故障的原因，或直接將其刪除。

其他資源和示例

Ethr是TCP、UDP和HTTP的網(wǎng)絡(luò)性能測量工具

Azure數(shù)據(jù)體系結(jié)構(gòu)指南