背景
工作室也經歷過好幾個游戲了。服務端的架構跟實際業務需求出現過不少的沖突。導致后來花了挺多時間去擦屁股的。以最近的一個游戲舉例，原本的世界觀設想是一個大服的世界觀。也就是只有一個服，撐下百萬用戶，數萬同時在線的設計。而后隨着業務變化和線上表現，原本大服的設計並不能滿足，最終變成了滾服玩法。由於大服變滾服，在原來的服務器架構約束下，對於后續增加的跨服玩法和合服實現都帶來了比較大的麻煩和不少的工作量。
物理分服
原來的架構是按照大服設計的，所以在數據庫上面的設計一個服對應一個數據庫。假設我們滾了500個服，就需要建500個數據庫，部署500個游戲服。無論后續跨服、合服的業務擴展，還是運維的維護方面，都變得比較復雜和困難。特別是合服的需求上面，需要將兩個數據庫甚至多個數據庫合並成一個數據庫。在量上來的時候，這一切都變得無比繁瑣和復雜。開發人員也需要花費較多的人力和時間去寫相應的工具。而且操作相對復雜，也比較容易出bug。而且后續新增的業務如果出現了持久化數據就需要增加相應的合服處理。
邏輯分服
如果說我們一開始就已經將數據庫合並了呢，是不是后續根本就不需要去合並數據庫了。所以如果在當初框架設計的時候就已經按照邏輯來分服的話，后續的事情處理起來就簡單多了。問過同行業的一些游戲架構，他們也是這么處理的。
對於合服
因為數據其實還是在同一個庫里面，而且也是在同一個服務器里面。只要簡單處理，或者甚至不需要任何處理，就可以將兩個或多個服合並。只需要在后台設置一下入口配置、可見配置就可以解決合服的問題了。
對於跨服
跨服原本的問題就是需要從不同庫讀取數據和與不同服進行交互。如果本身就不存在多服的問題，也不存在跨服的問題。
雖然邏輯分服可以比較完美解決合服的問題，但是對於跨服還是需要單獨處理。畢竟如果一個邏輯分服的服務器真的扛不住的時候，就會出現真的物理分服。對於跨服的需求來說，可能都是需要跨的。
維護成本
相對於物理分服，邏輯分服可以極大地降低運維成本。數據庫數量級可以極大減少，服務器數量也可以減少。對於備份、更新等運維操作都相對變得簡單。甚至可以不依賴於運維工具，就可以簡單地維護機器了。一台機器部署一個服(多個邏輯服)對比一台機器部署多個游戲服(一個邏輯服)，需要初始化的內存一般來說會變小(不排除不一樣的情況)，機器的資源占用一般來說會小很多。所以對物理機的利用效率可以提高很多。
用戶數量級的問題
邏輯分服必然會出現性能瓶頸，不可避免地出現了物理分服、分庫的情況。而對於合服來說，合服本身就是發生在用戶數量或者同時在線數量不足的情況下出現的。如果用戶數量過大，基本上不太可能出現合服的需求。如果前期量級大，已經物理分服了。后期量級小了，其實重新疊回去也不是什么大的問題。只需要跟運營溝通好了，還是可以使用邏輯分服的事情去解決合服的事情。當然如果運營需要真的在不同物理服上面進行合服，我也沒有想到比較好的辦法，只能又苦逼地去處理的樣子。
開發成本
由於邏輯分服，的確是增加了一些內容，譬如玩家所在的服務器ID。但是這個處理起來並沒有多大的難度，而且對key值也並沒有多大的影響。
邏輯分服的架構對於大世界和滾服都是支持的，只是對於大世界的話，就浪費了一個存儲空間和一點點內存。但是這樣的框架可以自如應對大世界到滾服之間的變化。如果一開始就按照大世界來設計，萬一某一天滾服了，就要麻煩地多。
所以邏輯分服並不會提升多大的開發成本。