FO产品总体技术方案.docx

FO产品总体技术方案.docx

《FO产品总体技术方案.docx》由会员分享，可在线阅读，更多相关《FO产品总体技术方案.docx（34页珍藏版）》请在冰点文库上搜索。

FO产品总体技术方案

FO产品总体技术方案

拟制：

日期：

审核：

日期：

版本号：

XXXV1.0

腾讯科技（深圳）有限公司

修订日期

修订内容

协议版本

修订人

1背景

2概述

2.1范围

2.2引用标准

2.3术语和定义

名词

解释

2.4符号和缩略语

缩写

英文描述

中文描述

3总体架构设计

3.1设计原则

3.1.1产品关联性原则

●尽量保持产品的独立性

●在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的可能性。

●在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性

●与幻想关联的产品主要是：

QQ和Q币支付系统。

3.1.2产品依赖原则

●尽可能重用公司内部已有的模块，以减少维护和开发的工作量。

●对于一些已有的产品，如果可以满足需求，直接整合到产品包中。

●由于幻想的特殊情况，目前幻想除了下载服务器以外，未重用任何模块或代码。

3.2设计目标

3.2.1路标规划

阶段

开始时间

完成时间

阶段目标和工作进度指标

DEMO

2003年10月27

2004年1月9

DEMO的制作

AHPLA1

2004年1月9

2004-3-12

●实现职业换装的人物头发换色

●完成以下界面:

（1）开始选单

（2）控制面板（3）人物状态栏

●完成战斗攻击系统

●地图编辑器:

（1）人物换色数据组织

（2）公用物件编辑（3）图素拼接地表

●特效编辑器:

实现战斗被击特效编辑.

AHPLA2

2004-3-12

2004-4-23

●增加道具系统

●构建游戏的第一个城镇

AHPLA3

2004-4-23

2004-6-4

●组队系统

●基本技能系统

●职业换装系统

●称号系统

●放置野外宝箱

AHPLA4

2004-6-4

2004-7-2

●功能性特性

●任务系统

●聊天系统

●怪物系统（怪物AI、怪物宝石）

●道具镶嵌和、改造、合成

●拜师系统

●好友系统（结合QQ）

AHPLA5

2004-7-2

2004-7-30

●建立跨组的游戏调试环境

●完成神明系统与异常状态的开发

●完成部分职业的技能（考虑纸娃娃实现,延后进行）

●进行功能完善:

AHPLA6

2004-7-30

2004-8-27

●完成界面的改进

●实现传送系统

●Server后台功能实现

●加入修罗城,长乐村等地图

AHPLA7

2004-8-27

2004-9-30

●DIRSERVER

●邮件系统

●寄售系统

●完善神明及战斗异常状态的画面表现

●加入神武山迷宫地图

●加入2张野外地图

AHPLA8

2004-9-30

2004-11-12

●开店系统

●职业技能

AHPLA9

2004-11-12

2004-12-31

游戏内容、数值调整

ClosedBeta版本

2004-12-31

2005-3-25

测试、BUG修改、完善；

ClosedBeta2

2005年4月第一周

2005年4月第四周

●商业技能（部分）

●怪物属性伤害（部分）

●道具镶嵌与合成（部分）

●任务（部分）

•ClosedBeta3

2005年4月第一周

2005年5月第四周

●卡片（部分）

●宠物系统（不含战斗）

●商业技能（全部）

●道具镶嵌和合成（全部）

●新地图黄金城和沙漠迷宫

●语音聊天功能（可选）

●客户端支持平滑升级（可选）

●任务（部分）

•OpenBeta

2005年4月第一周

2005年6月第四周

●工会系统（基本功能）

●怪物属性伤害（全部）

●支持代理服务器玩MMOG

●任务（部分）

●交通飞空艇

收费版

2005年4月第一周

2005年8月第二周

●宠物系统－战斗（完成）

●半自由PK系统

●工会系统（工会战）

●任务（部分）

●新地图－新大陆（可选）

●婚姻系统

国庆版

2005年4月第一周

2005年9月第四周

●全自由PK系统（预先完成）

●攻城战

