背景

工作室也經(jīng)歷過好幾個游戲了。服務(wù)端的架構(gòu)跟實際業(yè)務(wù)需求出現(xiàn)過不少的沖突。導(dǎo)致后來花了挺多時間去擦屁股的。以最近的一個游戲舉例，原本的世界觀設(shè)想是一個大服的世界觀。也就是只有一個服，撐下百萬用戶，數(shù)萬同時在線的設(shè)計。而后隨著業(yè)務(wù)變化和線上表現(xiàn)，原本大服的設(shè)計并不能滿足，最終變成了滾服玩法。由于大服變滾服，在原來的服務(wù)器架構(gòu)約束下，對于后續(xù)增加的跨服玩法和合服實現(xiàn)都帶來了比較大的麻煩和不少的工作量。
?

物理分服

原來的架構(gòu)是按照大服設(shè)計的，所以在數(shù)據(jù)庫上面的設(shè)計一個服對應(yīng)一個數(shù)據(jù)庫。假設(shè)我們滾了500個服，就需要建500個數(shù)據(jù)庫，部署500個游戲服。游戲賬號拍賣無論后續(xù)跨服、合服的業(yè)務(wù)擴展，還是運維的維護方面，都變得比較復(fù)雜和困難。特別是合服的需求上面，需要將兩個數(shù)據(jù)庫甚至多個數(shù)據(jù)庫合并成一個數(shù)據(jù)庫。在量上來的時候，這一切都變得無比繁瑣和復(fù)雜。開發(fā)人員也需要花費較多的人力和時間去寫相應(yīng)的工具。而且操作相對復(fù)雜，也比較容易出bug。而且后續(xù)新增的業(yè)務(wù)如果出現(xiàn)了持久化數(shù)據(jù)就需要增加相應(yīng)的合服處理。

邏輯分服

如果說我們一開始就已經(jīng)將數(shù)據(jù)庫合并了呢，是不是后續(xù)根本就不需要去合并數(shù)據(jù)庫了。所以如果在當(dāng)初框架設(shè)計的時候就已經(jīng)按照邏輯來分服的話，后續(xù)的事情處理起來就簡單多了。問過同行業(yè)的一些游戲架構(gòu)，他們也是這么處理的。

對于合服

因為數(shù)據(jù)其實還是在同一個庫里面，而且也是在同一個服務(wù)器里面。只要簡單處理，或者甚至不需要任何處理，就可以將兩個或多個服合并。只需要在后臺設(shè)置一下入口配置、可見配置就可以解決合服的問題了。

對于跨服

跨服原本的問題就是需要從不同庫讀取數(shù)據(jù)和與不同服進行交互。如果本身就不存在多服的問題，也不存在跨服的問題。

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

維護成本

相對于物理分服，邏輯分服可以極大地降低運維成本。數(shù)據(jù)庫數(shù)量級可以極大減少，服務(wù)器數(shù)量也可以減少。對于備份、更新等運維操作都相對變得簡單。甚至可以不依賴于運維工具，就可以簡單地維護機器了。一臺機器部署一個服(多個邏輯服)對比一臺機器部署多個游戲服(一個邏輯服)，需要初始化的內(nèi)存一般來說會變小(不排除不一樣的情況)，機器的資源占用一般來說會小很多。所以對物理機的利用效率可以提高很多。

用戶數(shù)量級的問題

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

開發(fā)成本

由于邏輯分服，的確是增加了一些內(nèi)容，譬如玩家所在的服務(wù)器ID。但是這個處理起來并沒有多大的難度，而且對key值也并沒有多大的影響。

邏輯分服的架構(gòu)對于大世界和滾服都是支持的，只是對于大世界的話，就浪費了一個存儲空間和一點點內(nèi)存。但是這樣的框架可以自如應(yīng)對大世界到滾服之間的變化。如果一開始就按照大世界來設(shè)計，萬一某一天滾服了，就要麻煩地多。

所以邏輯分服并不會提升多大的開發(fā)成本。

總結(jié)

以上是生活随笔為你收集整理的游戏服务端的逻辑分服与物理分服的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。