游戏平台架构与日常管理

By 翟羽佳@巨人网络

概述

多年来，一直工作在游戏公司的平台部门，日常工作主要包括平台各种系统的设计、开发、运营、维护，本文主要描述就是这些年来在系统架构设计和日常运营维护工作中所遇到的各式问题及其解决方案的心得体会。 首先需要说明的是这里所说的平台系统，更多是从技术层面来说，比如包括游戏登录所需要的账号系统，计费系统，数据系统等多个系统的统称，而非类似360、小米等面对导入用户流量的所谓游戏平台。

系统架构

分布式

对游戏平台的日常维护来说，系统地负载有个显著特点，在某个时间点，比如游戏推广节点或者游戏内活动的时候，会有突然高并发的访问压力，可能是日常并发的10倍以上，所以对这样的的访问，需要通过分布式系统的方案予以解决，我们这里所说的分布式，主要包括从数据层、逻辑层、机房三个部分组成。

数据层

数据层包括数据库（eg.mysql,mango），缓存（eg.redis,memcache）等不同业务数据从定义到存储的方案，都需要支持分布式，以尽可能避免数据库的访问压力、数据的存储压力。

比如从基础数据层面，用户的登录访问都需要通过账号进行提交，所以我们在数据库层面使用账号作为hash的值，将用户数据库拆分成多个数据库及数据表，并且可以根据服务的压力调整某一数据库内的所包含数据表的数量，达到进一步hash数据的目的；另外根据用户的行为分析，大多数并发的访问都是对数据库或者缓存的读操作，所以将数据库的读写分离，并发访问高的业务增加缓存层或者数据库从库。如果发生大量的写操作压力，则可以根据业务的设计，设法使用队列异步写入的方式，以避免发生系统崩溃的灾难。

逻辑层

出于对系统负载、数据库访问管理等多方面的考虑，我们将所有对用户基础数据的访问、包括查询、更新等操作，都通过一整套统一的中间件服务进行控制管理，其针对不同使用者的需要提供了HTTP和TCP长连接的接口，并在其中加入了访问控制，权限管理等多个模块。

在实际使用中，大多数的核心业务都是通过负载均衡设备（NetScale）将逻辑层所提供的各项服务对外供用户使用，同时通过不同策略允许对应的用户进行访问并进行日常管理维护。

机房

将业务同时分布在不同机房，既是灾备的一种需要，同时也是将业务进行分布式部署进一步提高系统负载的能力的需要，特别是考虑到非BGP带宽的游戏，我们还是期望用户能够尽可能地访问他们所在地附近相应运营商的机房。当然根据目前的趋势来看，将来还是会逐步过渡到全BGP带宽的时代。

当业务分布在不同机房的时候，就会出现数据跨机房同步的问题，关于这点，我们是从几个方面考虑的，一是我们用户的基础数据更新的频率不高，而且即使更新的话，数据本身也不是很大，所以用户基础数据通过数据库主从同步在不同机房间进行同步，二、对于可以分布式保存的数据，比如用户充值生成的订单数据，我们会保存在不同的机房，在需要查询的时候，会根据不同机房所生成的不同订单号去访问相对应机房数据源。

冗余

游戏公司的系统，主要分成两大部分，一是游戏系统，包括手游端游，各个游戏各自独立，没有任何关联性，另一部分是支撑系统，包括平台系统，数据系统等，特别平台系统与所有游戏系统紧密相关，当平台系统宕机的时候，会造成所有游戏业务无法正常使用，所以必须保证平台业务具有极高的系统可用性。

所以在平台系统架构之初，就需要考虑到在极端情况下，也要保证平台系统能够对外持续提供服务的能力。 至于说冗余和灾备需要做到哪个地步，这个我觉得更多是从业务实际需要和成本等各方面综合考虑平衡的结果。

冗余

冗余既包括系统层面的冗余也包括数据层面的冗余。

