FO产品总体技术方案.docx
- 文档编号:27608657
- 上传时间:2023-07-03
- 格式:DOCX
- 页数:34
- 大小:480.31KB
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小时
公式
计算结果
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- FO 产品 总体 技术 方案