手机游戏后台服务整体架构

综述

网络游戏发展了二十年，但是整体的后台架构基本上是比较稳定的。从职能上来分，主要分为周边系统和对局。游戏对局是整个游戏最重要的部分，是游戏体验的基石。网络游戏所有的周边系统都应该是为了这个对局服务的，为了让玩家拥有更好的游戏体验而存在的。有些团队，甚至会将周边系统外包出去，集中精力开发游戏对局。
网络游戏后台的周边系统，基本上是分为接入，数据处理和数据存储三个部分，周边系统会通过tcp和玩家保持连接。此外，对于最为重要的游戏对局，一般来说是会单独拉起一个进程来进行游戏，为了保证低延迟的游戏体验，这个对局服务会通过可靠udp来和玩家进行数据传输。一般来说，如下所示。

手机网络游戏的玩家一般的主要路径就是登陆账号，进入大厅，开启对局，对局结算等步骤。中间穿插着诸如访问商店，签到，领取邮件等步骤。
这个时候，对于后台而言，客户端通过接入层接入了游戏，双方建立了长连接。客户端通过该连接发送请求，接入层将该请求发送到数据处理层进行处理，数据处理层负责处理业务逻辑，同时将处理结果发送给数据存储层进行落地。当玩家发起了开始游戏的请求后，游戏后台会在后台进行匹配，在凑够了足够的开启对局的人数后，就会拉起游戏进程，并通过之前的长链接，将游戏进程的ip端口和其他必要信息发送给玩家。

接入层

接入层主要是指后台服务对外暴露的所有的出入口。比如说，所有游戏都会有的登录功能，游戏后台对游戏运营人员暴露的管理接口等等，以及接入外部系统（支付，关系链，游戏外的app等），都是接入层。
在接入层，主要的作用就是在玩家发起连接后，和玩家维护一个tcp的长连接。玩家的所有请求都可以通过这个长连接发送，同时游戏后台也可以通过对这个长连接是否存在来判断玩家是否掉线。
另外一方面，为了网络游戏的持续运营，游戏侧也需要提供大量的运营工具给到运营人员，一般来说，这部分工具对外暴露的被调接口，也可以算作是接入层。

分区分服

一般来说，接入层的另一个重要的工作就是分区分服。分区分服对游戏来说是件很寻常的事情，早年的游戏分区分服的原因大多是因为性能原因，机器性能扛不住，只能进行分区分服。随着现在架构和机器性能的改善，模块的拆分，现在的游戏，分区分服的原因基本都不是计算机技术的原因，更多是和渠道，游戏内的经济体系，苹果安卓的限制等因素相关。
目前游戏主要有两种方式进行分区分服。
最干脆的方法就是直接进行物理隔离，不同的服就是在不同的服务器组，拥有不同的数据存储。这种方式最大的好处是，游戏后台在逻辑处理上基本不需要做任何处理就能进行分区分服。不太方便的地方就在于隔离了之后，跨服的匹配和对战是很不方便的，另外在游戏运营的后期，对游戏进行合服也比较复杂。
另外的做法就是在逻辑上进行分区分服，不同的玩家在实际上接入的是同一个服务器，分区分服只是逻辑上的不通。这种逻辑上的分区分服可以有很多实现方式，比如说，在玩家建号的时候，在该玩家的uin中，设定其中的2到3位为区服标识位即可。在游戏的逻辑层，让同一标识位的玩家相互可见，不同标识位的玩家不可见即可。这是目前比较常用的分区分服的手段，游戏在实质上依旧是个全区全服的游戏，只不过在部分地方（排行榜，经济系统，好友等）对用户进行了隔离。

数据处理

玩家在登陆游戏后，需要进行一系列的操作。在接入层通过proxy转发或者直接将对应的请求转发到不同的业务模块上。业务模块对复杂的业务逻辑进行处理。
一般来说，对于玩家的请求，除了类似拉取商店，公告等请求，都需要经过拉取玩家数据库，处理数据，保存数据，回包等动作。
在数据处理层，除了关注玩家的请求是否被正确处理外，最为重要的就是关注日志了。

玩家请求异常失败的处理