●工会飞空艇

3.3系统需求

3.3.1系统软件需求

●SlackwareLinux10.1Kernel2.6.8.1（支持epoll、iptables）

●Cvs版本管理系统

●Mysql4.0.16

●Heatbeat1.2.1

●Libnet1.1.2.1

3.3.2系统硬件需求

DB服务器：

●DL380G3

●标配：

CPUP42.8G×2

●内存：

1GHPDDRRAM×2

●硬盘：

36G×4RAID5（100G）

前端服务器：

●PT2300GII

●标配：

CPUP42.4G×2

●内存：

1GDDRRAM×2

●硬盘：

36G×1NORAID

日志服务器：

●DL380G3

●标配：

CPUP42.8G×2

●内存：

1GHPDDRRAM×2

●硬盘：

146G×4RAID5（400G）

3.3.3系统功能需求

●实时战斗模式，server用2D方式实现，client端可以为2D或者3D沙盘

●用QQ号码登录游戏，不需单独注册

●通过QQserver验证，用Kerberos方式实现C/S128bit对称加密

●用户登录后，可以在一个world的不同地图，不同server自由切换，不需重新连接

●用户的前端连接和后台server处理逻辑分离，后台server的处理逻辑可以透明更新，不影响在线用户

●支持后台自动更新。

Client端需要更新版本时，用户可以一边玩一边后台更新。

当登录用户已经下载好新版本超过一定比例时才要求强行更新（如大于80%）

●server尽可能支持不同版本的client登录。

Client在升级失败时可以回退。

3.3.4系统性能需求

●最小化容量：

在一台机器上支持一个完整的world，约5-10万注册用户，1000-2000在线用户

●最大化容量：

在同一个IDC大区下，支持50万在线用户，划分5-50个world，每个world支持1–20万在线用户。

以平均每台机器支撑600-1000用户计算，大概是一个500-800台机器的集群系统

●通过简单的配置，可以较方便地实现从最小化到最大化的伸缩

●考虑到实际情况，可能是在若干个大的地区，安装200台左右的机器，支持10万-20万在线用户。

较小的地区采用更小的规模。

●响应速度要求：

用户登陆时间<5s，在一台1000-2000在线用户的机器上，用户操作延迟时间<500ms

3.4系统总体架构

3.4.1系统物理架构

FO采用两个Cluster，多个World的方式。

FO的基本架构是由三层组成：

最上一层是Cluster，主要是管理帐号和计费，在一个Cluster中，一个帐号只能登录一次。

中间一层是World，主要是管理玩家角色数据，World之间的角色数据是互不相关的，同一个帐号可以在每个World中创建最多三个角色。

最下一层是Zone，负责游戏的逻辑，Zone服务器是用户直接相关的服务器，属于同一个World的Zone服务器之间共享角色数据。

3.4.2系统逻辑架构

Cluster的逻辑架构图如下图所示：

World、Zone的逻辑架构图如下图所示：

4关键技术分析

4.1业务模型分析

4.1.1目标用户

●针对QQ，QQgame的现有用户群

●18-25岁的年轻用户为主，学生族群为主

●增加对女性玩家的吸引力，带动男性玩家

4.1.2用户入口

●QQ幻想客户端桌面入口

●QQ客户端菜单入口

●QQgame游戏大厅入偶

●Gameportal网页入口

4.1.3收费策略

●会员制，包月用户收费，价格不高于40元人民币

●会员制，包周用户收费，价格不高于15元人民币

●虚拟物品贩卖收费，单价0.1Q币~10Q币不等

4.1.4产品依赖关系

●QQ客户端上的入口及会员标志等多种表现形式

●QQgame游戏大厅入口，游戏内可进行QQgame的小游戏等

●与短信、QQ音乐等增殖业务结合增加收入

●QQ秀，QQ堂等业务推出宣传性道具和地图等

●内嵌QQ和QQmail发送功能

●宠物设计与QQ宠物结合一致

4.1.5典型业务过程

一个完整的用户登录过程如下图所示：

●用户输入帐号和密码，客户端开始连接QQ签名服务器。

