本人80后程序猿一枚，原來搞過C++/Java/C#，因為工作原因最后選擇一直從事C#開發，因為讀書時候對游戲一直比較感興趣，機緣巧合公司做一個手游的項目，我就開始游戲服務器的折騰之旅。
游戲的構架是前端unity3d，服務端C#，數據庫用SqlService。基礎工作做完，就開始動工，因為前期考慮不周，所以暫定使用Http短鏈接進行，這也是導致后面服務器失敗的根本原因之一，下面就說說前期最基礎的構架：
就是最基礎的構架，但是接下來由於游戲的細化，一些列的問題就出現了：
1.賬號登陸的頂號問題如何處理，我們采用的每個用戶登錄之后生成sessionID，然后在客戶端心跳包(輪訓)請求服務器，匹配用戶ID和SessionID的匹配進行用戶時候重復登錄；
2.在游戲戰斗過程中，會涉及服務器對客戶進行廣播數據，因為采用HTTP請求，所以就只有使用心跳包進行處理；
3.服務器很多配置文件都采用cspbuf進行配置使用，因為擔心每次加載數據過多，所以采用的依賴緩存進行加載和處理；
貌似所以的問題都處理好了，接下來就是測試了，開始進行小數量的測試，游戲還可以勉強的運行，但是隨后隨着游戲玩家數量的增加，服務器慢慢的支撐不住，出現CUP和內存消耗過高，導致游戲經常卡段的情況，最后經過分析，導致的原因可能如下：
1.客戶端采用過多的輪訓服務器，導致IIS壓力過大，CUP和內存增加；
2.配置緩存文件過多，導致服務器內存消耗；
3.游戲過程中很多數據都直接讀取數據庫操作，導致了IO過多，所以CUP和內存消耗過大；
4.傳輸過程中大部分數據使用正常的JSON數據沒有進過壓縮和處理，也導致傳輸通道消息資源的浪費；
5.程序中的部分優化沒有做到；
反正等等原因導致了第一次游戲服務器的開發，出現各種問題，現在表面解決了問題，能夠在小數量范圍運行，但是數據大就出現問題，所以就開始考慮下一個版本的重構；