正确处理玩家请求是需要各个业务模块自行保证的，但在一个涉及到多个模块的玩家请求最终失败的时候，如何正确的处理这个请求是一个难点。在游戏中，一般来说不会去将玩家的请求作为一个事务来进行处理。举一个例子，玩家请求领取一封有附件的邮件，这个时候，在后台的周边系统中，至少会涉及到邮件和仓库两张表，有时候如果玩家领取来高级物品，可能还需要去账号模块请求增加积分等等。在这个过程中，如果有一个动作失败了，比如仓库模块成功保存物品了，但是邮件的已读状态更新失败了，将该玩家的请求进行回滚会是一件非常复杂的事情。该如何正确的处理这个情况是一个问题。（目前在做的游戏是，游戏侧不做处理，记录好日志，如果有较大影响了，手动进行处理。）

日志

游戏内的日志是非常关键的。日志分为两种，一种是程序自身打出的日志，另一种是用户行为日志。程序自身的日志可以用来辅助开发进行调试或其他作用。
程序内部的日志，一般来说是用于游戏开发阶段定位问题的。线上的程序，日志不宜打太具体，因为线上的日志太多，很容易就将日志冲掉。线上的周边模块，一般来说能保存近两天的debug日志就已经很不错了。
对于游戏来说，记录用户的关键行为的用户行为日志是至关重要的。玩家的关键行为记录可以用来进行用户行为分析，客服检验关键信息，补偿发放，防作弊行为等。

数据存储

负责处理网络游戏后台产生的所有信息。一般来说，主要有玩家数据和日志两个部分。玩家数据无需多言。一般都存储在游戏的数据库内。是用来保存玩家在游戏过程中产生的数据。比如说玩家的金币钻石，道具，好友，历史战绩等信息。
游戏内需要存储的日志主要是用户行为日志。这些日志一般来说会以文件的形式保存在本地。同时也会存储在独立于游戏的数据库中，由于后续的数据分析。

对局服务器

对于网络游戏中，对局服务是整个游戏最为关键的部分了，是网络游戏的立足之本。对于非MMO的游戏来说，游戏的对局服务是和整个游戏后台周边系统相对独立的。一般来说，周边系统只会在拉起对局时传递用户信息，结束对局时接收结算信息，除此以外不会和游戏对局进程有太过频繁的交互。
游戏对局一般来说，会维护一条和周边系统的连接（可以是可靠udp也可以是tcp），用来和周边系统进行必要的交互。同时会监听一个udp端口，该端口用来接收玩家发过来的各种信息。对局服务作为短期的一次性的进程存在的意义主要有三个。1. 对局服务的稳定性可以保证，一般来说，bug是会一直伴随着游戏存在的。容易出现的bug一般会在游戏的开发和测试阶段被暴露出来。而一些需要进程长时间存在才有可能爆率出来的问题（尤其是内存泄露问题）在上线前不好暴露。通过降低进程存在的时间，就可以降低这类bug出现的频率。同时也可以在出现bug的时候利用重启来临时解决 bug。2. 降低bug或崩溃带来的影响。如果说对局进程是一个统一的大进程，当对局服务奔溃的时候，整个进程上承载的游戏玩家都会受到影响。而保持小进程，则可以减少受影响的玩家。

游戏外的系统

对于网络游戏而言，一般来说都需要对管理人员开放运营管理接口，同时需要提供一定的监控能力。包括服务器容量的监控，玩家的行为追踪分析的能力等。对于一些大公司而言，还会提供很多公共组件来帮助不同的游戏运营等。

一般来说，游戏后台接入外部系统的方式有两种，暴露被调端口和游戏日志。如图所示。

游戏运营管理人员会通过调用接口来进行对游戏进行管理，运营人员通过日志来分析玩家行为，进而决定运营的策略。而一些有多款游戏的公司或者渠道商，可能会提供给游戏一些运营组件，比如腾讯的潘多拉，或者利用小程序等外部能力来丰富玩家等游戏外体验。这些组件，在游戏客户端以sdk的形式嵌入，在后台则有自己的服务器，与游戏后台通过管理接口和游戏日志进行交互。