●QQ签名服务器根据用户输入的帐号和密码，进行鉴权，并返回签名。

●客户端连接Dir服务器，试图获得Zone服务器的目录列表。

●Dir服务器返回当前可用的Zone服务器列表以及负载信息。

●用户选择要连接的Zone服务器，发送连接请求和签名信息。

●Zone接到请求后，验证该签名，并向World服务器发送帐号登录请求。

●World服务器接收到帐号登录请求后，向Cluster服务器转发该请求。

●Cluster服务器接收到帐号登录请求，记录相应的信息，并向World服务器返回应答。

●World服务器转发该应答到对应的Zone服务器。

●Zone服务器得到应答，进行有关的帐号登录处理，并通知客户端。

一个典型的用户操作过程：

●Client向Zone服务器发送移动或打斗的操作。

●Zone服务器计算出Client移动的新位置或打斗的动作，将它反射给其他Client，使得其他用户可见。

●Zone服务器定时将Client操作后的数据同步给World服务器

一个典型的用户查询过程：

●Client向Zone服务器发送查询请求。

●Zone服务器将此请求发送给World服务器。

●World服务器将查询后的结果返回给Zone服务器。

●Zone服务器将查询结果返回给Client。

4.2用户模型分析

4.2.1用户基础信息

一个Cluster支持的在线用户为500K

一个World支持的在线用户为5000

一个Zone支持的在线用户为1500

单个用户平均在线时间：

1小时/每天

在线与注册用户比例：

5%

活跃与注册用户比例：

20%

4.2.2用户操作信息

用户登录：

●按每个Cluster有500K同时在线人数，平均每人每天1小时的在线时长，则将造成约140次/s登录请求，这样World将有140次/s访问Cluster（内网访问），Cluster将有140次/s访问ClusterDB（数据库操作）。

●按每个World有5000人同时在线人数，平均每人每天1小时的在线时长，则将造成约1.4次/s登录请求，这样Zone将有1.4次/s访问World（内网访问），World将有1.4/s访问WorldDB（数据库操作）。

●按每个Zone有1500人同时在线人数，平均每人每天1小时的在线时长，则将造成0.42次/s登录请求，这样Client将有0.42次/s访问Zone（外网访问）。

用户注销：

●按每个Cluster有500K同时在线人数，平均每人每天1小时的在线时长，则将造成约140次/s注销请求，这样World将有140次/s访问Cluster（外网访问），Cluster将有140次/s访问ClusterDB（数据库操作）。

●按每个World有5000人同时在线人数，平均每人每天1小时的在线时长，则将造成约1.25次/s注销请求，这样Zone将有1.4次/s访问World（内网访问），World将有1.4/s访问WorldDB（数据库操作）。

●按每个Zone有1500人同时在线人数，平均每人每天1小时的在线时长，则将造成0.42次/s注销请求，这样Client将有0.42次/s访问Zone（外网访问）。

用户移动（网络游戏中的角色行走）：

●按每个Zone有1500人同时在线人数，平均每人每天1小时在线时长，每人每秒移动1次，每个用户平均被10个其他用户可见，则造成15K次/s的移动请求，这样Client将有15K次/s访问Zone（外网访问）。

●按每个World有5000人同时在线人数，每3分钟同步一次Zone的数据，则将造成27次/s同步请求，这样Zone将有27/s访问World（内网访问），World将有25/s访问WorldDB（数据库操作）。

用户攻击（网络游戏中的角色打斗）：

●按每个Zone有1500人同时在线人数，平均每人每天1小时在线时长，每人每秒攻击1次，每个用户平均被10个其他用户可见，则造成15K次/s的攻击请求，这样Client将有15K次/s访问Zone（外网访问）。

●Zone与World的同步请求与用户移动的操作同时进行，故不再累计。

用户查询（网络游戏中角色查询货舱等操作）：

●按每个Zone有1500人同时在线人数，每10分钟查询一次数据，则造成2.5次/s查询请求，这样Client将有2.5次/s访问Zone（外网访问）。

●按每个World有5000人同时在线人数，每10分钟查询一次数据，则造成8.3次/s查询请求，这样Zone将有7.5次/s访问World（内网访问），World将有8.3次/s访问WorldDB（数据库操作）。

