3.2　方案設計

要支持數(shù)以萬計的在線玩家，必然要采取分布式的設計方案。本節(jié)會介紹一種通用的分布式服務端架構方案。如果讀者沒有服務端開發(fā)的經(jīng)驗，閱讀時可能會稍微有些吃力，不過沒關系，先了解思路，后面進一步學習。

3.2.1　拓撲結構

我們設計了如圖3-3所示的服務端結構，其中圓圈代表服務，圈內(nèi)文字指明服務的類型和編號，比如“gateway1”代表“gateway”類型的1號服務。此服務端結構有如下特點：

·可以支持多個節(jié)點橫向拓展。理論上，只要開啟更多節(jié)點，就能夠支持更多玩家。

·符合Skynet設計理念。每個服務都是輕量級的，功能單一，通過多個服務協(xié)作完成服務端功能。

在圖3-3中，每個節(jié)點被劃分成兩部分，其中，用虛線方框圍起來的稱為“本地”服務，方框外的稱為“全局”服務，它們的具體區(qū)別如表3-1所示。

圖3-3　服務端拓撲結構設計圖

表3-1　圖3-3中本地服務和全局服務的區(qū)別

3.2.2　各服務功能

服務端包含了gateway、login等多個類型的服務，它們的功能如表3-2所示。

表3-2　各種服務的功能

3.2.3　消息流程

從客戶端發(fā)起連接開始，服務端內(nèi)部的消息處理流程如圖3-4所示（這是個簡化圖，忽略了nodemgr）。

圖3-4　服務端消息處理流程

登錄過程：在階段①客戶端連接某個gateway，然后發(fā)送登錄協(xié)議。gateway將登錄協(xié)議轉(zhuǎn)發(fā)給login（階段②），校驗賬號后，由agentmgr創(chuàng)建與客戶端對應的agent（階段③和④）完成登錄。如果該玩家已在其他節(jié)點登錄，agentmgr會先把另一個客戶端頂下線。

游戲過程：登錄成功后，客戶端的消息經(jīng)由gateway轉(zhuǎn)發(fā)給對應的agent（階段⑤），agent會處理角色的個人功能，比如購買裝備、查看成就等。當客戶端發(fā)送“開始比賽”的協(xié)議時，程序會選擇一個場景服務器，讓它和agent關聯(lián)，處理一場戰(zhàn)斗（階段⑥）。

3.2.4　設計要點

1.gateway

這套服務端系統(tǒng)采用傳統(tǒng)C++服務器的架構方案。gateway只做消息轉(zhuǎn)發(fā)，啟用gateway服務有以下好處：

·隔離客戶端與服務端系統(tǒng)。如果要更改客戶端協(xié)議（比如改用json協(xié)議或protobuf），僅需更改gateway，不會對系統(tǒng)內(nèi)部產(chǎn)生影響。

·預留了斷線重連功能，如果客戶端掉線，僅影響到gateway（下一章介紹）。

然而引入gateway意味著客戶端消息需經(jīng)過一層轉(zhuǎn)發(fā)，會帶來一定的延遲。將同一個客戶端連接的gateway、login、agent置于同一節(jié)點，有助于減少延遲。

2.agent和scene的關系

agent可以和任意一個scene通信，但跨節(jié)點通信的開銷較大（見1.4.2節(jié)）。一個節(jié)點可以支撐數(shù)千名玩家，足以支撐各種段位的匹配，玩家應盡可能地進入同一節(jié)點的戰(zhàn)斗場景服務器（scene）。

3.agentmgr

agentmgr僅記錄agent的狀態(tài)、處理玩家登錄、登出功能，所有對它的訪問都以玩家id為索引。它是個單點，但很容易拓展成分布式。