原來的架構是按照大服設計的，所以在資料庫上面的設計乙個服對應乙個資料庫。假設我們滾了500個服，就需要建500個資料庫，部署500個遊戲服。無論後續跨服、合服的業務擴充套件，還是運維的維護方面，都變得比較複雜和困難。特別是合服的需求上面，需要將兩個資料庫甚至多個資料庫合併成乙個資料庫。在量上來的時候，這一切都變得無比繁瑣和複雜。開發人員也需要花費較多的人力和時間去寫相應的工具。而且操作相對複雜，也比較容易出bug。而且後續新增的業務如果出現了持久化資料就需要增加相應的合服處理。
如果說我們一開始就已經將資料庫合併了呢，是不是後續根本就不需要去合併資料庫了。所以如果在當初框架設計的時候就已經按照邏輯來分服的話，後續的事情處理起來就簡單多了。問過同行業的一些遊戲架構，他們也是這麼處理的。
對於合服
因為資料其實還是在同乙個庫裡面，而且也是在同乙個伺服器裡面。只要簡單處理，或者甚至不需要任何處理，就可以將兩個或多個服合併。只需要在後台設定一下入口配置、可見配置就可以解決合服的問題了。
對於跨服
跨服原本的問題就是需要從不同庫讀取資料和與不同服進行互動。如果本身就不存在多服的問題，也不存在跨服的問題。
雖然邏輯分服可以比較完美解決合服的問題，但是對於跨服還是需要單獨處理。畢竟如果乙個邏輯分服的伺服器真的扛不住的時候，就會出現真的物理分服。對於跨服的需求來說，可能都是需要跨的。
維護成本
相對於物理分服，邏輯分服可以極大地降低運維成本。資料庫數量級可以極大減少，伺服器數量也可以減少。對於備份、更新等運維操作都相對變得簡單。甚至可以不依賴於運維工具，就可以簡單地維護機器了。一台機器部署乙個服(多個邏輯服)對比一台機器部署多個遊戲服(乙個邏輯服)，需要初始化的記憶體一般來說會變小(不排除不一樣的情況)，機器的資源占用一般來說會小很多。所以對物理機的利用效率可以提高很多。
使用者數量級的問題
開發成本
由於邏輯分服，的確是增加了一些內容，譬如玩家所在的伺服器id。但是這個處理起來並沒有多大的難度，而且對key值也並沒有多大的影響。
邏輯分服的架構對於大世界和滾服都是支援的，只是對於大世界的話，就浪費了乙個儲存空間和一點點記憶體。但是這樣的框架可以自如應對大世界到滾服之間的變化。如果一開始就按照大世界來設計，萬一某一天滾服了，就要麻煩地多。
所以邏輯分服並不會提公升多大的開發成本。
遊戲服務端為什麼需要登入服
注 這篇文章不僅會說登入服，還會說一些其它遊戲相關的事哦！我們都知道，很多遊戲在上線時，都會大肆宣傳，最近宣傳比較多的就是 激戰2 了。當然我不是 激戰2 的水軍 很多玩家都會提前坐在電腦前，等候遊戲官方給出的開服時間，搶點進入遊戲，因為這樣能佔據時間的紅利，可以在遊戲中占個好排名。當我們建立角色，...
遊戲服務端為什麼須要登入服
注 這篇文章不僅會說登入服。還會說一些其他遊戲相關的事哦！我們都知道。非常多遊戲在上線時，都會大肆宣傳，近期宣傳比較多的就是 激戰2 了。當然我不是 激戰2 的水軍 非常多玩家都會提前坐在電腦前，等候遊戲官方給出的開服時間，搶點進入遊戲，由於這樣能占領時間的紅利，能夠在遊戲中占個好排名。當我們建立角...
遊戲服務端邏輯模組處理框架
當遊戲服務端啟動時，服務端會根據配置檔案中的資訊，載入各個遊戲邏輯處理模組的動態鏈結庫，然後呼叫模組的 dllcreate 函式對模組進行初始化。配置檔案可以像下面這樣 modulecount 30 module1 battlesys module2 equipsys module3 friends...