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

　　近几年，网络游戏产业发展迅猛。据资料显示，2009年在中国大陆地区新上线的大型

　　网络游戏超过200款，拥有网游企业近750家，而市场规模将达到260亿。

　　目前网络游戏界的常见的运营模式，是“游戏开发商”+“游戏代理运营商”模式。双

　　方之间一旦确定了合作关系，应该是一个密不可分的整体，但是如何划分彼此之间的权

　　利和义务？暂且以“产品”为界限，这个“产品”，就是网络游戏本身——是一个独立

　　的软件系统，提供了一个公众娱乐的虚拟世界的载体，很少包含运营相关的内容。而后

　　可以说，每一款网络游戏的背后，都有一套运营系统在支撑。所谓“麻雀虽小，五脏俱

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

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

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

　　一般来说，网络游戏服务器(GameServer)主流的运行平台为Windows和Linux。一般配置

　　为低端的PC服务器，主要以“组”为单位（行业术语叫“游戏大区”），一组游戏服务器（一

　　个“大区”）大概是几台到十几台的规模不等，大部分分布于全国各地的IDC机房。这样做

　　的主要目的是：一是基于成本的考虑——二三级城市的带宽和服务器成本要远远低于北京、

　　上海等大城市；二是提高游戏的流畅度——用户可以选择离自己距离更近，带宽情况更好的

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

　　这些服务器往往都位于同一个局域网内部，彼此之间进行内部通信，形成一个功能相对独立

　　的游戏世界。游戏服务器与桌面客户端之间的通信，大部分采用TCP协议，也有一些动作

　　竞技类休闲游戏，采用UDP协议来减少网络延时和增大有效负载。每个游戏用户的带宽从

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

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

　　运营支撑系统在获取到这些数据和消息以后，其中一部分需要进行实时响应（例如用户登陆

　　在设计运营支撑系统之前，需要制定完整的运营计划，比如：游戏何时上线运营？游戏是按

　　时间收费还是按道具收费？是否考虑实施包月制？是否发行自己的游戏点卡并建立销售渠

　　道？游戏虚拟道具的价格和汇率(和RMB之间)是否固定？使用该系统的各部门关系、工作

　　流程是否已经明确？这些都最终与运营支撑系统紧密关联。只有计划已经基本确定，才能有

　　条不紊地进行持续开发。否则，不断的需求变动容易导致系统不稳定，最终导致整个运营过

　　运营支撑系统是一个持续运行，不断变化的软件系统，从开始运营，直到游戏停止服务，一

　　容量大——一款流行的网络游戏的注册人数可能达到“1000万”级别，每天产生若干

　　高并发——一个游戏大区分组可达到上万人同时在线，所有大区加起来可以达到数十万

　　乃至上百万的规模，这些大量用户的数据和消息在游戏过程中会产生大量数据和消息，最终

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

　　运营支撑系统可以采用集中式的星型拓扑结构（近来，也有一些运营商采用了少量的分布式

　　技术，但从总体上来说还是属于集中式架构）。采用集中式结构，可以显著降低运营的复杂

　　程度和成本——为了数据安全考虑，运营商需要采购高端的存储设备、服务器和网络设备、

　　灾备系统；而采用集中式的结构，只需要在一个“中心”结点上投资和部署这些设备即可。

　　运营支撑系统通常围绕核心数据库来建设，一般采用大型商业数据库，例如MSSQLServer、

　　Oracle、DB2等，除了功能比较完善以外，还能获得厂商的技术服务和支持。

　　兼而有之。采用B/S 架构，可以根据自身特长，利用业界成熟的解决方案，例如、J2EE

　　等。而采用 C/S 架构，往往需要从底层开发一些服务器端/客户端应用程序，从而对开发团

　　运营网关服务器——负责与各个游戏大区的服务器进行通信，内容包括用户登录认证、购买

　　道具、获取奖励等与游戏过程直接相关的信息。一般用服务器守护(daemon)进程实现。

　　在系统设计的时候，需要注意角色(Role)和权限(Privilege)划分。不同角色，拥有的权限不尽

　　相同，不论在应用程序部分，还是在数据库内部，都要做严格区分。同时，还需要考虑到角

　　网络游戏是一个产品，但运营网络游戏却是一项服务。在整个服务周期中，运营支撑系统所

　　具有的功能会随着市场和经营策略进行调整。如何能快速地随需而动？对运营支撑系统的可

　　1． 在设计应用程序的底层模块时，尽量保持其无状态(Stateless)。无状态的应用程序在规模

　　2． 运营支撑系统的业务逻辑可以封装在应用程序里，也可封装在数据库里，封装在后者的

　　业务逻辑以存储过程(Storage Procedure)或触发器的形式体现。在运行存储过程前，数据

　　库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极

　　大地改善SQL 语句的性能。由于执行SQL 语句的大部分工作已经完成，所以存储过程

　　能以极快的速度执行。同时由于存储过程和应用程序之间在多数情况下仅仅只是接口的

　　参数传递，而不是完整的 SQL 逻辑，可以大大降低网络的通信量。当业务逻辑发生变

