一款自己在公司做了一年的游戏两个月前已经上线了，目前处在一个稳步运营的状态中。

先简单说说我们做的什么游戏吧，这是一个回合制的MMORPG手机网络游戏，迫于各种压力，策划层面上有很多机制都是模仿的猪厂某西游设计的，作为一个技术开发人员，对此我也不好多做评价。如今，上线没两个月，内容的雷同又匮乏，导致跨服战这样的功能被提上了议程。

这次我们模仿的对象是某西游的剑会群雄这个跨服PK的功能，简单来说，就是有各个服务器上的玩家可以在一起，开房间，组队，和其他房间的队伍匹配打回合制的战斗，然后排行，奖励。

因为玩家来自各个不同的服务器，战斗逻辑又对各个玩家的数据（属性，装备，背包，宠物等等）有各种繁多的操作，所以，必须把一份跨服玩家数据的拷贝放在一个中介的跨服服务器中，以此让战斗逻辑计算处理在该服务器中进行。So，我的跨服功能将以下面这种方式最终部署（这里省去了为了部署服务器所需要的网关，代理，登录等服务器的部署情况）。

                           +------------------------+
                           |                        |
           +-------------> |      cross server      | <--------------+
           |               |                        |                |
           |               +------------------------+                |
           |                                                         |
           |                                                         |
+----------+------------+                               +------------+-----------+
|                       |                               |                        |
|     game server A     |                               |      game server B     |
|                       |                               |                        |
+-----------------------+                               +------------------------+

结构其实很简单，只是在跨服的连接接入上，却又几种机制供我们研究和选择。这里，我们统一以一个客户端玩家player1由游戏服务器A跨服战斗遇到游戏服务器B的客户端玩家player2为例子，探讨一下以下的几种接入方式的利弊：

1. 客户端player1和客户端player2各自准备好跨服战斗后，服务器将他们的战斗必须的数据拷贝到cross server，然后cross server处理回合制战斗中各种技能施法、物品消耗等。在这个过程中，客户端依旧保持连接到各自原来的game server上，但所有的战斗交互操作都会转发到cross server上，cross server上处理完，在广播到战斗中的各个单位去。

   这种方案的优势是跨服操作对于客户端而言完全透明，客户端基本不需要改原来逻辑，直接按照以前的功能做就可以了，服务端改动也还行，只是，跨服动作变成一种完全为了配合这次策划需求的跨服战斗的定制设计，如果以后扩展跨服玩法，比如跨服副本或其他一些，不同玩家跨服在同一场景里打怪，那就又是一通乱改。

2. 客户端player1和客户端player2各自准备好跨服战斗后，他们各自所在的game server把数据同步到cross server后发送跨服玩法对应的服务器ip和port，然后客户端在保持原本服务器的tcp连接的同时直接发起到跨服的tcp连接。客户端同时维护两条不同服务器的连接，跨服战斗处理在cross server上处理，处理完直接返回客户端结果。

   这种方案好处是针对不同的玩法，跨服可以部署到不同的服务器上，以后的跨服玩法扩展会比较方便简单，而且服务器基本逻辑不需要改动，但是客户端维护两个socket的连接，且要对不同socket的消息区分处理，客户端的框架改造是一个不小的工程。

3. 客户端player1和客户端player2各自准备好跨服战斗后，他们各自所在的game server把数据同步到cross server后发送跨服玩法对应的服务器ip和port以及登录到新服务器的临时身份token或session，客户端直接切断当前game server服务器的连接，然后带着身份验证方式连上对应ip：port的cross server执行一遍登录，进入该玩法。

   这种方案是之前两种方案的一种折中的处理方式，优势就是跨服操作简单，就是重新登录一次，对应的战斗逻辑也是在cross server上单独处理完立即广播给战斗单位，无需转发，而且客户端也不用为了维护两条连接而对之前的框架进行大手术，今后的扩展较好。唯一麻烦的是玩家数据的同步之后，以及数据的回写操作，需要逻辑上的完美保证，如果需要写回原服的数据较少，那还好，可以通过消息针对不同数据修改，但如果，改变较大，需要某个甚至几个表中某一玩家的整个数据回写覆盖到原游戏服务器，就必须保证原服的后来的数据不能覆盖掉要回写的数据，比较常见的情况是玩家跨服断线，重新登陆到原服务器，然后跨服同步，后来的数据覆盖的原来有的数据，导致跨服收益或消耗的数据丢失。不过，毕竟不是一日之功，相信该方案通过不断的测试完善，这些都是可以避免的。

经过和组内的同学们交流讨论以上几种方案，最后我们决定使用第三种折中的方案按实施策划的本次需求，主要还是该方案对于服务器和客户端而言在开发上都有一定优势，而且扩展性良好。

最后回到策划现在的逻辑需求里，我们决定在中央跨服中进行必要的匹配和战斗逻辑，在开房间匹配过程中，客户端依旧保持原来服务器的连接，匹配完成后确定开始战斗，各个服务器开始向主跨服服务器同步数据准备战斗开始，数据同步全部同步成功后通知客户端重新连接到新的服务器处理战斗。

---

版权声明:

本文由greedcoder创作、发表并维护,

采用自由分享-保留署名-非商用-禁止演绎4.0(CC BY-NC-ND 4.0)国际许可协议进行许可.

版权有一点，侵权不一定究！

本文永久链接：https://greedcoder.github.io/2016/08/26/server-cross-structure/