对于我们来说，系统层面的冗余主要包括在多个机房都能够提供为所有业务提供服务能力，当除用户主数据库机房之外的某一机房离线时，我们需要通过如下手段将用户访问迅速切换到能够正常对外提供服务的机房去。

• 切换DNS
• 将出问题的机房IP从对外提供服务的列表中清除

如果当主库机房整体离线时，则需要评估离线影响时间，当时间确认不长时，则不进行切换主库的操作，系统对外服务进行降级处理，比如系统只能进行读操作，所有新用户注册等对主库有更新的功能全部暂时停止服务；如果确认主库离线时间较长，则需要将主库从问题机房切换到其它机房。

系统可用性

系统可用性的基础需要对核心业务进行重要性区别，然后根据不同的重要性，制定相关的系统降级策略，以达到保证核心业务可用的这一根本目的。

对于这点，我们把相关的业务各个模块都进行了分析，制定了在某一特定条件下，可以对某一模块进行关闭，以保证核心功能的可用性。

比如登录，我们可以在某一个需要的时间段，将用户是否绑定密保、是否被封停、是否是异常登录等多个安全、控制模块进行关闭，以保证用户只需要使用账密就能够登录游戏。

或者当游戏服务器在无法连接平台服务器进行二次验证的时候，可以使用另外一套我们预先定义的本地的秘钥算法进行离线验证，以保证用户尽可能不受平台服务器发生问题的影响，可以正常进入游戏，同时也能保证最基本的账密安全。

再比如第三方支付的通知接口，不管是哪一家支付接口，都曾经发生过因为网络问题或者系统问题造成通知延迟等各种支付不到账的情况，出于这点，我们会在每隔一定时间将所有不成功的订单，与第三方支付的接口进行校对，根据结果来进行对应的补单，这样可以保证最长的订单不到账情况得以控制。

这里还需要指出的是对第三方提供的设备、接口，在相关系统进行系统设计时，首先需要确定的是，所有第三方服务都是不可信的，他们有可能在任何时候发生不可知问题，所以需要在系统内留下相关第三方接口或者可以配置开关，或者备份系统，总而言之，不能因为第三方接口的问题造成我们自己系统的异常，而无法处理。同时在监控系统中，针对第三方接口也需要加入专门的监控项，以方便及时发现问题，进行报警处理。

以上的各种系统可用性的操作条件很多都基于以下要说的监控方法以控制其能适时启用。

日常维护

监控

由于线上系统随着时间的推移，日益庞大，系统间的关联性也愈发复杂，有时候发布前的测试会发现不了部分隐藏较深的问题，所以我们觉得不管是运维人员的日常工作、故障处理，还是开发人员确认发布是否正确的基础就在于监控系统的完善与否。一般如果系统发生问题，等到有玩家通过客服渠道报告，然后客服确认，通知维护人员，再找到开发确认，这个一套流程下来，至少大半小时已经过去了，甚至更长，这样的情况是我们无法接受的，所以监控系统在这时候就显得更为重要。

目前我们日常使用的监控大致可以包括两部分，一是服务器、网络层面的基本监控，包括系统资源、网络流量、服务端口是否存在，系统服务是否正常等比较常规的监控内容；第二部分更为重要监控是面向提供应用服务功能是否正常的监控方案，主要包括：

用户行为监控

这部分主要是模拟一个正常用户进行某一特定操作，所需要访问的不同接口，其返回的结果值是否正确，时间是否合理来进行判断。

另外还会实时统计关键的用户操作，通过对使用频率，响应时间等关键指标的历史与当前数据的比较，比如同比某天，某周，某月时间段内的订单生成数、成功交易数，尝试登录量，成功登录数等等各项数据的差异，来发现系统是否正常对外提供服务，并及时发现问题。

