游戏服务器开发的基本体系与服务器端开发的一些建议
近年来,我身边的朋友有很多都从web转向了游戏开发。他们以前都没有做过游戏服务器开发,更谈不上什么经验,而从网上找的例子或游戏方面的知识,又是那么的少,那么的零散。当他们进入游戏公司时,显得一脸茫然。如果是大公司还好点,起码有人带带,能学点经验,但是有些人是直接进入了小公司,甚至这些小公司只有他一个后台。他们一肩扛起了公司的游戏后端的研发,也扛起了公司的成败。他们也非常尽力,他们也想把游戏的后端做好。可是就是因为没什么经验,刚开始时以为做游戏服务器和做web差不多,但是经过一段时间之后,才发现代码太多,太乱了,一看代码都想重构,都是踩着坑往前走。
这里我把一些游戏开发方面的东西整理一下,希望能对那些想做游戏服务器开发的朋友有所帮助。
首先,要明确一点,做游戏服务器开发和做传统的web开发有着本质的区别。游戏服务器开发,如果没有经验,一开始根本没有一个明确清析的目标,不像web那样,有些明确的MVC架构,往往就是为了尽快满足策划的需求,尽快的实现功能,尽快能让游戏跑起来。但是随着功能越来越多,在老代码上面修改的越来越频繁,游戏测试时暴露出来的一堆bug,更让人觉得束手无策,这个时候我们想到了重构,想到了架构的设计。
游戏的构架设计非常重要,好的构架代码清析,责任明确,扩展性强,易调试。这些会为我们的开发省去不少时间。那要怎么样设计游戏的构架呢?可能每个游戏都不一样,但是本质上还是差不多的。
对于游戏服务器的构架设计,我们首先要了解游戏的服务器构架都有什么组成的?一款游戏到上线,需要具备哪些功能?有些人可能会说,只要让游戏跑起来,访问服务器不出问题不就行了吗?答案是不行的,游戏构架本身代表的是一个体系,它包括:
系统初始化
游戏逻辑
数据库系统
缓存系统
游戏日志
游戏管理工具
公共服务组件
这一系统的东西都是不可少的,它们共同服务于游戏的整个运营过程。我们一点点来介绍各个系统的功能。
一,系统初始化
系统初始化是在没有客户端连接的时候,服务器启动时所需要做的工作。基本上就是配置文件的读取,初始化系统参数。
但是我们必须要考虑的是:
系统初始化需要的参数配置在哪儿,是配置在本地服务器,还是配置在数据库;
服务器启动的时候去数据库取;
配置的修改需不需要重启服务器等。
二,游戏逻辑
游戏逻辑是游戏的核心功能实现,也是整个游戏的服务中心,它被开发的好坏,直接决定了游戏服务器在运行中的性能。那在游戏逻辑的开发中我们要注意些什么呢?
游戏是一种网络交互比较强的业务,好的底层通信,可以最大化游戏的性能,增加单台服务器处理的同时在线人数,给游戏带来更好的体验,至少不容易出现因为网络层导致的数据交互卡顿的现象。在这里我推荐使用Netty,它是目前最流行的NIO框架,它的用法可以在我之前的文章中查看,这里不再多说了。
有人疑问,代码也需要分层次?这个是当然了,不同的代码,代表了不同的功能实现。现在的开发语言都是面向对象的,如果我们不加思考,不加整理的把功能代码乱堆一起,起始看起来是快速实现了功能,但是到后期,如果要修改需求,或在原来的代码上增加新的需求,那真是被自己打败了。所以代码一定要分层,主要有以下几层:
协议层,也叫前后台交互层,它主要负责与前台交互协议的解析和返回数据。在这一层基本上没有什么业务逻辑实现。与前台交互的数据都在这一层开始,也在这一层终止。比如你使用了Netty框架,那么Netty的ChannelHandlerContext即Ctx只能出现在这一层,他不能出现到游戏业务逻辑代码的实现中,接收到客户端的请求,在这一层把需要的参数解析出来,再把参数传到业务逻辑方法中,业务逻辑方法处理完后,把要返回给客户端的数据再返回到这一层,在这一层组织数据,返回给客户端,这样就可以把业务逻辑和网络层分离,业务逻辑只关心业务实现,而且也方便对业务逻辑进行单元测试。
业务逻辑层,这里处理真正的游戏逻辑,该计算价格计算价格,该通关的通关,该计时的计时。该保存数据的保存数据。但是这一层不直接操作缓存或数据库,只是处理游戏逻辑计算。因为业务逻辑层是整个游戏事件的处理核心,所以他的处理是否正确直接决定游戏的正确性。所以这一层的代码要尽量使用面向对象的方法去实现。不要出现重复代码或相似的功能进行复制粘贴,这样修改起来非常不方便,可能是修改了某一处,而忘记了修改另外同样的代码。还要考虑每个方法都是可测试的,一个方法的行数最好不要超过一百行。另外,可以多看看设计模式的书,它可以帮助我们设计出灵活,整洁的代码。
三,数据库系统
数据库是存储数据库的核心,但是游戏数据在存储到数据库的时候会经过网络和磁盘的IO,它的访问速度相对于内存来说是很慢的。一般来说,每次访问数据库都要和数据库建立连接,访问完成之后,为了节省数据库的连接资源,要再把连接断开。
这样无形中又为服务器增加了开销,在大量的数据访问时,可能会更慢,而游戏又是要求低延时的,这时该怎么办呢?我们想到了数据库连接池,即把访问数据库的连接放到一个地方管理,用完我不断开,用的时候去那拿,用完再放回去。这样不用每次都建立新的连接了。
但是如果要我们自己去实现一套连接池管理组件的话,需要时间不说,对技术的把控也是一个考验,还要再经过测试等等,幸好互联网开源的今天,有一些现成的可以使用,这里推荐Mybatis,即实现了代码与SQL的分离,又有足够的SQL编写的灵活性,是一个不错的选择。
四,缓存系统
游戏中,客户端与服务器的交互是要求低延迟的,延迟越低,用户体验越好。像之前说过的一样,低延迟就是要求服务器处理业务尽量的快,客户端一个请求过来,要在最短的时间内响应结果,最低不得超过500ms,因为加上来回的网络传输耗时,基本上就是600ms-到700ms了,再长玩家就会觉得游戏卡了。
如果直接从数据库中取数据,处理完之后再存回数据库的话,这个性能是跟不上的。在服务器,数据在内存中处理是最快的,所以我们要把一部分常用的数据提前加载到内存中,比如说游戏数据配置表,经常登陆的玩家数据等。这样在处理业务时,就不用走数据库了,直接从内存中取就可以了,速度更快。
游戏中常见的缓存有两种:
直接把数据存储在jvm或服务器内存中
使用第三方的缓存工具,这里推荐Redis,详细的用法可以自己去查询。(本公号内有系列文章,详情见【菜单栏】- 【技术文章】 - 【基础系列】 - 【实战R1,实战R2】)
五,游戏日志
日志是个好东西呀,一个游戏中更不能少了日志,而且日志一定要记录的详细。它是玩家在整个游戏中的行为记录,有了这个记录,我们就可以分析玩家的行为,查找游戏的不足,在处理玩家在游戏中的问题时,日志也是一个良好的凭证和快速处理方式。
在游戏中,日志分为:
系统日志,主要记录游戏服务器的系统情况。比如:数据库能否正常连接,服务器是否正常启动,数据是否正常加载;
玩家行为日志,比如玩家发送了什么请求,得到了什么物品,消费了多少货币等等;
统计日志,这种日志是对游戏中所有玩家某种行为的一种统计,根据这个统计来分析大部分玩家的行为,得出一些共性或不同之处,以方法运营做不同的活动吸引用户消费。
在构架设计中,日志记录一定要做为一种强制行为,因为不强制的话,可能由于某种原因某个功能忘记加日志了,那么当这个功能出问题了,或者运营跟我们要这个功能的一些数据库,就傻眼了。又得加需求,改代码了。日志一定要设计一种良好的格式,日志记录的数据要容易读取,分解。日志行为可以用枚举描述,在功能最后的处理方法里面加上这个枚举做为参数,这样不管谁在调用这个方法时,都要去加参数描述。
俗话说,工欲善其事,必先利其器。游戏管理工具是对游戏运行中的一系列问题处理的一种工具。它不仅是给开发人员用,大多数是给运营使用。游戏上线后,我们需要针对线上的问题进行不同的处理。不可能把所有问题都让程序员去处理吧,于是程序员们想到了一个办法,给你们做一个工具,你们爱谁处理谁处理去吧。
六, 游戏管理工具
游戏管理工具是一个不断增涨的系统,因为它很多时候是伴随着游戏中遇到的问题而实现的。
但是根据经验,有一些功能是必须有的,比如:
服务器管理,主要负责服务器的开启,关闭,服务器配置信息,玩家信息查询;
玩家管理,比如踢人,封号;
统计查询,玩家行为日志查询,统计查询,次留率查询,邮件服务,修改玩家数据等。
根据游戏的不同要求,凡是可以能过工具实现的,都做到游戏管理工具里面。它是针对所有服务器的管理。
一个好的,全的游戏管理工具,可以提高游戏运营中遇到问题处理的效率,为玩家提供更好的服务。
七,公共组件
公共组件是为游戏运行中提供公共的服务。例如:
充值服务器,我们没必须一个服用一个充值,而且你也不能对外提供多个充值服务器地址,和第三方公司对接,他们绝对不干,这是要疯呀;
还有运营搞活动时的礼包码;
还有注册用户的管理,玩家一个注册账号可以进不同的区等。
这些都是针对所有区服提供的服务,所以要单独做,与游戏逻辑分开,这样方便管理,部署和负载均衡。
还有SDK的登陆验证,现在手游比较多,与渠道对接里要进行验证,这往往是很多http请求,速度慢,所以这个也要拿出来单独做,不要在游戏逻辑中去验证,因为网络IO的访问时间是不可控制的,http是阻塞的请求。
所以,综上来看,一个游戏服务器起码有几个大的功能模块组成:
游戏逻辑工程;
日志处理工程;
充值工程;
游戏管理工具工程;
用户登陆工程;
公共活动工程等。
根据游戏的不同需要,可能还有其它的。所在构架的设计中,一定要考虑到系统的分布式部署,尽量把公共的功能拆出来做,这样可以增强系统的可扩展性。
服务器端开发的一些建议
本文作为游戏服务器端开发的基本大纲,是游戏实践开发中的总结。
第一部分 —— 专业基础,用于指导招聘和实习考核;
第二部分 —— 游戏入门,讲述游戏服务器端开发的基本要点;
第三部分 —— 服务端架构,介绍架构设计中的一些基本原则。
希望能帮到大家!
一、专业基础
1.1网络
1.1.1理解TCP/IP协议
网络传输模型
滑动窗口技术
建立连接的三次握手与断开连接的四次握手
连接建立与断开过程中的各种状态
TCP/IP协议的传输效率
思考:
请解释DOS攻击与DRDOS攻击的基本原理
一个100Byte数据包,精简到50Byte, 其传输效率提高了50%
TIMEWAIT状态怎么解释?
1.1.2掌握常用的网络通信模型
Select
Epoll,边缘触发与平台出发点区别与应用
Select与Epoll的区别及应用
1.2存储
计算机系统存储体系
程序运行时的内存结构
计算机文件系统,页表结构
内存池与对象池的实现原理,应用场景与区别
关系数据库MySQL的使用(本公众号内有系列文章,详情见【菜单】-【
共享内存
1.3程序
对C/C++语言有较深的理解
深刻理解接口,封装与多态,并且有实践经验
深刻理解常用的数据结构:数组,链表,二叉树,哈希表
熟悉常用的算法及相关复杂度:冒泡排序,快速排序
二、游戏开发入门
2.1防御式编程
不要相信客户端数据,一定要检验。作为服务器端你无法确定你的客户端是谁,你也不能假定它是善意的,请做好自我保护。(这是判断一个服务器端程序员是否入门的基本标准)
务必对于函数的传人参数和返回值进行合法性判断,内部子系统,功能模块之间不要太过信任,要求低耦合,高内聚。
插件式的模块设计,模块功能的健壮性应该是内建的,尽量减少模块间耦合。
2.2设计模式
道法自然。不要迷信,迷恋设计模式,更不要生搬硬套
简化,简化,再简化,用最简单的办法解决问题
借大宝一句话:设计本天成,妙手偶得之
2.3网络模型
自造轮子: Select, Epoll, Epoll一定比Select高效吗?
开源框架: Libevent, libev, ACE。(本公众号内有Libevent源码详解,详情见【菜单】-【开源软件】-【源码分析】-【网络库I】)
2.4数据持久化
自定义文件存储,如《梦幻西游》
关系数据库: MySQL
NO-SQL数据库: MongoDB
选择存储系统要考虑到因素:稳定性,性能,可扩展性
2.5内存管理
使用内存池和对象池,禁止运行期间动态分配内存
对于输入输出的指针参数,严格检查,宁滥勿缺
写内存保护,使用带内存保护的函数(strncpy, memcpy, snprintf, vsnprintf等)
严防数组下标越界
防止读内存溢出,确保字符串以'