H5遊戲開發的架構總結(二) 服務器端

【服務器端】
1.關於Go語言
我們的H5遊戲服務器框架是用Go語言開發的。以前做頁遊的時候是用的php和python，都是動態語言。在上線之後，高併發的時候，單機有性能問題，一直沒有好的解決辦法！
13年的時候我原來的領導開始轉用Go來開發手遊的服務器端，所以我也跟着轉型了！
正如七牛的許世偉所說，用go開發，是可以降低程序員心智負擔的！靜態編譯的優點不用贅述，語言簡潔，開發效率高，特別是goroutine和chanel兩大神器，專治各種疑難雜症。
Go語言這兩年的發展非常迅猛，特別是在中國的很多重量級互聯網公司得到大量運用。
而且語言本身已經發展到1.6版本，GC時間從原來飽受詬病的幾秒下降到了1毫秒，除非是對延遲要求非常苛刻的應用場景，絕大部分的應用場景都能hold住！

2.關於通訊協議
我們這套框架，最開始是手遊的遊戲服務器。所以只支持tcp socket。
後來轉H5之後，又加入了對websocket協議的支持，兩者放在一起，做了封裝。
後來爲了兼容不支持websocket協議的android手機，又加入了對http協議的支持，因爲http屬於應用層協議，tcp是傳輸層協議，沒法簡單的封裝在一起，所以就寫了兩套。
但是發送和接受的內容都是一樣的：加密之後的自定義格式的二進制數據。


3.關於緩存和數據庫
我們的數據庫用的是mysql，緩存同時支持memcache和redis。
在業務層和數據庫之間，封裝了一層k-v的cache，可以通過配置分別使用memcache或者redis。
每張數據表都有自增長的id主鍵，並且有一個類似java bean的struct與之相對應.
針對單表的sql操作，根據類型不同有不同的處理機制：
1)select操作就根據id去緩存裏面取值，沒有就查mysql，然後緩存結果.
2)update/insert/delete操作，就直接操作mysql，同時刪除對應緩存.

如果是對多表的聯合查詢，一般都是直接走sql，不走緩存。

這樣就可以在高併發的時候，減輕數據庫的訪問壓力。
目前是只用到一個主庫。後期壓力上來可以改成1主多從。


4.關於單元測試
Go語言對單元測試的原生支持，讓測試驅動開發成爲一種本能！
但是單元測試也有不同的重量級，有的功能需要依賴項目啓動時讀取的配置文件，有的功能還需要玩家的特殊狀態。
再加上多人協作開發的時候，需要控制每個人的私有單元測試邊界和公用的單元測試範圍，免得互相影響，因爲引入不必要的測試而導致測試總時長增加！
在項目開始的時候，強調單元測試的重要性，並做好整個項目的單元測試的組織規劃和部署，非常重要，可以事半功倍，節省大量後期測試和糾錯的時間！


5.關於excel工具鏈
策劃的數值表都是excel，我們用go寫了個轉換工具可以通過命令行把指定的excel轉成服務器端需要的json格式文件。
其中有些json文件的內容是客戶端需要的，於是又用python寫了個轉換腳本，提取和組合服務器端的json文件內容，生成客戶端需要的json格式文件。
有了這兩個工具，就可以實現自動化部署，方便測試在單獨的數據測試服上調數據！


6.關於服務器端AI
碰碰車的聯網比賽場裏的AI行爲比客戶端複雜，策劃在AI行爲數據表裏進行配置，轉成json，在比賽場里根據AI配置文件控制NPC的行爲。
將計算之後的NPC的位置和角度等狀態發送給客戶端，客戶端只負責呈現！


7.關於聯網糾偏
碰碰車的聯網比賽，服務器端在房間裏會模擬客戶端的幀update事件，更新頻率在80毫秒一次。
每次update的時候都需要計算房間內所有agent的位置，進行碰撞檢測，以及其他邏輯。並把更新後的信息，通過糾偏事件下行給所有玩家。
這個更新頻率太短和太長都不好。太短會造成服務器和客戶端CPU壓力太大和網絡流量的增加，太長會造成客戶端收到的位置和自身計算的位置差距太大，
如果不做線性補償，直接以服務器端爲準進行更新，會有跳躍感。


8.關於微服務和全球統一服
我們一開始做這套遊戲框架的目標就是支持高併發的全球統一服。
單機的性能再怎麼優化都有天花板，微服務和容器雲是目前互聯公司應對類似需求場景的通用解決方案！
按計劃分三步走：
第一步：單塊系統，通過命令行來打包和發佈。目前已在線上運行！
第二步：通過docker創建容器，實現自動化打包和發佈。目前已經在本地mac實現docker創建容器和運行測試，還沒有部署到線上！
第三步：進行微服務拆分，通過docker容器雲實現動態擴容，支持高併發，實現全球統一服。


9.關於服務監測
go是靜態語言，所以編譯運行的web應用如果出現panic，整個進程就退出了，所有連接都會被斷開。
這跟php這種動態語言提供的web應用還不太一樣，一個連接的服務掛了，其他連接不受影響。
所以必須充分的測試，儘量做到線上的服務不要panic。但是人難免會犯錯，程序也不可能百分百沒有bug，所以必須做好監控和預防措施！
我們的解決方案是有個定時程序每分鐘檢查一次服務器程序的進程是否還在，如果沒有就說明程序panic了，就重啓服務器應用，將影響降至最低。
同時郵件通知相關技術。技術收到郵件之後可以通過日誌查看panic的原因，解決bug之後，測試通過，再發布更新！


10.關於壓力測試
1）測併發鏈接數上限，並以此爲參考，設定登錄排隊系統的人數限制！
2）測比賽場的玩家數上限，這個需要提前準備足夠的AI玩家數據，然後同時進入指定比賽場，
   一是看自動分房間功能是否正常，而是看有沒有併發死鎖和chanel掛起等問題發生。這些問題在開發的時候，本地單元測試是發現不了的！

H5遊戲開發的架構總結(一) 客戶端