构建网络游戏运营支撑系统

构建网络游戏运营支撑系统

一、 前言

近几年，网络游戏产业发展迅猛。据资料显示，2009年在中国大陆地区新上线的大型网络游戏超过200款，拥有网游企业近750家，而市场规模将达到260亿。

 

目前网络游戏界的常见的运营模式，是“游戏开发商”+“游戏代理运营商”模式。双方之间一旦确定了合作关系，应该是一个密不可分的整体，但是如何划分彼此之间的权利和义务？ 暂且以“产品”为界限，这个“产品”，就是网络游戏本身——是一个独立的软件系统，提供了一个公众娱乐的虚拟世界的载体，很少包含运营相关的内容。而后者，一般由运营商自己来建设。

 

可以说，每一款网络游戏的背后，都有一套运营系统在支撑。所谓“麻雀虽小，五脏俱全”，即使是运营最小规模的网络游戏，也需要建设一套完整的运营支撑系统。

二、 网络游戏运营的特点

网络游戏运营具有以下特点：

节奏快  运营策略经常会随着根据市场现状和竞争对手的情况进行调整；

投资大  购买游戏版权、部署服务器和宣传推广都将投资巨大；

风险高  难以确定某一款游戏内容和形式是否会满足市场需要；

杂事多  网络游戏是一个对公众提供服务的系统工程，需要做大量事无巨细的工作；

周期紧  以上市公司和风险投资为主体的组织机构，都希望在最短时间看到投资收益；

 

三、 运营支撑系统的组成

运营支撑系统主要包括以下功能:

▲ 通行证注册(Registration)

▲ 用户认证与授权(Authentication & Authorization)

▲ 游戏计费(Billing)

▲ GM（Game Master,游戏客服）管理

▲ 游戏公告、新闻发布

▲ 营收状态跟踪与数据挖掘

▲ 反外挂、防黑客攻击

▲ 防沉迷

▲ 客户端打包、下载与更新

▲ 网络与服务器监控

▲ 游戏点卡销售与用户充值

▲ 第三方支付平台接口以及对帐

▲ 数据统计、查询、排序及报表

▲ 在线广告效果追踪

▲ 其他一些支持系统

 

这些功能并不是孤立存在的，而是根据需求划分归纳在一个、或多个子系统或者模块之中。典型的包括：

▲ 游戏官方网站

▲ 游戏充值平台

▲ 游戏认证与计费服务器

▲ GM客服管理工具

▲ 经营分析系统

▲ … …

根据游戏的规模，运营商可以裁减或增加一些系统模块，来满足运营的需要。

 

四、 网络游戏服务器结构简介

 

一般来说，网络游戏服务器(Game Server)主流的运行平台为Windows 和 Linux 。一般配置为低端的PC服务器，主要以“组”为单位（行业术语叫“游戏大区”），一组游戏服务器（一个“大区”）大概是几台到十几台的规模不等，大部分分布于全国各地的IDC机房。这样做的主要目的是：一是基于成本的考虑——二三级城市的带宽和服务器成本要远远低于北京、上海等大城市；二是提高游戏的流畅度——用户可以选择离自己距离更近，带宽情况更好的游戏服务器组进行游戏。

 

每个游戏服务器组（游戏大区）的组成，根据游戏类型的不同而有所差异，比较常见的有：

▲登陆服务器

▲游戏逻辑服务器

▲游戏数据库服务器

▲物理服务器

▲聊天服务器

*为了满足某些特定需要，还会一些功能独特的服务器。

这些服务器往往都位于同一个局域网内部，彼此之间进行内部通信，形成一个功能相对独立的游戏世界。游戏服务器与桌面客户端之间的通信，大部分采用TCP协议，也有一些动作竞技类休闲游戏，采用UDP协议来减少网络延时和增大有效负载。每个游戏用户的带宽从几Kb/s到几十Kb/s不等。

 

各个游戏大区通过互联网与“中心节点”的运营支撑系统通信，形成星型的拓扑结构，如图1所示：

 

图1  简单的拓扑结构

 

在通信的过程中，各种数据将从各个游戏大区采集上来，以MMORPG类游戏为例：

1． 游戏角色的昵称、等级、经验、生命力值等属性信息

2． 游戏角色在使用道具、装备，宠物等过程信息

