最近调研了一下游戏服务器设计的问题,周末花了些时间查阅相关的书籍和文章,也了解了一下Photon、KBEngine、Skynet这些开源游戏服务器的结构和实现,边学习,边整理。
Web服务器设计
在思考游戏服务器设计的时候,我首先想到的是一般Web服务器的设计结构。最简单而典型的Web服务器模型可以总结为:
服务端创建一个监听Socket持续等待新连接,客户端发起TCP连接,然后三次握手成功建立连接。接着客户端(浏览器)发送HTTP请求给服务器,服务器返回HTTP响应回复,并在客户端呈现用户想要的内容。
在这个基础上,再进一步,如果是运行有Web App应用的服务器,则会加入Web框架,来进行多个应用模块的管理、使用及调度,例如python中的Django、Flask都是优雅而易用的框架。如果在一个服务器上需要运行多个框架及应用的时候,会考虑在服务器和框架之间加入中间件组件,它可以根据目标URL将请求消息路由到不同的框架应用,也可以进行负载均衡,例如针对python的WSGI接口设计。在这种情况下,Web服务器模型可以总结为:
服务端监听客户端连接,客户端发起连接,创建连接后,客户端发送HTTP请求给服务器。中间件通过消息路由、转发请求找到框架,提供可调用的应用。服务器调用可调用的应用,处理接收到的HTTP请求。框架/应用产生HTTP状态和HTTP响应头和响应体传递给服务器。由服务器组装成一个完整的报文返回给客户端,并在客户端呈现用户想要的内容。
在此基础上更进一步,大型的Web网站和动态应用,我理解的服务器设计就是指后台整体设计了,包括:
- 基础服务器配置(Apache、Nginx)
- Web应用框架和中间件
- 数据库IO(MySQL/Oracle/MongoDB、优化存储、读写分离、负载均衡、数据与应用分离等)
- 缓存系统(常分为文件缓存、内存缓存和数据库缓存,在大型应用中使用最多且效率最高的是内存缓存,现在常用的内存缓存工具有Memcached和Redis。而且现在大家都比较关注图片缓存优化,常常有专门针对图片的服务器设计)
- 分布式存储系统(Hadoop、Spark、HBase对这方面还不熟)
-
分布式服务器管理系统(批量化的任务执行、配置文件、命令管理、脚本程序、补丁安装等等,运维的工作)
代码发布系统(生产环境下以虚拟主机方式提供,源代码管理和版本控制,集群间代码同步,参与内部开发、内部测试、生产环境测试、生产环境发布4个开发阶段的管理)
游戏服务器设计
Web服务器的设计大概可以这样去划分。那么游戏服务器和Web服务器又有什么样的不同呢?
首先,根据前面的描述,一般的Web Application,是典型的Request-Response模式,通过TCP和服务器建立短连接,而请求数据和影响数据通过HTTP协议进行组装,当完成交互的时候,服务器端和客户端TCP连接就会释放,把服务器端socket资源留给新的客户端。游戏服务器最大的特点是多数要求通信的实时性,客户端和服务器端通常采用长连接(并非绝对),客户端会主动给服务器发送数据,服务器也可能主动往客户端发送数据,生命周期比较长,一次发送的数据量比较小,但是数据交互发送比较频繁。由于要进行长连接,服务器端的socket就不能进行复用。其次,在web程序中,客户端之间的数据是没有交互的,所有的数据都是通过web服务器响应给客户端;但是网游服务器中,每个客户端的数据的变化,都要通过服务器端广播给其他客户端进行同步。所以客户端会有上限,同时服务器要进行分区,一个区里面同时在线人数会有限制。
除了这两方面不同外,其实很多Web服务器的设计方法是可以应用到游戏服务器上的,下面是我设想的一种游戏服务器设计:
关于这个设计的说明:
- 结构
- 网关服务器:负责监听和维持客户端连接,数据发送到游戏逻辑服务器,客户端和游戏服务器之间的消息转发和加密解密,没有具体游戏逻辑,可能需要设定连接数量。
- 游戏服务器:游戏进程实现,负责提供游戏逻辑,与数据库服务器通信负责数据交互。一般单进程或单线程模型可以应付,有的采用其他解决方案(比如Photon的纤程)。这里采用多个游戏服务器来模拟多个区服情况。
- 数据库服务器:专门用来处理与数据库的连接、查询、数据存盘等操作。方便游戏服务器异步读写数据库的数据。
- 管理服务器:有点像混合P2P通信里的中心节点,负责管理所有的游戏逻辑服务器以及他们之间的之间消息转发,提供广播到所有游戏服务器的功能。
- 战斗服务器:考虑到多人MMO同步操作的实时性要求,是否需要单独设计这么一个部分不是很确定。
-
数据库
目前一般是在关系型数据库mysql和非关系型数据库mongodb两者中选型。数据库写操作采用周期存盘方式,每隔固定时间存盘一次,比如10秒或者15秒,减小数据库压力。采用Memcached或者Redis分布式内存缓存方案来减少读数据库的压力。 -
通信协议
客户端与服务器之间协议通信,弱联网手游,一般采用http协议通信即可。大型MMORPG网游大多数都采用TCP协议或者HTTP和TCP结合,客户端和游戏服采用http协议。多人战斗情况下与战斗服通信采用tcp长连接。用UDP的情况主要是为了提高通信效率,需要自己做丢包重传和组装、校验的工作。服务器之间通信可以采用目前较为流行的ZeroMQ消息队列,然后也有很多优秀的开源通信库可以用来实现通信协议。 -
开发语言
业界主要的是c/c++ + python/lua模式做游戏服务器。c/c++做网络通讯数据传输,python/lua做业务逻辑。这样既保持了网络传输的效率(c++),又提升开发效率(python/lua),同时也支持热更新。 -
其他
-
protobuf:google提供的序列化和反序列化组件,将自定义类型的数据转化为二进制序列传输。优势是对于传输比较大的数据产生的数据很紧凑很小,可以明显减小传输量。而且处理速度也比较快,又有各种编程语言的实现,例如C++,Java,PHP等等。缺点是不能明文编辑(数据是二进制的)。
用protobuf rpc进行数据传输很方便,但需要自己实现。 - ZeroMQ:稳健,简洁的多进程消息队列实现方案。ZeroMQ 不一定基于 TCP 协议,它也可以用于进程间和进程内通讯。在这里它更适合服务器与服务器之间的通信,逻辑服和战斗服之间的通信。
-
memcached:高性能的分布式内存对象缓存系统,用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,不需要每次操作都访问数据库,提升性能。基于http协议的通信可以用memcached,如果是tcp长链接,就维护一个在线的内存对象。类似的技术还可以考虑redis等。
log4net/glog/zlog:日志记录组件。定义好日志级别:error / debug / fatal / info,做好时间戳。
-
protobuf:google提供的序列化和反序列化组件,将自定义类型的数据转化为二进制序列传输。优势是对于传输比较大的数据产生的数据很紧凑很小,可以明显减小传输量。而且处理速度也比较快,又有各种编程语言的实现,例如C++,Java,PHP等等。缺点是不能明文编辑(数据是二进制的)。
一些服务器框架##
最后,附上一些目前正在进行,而且应该今后较长一段时间都会在看的一些优雅而易用的服务器框架吧:
Photon:目前在Unity 3D手游方面用的最广泛的服务器框架,支持部署自己的服务器,Photon也有提供云服务器。运行于Windows平台,底层C++实现,上层采用C#作为开发语言。更多的关于Photon的内容在这里。
KBEngine(github):同样应用于Unity 3D的网游开源服务器框架,C++ + Python的模式,文档和视频教程还比较全。有一个不错的Demo可以学习。
Firefly(github)9秒社区开发的一款基于python的游戏服务器框架,刚出来不久的小鲜肉。
SkyNet: 国内的游戏开发大神云风写的一套基于Actor并发模型的服务端底层管理框架,看了一下,不得要领T_T。
Tornado:基于python的Web开发框架,被Facebook、知乎和豆瓣采用。特点是实现异步非阻塞的I/O模型。因为这个模型和Unity 3D中的协程很像,所以挺有兴趣。
可能随着以后对于服务器开发的深入实践再回头看这篇文章会发现很多幼稚和错误吧,不过偶尔思考和实现这些像模型一样的设计的东西也挺有趣的。