[遊戲]服務端的邏輯分服與實體分服

工作室也經曆過好幾個遊戲了。服務端的架構跟實際業務需求出現過不少的沖突。導緻後來花了挺多時間去擦屁股的。以最近的一個遊戲舉例，原本的世界觀設想是一個大服的世界觀。也就是隻有一個服，撐下百萬使用者，數萬同時線上的設計。而後随着業務變化和線上表現，原本大服的設計并不能滿足，最終變成了滾服玩法。由于大服變滾服，在原來的伺服器架構限制下，對于後續增加的跨服玩法和合服實作都帶來了比較大的麻煩和不少的工作量。

原來的架構是按照大服設計的，是以在資料庫上面的設計一個服對應一個資料庫。假設我們滾了500個服，就需要建500個資料庫，部署500個遊戲服。無論後續跨服、合服的業務擴充，還是運維的維護方面，都變得比較複雜和困難。特别是合服的需求上面，需要将兩個資料庫甚至多個資料庫合并成一個資料庫。在量上來的時候，這一切都變得無比繁瑣和複雜。開發人員也需要花費較多的人力和時間去寫相應的工具。而且操作相對複雜，也比較容易出bug。而且後續新增的業務如果出現了持久化資料就需要增加相應的合服處理。

如果說我們一開始就已經将資料庫合并了呢，是不是後續根本就不需要去合并資料庫了。是以如果在當初架構設計的時候就已經按照邏輯來分服的話，後續的事情處理起來就簡單多了。問過同行業的一些遊戲架構，他們也是這麼處理的。

因為資料其實還是在同一個庫裡面，而且也是在同一個伺服器裡面。隻要簡單處理，或者甚至不需要任何處理，就可以将兩個或多個服合并。隻需要在背景設定一下入口配置、可見配置就可以解決合服的問題了。

跨服原本的問題就是需要從不同庫讀取資料和與不同服進行互動。如果本身就不存在多服的問題，也不存在跨服的問題。

雖然邏輯分服可以比較完美解決合服的問題，但是對于跨服還是需要單獨處理。畢竟如果一個邏輯分服的伺服器真的扛不住的時候，就會出現真的實體分服。對于跨服的需求來說，可能都是需要跨的。

相對于實體分服，邏輯分服可以極大地降低運維成本。資料庫數量級可以極大減少，伺服器數量也可以減少。對于備份、更新等運維操作都相對變得簡單。甚至可以不依賴于運維工具，就可以簡單地維護機器了。一台機器部署一個服(多個邏輯服)對比一台機器部署多個遊戲服(一個邏輯服)，需要初始化的記憶體一般來說會變小(不排除不一樣的情況)，機器的資源占用一般來說會小很多。是以對實體機的利用效率可以提高很多。

邏輯分服必然會出現性能瓶頸，不可避免地出現了實體分服、分庫的情況。而對于合服來說，合服本身就是發生在使用者數量或者同時線上數量不足的情況下出現的。如果使用者數量過大，基本上不太可能出現合服的需求。如果前期量級大，已經實體分服了。後期量級小了，其實重新疊回去也不是什麼大的問題。隻需要跟營運溝通好了，還是可以使用邏輯分服的事情去解決合服的事情。當然如果營運需要真的在不同實體服上面進行合服，我也沒有想到比較好的辦法，隻能又苦逼地去處理的樣子。

由于邏輯分服，的确是增加了一些内容，譬如玩家所在的伺服器ID。但是這個處理起來并沒有多大的難度，而且對key值也并沒有多大的影響。

邏輯分服的架構對于大世界和滾服都是支援的，隻是對于大世界的話，就浪費了一個存儲空間和一點點記憶體。但是這樣的架構可以自如應對大世界到滾服之間的變化。如果一開始就按照大世界來設計，萬一某一天滾服了，就要麻煩地多。

是以邏輯分服并不會提升多大的開發成本。

本文轉自 Ron Ngai 部落格園部落格，原文連結：http://www.cnblogs.com/rond/p/5528522.html  ，如需轉載請自行聯系原作者