3． 游戏角色购买道具、装备时的消费纪录

4． 游戏角色获赠礼物或奖励信息

5． 进出游戏的纪录

6． 比赛或PK的结果数据

* 还有一些信息可以更详细地收集，这取决于运营商对于游戏的管理粒度。

 

运营支撑系统在获取到这些数据和消息以后，其中一部分需要进行实时响应（例如用户登陆请求），有些暂时存放至数据库，稍后进行批量作业处理。

 

五、 运营支撑系统的架构

在设计运营支撑系统之前，需要制定完整的运营计划，比如：游戏何时上线运营？游戏是按时间收费还是按道具收费？是否考虑实施包月制？是否发行自己的游戏点卡并建立销售渠道？游戏虚拟道具的价格和汇率(和RMB之间)是否固定？使用该系统的各部门关系、工作流程是否已经明确？这些都最终与运营支撑系统紧密关联。只有计划已经基本确定，才能有条不紊地进行持续开发。否则，不断的需求变动容易导致系统不稳定，最终导致整个运营过程杂乱无章。

 

运营支撑系统是一个持续运行，不断变化的软件系统，从开始运营，直到游戏停止服务，一直需要保持稳定地持续运行。因此，运营支撑系统需要具备以下技术特点：

高可用性 —— 不间断的持续运行。

通信效率 —— 对消息进行毫秒级响应（或处理）；

安全可靠 —— 防止黑客窃听、盗取和未经授权的内部访问；

数据准确 —— 防止数据丢失、遗漏、错误

容量大   —— 一款流行的网络游戏的注册人数可能达到“1000万”级别，每天产生若干Giga Bytes的日志文件和数据。

高并发   —— 一个游戏大区分组可达到上万人同时在线，所有大区加起来可以达到数十万乃至上百万的规模，这些大量用户的数据和消息在游戏过程中会产生大量数据和消息，最终都需要通过运营支撑系统进行处理；

可恢复性 —— 一旦出现意外情况甚至灾难，需要在最短时间恢复用户数据，继续提供服务；

可扩展性 —— 无论是规模扩展还是功能改变，可以平滑升级；

 

运营支撑系统可以采用集中式的星型拓扑结构（近来，也有一些运营商采用了少量的分布式技术，但从总体上来说还是属于集中式架构）。采用集中式结构，可以显著降低运营的复杂程度和成本——为了数据安全考虑，运营商需要采购高端的存储设备、服务器和网络设备、灾备系统；而采用集中式的结构，只需要在一个“中心”结点上投资和部署这些设备即可。

 

运营支撑系统通常围绕核心数据库来建设，一般采用大型商业数据库，例如MS SQL Server 、Oracle 、DB2等，除了功能比较完善以外，还能获得厂商的技术服务和支持。

 

应用程序架构包含有B/S(Browser Server)三层架构，或C/S(Client Server)两层架构，或两者兼而有之。采用B/S架构，可以根据自身特长，利用业界成熟的解决方案，例如.Net 、J2EE等。而采用C/S架构，往往需要从底层开发一些服务器端/客户端应用程序，从而对开发团队提出了更高的要求。

 

图2是一款MMORPG游戏的运营支撑系统的示意图：

 

图2 一款MMORPG游戏的运营支撑系统示意图

Web服务器——游戏的官方网站，用多台服务器并行，以实现负载均衡。

数据库实例——用于实现数据库集群或双机热备的服务节点。

运营网关服务器——负责与各个游戏大区的服务器进行通信，内容包括用户登录认证、购买道具、获取奖励等与游戏过程直接相关的信息。一般用服务器守护(daemon)进程实现。

 

一般来说，运营商可能对以下数据比较关心：

▲ 注册会员数和活跃会员数

▲ 同时在线人数/时间曲线

▲ 最低、最高同时在线数

▲ 用户的地域分布

▲ 用户流失率和平均在线时间

▲ 投放网络广告媒体的效果

▲ 每天/每月的道具销售情况

▲ 用户投诉焦点

▲ 用户在游戏中的级别分布

▲ 服务器的状态和网络流量

 

在系统设计的时候，需要注意角色(Role)和权限(Privilege)划分。不同角色，拥有的权限不尽相同，不论在应用程序部分，还是在数据库内部，都要做严格区分。同时，还需要考虑到角色进入系统进行操作的审计日志，防微杜渐。

 

