一、項目背景介紹
1.1 項目內容
以世界多同屏為技術背景，結合雲原生技術，設計並實現一款支持多人交互的高實性游戲后台系統。借助Kubernetes雲原生技術將后台系統按照工業界標准進行容器化，使得面臨業務時能夠靈活的彈性伸縮與動態調度。在實現基礎游戲服務框架的基礎上，支撐多玩家同屏競技，對多人競技的性能問題進行進一步的優化。搭建工業化的流程管線，借助敏捷方法與DevOps思想支持持續迭代和運維自動化，可一鍵部署到雲環境中對外提供可靠服務。
1.2 項目意義
在游戲發展如此迅速的今天，網絡游戲越來越頻繁地進入人們的視線，但網絡游戲的開發和運維中有着一系列的問題也逐漸暴露出來，例如：游戲中數據的同步問題、影響客戶端與服務端交互的性能瓶頸問題、最大支持的同屏人數問題、以及在運維過程當中的單點故障等問題。
本課題的目的擬在實現一個部署在雲端的游戲后台系統，來實現對多人同屏的支持、單點故障的解決以及對后台服務的更好地維護和管理。在當前游戲產業不斷成熟、消費群體不斷擴大的大背景下，該后台系統可以為解決上述網絡游戲開發的常見問題提供良好的解決方案。
二、軟件設計方案
2.1 系統架構
本項目內部系統之間采用微服務架構,微服務架構是由一系列獨立的微服務共同組成軟件系統的一種架構模式；每個微服務單獨部署，跑在自己的進程中，也就是說每個微服務可以有一個自己獨立的運行環境和軟件堆棧；每個微服務為獨立的業務功能開發，一般每個微服務應分解到最小可變產品（MVP），達到功能內聚的理想狀態。系統中的各微服務是分布式管理的，各微服務之間非常強調隔離性，互相之間無耦合或者極為松散的耦合，系統通過前端應用或API網關來聚合各微服務完成整體系統的業務功能。
客戶端與對戰專屬服務器之間采用C/S架構(客服-服務器架構)，客戶端通過udp協議與對戰專屬服務器進行通信，服務器為所有客戶端提供轉發和業務處理服務。
各個模塊之間使用grpc進行通信。在客戶端進行游戲時，客戶端通過與服務器之間維持的一條UDP連接來直接傳送幀數據和校驗數據。
2.2 接口API列表
由於篇幅有限，下面展示最核心的狀態同步接口：
- 游戲實體狀態改變廣播推送（EntityInfoChangeNotify）由服務器向客戶端推送，用於廣播對局中玩家實體或者道具實體發生狀態改變的推送（比如吃到道具、檢測到碰撞、道具消失等）
| 參數名 | 參數描述 | 參數類型 | 是否必須上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| entityType | 實體類型（包含道具、玩家等） | int32 | 是 | 否 |
| entityId | 實體唯一標識 | int32 | 是 | 否 |
| playerMsg | 改變后玩家狀態 | PlayerMsg | 否 | 否 |
| itemMsg | 改變后物品狀態 | ItemMsg | 否 | 否 |
- 游戲全局初始化信息推送（GameGlobalInfoNotify ）由服務器向客戶端推送，用於對局開始時向各個玩家推送初始化信息（比如出生位置，道具初始位置，倒計時等）
| 參數名 | 參數描述 | 參數類型 | 是否必須上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| playerNumber | 玩家數量 | int32 | 是 | 否 |
| time | 倒計時 | int64 | 是 | 否 |
| playerMsg | 玩家信息列表 | PlayerMsg | 是 | 是 |
| ItemMsg | 道具信息列表 | ItemMsg | 是 | 是 |
| mapMsg | 初始化地圖信息 | MapMsg | 是 | 是 |
- 玩家狀態改變請求（EntityInfoChangeRequest ）由客戶端向服務器發送，用於當狀態改變事件（發生碰撞等）觸發時，向服務器請求改寫狀態並廣播至其他的客戶端
| 參數名 | 參數描述 | 參數類型 | 是否必須上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| eventType | 事件類型 | int32 | 是 | 否 |
| playerId | 發生改變的玩家id | int32 | 是 | 否 |
| linkedId | 改變關聯實體的id（比如吃道具事件中關聯者就是該道具） | int32 | 是 | 否 |
| linkedType | 關聯實體類型 | int32 | 是 | 否 |
| playerMsg | 改變后玩家狀態 | PlayerMsg | 是 | 否 |
- 玩家狀態改變響應（EntityInfoChangeResponse ）由服務器向客戶端發送，用於回復客戶端發來的玩家狀態改變請求，此時服務器要對該玩家進行一系列的合法性校驗
| 參數名 | 參數描述 | 參數類型 | 是否必須上送 | 是否支持以列表形式上送 |
|---|---|---|---|---|
| changeResult | 響應結果 | bool | 是 | 否 |
三、軟件系統概念原型視圖
分解視圖
分解是構建軟件架構模型的關鍵步驟，分解視圖也是描述軟件架構模型的關鍵視圖，一般分解視圖呈現為較為明晰的分解結構（breakdown structure）特點。分解視圖用軟件模塊勾划出系統結構，往往會通過不同抽象層級的軟件模塊形成層次化的結構。本項目的功能分解視圖如下：
依賴視圖
依賴視圖展現了軟件模塊之間的依賴關系，能有效幫助理清一個軟件模塊的變更對其他軟件模塊帶來影響范圍。本項目依賴視圖如下：
執行視圖
執行視圖展示了系統運行時的時序結構特點，比如流程圖、時序圖等。執行視圖中的每一個執行實體，一般稱為組件（Component），都是不同於其他組件的執行實體。本項目的核心業務時序圖如下：
部署視圖
部署視圖是將執行實體和計算機資源建立映射關系，本項目部署在騰訊雲中的k8s環境下，部署視圖如下：
實現視圖
本項目的項目文件結構如下：
|——assets
|——build
|——cmd
|——configs
|——tools
|——apt
|——proto
|——net
|——game
| |——module
| |——battle
| |——handler
|——main.go
四、數據庫設計
賬戶（Account）：用於存儲玩家賬戶信息，主要存儲登錄憑證以及玩家的等級得分等持久化數據。
玩家（Player）：玩家代表一局游戲中出現的賬戶實體，相比於賬戶，玩家是一個更實時性的概念，由於核心數據都持久化存儲在賬戶表中，因而玩家可以隨時被創建和銷毀，不用擔心持久存儲的問題。
對局（Game）：對局主要管理單局比賽的數據，包括玩家的創建和銷毀，玩家之間的匹配，以及等級和分數的結算等。
道具（Prop）：代表可能出現在對局中的道具，不同的道具有不同的效果和類型，對玩家帶來的增益也不同。
蛇（Snake）：對局中玩家操控蛇對象的實際表征數據。
五、技術選型&部署環境
5.1 技術選型
- grpc：基於HTTP/2高性能RPC框架
- kcp-go: 高安全性的kcp的 GO語言實現，包含 UDP會話管理的簡單實現，可以作為后續開發的基礎庫
- mongoDB：基於分布式文件存儲的非關系型數據庫
5.2 部署環境
- Kubernetes：Google開源的一個容器編排引擎
- Docker：開源的應用容器引擎
- 騰訊雲
六、項目概念原型核心工作機制
項目概念原型的核心工作流程為：
- 玩家通過登錄、注冊等常規操作進入游戲，進入游戲后可以查看到賬號的等級、歷史最高分等信息
- 玩家點擊開始匹配按鈕以后可以開始進行多玩家對局匹配，匹配成功以后玩家進入到貪吃蛇對局中，可以通過遙感操控蛇移動與吃道具等游戲操作
- 對局倒計時結束進行所有玩家的分數結算，然后玩家返回到主界面