手游和端游的区别-天天飞车与QQ飞车后台差异简介

天天飞车（以下简称天飞）后台是在QQ飞车（以下简称Q飞）后台基础上，为适应手游特点进行了相应调整所开发出来。本文将结合天飞和Q飞后台的实践，对全区全服的ACG在手游和端游后台的区别进行对比。

一、架构

天飞在总体架构上和Q飞保持一致，分为接入层、业务逻辑层、消息转发层和数据持久化层，两者的主要区别体现在接入层。

Q飞gamesvr在业务层分为各种不同的频道和游戏模式，客户端在登陆时通过dirsvr拉取gamesvr列表信息，并且根据玩家的选择从指定类型的gamesvr中选择一台进行登陆，因此需要感知到所有gamesvr的地址信息，并且每一台gamesvr都需要分配独立的tgw地址。天飞的gamesvr之间是等价的，客户端登陆时不需要指定具体的gamesvr进行连接，因此只需要提供少数几个统一的tgw地址，通过tgw的负载均衡策略进行分配。

导致两者选择不同方案的是业务层的因素，Q飞主要是PVP玩法，一局游戏里的玩家需要登陆同一台gamesvr，以便进行单局内数据同步等逻辑。天飞主要是单机玩法，没有单局内与其他玩家强同步的要求，因此没有指定服务器登陆的必要性。天飞后续将会开发类似Q飞的单局内试试交互pvp玩法，将在现有架构基础上，额外增加一批负责pvp单局逻辑的pvpsvr，客户端只在进行pvp单局时和对手同时连接到系统所分配的pvpsvr上，以实现单局同步等功能。

二、网络接入

网络是手游和端游后台区别最大的因素，移动网络的不稳定性对接入、架构以及业务逻辑设计都有影响。天飞和Q飞在gamesvr的接入上基本一致，由专门的接入进程负责客户端的连接管理和数据收发，再通过共享内存的方式与同机部署的gamesvr通信，主要区别体现在连接保持和弱网络处理上。

2.1、连接保持

在连接保持方案上，Q飞客户端一旦检测到网络连接断开时，会马上发起登陆请求以维持连接建立状态。天飞客户端在这种情况下不会立即恢复连接，只在客户端需要向服务器发送消息前，确保连接正确建立。我们称这种按需的长连接方式为“弱长连接”，其优点是即使网络连接被频繁中断，也能最大程度保证体验的流畅性，同时也为gamesvr在线灰度重启提供了技术基础。缺点是服务器不能完全感知客户端在线状态，由服务器主动下发的消息不可靠，只能做为非重要消息的告知方式，重要的逻辑都必须由客户端主动触发完成。

2.2、弱网络

在弱网络情况下，需要考虑客户端频繁掉线重连的成本以及数据同步性。Q飞在客户端请求登陆的回复中，会将用户数据下发，这种方案在弱网络频繁断线重连时会产生大量的流量开销。天飞将该流程分解为“登陆”和“数据拉取”两步操作：登陆操作只进行CS连接建立；数据拉取由客户端在适当的时机主动发起，一般在登陆进入主界面和单局游戏结束返回主界面等时机进行。

弱网络下数据同步问题主要出现在“服务器收到请求但客户端没收到回复”情况下，我们将请求分为“数据可恢复”和“数据不可恢复”两类。“数据可恢复请求”是指客户端没收到回复时，可以通过其他方式同步数据，对玩家不造成损失的操作。如在主界面购买道具、改装赛车等，即使后台处理后客户端没收到回复，玩家通过重新登陆等方式也可以正确获得购买的物品。“数据不可恢复请求”是指客户端没收到回复，玩家收益受损的请求，一般是由于请求上下文无法通过特殊操作恢复所导致。例如里玩家在游戏内使用紧急燃油，如果服务器回包没有到达客户端，玩家不能通过重新登陆或开局的方式恢复购收益。对于这些操作，客户端提供超时重试提示，请求中携带上下问信息，用于后台区分是否为重试请求，当后台收到和上一次同样上下文的请求时，会跳过部分消耗逻辑，将上一次的回复数据再次返回给玩家。这种机制的难点在于存在被作弊利用的可能，需要对请求的上下文和玩家相关收益做非常强的校验工作。

三、数据校验及反外挂