网络游戏是一个产品，但运营网络游戏却是一项服务。在整个服务周期中，运营支撑系统所具有的功能会随着市场和经营策略进行调整。如何能快速地随需而动？对运营支撑系统的可扩展性是一项挑战。 以下是推荐的几点：

1． 在设计应用程序的底层模块时，尽量保持其无状态(Stateless)。无状态的应用程序在规模扩展时，其复杂程度要低于有状态(Stateful)应用程序。

2． 运营支撑系统的业务逻辑可以封装在应用程序里，也可封装在数据库里，封装在后者的业务逻辑以存储过程(Storage Procedure)或触发器的形式体现。在运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。由于执行SQL语句的大部分工作已经完成，所以存储过程能以极快的速度执行。同时由于存储过程和应用程序之间在多数情况下仅仅只是接口的参数传递，而不是完整的SQL逻辑，可以大大降低网络的通信量。当业务逻辑发生变化时在数据库服务器中改变存储过程即可，无须修改任何应用程序，从而极大提高应变能力。

3． 充分利用数据库提供的视图(view)功能。视图是底层数据的抽象，可以理解为“数据的脚本”。可以根据需要，随时修改脚本规则，而对应用程序透明。

4． 把经常变动的环境变量或者业务逻辑，单独放在XML配置文件，甚至脚本语言里执行，比如LUA ,Python，把应用程序的框架部分，用C++或者Java实现。这样，在变动发生的时候，不需要重新编译应用程序，修改以后就能立刻执行。

 

六、 开发过程

基本上很难找到一套成熟的、或类似的软件，不加修改就可以直接使用。即使这样，运营支撑系统的开发仍然与一般的软件开发方法基本相同，可选的方法很多，比如敏捷开发过程(Agile software development), 不再赘述。

 

七、 性能和安全优化

运营支撑系统以大量的数据库事务处理为主，辅以少量的逻辑计算(应该不算CPU Bound型)，需要对以下几点进行性能优化：

1． 网站优化

游戏网站是网络游戏对外提供服务的窗口，在运营商持续的广告投放之后，大量的随机访问伴随就开始蜂拥而入。在游戏成长过程中的几个关键阶段，开放式内测、公测，加上一些潜在的DDOS攻击，Web必然要经历大规模网络流量的考验。

可以考虑部署基于硬件的负载均衡器，安装在服务器和外部网络间，性能得到大幅提高，加上多样化的负载均衡策略，智能化的流量管理，从而达到最佳的负载均衡效果。

*值得一提的是，Linux 内核 2.6 以后集成了LVS集群技术，它采用IP负载均衡技术和基于内容请求分发技术。该技术已经在一些项目上得到成功运用。

 

Cache——在Web逻辑层和数据库存储(Storage)之间，构建Cache策略，有效减轻数据库负载。

 

2． 网络I/O优化

在自下而上构架应用服务器的时候，进程间通信通常会用到socket。如何建立服务器软件模型和处理大量的并发连接，有关的论述比较多，比如：

The C10K problem          http://www.kegel.com/c10k.html

POSA2                   http://www.cs.wustl.edu/~schmidt/POSA/POSA2/

《UNIX网络编程2:进程间通信(2Ed)》 出版社：Prentice Hall/Pearson作者：W.Richard Stevens

 

一般来说，在Windows上可以利用“完成端口”IOCP, 在 Linux可用 Epoll（当然在连接数不多的情况下，用BSD Socket 的Select 模型也够用）。互联网上也有开源的网络库可用，如下所示：

ACE       http://www.cs.wustl.edu/~schmidt/ACE.html

Libevent    http://www.monkey.org/~provos/libevent/

Asio       http://think-async.com/Asio/

 

服务器之间通信协议的选择灵活度比较大，如果在一个局域网(LAN)内通信，安全问题会少很多；否则，还需要注意防止窃听和欺骗等黑客行为。除了在部署网络防火墙以及入侵检测系统以外，还可以对通信协议本身做一定的处理。如图3所示。

 

图3： 通信协议的一个例子

 

Total length:协议单元的总长度

Command type:协议单元的类型

Sequence id :协议单元的序列号，说明其适用于异步通信环境

*注：以上三部分组成了“协议单元头部”(pdu header),

Packet body :协议单元的数据体

