游戏服务器框架简述

最新推荐文章于 2024-05-15 05:30:22 发布

huangshulang1234

最新推荐文章于 2024-05-15 05:30:22 发布

阅读量2.1k

点赞数

分类专栏：架构文摘文章标签：服务器框架游戏

341 篇文章 1 订阅

订阅专栏

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

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

Gateway Service

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

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

- 多线程模型，如果对网络编程不熟悉，可以选择开源实现，比如muduo， asio，netty等。
- 纤程，这一类的开源实现也有很多，语言级别的golang，erlang，单独库形式的libco，skynet。

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做备份。

这一节主要针对Logic Service，也就是游戏核心业务的驱动。游戏的业务主要是响应外部请求和处理内部状态改变，包括以下两种驱动方式：

实现这两种驱动之后，游戏服务器可以响应外部和内部的改变，基本上服务就可以正常的运转。游戏业务与其他所有后端业务都一样，本身就是数据结构的组织。下面介绍一些常用的设计模式和算法帮助游戏业务的实现。

来源：http://mmogamecoder.com

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-

关注

专栏目录