总计：

Cluster：

280次/s（包数）内网访问，280次/s数据库操作，其中140次/s的Select操作，140次/s的Update操作

World：

35次/s（包数）内网访问，35次/s数据库操作，其中25次/s的Update操作，10次/s的Select操作

Zone：

30K次/s（包数）外网请求

4.2.3用户流量信息

用户登录请求流量（Client－Dir）：

200Bytes

用户登录返回流量（Dir－Client）：

1000Bytes

用户登录请求流量（Client－Zone）：

100Bytes

用户注销请求流量（Client－Zone）：

100Bytes

用户登录返回流量（World－Zone）：

5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件）＝62KBytes

用户登录请求流量（World－Cluster）：

100Bytes

用户注销请求流量（World－Cluster）：

100Bytes

用户更新流量（Zone－World）：

5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）=17Kbytes

用户查询请求流量（Client－Zone）：

100Bytes

用户查询返回流量（World－Zone）：

7KBytes

用户移动请求流量（Client－Zone）：

100Bytes

用户攻击请求流量（Client－Zone）：

100Bytes

聊天消息流量：

140Bytes

日志信息流量：

140Bytes

单位用户流量（平均用户每1秒攻击一次，每1秒移动一次，每一个用户平均被10个其他用户可见）：

10×200Bytes×8Bit＝16Kps

语音流量：

15Kps

Zone切换流量：

240Kps

4.3系统模型分析

4.3.1ClusterServer

Cluster服务器包括cluster_login和db_process，cluster_login负责与WorldServer交互，并维护OnlineAccountTable，对数据库的访问由db_process负责。

4.3.2WorldServer

一个world可以包含多个zoneserver，每个zoneserver管理一块或者多块地图。

一个world最多包括100个zoneserver，每个处理1000-2000在线用户的话，一个world可以同时在线10-20万人

4.3.3Zoneserver

Zone服务器由zone_connect、zone_disp和zone_server构成。

zone_connect负责接收来自客户端的连接，并进行解密，并把消息传递给zone_server进行处理。

zone_server负责进行逻辑处理，并根据处理结果或者转给zone_disp并交由其它zone_server进行处理，或者交由World服务器进行处理。

4.4性能容量分析

4.4.1Cluster设备和流量需求

Cluster：

在线人数：

500K

注册人数：

500K/5%＝10M

平均在线时长：

1小时

公式

计算结果

备注

存储要求

注册用户数×单位用户信息

10M×100Byte＝1G

其中100Byte是单位用户信息

带宽要求（内网）

在线人数×（World与Cluster之间通信量）/在线时间×8Bit

500K*（100Byte+100Byte）/3600*8Bit=0.22Mbps

其中第一个100Byte是Login的开销，后100Byte是Logout的开销

带宽要求（外网）

无

机器要求

2台G3

双机热备，1台为主，另一台备份

关键负荷分析

280个/s的数据包

280次/s的数据库操作

数据包数不是瓶颈，

其中140次/s的Select操作（Login），140次/s的Update操作（Logout），由于Select和Update的数据量较小，不会造成数据库的访问瓶颈

4.4.2World设备和流量要求

World：

在线人数：

4500

注册人数：

4500/5%＝90K

平均在线时长：

1小时

公式

计算结果

备注

存储要求

注册用户数×（角色数据＋保管箱数据＋邮件数据＋寄售物品数据）

90K×（75K＋12K＋120K＋0.6K）=18.68G

角色数据＝（5K（背包）+5K（任务）+12K（赠送记录）+3K（基本数据））*3（每个帐号可以创建3个角色）＝75K

保管箱数据＝4K（大、小保管箱）*3（每个帐号可以创建3个角色）＝12K

邮件数据＝1K（每封）*40（每个角色）*3（每个帐号可以创建3个角色）＝120K

寄售物品数据＝（5（byte）*40）（寄售物品）*3（每个帐号可以创建3个角色）＝0.6K

带宽要求（内网）

在线人数×（登录请求/在线时间＋定时更新/更新频率＋查询请求/查询频率）×8Bit