由于端游网络环境较好，Q飞在单局游戏内客户端和服务器之间的交互频繁，玩家的关键操作都能即时同步到服务器，关键的逻辑更是在服务器完成（如拾取使用道具、经过终点等），使得玩家在单局里的行为在服务器端的回放和校验相对容易。移动网络的高延迟和不可靠性，使得手游单局内玩法不能有太多的cs交互，否则网络交互延迟会影响体验流畅性，尤其对赛车题材的游戏，因此更多需要使用后校验的方式对玩家行为合法性进行校验。飞的后台反外挂体系分为几部分：玩法规则优化、后校验规则网和运营监控：

3.1、玩法规则优化

玩法规则优化是在玩法设计层面进行调整优化，将部分高风险规则进行调整或在规则层面加上增加约束（如数值天花板），使得系统玩法层面减少可被利用的漏洞或检验困难的规则。

3.2、后校验规则网

后检验规则网是后台反外挂的策略框架，我们对单局内的核心数据分别设计策略，这些策略需要客户端采集表现层面的数据，通过表现数据反推核心数据的合理性。单条策略本身会比较简单，但是策略使用的数据会尽量形成交叉校验的结构，从而用许多策略编织成相互校验的规则网。

3.3、运营监控

运营监控主要包括对反外挂策略踢人、误踢等统计，通过统计数据和论坛、客服以及外团的反馈，进行策略开关及阈值调整。

四、版本兼容

Q飞客户端使用强制更新的方式，因此不存在版本兼容的问题。天飞的版本兼容包括协议兼容和逻辑兼容两部分。

4.1、协议兼容

天飞使用TDR作为CS交互的协议格式，TDR本身提供了相对完善的协议兼容和裁减方案，但是也存在一些使用上的约束。天飞在TDR的使用上，总结了以下额外注意事项：

4.2、逻辑兼容

逻辑兼容主要指在相同触发条件（客户端请求或内部逻辑）下，需要对不同版本客户端进行不同的逻辑处理。天飞以特性的粒度进行管理，为每个特性配置最低支持的客户端版本号，在代码层面提供查询接口，以判断指定客户端版本号是否支持该特性，再进行逻辑分支。

举例说明，天飞的1.3.5.0版本开始，在玩家给好友赠送爱心的时候会一并赠送体力，由于赠送爱心的协议老版本也会请求，因此需要在处理逻辑里增加版本兼容逻辑。首先我们声明了一个特性EFID_SEND_ENERGY，并且通过配置说明1.3.5.0以上的客户端支持该特性。

在赠送爱心的代码里，通过调用玩家player对象的IsFeatureEnable接口判断该玩家的客户端版本是否支持该特性，从而进行赠送体力功能的开关。

五、平台接入

Q飞和天飞都接入了不少如帐号、支付各方面的第三方平台，下面重点介绍天飞的平台接入和相关注意事项。

5.1、统一抽象接口

天飞同时接入了微信和手Q两个平台，由于各平台的接口存在差异，建议在上层逻辑对业务接口需求进行抽象封装，便于适配不同的开平接口，同时也对业务国际化接入其他开放平台提供基础。

5.2、iOS注意事项

手机平台方面支持iOS和android。苹果对上架AppStore的应用要求与其他平台数据不互通，一般有物理分区和逻辑分区两种做法：物理分区就是将不同平台分为不同大区，管理方便，适合分区分服的游戏；逻辑分区是在逻辑层面对不同平台的数据分开存储以及使用，管理较为复杂，产品和开发都需要考虑到相关设计的影响，适合全区全服的游戏。

此外上架AppStore还需要提供8-14天的审核时间，由于提交审核的版本即为最终上架的版本，需要为该版本提供审核的环境，一般有以下两种方案：

a、直接使用现网后台环境

这种方案要求在提交苹果审核之前就要对现网后台环境进行更新，要求版本封版比上线提前一周到两周的时间，适合于版本开发周期较长的项目。

b、使用单独的后台环境

对于节奏更快的项目，可以单独搭建一套用于苹果审核的后台环境。对于提交审核的IOS客户端，需要提供登陆跳转方案，控制提审的客户端版本在上架前后，分别登陆审核环境和正式环境。

对于使用域名登陆服务器的，可以对提审的版本配置新的域名，对该域名在上架前后切换目标地址。

另外一种方案是在业务服务器提供重定向功能。提审的客户度版本直接往现网服务器发起登陆请求，服务器再告知其审核环境的地址，客户端自行进行跳转。这种方案需要自行开发跳转逻辑，并且要求登陆协议不能修改，才能保证老版本的服务器进程能够正确处理新版本客户端的登陆请求。