【伺服器端】
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掛起等問題發生。這些問題在開發的時候，本地單元測試是發現不了的！