[遊戲]服務端的邏輯分服與物理分服

背景

工做室也經歷過好幾個遊戲了。服務端的架構跟實際業務需求出現過很多的衝突。致使後來花了挺多時間去擦屁股的。以最近的一個遊戲舉例，本來的世界觀設想是一個大服的世界觀。也就是隻有一個服，撐下百萬用戶，數萬同時在線的設計。然後隨着業務變化和線上表現，本來大服的設計並不能知足，最終變成了滾服玩法。因爲大服變滾服，在原來的服務器架構約束下，對於後續增長的跨服玩法和合服實現都帶來了比較大的麻煩和很多的工做量。

物理分服

原來的架構是按照大服設計的，因此在數據庫上面的設計一個服對應一個數據庫。假設咱們滾了500個服，就須要建500個數據庫，部署500個遊戲服。不管後續跨服、合服的業務擴展，仍是運維的維護方面，都變得比較複雜和困難。特別是合服的需求上面，須要將兩個數據庫甚至多個數據庫合併成一個數據庫。在量上來的時候，這一切都變得無比繁瑣和複雜。開發人員也須要花費較多的人力和時間去寫相應的工具。並且操做相對複雜，也比較容易出bug。並且後續新增的業務若是出現了持久化數據就須要增長相應的合服處理。

邏輯分服

若是說咱們一開始就已經將數據庫合併了呢，是否是後續根本就不須要去合併數據庫了。因此若是在當初框架設計的時候就已經按照邏輯來分服的話，後續的事情處理起來就簡單多了。問過同行業的一些遊戲架構，他們也是這麼處理的。

對於合服

由於數據其實仍是在同一個庫裏面，並且也是在同一個服務器裏面。只要簡單處理，或者甚至不須要任何處理，就能夠將兩個或多個服合併。只須要在後臺設置一下入口配置、可見配置就能夠解決合服的問題了。

對於跨服

跨服本來的問題就是須要從不一樣庫讀取數據和與不一樣服進行交互。若是自己就不存在多服的問題，也不存在跨服的問題。

雖然邏輯分服能夠比較完美解決合服的問題，可是對於跨服仍是須要單獨處理。畢竟若是一個邏輯分服的服務器真的扛不住的時候，就會出現真的物理分服。對於跨服的需求來講，可能都是須要跨的。

維護成本

相對於物理分服，邏輯分服能夠極大地下降運維成本。數據庫數量級能夠極大減小，服務器數量也能夠減小。對於備份、更新等運維操做都相對變得簡單。甚至能夠不依賴於運維工具，就能夠簡單地維護機器了。一臺機器部署一個服(多個邏輯服)對比一臺機器部署多個遊戲服(一個邏輯服)，須要初始化的內存通常來講會變小(不排除不同的狀況)，機器的資源佔用通常來講會小不少。因此對物理機的利用效率能夠提升不少。

用戶數量級的問題

邏輯分服必然會出現性能瓶頸，不可避免地出現了物理分服、分庫的狀況。而對於合服來講，合服自己就是發生在用戶數量或者同時在線數量不足的狀況下出現的。若是用戶數量過大，基本上不太可能出現合服的需求。若是前期量級大，已經物理分服了。後期量級小了，其實從新疊回去也不是什麼大的問題。只須要跟運營溝通好了，仍是能夠使用邏輯分服的事情去解決合服的事情。固然若是運營須要真的在不一樣物理服上面進行合服，我也沒有想到比較好的辦法，只能又苦逼地去處理的樣子。

開發成本

因爲邏輯分服，的確是增長了一些內容，譬如玩家所在的服務器ID。可是這個處理起來並無多大的難度，並且對key值也並無多大的影響。

邏輯分服的架構對於大世界和滾服都是支持的，只是對於大世界的話，就浪費了一個存儲空間和一點點內存。可是這樣的框架能夠自如應對大世界到滾服之間的變化。若是一開始就按照大世界來設計，萬一某一天滾服了，就要麻煩地多。

因此邏輯分服並不會提高多大的開發成本。