Crc checksum:协议单元的crc校验值

说明：

i． 为了增强安全性同时又不失速度，可以只对“协议单元头部”进行加密——加密解密总是需要耗费时间的——而对余下的部分不作处理。

ii. 利用私有的crc校验算法，可以防止数据在传输过程中发生歧变。

 

3． 存储I/O优化

在大规模负载和压力情况下，磁盘I/O经常成为应用程序的性能短板。怎样在不失安全性的前提下提高速度？可以考虑在关键的文件和数据库服务器采用专用存储设备，比如直连式(DAS)存储磁盘阵列，甚至是存储区域网络(SAN)。

另外，文件系统的格式选择也很重要，“更快”和“更安全”往往是矛盾的对立面。比如Linux系统就同时支持ReiserFS 、ext3。一般来说，如果对数据安全性要求很高，那么可以考虑使用ext3；如果更在意文件系统的速度及可扩展性，那么ReiserFS应该是首选。

 

4． 借助CDN

CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。

广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种DDOS攻击对网站的影响。在游戏网站的内容发布，游戏客户端的分发下载、更新方面将显著提高服务质量。

 

5． 定时单独作业

网络游戏具有明显的时间分布规律，一般在下午和晚上用户比较集中，凌晨的用户较少，可以在这个时间段，利用操作系统提供的定时执行工具（例如crontab）,把需要进行日常统计和计算的数据抽取出来，在专门的服务器上进行统计、排序计算，从而减轻核心系统的压力。

 

6． 数据库优化

常规的包括建立索引字段，调整SQL，调整数据库服务器参数等内部优化。还包括数据库级的优化，现代的数据库均可提供集群式(Cluster)或主从式(Master Slave)的解决方案。比如采用Oracle RAC方案，能在数据库故障切换和负载均衡方面提供很好的支持。

 

同时，应用服务器在访问数据库时，需要采用数据库连接池(Connection Pool)。数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放超时的空闲连接来避免连接遗漏，能明显提高对数据库操作的性能。

 

八、 数据的完整性和一致性考虑

可以依赖于数据库提供的完整性和一致性支持技术，例如触发器、事务(Transaction)管理、规则约束(Rules & Restrictions)等，也可以在应用程序自行封装完成。

 

除了依赖于核心数据库直接支持的相关技术以外，设计运营支撑系统，特别是计费部分，可以参照会计记账的基本原则，建立简单的数学模型。这样做一是可以杜绝部分程序错误，二是可以定期对帐，及时发现运营过程中的“金额不平”等情况。

例如：

公式1：存量 = 进项收入 – 消耗量

存量：    存放在用户帐上的未被消费的账户余额

进项收入：用户经过充值通道，进入自己账户上的进项金额总和

消耗量：  发生在用户玩游戏过程中购买道具等的出项金额总和

 

公式2：账户余额当前值 = 账户余额历史值 + 改变量

当用户往帐户里充值的时候，改变量为正；当用户在消费（比如购买道具）的时候，改变量为负。在用户充值或者消费过程中，每一次账户余额发生改变的时候，都要记录此次改变发生的时间、金额、科目名称等凭证，以及改变前后的账户余额。

 

九、 测试

关于软件测试工具和测试方法的论述很多，不再废笔墨，按照传统意义上的软件系统测试流程进行即可，这里只想强调测试环境的问题。

运营支撑系统作为联机在线系统，局部的调整和修改在所难免。直接在生产环境中修改风险太大，往往由于一时疏忽造成不可挽回的损失。因此，一定要模拟真实生产环境，建立一整套逼真的测试环境。只有在测试环境中反复严格测试，确认无误，才可提交到真实环境中去运行。

 

十、 综述

在网络游戏产业这几年的发展过程中，由于运作不当而酿下大错，或者技不如人，导致最终流产的网络游戏不乏例证：有的是游戏本身设计的问题，有的是运营策略的问题，还有的因为技术方面的重大事故。制作一款质量精良的网络游戏来之不易，但缺少配套的运营支撑系统也会导致前功尽弃、功亏一篑。只有两者相得益彰，才能发挥网络游戏本身作为一个文化创意作品具有的真正价值。

 

作者简介：

张建民，北京干线动力网络技术有限公司首席架构师，对集群和并行计算、Linux嵌入式开发方面感兴趣。