1.如今的手遊世界，如果沒搞個跨服賽事，都不好意思說它是一個手遊了。
說到跨服，就不得不說下匹配服了。比如一個跨服天梯賽事，需要滿足不同服的玩家能夠同屏ＰＫ。為了能夠把實力接近的玩家作為對手，我們需要一個獨立的匹配服來收集資料，然後進行房間分配。匹配服，也是跨服賽設計的基礎。
典型的匹配服通訊層我們可以採用http,也可以採用socket。本文將採用http作為遊戲服與匹配服的通訊層。選擇http方式，我們可以搭個tomcat服務，非常方便。當然，如果不使用tomcat的話，我們也可以使用mina或者netty本身的http服務。
設計思路也非常簡單，有點像遊戲服的業務處理器。我們需要做到，對於不同的請求，我們都繫結一個方法與之對應。而對於資料的編解碼，由於匹配服的通訊資料一般都比較短，我們直接用json進行序列化即可。
下面，開始我們的編碼。
2.搭建mina的http服務
在前面遊戲後臺設計中，我們已經看到如何使用mina搭建http服務了。
3.訊息通訊
在遊戲服，我們發出一條http請求。匹配服為了將請求分發到對應的處理器，我們需要為每一條訊息作一個標記。最簡單的，可以使用請求訊息的類名。所以，我們必須把業務簽名和引數都融合到url裡面去。也就是說，一個有效的url可能是這樣：
http://localhost:8899?service=MReqLadderApplyMessage¶m={"playerId":0,"score":0,"power":0}
為了能區別遊戲服和匹配服的訊息型別，我們匹配服的訊息，都加一個M(Match)前
4.業務處理器
我們依然使用 @Controller註解來標識一個模組處理器，使用@RequestMapper註解來標記業務處理方法。不同的是，在遊戲服我們每個訊息的元資訊都帶有一個模組號和子型別號。在匹配服，我們就不這裡處理了。因為匹配服的業務比較少。我們直接用訊息類的名稱作為業務簽名即可。
在業務分發器，我們儲存每一個方法簽名，與對應的方法處理器。
5.匹配服在收到一個http請求，透過引數解析得到對應的業務簽名，同時透過json反序列化得到請求訊息的引數。將訊息分發到對應的業務處理器。程式碼如下： 一個完整的業務處理器，程式碼如下 （可以看出，跟遊戲服是非常類似的）：示例程式碼
啟動匹配服伺服器（MatchStartup.java）
再執行遊戲服的單元測試
1.如今的手遊世界，如果沒搞個跨服賽事，都不好意思說它是一個手遊了。
說到跨服，就不得不說下匹配服了。比如一個跨服天梯賽事，需要滿足不同服的玩家能夠同屏ＰＫ。為了能夠把實力接近的玩家作為對手，我們需要一個獨立的匹配服來收集資料，然後進行房間分配。匹配服，也是跨服賽設計的基礎。
典型的匹配服通訊層我們可以採用http,也可以採用socket。本文將採用http作為遊戲服與匹配服的通訊層。選擇http方式，我們可以搭個tomcat服務，非常方便。當然，如果不使用tomcat的話，我們也可以使用mina或者netty本身的http服務。
設計思路也非常簡單，有點像遊戲服的業務處理器。我們需要做到，對於不同的請求，我們都繫結一個方法與之對應。而對於資料的編解碼，由於匹配服的通訊資料一般都比較短，我們直接用json進行序列化即可。
下面，開始我們的編碼。
2.搭建mina的http服務
在前面遊戲後臺設計中，我們已經看到如何使用mina搭建http服務了。
3.訊息通訊
在遊戲服，我們發出一條http請求。匹配服為了將請求分發到對應的處理器，我們需要為每一條訊息作一個標記。最簡單的，可以使用請求訊息的類名。所以，我們必須把業務簽名和引數都融合到url裡面去。也就是說，一個有效的url可能是這樣：
http://localhost:8899?service=MReqLadderApplyMessage¶m={"playerId":0,"score":0,"power":0}
為了能區別遊戲服和匹配服的訊息型別，我們匹配服的訊息，都加一個M(Match)前
4.業務處理器
我們依然使用 @Controller註解來標識一個模組處理器，使用@RequestMapper註解來標記業務處理方法。不同的是，在遊戲服我們每個訊息的元資訊都帶有一個模組號和子型別號。在匹配服，我們就不這裡處理了。因為匹配服的業務比較少。我們直接用訊息類的名稱作為業務簽名即可。
在業務分發器，我們儲存每一個方法簽名，與對應的方法處理器。
5.匹配服在收到一個http請求，透過引數解析得到對應的業務簽名，同時透過json反序列化得到請求訊息的引數。將訊息分發到對應的業務處理器。程式碼如下： 一個完整的業務處理器，程式碼如下 （可以看出，跟遊戲服是非常類似的）：示例程式碼
啟動匹配服伺服器（MatchStartup.java）
再執行遊戲服的單元測試