高效能MMORPG泛型服務端引擎設計之->基本概念篇二

 

書接上回<高效能MMORPG泛型服務端引擎設計之->基本概念篇>

 

上回說道我們將伺服器組的職責劃分為了，前端伺服器，情境伺服器，登入伺服器，資料服務器...etc.

Logic-Service   Logic-Service    DB-Service

           |                     |                     |

           -----------------------------------

                                 |

                        Scene Manager

                                 |

               ------------------------------------- 

              |                       |                      |

          Front Server   Front Server     Login Server

              |                      |

             Client             Client        

不過經過思考後發現這個結構有點問題。

問題何在呢？我們來好好分析一下遊戲的邏輯後會發現，整個MMORPG的服務端邏輯，其實是對服務端事件的響應，這裡有兩種事件，一種是對自身屬性的改變（比如切換技能，向腰帶放入藥瓶之類的），一種是改變其他玩家屬性，或者是需要通知其他玩家知道的自身屬性改變（比如，攻擊對方，自己回血，換裝，移動等），也就是前文中我們分析發生在情境中的事件，第二種事件遠遠超過第一種事件，而且大部分的商務邏輯也發生在這些事件中，所以這類事件的處理需要消耗更多的CPU。這樣就帶來問題了，前端伺服器的壓力主要在IO，而情境伺服器的壓力主要在CPU，那麼如果分開在不同的機器上部署，那麼這兩邊伺服器的壓力就不均衡了，前端伺服器的CPU剩餘很多，情境伺服器的CPU又不夠用。所以我決定將這兩個部分再次合并起來，合成Logic服務，然後多個Logic服務並行運行。

所有的遊戲邏輯都在邏輯服務中運算，但是按照MMORPG的業務，所有的邏輯基本都是按照情境來分布的，所以這個時候我門又面臨2難的選擇題了。第一種方案是，我們可以按照情境來組織邏輯，比如伺服器A負責1，3，5，7情境，伺服器B負責2，4，6情境，因為情境之間的人數不平均，有的情境人多（比如某某城內，正在被大批人追殺的BOSS所在地），有的情境人少（比如運行一段時間後的新手村），而且遊戲中的熱點情境是動態變化的，隨著遊戲進程的發展會有變化。所以這個情況下我們需要一個情境管理服務，這個服務用於監控每個邏輯服務，將熱點情境所在的服務裡的其他情境遷移到空閑邏輯伺服器。這個邏輯需要用戶端提供支援，要實現伺服器的軟切換。還有一種方式是將情境的邏輯隨機分布到所有邏輯伺服器上，情境間的聯絡通過訊息來傳遞，由一個Message Service器來為所有情境提供廣播組來分發訊息。這樣就會多個Message Service器出來。這兩個方案中第一個對單個玩家來說延遲最小，但是如果情境管理做得不好就會造成CPU資源分布不均勻，還有就是情境容量受到單個進程處理能力極限的局限。第二種方案延遲肯定大過第一種，但是情境的容量不受單個進程計算能力的影響，擴充性更好一點。

 

最後我決定用Python來實現這個想法，一，有豐富的基礎架構可以選擇，比如用高效能的Gevnet或者Eruasia來作為TCP Server的基礎。二是Python本來就是動態，所以不需要再嵌入另一個動態語言來適應多變的商務邏輯了。其三是Python是動態類型的，在實現Message Service的時候更方便。本來打算用erlang的，不過暫時對OTP還不是很熟悉所以暫時作罷，不過如果採用第二種方式的話我可能會用Erlang來實現Message Service器。

 

下一章直接進入實現階段，並且無論如何我都會把這個玩意兒弄出來，如果沒有公司願意花錢讓我弄，我就業餘時間自己弄出來開源，哼哼