BOSS

业务运营支撑系统

Business & Operation Support System，BOSS

 

 

下文转自：构建网络游戏运营支撑系统

 

一、 前言

 

近几年，网络游戏产业发展迅猛。据资料显示，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之间)是否固定？使用该系统的各部门关系、工作流程是否已经明确？这些都最终与运营支撑系统 紧密关联。只有计划已经基本确定，才能有条不紊地进行持续开发。否则，不断的需求变动容易导致系统不稳定，最终导致整个运营过程杂乱无章。

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

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

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

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

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

容量大   —— 一款流行的网络游戏的注册人数可能达到“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)内通信，安全问题会少很多；否则，还需要注意防止Qieting和欺骗等黑客行为。除了在 部署网络防火墙以及入侵检测系统以外，还可以对通信协议本身做一定的处理。如图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：账户余额当前值 = 账户余额历史值 + 改变量

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

 

九、测试

 

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

 

十、综述

 

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