首页 ›存档› 技术 › 查看内容

游戏服务器框架简述

2018-3-30 13:00 |来自: 互联网 438 0

摘要: 框架目前游戏类型千差万别(卡牌，arpg，mmo，moba等)，每种类型游戏设计的侧重点不相同导致框架上的差异，不过即使相同类型游戏，不同设计师实现的框架也不经相同。这里我们不会针对各种纷杂的框架一一介绍，本着 ...

目前游戏类型千差万别(卡牌，arpg，mmo，moba等)，每种类型游戏设计的侧重点不相同导致框架上的差异，不过即使相同类型游戏，不同设计师实现的框架也不经相同。这里我们不会针对各种纷杂的框架一一介绍，本着求同存异的态度，只是从分层架构设计的角度来阐述这些零零种种框架的本质。

依据业务上的差异，基本上可以把游戏服务器框架映射到一个四层架构模型上，如图：

Gateway Service

负责客户端网络接入，收敛网络入口。gateway的业务逻辑相对比较简单，主要处理网路消息的转化（客户端发送到后端服务器，后端服务器发送到客户端）与过滤。从它负责的业务角度上可以看出一个好的gateway service其实就是一个高性能的网络服务。针对高性能网络服务的实现有很多方式，常见模型有：

在我们游戏里面使用的方案是基于linux系统下的多线程模型。具体的实现是，one loop per thread，loop是基于反应器的设计模式实现。系统层面也会做相应的优化，比如cpu绑定，网卡的硬中断，软中断的优化。在这些完成之后，一个高性能的网络服务器基本上就成型了。在我们实际运行过程，单Gateway最高同时在线达到15w，机器整体的负载也不高。

Logic Service

游戏逻辑主要在这个服务上处理。常见的实现，多IO线程加单独的业务线程。线程之间通过消息队列进行通信，消息队列简单可以用一个加锁的队列实现，也可以选择无锁队列（建议使用成熟的开源方案）。网络消息汇总到同一个线程中处理，也就是说游戏业务处理是单线程的，这种设计的优势在于避免业务开发中数据竞争。如果单线程实在不能满足性能要求，比如一些mmo游戏中，可以采用多进程的模式，也就是有多个logic service，配合可能也需要一些协调logic service的服务。

Record Service

数据库的代理层，负责与数据库交互，解耦业务层的数据处理，适应数据库的改变，业务逻辑也相对简单。实现类似于Logic Service，它也可以合并到logic service里，但是独立开来，整体框架更加清晰。

Database

顾名思义，保存玩家数据的地方。常见的游戏数据库包括: mysql，redis，mongodb等。我们游戏数据库选择是RedisLV，它解决了redis备份时候可能导致内存使用过高的问题。它使用的方法是为redis引入基于leveldb的数据落地方案。leveldb是google开源的kv数据库，使用lsm tree算法，数据写入的性能比较高。修改redis的源码，在redis中与写入操作相关的命令处理中，将改变同时写入leveldb，数据库的备份只针对leveldb做备份。