系統簡介

我們在《江湖X:漢家江湖》系統中設計了一個每晚9點-10點的論劍系統，它的核心是一個帶實時BAN/PICK的服務端自動計算的RANK框架。

如圖：

根據雙方分數匹配上之後，雙方輪流進行BAN人、選人。最後伺服器計算自動戰鬥，並且下發錄像，雙方進行播放。

我們使用伺服器組架構，當下的峰值數據大概是單服同時在線1萬人，一個小時內觸發的戰鬥量級可達數十萬場。我們的戰鬥參數非常複雜，整場戰鬥在一台I7的PC機上計算約需要3-4秒，吃滿一個core。所以這種量級的處理，放在單台伺服器上是非常不科學的，估計同時一百人戰鬥就可以隨便down掉這台伺服器。

我們的設計目標是世界同服，所以需要一個架構來支撐理論上無限擴展的用戶並發量級，所以在此設計一個分散式的處理架非常重要。

今天給大家分享一下，我們是如何設計和實現這套系統的。

漢家江湖的伺服器組結構

先說一下設計前提：漢家江湖使用的是基於redis為核心的伺服器組架構。一個邏輯伺服器的實體下掛接了若干台ECS、DB、redis，以及一台雙備的索引伺服器。這樣是為了提高同服在線玩家數和伺服器穩定性，不了解的玩家可以看我們這篇文章：

兩萬人在線伺服器架構和一些公有雲使用心得(兩萬人在線伺服器架構和一些公有雲使用心得)

分散式的論劍計算系統

然而我們希望論劍系統是獨立於伺服器組之外的，也就是未來可以實現跨伺服器組的論劍交互。所以我們給該玩法系統設定的是一個完全獨立的玩法系統

1、系統架構

其中proxyServer可以認為是來自於不同伺服器組的ECS實體，直接處理與客戶端長連接的session。

其中各個名詞解釋如下：

1、Client 指unity遊戲客戶端；

2、RankProxy：Rank客戶端在伺服器上的代理，指當前的遊戲服（SCUT SERVER），由於是世界服的，所以遊戲服只充當代理角色；

3、RankDb 指RANK相關的資料庫，同一個RANK群落（跨服戰鬥）指向同一個RANK資料庫；

4、ComputeNode：RANK的計算節點，指一台伺服器上部署的用於計算RANK戰鬥結果的程序；

5、RankComputeCluster:指ComputeNode的集合。

6、MatchServer配對伺服器，一個Rank群落只有一個實例。

7、MessageBus：消息匯流排，提供訂閱/發布介面，實現松耦合的分散式通信機制

2、功能要點：

• RankProxy
  • 接受終端用戶的所有行為（登錄、登出、匹配、BAN/PICK、查詢等）
  • 與終端用戶交互
• RankDb
  • 一個RANK DB集中存儲一個RANK群落的所有數據（從部署架構來說，我們可以實現同一區內的RANK戰鬥、甚至是跨大區的RANK戰鬥，區別只是在於RankDb）
  • RANK DB自身高可用
• ComputeNode
  • 集群計算（可以以集群的方式接受任務，任務可以分步到各個節點去分別計算）
  • 冪等（任何一台實例計算結果一致，並且不會重複計算）
• MatchServer
  • RANK匹配配對
  • 主動清理過期RANK
  • 為了防止單點故障，其自身應該是高可用的
• 各個伺服器應該都是無狀態的
  • 原因是支持客戶端斷線重連，而客戶端連接是根據網關路由分配RankProxy的，所以這裡要求連到任何一個RankProxy都可以繼續流程
• MessageBus、MQ
  • 見消息匯流排說明

3、業務時序

帶顏色部分為使用消息匯流排通信

1、橙色部分使用MessageBus

2、綠色部分使用MQ

4、消息匯流排

我們使用互聯網中間件來實現各個分散式模塊的通信，以及分散式計算的集群消費模式。同時使用以下兩種方案：

MessageBus

MessageBus使用redis的發布/訂閱作為伺服器間的實時通信信道，所有的通信均採用廣播，根據業務屬性，該廣播信息為一次性的（可丟棄）。每個伺服器根據自己的需要過濾消息。

MQ

戰鬥計算任務由於佔用大量的CPU計算資源，我們需要搭建計算集群。使用阿里雲MQ提供的集群消費模式，保證數據下發到一台計算節點。

成果

漢家江湖上線近2個月以來，我們以彈性的雲計算資源實現了峰值DAU10萬用戶規模的論劍，並發上千場戰鬥計算，一小時內十萬級別的計算規模。在僅1個程序員維護伺服器系統的情況下，保證系統穩定運行。

其中雲伺服器提供商（阿里雲）出過幾次MQ和Redis的BUG，導致我們的系統紊亂之外，沒有任何運營事故。並且此框架未來足以支撐更大量級的用戶，目前來看其理論瓶頸在於基於redis pub/sub的消息匯流排（MessageBus）的IOPS，未來需要的時候可以在這個點做基於業務邏輯的水平拆分。

推薦閱讀：