增加这部分的监控还有个目的，为了覆盖某些可能未曾考虑到的底层监控盲点，因为用户的行为成功率是真正代表系统是否能够正常对外提供服务的关键点。当包括网络、服务器、代码更新等等会对系统造成影响的行为发生的时候，最终肯定会对用户的操作造成影响，在这时候我们期望通过各种监控的手段尽快发现问题的点，并予以解决。我们期望达到的目的是系统的任何变化都可以通过监控系统反映出来。

接口监控

直接调用特定接口，判断其真实返回值是否正常。

日志监控

日志监控则是将所有应用服务器打印的相关运行日志进行统一收集，然后进行统一的分析判断，甚至包括比如某一台机器在一个时间段里突然发生日志不更新了，或者突然有大量的错误信息，这些都需要进行报警处理。

监控服务器

当系统分布在多个机房的时候，需要考虑到监控服务器的灾备。我们目前的策略是会在两个不同机房布置两套完全相同监控功能的监控服务，这样可以保证相关的监控服务随时在线提供服务。

自动化

系统更新

当系统分布在不同服务器、不同机房以后，自然系统更新就需要通过自动化工具进行了，否则每次发布的工作将是一件令人头痛的事情，我们使用puppet将开发人员提交到SVN上的发布版本，自动更新到全部或者部分外网服务器，然后开发、运维人员通过对监控系统、日志等的变化，来确认更新是否成功，如果发现问题可以通过系统即时回滚上一可用的版本。

当然对核心功能的发布来说灰度更新也是必不可少的，因为游戏的特性，我们会针对某个玩家不多的游戏所连接的平台服务进行更新，待确认此次更新达到目的，才会将此版本更新到所有游戏；对于WEB系统来说，我们可以使用负载均衡设备将少量用户导入到灰度更新后的某台服务器上，进行测试运行。

日常维护

自动化日常维护的关键，基本上我们的期望是将能够通过脚本解决的问题，都通过脚本或者系统解决，尽可能减少人工参与的部分，当然这也是会有发生严重问题的风险，所以在某些关键操作的自动化运行中，加入部分人工确认的步骤也是保证安全的可行的办法之一。

故障处理

SOP

SOP是指标准作业程序，可以将日常维护的各种操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作。 我觉得SOP两部分作用，一是指导一线的维护人员，在发生日常事件的时候，可以通过SOP指导完成处理工作，以减少高级运维人员的工作量；另一部分我觉得是更重要的作用是，当系统发生灾难性的事件时候，能够对当前的处理人员稳定心理，操作上拾遗补缺有很好的帮助和指导作用。

特别是类似我们这种系统上线多年，系统的架构、功能也已迭代开发多次，而其间大部分开发人员、运维人员也都早已离职，而系统又很庞杂，对内对外有多个接口需要连接，大多数日常维护人员对系统的整体情况也不是非常了解的情况。

下面的表格是我们某个业务切换主库操作的SOP文档样例：

这里也要指出的是，由于我们的核心业务基本保持稳定，在多年的运营维护的经验上，所以我们才能够编写出较为可行的SOP操作手册，对于业务急剧变化的创业项目，想编写一份完善的SOP操作手册是较有难度的，但SOP手册对故障处理，灾难恢复的帮助，还是非常有价值的，所以有可能的话还是从最小颗粒度逐步建立为宜。

一旦开始建立SOP，那定期的更新维护是必不可少的，否则错误内容的SOP对相关的故障恢复造成的将是更大的灾难。

日常演练

有了SOP手册之后，就需要对相关的操作进行定时的演练，以保证操作手册的指导行为是可行和有效的，否则在正式使用的时候，会发生各种各样不可思议的问题，包括每个人对手册文字的理解都会有差异，所以我们基本上会每隔3个月安排对大多数业务进行逐一切换的演练操作。

展望

多年来公司业务的发展，从端游到页游再到现在的手游，不同类型的游戏，都对平台系统提出了各种各样的新要求；技术的发展，各种新名词，新技术也在日新月异的发展着，我们抱着不断学习的态度，拥抱新的需求，新的技术，不断前行。