手機遊戲伺服器架設教學

操作方法

• 01

  如今的手遊世界，如果沒搞個跨服賽事，都不好意思說它是一個手遊了。
  說到跨服，就不得不說下匹配服了。比如一個跨服天梯賽事，需要滿足不同服的玩家能夠同屏ＰＫ。為了能夠把實力接近的玩家作為對手，我們需要一個獨立的匹配服來收集資料，然後進行房間分配。匹配服，也是跨服賽設計的基礎。
  典型的匹配服通訊層我們可以採用http,也可以採用socket。本文將採用http作為遊戲服與匹配服的通訊層。選擇http方式，我們可以搭個tomcat服務，非常方便。當然，如果不使用tomcat的話，我們也可以使用mina或者netty本身的http服務。
  設計思路也非常簡單，有點像遊戲服的業務處理器。我們需要做到，對於不同的請求，我們都繫結一個方法與之對應。而對於資料的編解碼，由於匹配服的通訊資料一般都比較短，我們直接用json進行序列化即可。
  下面，開始我們的編碼。

  
• 02

  搭建mina的http服務
  在前面遊戲後臺設計中，我們已經看到如何使用mina搭建http服務了。

  
• 03

  訊息通訊
  在遊戲服，我們發出一條http請求。匹配服為了將請求分發到對應的處理器，我們需要為每一條訊息作一個標記。最簡單的，可以使用請求訊息的類名。所以，我們必須把業務簽名和引數都融合到url裡面去。也就是說，一個有效的url可能是這樣：
  http://localhost:8899?service=MReqLadderApplyMessage&param={"playerId":0,"score":0,"power":0}
  為了能區別遊戲服和匹配服的訊息型別，我們匹配服的訊息，都加一個M(Match)字首，那麼請求協定就MReq，響應協定就是MRes了。
  對於遊戲服來說，發出的請求屬於Message的子類，返回的訊息也是Message的子類。底層幫我們實現了訊息的編解碼。我們可以看下程式碼實現。
• 04

  業務處理器
  我們依然使用 @Controller註解來標識一個模組處理器，使用@RequestMapper註解來標記業務處理方法。不同的是，在遊戲服我們每個訊息的元資訊都帶有一個模組號和子型別號。在匹配服，我們就不這裡處理了。因為匹配服的業務比較少。我們直接用訊息類的名稱作為業務簽名即可。
  在業務分發器，我們儲存每一個方法簽名，與對應的方法處理器。

  
• 05

  匹配服在收到一個http請求，通過引數解析得到對應的業務簽名，同時通過json反序列化得到請求訊息的引數。將訊息分發到對應的業務處理器。程式碼如下：
  一個完整的業務處理器，程式碼如下　（可以看出，跟遊戲服是非常類似的）：
  範例程式碼
  啟動匹配服伺服器（MatchStartup.java）
  再執行遊戲服的單元測試

  
• End