　　化时在数据库服务器中改变存储过程即可，无须修改任何应用程序，从而极大提高应变

　　3． 充分利用数据库提供的视图(view)功能。视图是底层数据的抽象，可以理解为“数据的

　　4． 把经常变动的环境变量或者业务逻辑，单独放在XML 配置文件，甚至脚本语言里执行，

　　比如LUA ,Python，把应用程序的框架部分，用C++或者Java 实现。这样，在变动发生

　　基本上很难找到一套成熟的、或类似的软件，不加修改就可以直接使用。即使这样，运营支

　　撑系统的开发仍然与一般的软件开发方法基本相同，可选的方法很多，比如敏捷开发过程

　　运营支撑系统以大量的数据库事务处理为主，辅以少量的逻辑计算(应该不算CPU Bound 型)，

　　游戏网站是网络游戏对外提供服务的窗口，在运营商持续的广告投放之后，大量的随机访问

　　伴随就开始蜂拥而入。在游戏成长过程中的几个关键阶段，开放式内测、公测，加上一些潜

　　可以考虑部署基于硬件的负载均衡器，安装在服务器和外部网络间，性能得到大幅提高，加

　　*值得一提的是，Linux 内核 2.6 以后集成了LVS 集群技术，它采用IP 负载均衡技术和基

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

　　在自下而上构架应用服务器的时候，进程间通信通常会用到socket。如何建立服务器软件模

　　不多的情况下，用BSD Socket 的Select 模型也够用）。互联网上也有开源的网络库可用，

　　服务器之间通信协议的选择灵活度比较大，如果在一个局域网(LAN)内通信，安全问题会少

　　很多；否则，还需要注意防止窃听和欺骗等黑客行为。除了在部署网络防火墙以及入侵检测

　　i． 为了增强安全性同时又不失速度，可以只对“协议单元头部”进行加密——加密解

　　在大规模负载和压力情况下，磁盘I/O 经常成为应用程序的性能短板。怎样在不失安全性的

　　前提下提高速度？可以考虑在关键的文件和数据库服务器采用专用存储设备，比如直连式

　　另外，文件系统的格式选择也很重要，“更快”和“更安全”往往是矛盾的对立面。比如Linux

　　系统就同时支持 ReiserFS 、ext3。一般来说，如果对数据安全性要求很高，那么可以考虑

　　使用ext3；如果更在意文件系统的速度及可扩展性，那么ReiserFS 应该是首选。

　　中增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可以就近

　　取得所需的内容，解决Internet 网络拥挤的状况，提高用户访问网站的响应速度。从技术上

　　全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应

　　广泛分布的CDN 节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各

　　种 DDOS 攻击对网站的影响。在游戏网站的内容发布，游戏客户端的分发下载、更新方面

　　网络游戏具有明显的时间分布规律，一般在下午和晚上用户比较集中，凌晨的用户较少，可

　　以在这个时间段，利用操作系统提供的定时执行工具（例如 crontab）,把需要进行日常统计

　　和计算的数据抽取出来，在专门的服务器上进行统计、排序计算，从而减轻核心系统的压力。

　　常规的包括建立索引字段，调整 SQL，调整数据库服务器参数等内部优化。还包括数据库

　　级的优化，现代的数据库均可提供集群式(Cluster)或主从式(Master Slave)的解决方案。比如

　　采用Oracle RAC 方案，能在数据库故障切换和负载均衡方面提供很好的支持。

　　同时，应用服务器在访问数据库时，需要采用数据库连接池(Connection Pool)。数据库连接

　　池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而

　　再不是重新建立一个；释放超时的空闲连接来避免连接遗漏，能明显提高对数据库操作的性

　　可以依赖于数据库提供的完整性和一致性支持技术，例如触发器、事务(Transaction)管理、

　　除了依赖于核心数据库直接支持的相关技术以外，设计运营支撑系统，特别是计费部分，可

　　以参照会计记账的基本原则，建立简单的数学模型。这样做一是可以杜绝部分程序错误，二

　　当用户往帐户里充值的时候，改变量为正；当用户在消费（比如购买道具）的时候，改变量

　　为负。在用户充值或者消费过程中，每一次账户余额发生改变的时候，都要记录此次改变发

　　关于软件测试工具和测试方法的论述很多，不再废笔墨，按照传统意义上的软件系统测试流

　　运营支撑系统作为联机在线系统，局部的调整和修改在所难免。直接在生产环境中修改风险

　　太大，往往由于一时疏忽造成不可挽回的损失。因此，一定要模拟真实生产环境，建立一整

　　套逼真的测试环境。只有在测试环境中反复严格测试，确认无误，才可提交到真实环境中去

　　在网络游戏产业这几年的发展过程中，由于运作不当而酿下大错，或者技不如人，导致最终

　　流产的网络游戏不乏例证：有的是游戏本身设计的问题，有的是运营策略的问题，还有的因

　　为技术方面的重大事故。制作一款质量精良的网络游戏来之不易，但缺少配套的运营支撑系

　　统也会导致前功尽弃、功亏一篑。只有两者相得益彰，才能发挥网络游戏本身作为一个文化

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