全球同服--coc類遊戲服務器架構

首先，遊戲服務器是IO密集型服務器，它的主要瓶頸在網絡IO，而不是CPU，這點要記住了。所以經常服務器問題都會出現在網絡IO，帶寬，數據庫磁盤讀寫上面，而非CPU上面。

其實全球同服也就是大量在線嘛，比如C1000k，甚至更多。同服，只是你看起來同服，而不是他本身就在同一個服務器上，或者同一個進程上，這是完全不現實的。一個好的服務器進程，能同時承載10k的遊戲玩家(還依賴於遊戲邏輯複雜度)已經不錯了。其實要全球同服，就是堆服務器進程嘛。
講一下我用過的其中一種架構模型，也是公司按着bigworld架構設計的：
1.Gate:首先要有一個(多個)Gate(網關)服務器，負責客戶端連接及消息轉發到GameServer(遊戲服)（選服邏輯）,保持客戶端到服務端的連接
沒有任何邏輯，只做消息加密和解密，以及客戶端和服務器消息的轉發(相當於兩者之間的橋樑).
2.GameServer:GameServer是主要的遊戲進程,提供遊戲邏輯功能(採用單進程(或者單線程)模型,遊戲服務器的瓶頸從來不在CPU,所以只做邏輯功能的話單線程足夠了,在這裏沒必要用多線程或多進程)。
3.DBManager:實現數據庫的讀寫，方便Game服務器異步讀寫數據庫的數據(有些把數據庫讀寫放在遊戲服，沒有單獨的服務器，那恐怕遊戲服單進程就不夠用了)。
4.GameManager:負責管理所有的GameServer，GameServer之間消息轉發，提供廣播到所有Game的功能。

客戶端連Gate，Gate連GameServer，GameServer連DBManager，GameManager管理所有的GameServer並通知所有的Gate。

除了GameManager只有一個，理論上Gate，GameServer，DBManager都可以擴展到多個實例，你要實現全球唯一服，理論上就是擴展GameServer，那麼怎麼讓他們看起來在一個服呢？其實很簡單，COC大多數都是單服玩法，只有交互玩法的時候你才能感受到它是同一個服。

主要講講GameServer，這是主要的處理服務器邏輯的地方，一般單進程就可以了，一個epoll_wait
hold住全場，然後做分發，理論上cpu都能承載的住，而epoll能處理的上限，一般跟機器的內存有關，遠大於1024，正常的也達到100k，當然考慮到邏輯的複雜度，一個實例一般處理的連接接近10k就可以了。
那怎麼處理100k，1000k甚至更多了，那就多個實例，那這樣還是唯一服嗎？是的，至少可以看起來是，遊戲自然有單人玩法和多人玩法，單人玩法自然自己在自己的服就可以了，誰也不知道是不是跟別人一個服。
當然有全服的排行榜，好友系統之類的怎麼辦呢，其實很簡單，我們不是有GameManager嗎，它就是負責做這事的，每當你發個好友請求，GameManager廣播一條消息，然後如果有某個GameServer存在這個玩家，那就回應你，你們就可以相互通信了，更簡單的想辦法獲取玩家的服務器ID號，直接通過GameManager轉發給那個服務器，自然就可以通信了，就像在同一個服務器一樣。
排行榜呢，最簡單的，指定一個服務器，或者單獨開闢一個服務器做排行榜，所有數據變動都通知這個服務器，然後服務器自然就能排行了，然後再廣播。
雙人戰鬥或者多人副本呢？
像COC這樣的，掠奪戰，我們當時的做法就是，直接搜到敵方，然後把自己的玩家，士兵軍隊等需要的數據序列化之後，傳到對面的服務器去，反序列化，然後直接開打，打完再把數據傳回來。
更多人的呢，那就方便點，再開闢一類服務器，叫BattleServer，專門負責多人玩法，副本玩法之類的，多人的時候，把所有的多人數據遷移到BattleServer，然後多人（副本玩法）結束的時候，再通過GameManager把數據遷移回原來的服務器。

這樣看，其實全球唯一服也就沒有那麼高大上了。

如果有興趣，可以看看KBEngine服務器引擎，作者按照bigworld架構設計的，可以滿足你的要求。