4500*（16Bytes＋94Byte+12Byte）*8Bit=0.44Mbps

登录请求＝5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件）/3600＝16Bytes

假定更新频率为3分钟，

定时更新＝5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）/180＝94Byte

假定查询频率为10分钟，

7K/600=12Byte

带宽要求（外网）

无

机器要求

2台G3

双机热备，1台为主，另一台备份

关键负荷分析

35个/s的数据包，

35次/s的数据库操作

由于网络包数和数据库操作较少，所有没有瓶颈问题

4.4.3Zone设备和流量需求

假定一个Zone支持的最高人数为1500，平均人数为1000，每用户流量20Kbps，每用户平均游戏时间为1个小时。

Zone：

在线人数：

1500

单位用户流量：

20Kbps

平均在线时长：

1小时

公式

计算结果

备注

存储要求

无

带宽要求（内网）

在线人数×（登录请求/在线时间＋定时更新/更新频率＋切换Zone/切换频率）×8Bit

1500*（15Bytes+94Bytes+167Bytes）*8Bit=3.3Mbps

登录请求＝（5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱）+40*1K（邮件））/3600=15Byte

假定更新频率为3分钟，

定时更新＝（5K（背包）+5K（任务）+3K（基本数据）+4K（大、小保管箱））/180=94Byte

假定Zone切换频率为3分钟，

切换Zone＝30K/180=167Byte

带宽要求（外网）

在线人数×单位用户流量×8Bit

1500×2K×8Bit＝24Mbps

主要以用户最常使用的操作来进行评估，平均用户每1秒攻击一次，每1秒移动一次，每一个用户平均被10个其他用户可见。

10×200Bytes＝2K

机器要求

1台NRS

关键负荷分析

30K个/s的数据包

30K个/s的数据包将成为数据访问的瓶颈，但由于估算是考虑的是每个人每秒移动并且攻击一次，而且每个人都将给其他10个看到，考虑到并不是所有人都在移动或攻击状态，所以按30％统计，9K个/s的数据包也应该不会对系统造成访问瓶颈

4.4.4杂项设备和流量需求

1.客户端版本检查服务器

客户端版本大小：

600M

在线用户：

500K

平均在线时间：

1小时

更新版本用户：

200K

每天下载版本用户：

20K

公式

计算结果

备注

存储要求

客户端版本大小×保存的版本数量

600M×2＝1.2G

带宽要求（内网）

带宽要求（外网）

（在线人数×版本检测流量/在线时间＋更新用户数×版本更新流量/更新时间＋下载人数×下载流量）×8Bit

（500K×0.28Byte＋200K×291Bytes＋20K×1K）×8Bit＝0.67Gbps

假设版本检测需要1K流量，版本检测＝1K/3600＝0.28Byte

假设每次更新大小为4M数据，每次更新时间为4小时，更新流量＝4M/3600/4＝291Byte

假设采用P2P技术可以节省80％的带宽流量，600M/3600/24/4=1K

机器要求

3台NRS（千兆网卡）

以每台可以支撑的有效负载流量250Mbps来计算

关键负荷分析

下载新版本流量为8Kbps

考虑到公测的前一个月下载人数可能在100K左右，流量带宽将有0.8Gbps，所以在公测前期可能的带宽流量为1.3Gbps

2.Web服务器

公式

计算结果

备注

存储要求

带宽要求（内网）

带宽要求（外网）

150Mbps

参考《凯旋》，《凯旋》的官网流量约为100MBps。

机器要求

2台NRS（千兆网卡）＋1台G3

关键负荷分析

3.语音服务器

在线人数：

500K

语音聊天人数：

500K×10％＝50K

单位语言流量（一路）：

15Kbps

公式

计算结果

备注

存储要求

带宽要求（内网）

带宽要求（外网）

语音聊天人数×语音流量

50K×15K＝725Mbps

机器要求

3台NRS（千兆网卡）

以每台可以支撑的有效负载流量250Mbps来计算

关键负荷分析

4.Dir服务器

在线人数：

500K

平均在线时长：

1小时

公式

计算结果