深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍

一、Pomelo 的定义和组成

以下是 Pomelo 官网给出的最初定义:Pomelo 是基于 node.js 的高性能, 分布式游戏服务器框架。它包括基础的开发框架和相关的扩展组件(库和工具包),可以帮助你省去游戏开发枯燥中的重复劳动和底层逻辑的开发。

Pomelo 最初的设计初衷是为了游戏服务器, 不过我们在设计、开发完成后发现 pomelo 是个通用的分布式实时应用开发框架。它的灵活性和可扩展性使 pomelo 框架有了更广阔的应用范围。 由于强大的可能伸缩性和灵活性,pomelo 在很多方面甚至超越了现有的开源实时应用框架。

如果你浏览一下网易的github ,会发现pomelo 远远不止是一个repository, 它是由一系列松耦合的组件组合在一起的,包括了各类demo, 各类客户端,各种库和工具。

下图是pomelo 最初的组成图:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第1张图片

pomelo 包括以下几部分:

  • 框架, 框架是 pomelo 最核心的部分。
  • 库,pomelo 提供了很多库,有些是跟游戏逻辑完全相关的,如 AI , AOI ,寻路等;也有与游戏逻辑无关的,如定时任务执行, 数据同步。
  • 工具,pomelo 提供了管理控制台、命令行工具、压力测试工具等一系列工具。
  • 各类客户端, pomelo 提供了各类平台的客户端,包括 js, C, android, iOS, unity3d 等,这些都可以从 pomelo 的官方主页查到。
  • Demo, 一个框架需要强大的 demo 来展示功能,pomelo 提供了全平台的聊天 demo 和基于HTML5 的捡宝Demo ,系统还提供了一个强大的基于HTML5 开发的强大的MMO 游戏demo Lord Of Pomelo 。

而最妙的地方在于所有这些组件都是松耦合的,所有这些组件都可以独立使用。这使 pomelo 框架异常灵活,可 由于篇幅有限,本篇文章只讨论 pomelo 框架。

二、游戏服务器开发架构分析

2.1 游戏服务器运行架构

从单进程到多进程

最初的网络服务器是单进程的架构,所有的逻辑都在单台服务器内完成, 这对于同时在线要求不高的游戏是可以这么做的。由于同时在线人数的上升, 单服务器的可伸缩性必然受到挑战。

随着网络游戏对可伸缩性要求的增加,分布式是必然的趋势的。

游戏服务器与 web 应用的不同

游戏服务器的分布式架构与 Web 服务器是不同的, 以下是 web 服务器与游戏服务器架构的区别:

  • 长连接与短连接。web 应用使用基于 http 的短连接以达到最大的可扩展性,游戏应用采用基于 socket(websocket) 的长连接,以达到最大的实时性。
  • 分区策略不同。web 应用的分区可以根据负载均衡自由决定, 而游戏则是基于场景 (area) 的分区模式, 这使同场景的玩家跑在一个进程内, 以达到最少的跨进程调用。
  • 有状态和无状态。web 应用是无状态的, 可以达到无限的扩展。 而游戏应用则是有状态的, 由于基于场景的分区策略,它的请求必须路由到指定的服务器, 这也使游戏达不到 web 应用同样的可扩展性。
  • 广播模式和 request/response 模式。web 应用采用了基于 request/response 的请求响应模式。而游戏应用则更频繁地使用广播, 由于玩家在游戏里的行动要实时地通知场景中的其它玩家, 必须通过广播的模式实时发送。这也使游戏在网络通信上的要求高于 web 应用。

因此,同样是多进程架构,Web 应用与游戏应用的运行架构也完全不同, 下图是通常 web 应用与游戏应用的不同运行架构:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第2张图片

以上的游戏服务器运行架构中只是个示意图, 现在实情况比这复杂很多。

走向分布式开发

可以看到由于 web 服务器的无状态性,只需要通过前端的负载均衡器可以导向任意一个进程,因此运行架构相对简单, 而且很少需要分布式开发。

而游戏服务器是蜘蛛网式的架构,每个进程都有各自的职责,这些进程的交织在一起共同完成一件任务。

因此游戏服务器是一个标准的分布式开发架构。

2.2 分布式开发与难点

几乎在很多书、演讲和文章中都可以看到这样的观点: 分布式开发是很难的。 如果把所有这些难点都合起来也许有好几本书,我们今天着重看来一下游戏服务器开发的难点吧。

多进程(服务器)的管理,重量级的架构影响开发效率

通常的游戏服务器要由很多进程共同去完成任务。当这些进程交织在一起的时候,多进程的管理并不那么容易。

  • 如果没有统一的抽象与管理,光把这些开发环境的进程启动起来就是非常复杂的工作, 进程的启动与重启就将严重影响开发效率。
  • 重量级的进程消耗大量的机器资源,普通的开发机支撑不了那么多进程,可能一个人的开发环境就需要多台机器。
  • 多进程间的调试并不容易, 我们发现一个 bug 就要跨好几个进程。

rpc 调用

rpc 调用的解决方案已经有 n 多年的历史了,但 rpc 在分布式开发效率上仍然没有明显提升。

以当前最流行的开发框架 thrift 为例,它在调用代码前需要经过以下步骤:

  • Writing a .thrift file

  • Generate Thrift file to source code

    thrift --gen (language) (Thrift filename)

  • Copy the source to application

如果发生接口改动,我们又需要重新修改描述文件,重新生成 stub 接口。对于接口不稳定的开发环境, 这种方式对开发效率影响较大。

要想让 rpc 调用的开发达到最简,不需生成 stub 接口, 无需描述文件, 我们需要一种很巧妙的方法。

分布式事务、异步化操作

尽管我们尽量把逻辑放在一个进程里处理,但分布式事务仍然是不可避免的。两阶段提交的代码,异步化的操作在普通的开发语言里并不是容易的事。

但我们会发现用了 node.js 之后,它的编程模式里天生就是这种模式, 两阶段提交、异步化操作这些看似复杂的工作里在 node.js 只是一个正常的异步执行流程。

负载均衡,高可用

由于游戏服务器的有状态性,很多请求需要通过特定的路由规则导到某台服务器;对于有些无状态的服务器,我们则可以把请求路由到负载最低的服务器。

通常对于无状态的服务器, 高可用是比较好做的。对于有状态的服务器,要做高可用会非常困难, 但也不是完全没有办法,常见的两招:

  • 将状态引出到外存,例如 redis, 这样进程本身就可以无状态了。但由于所有的操作都通过 redis 可能带来性能损耗,有些场景是不能应会这些损耗的。
  • 通过进程互备, 将状态通过日志等方式同步到另一进程, 但这可能存在着瞬间数据丢失的问题,这种数据丢失在一些应用场景可能毫无问题, 但在另外一些应用场景可能引起严重的数据不一致。

有状态的高可用并不是那么好实现的,pomelo 将在 0.5 版本提供高可用的实现机制,引入 zookeeper 和 redis 可以解决一些进程(如 master)的高可用问题,但真正复杂的应用场景的逻辑只能由应用自己处理。

2.3 Node.js 的引入

为什么会在这里谈 node.js 的引入? 因为在讲了这么多分布式开发的难点之后,引入 node.js 实在是太自然了。它解决了分布式开发的很多问题。

  • 天生的分布式, node.js 之所以叫 node 就是因为它天生就是做多进程开发的, 多个节点 (node) 互相通讯交织在一起组成的分布式系统是 node 天生就应该这么干的。例如前面提到的分布式事务、异步化操作在 node.js 里只是个正常的流程。
  • 网络 io 与可伸缩性的优势。游戏是非常 io 密集型的应用, 采用 node.js 是最合适的, 可达到最好的可伸缩性。
  • 轻量级, 轻量级的进程带来的开发效率的优势在开发的时候异常明显。
  • 语言优势。使用 javascript 开发可以实现快速迭代,客户端 html 5 使用 javascript,甚至在 unity3d,cocos2d-x 这样的游戏平台上也可以使用 javascript, 可实现最大限度的代码共用。

三、pomelo 架构分析

pomelo 框架在最初设计的时候只为了一个目标:为基于长连接的分布式游戏服务器架构提供基础设施。框架的内容在逐渐扩展,但最核心的框架只为了干以下三件事:

  • 服务器(进程)的抽象与扩展

在 web 应用中, 每个服务器是无状态、对等的, 开发者无需通过框架或容器来管理服务器。 但游戏应用不同, 游戏可能需要包含多种不同类型的服务器,每类服务器在数量上也可能有不同的需求。这就需要框架对服务器进行抽象和解耦,支持服务器类型和数量上的扩展。

  • 客户端的请求、响应、广播

客户端的请求、响应与 web 应用是类似的, 但框架是基于长连接的, 实现模式与 http 请求有一定差别。 广播是游戏服务器最频繁的操作, 需要方便的 API, 并且在性能上达到极致。

  • 服务器间的通讯、调用

尽管框架尽量避免跨进程调用,但进程间的通讯是不可避免的, 因此需要一个方便好用的 RPC 框架来支撑。

下面分别对这三个目标进行详细的分析:

服务器(进程)的抽象与扩展介绍

服务器的抽象与分类

该架构把游戏服务器做了抽象, 抽象成为两类:前端服务器和后端服务器, 如图:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第3张图片

前端服务器 (frontend) 的职责:

  • 负责承载客户端请求的连接
  • 维护 session 信息
  • 把请求转发到后端
  • 把后端需要广播的消息发到前端

后端服务器 (backend) 的职责:

  • 处理业务逻辑, 包括 RPC 和前端请求的逻辑
  • 把消息推送回前端

服务器的鸭子类型

动态语言的面向对象有个基本概念叫鸭子类型 服务器的抽象也同样可以比喻为鸭子, 服务器的对外接口只有两类, 一类是接收客户端的请求, 叫做 handler, 一类是接收 RPC 请求, 叫做 remote, handler 和 remote 的行为决定了服务器长什么样子。 因此我们只要定义好 handler 和 remote 两类的行为, 就可以确定这个服务器的类型。

服务器抽象的实现

利用目录结构与服务器对应的形式, 可以快速实现服务器的抽象。

以下是示例图:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第4张图片

图中的 connector, connector, gate 三个目录代表三类服务器类型, 每个目录下的 handler 与 remote 决定了这个服务器的行为(对外接口)。 开发者只要往 handler 与 remote 目录填代码, 就可以实现某一类的服务器。这让服务器实现起来非常方便。 让服务器动起来, 只要填一份配置文件 servers.json 就可以让服务器快速动起来。 配置文件和对应的进行架构如下所示:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第5张图片

客户端请求与响应、广播的抽象介绍

所有的 web 应用框架都实现了请求与响应的抽象。尽管游戏应用是基于长连接的, 但请求与响应的抽象跟 web 应用很类似。 下图的代码是一个 request 请求示例:

深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍_第6张图片

请求的 api 与 web 应用的 ajax 请求很象,基于 Convention over configuration 的原则, 请求不需要任何配置。 如下图所示,请求的 route 字符串:chat.chatHandler.send, 它可以将请求分发到 chat 服务器上 chatHandler 文件定义的 send 方法。

Pomelo 的框架里还实现了 request 的 filter 机制,广播 / 组播机制,详细介绍见 pomelo 框架参考。

服务器间 RPC 调用的抽象介绍

架构中各服务器之间的通讯主要是通过底层 RPC 框架来完成的,该 RPC 框架主要解决了进程间消息的路由和 RPC 底层通讯协议的选择两个问题。 服务器间的 RPC 调用也实现了零配置。实例如下图所示:

 

上图的 remote 目录里定义了一个 RPC 接口: chatRemote.js,它的接口定义如下:

复制代码

 
   
 

chatRemote.kick = function(uid, player, cb) {

 

}

其它服务器(RPC 客户端)只要通过以下接口就可以实现 RPC 调用:

复制代码

 
   
 

app.rpc.chat.chatRemote.kick(session, uid, player, function(data){

 

});

这个调用会根据特定的路由规则转发到特定的服务器。(如场景服务的请求会根据玩家在哪个场景直接转发到对应的 server)。

rpc 的使用远比其它 rpc 框架简单好多,因为我们无需写任何配置文件,也无需生成 stub。因为我们服务器抽象的实现的方式,使得 rpc 客户端可以在应用启动时扫描服务器目录自动生成 stub 对象。

完成了以上三个目标, 一个实时的分布式应用框架的轮廓就搭出来了,剩下的工作是往上添肉,这是我们后续文章里的内容。

四、从游戏框架到实时应用框架

当我们分析完 pomelo 框架的设计目标时, 我们发现核心框架的这件事情竟然与游戏没有任何关系。这是一个通用的实时分布式应用开发框架。官网上的聊天服务器 demo 就是一个实时应用。

事实上 pomelo 已经被应用在很多非游戏领域。 网易的消息推送平台是基于 pomelo 开发的,它承担了网易移动端和 web 端的消息推送, 目前已经上线使用。

整个开源社区没有与 pomelo 定位相同的实时应用框架。目前在开源社区最流行的实时应用框架当数 meteor,它与 pomelo 有着截然不同的设计目标。我们来比较一下这两个框架的区别。

以下是 meteor 给出的定义:

Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you’re an expert developer or just getting started.

可以用以下两点概括:

  • meteor 是只能面向 web 的实时应用
  • meteor 最关注的是开发效率

但是我们的问题是:

  • 现在的实时应用有多少是只面向 web 端的?
  • 规模稍大的实时应用,瓶颈是在可伸缩性、性能还是在开发效率?

我们给出的答案是:

  • 同时支持移动端、web 端、PC 端的实时应用已经是主流
  • 相比开发效率,可伸缩性、性能是规模较大的实时应用更有可能出现的瓶颈

而 pomelo 在这两方面具有明显的优势:

  • pomelo 支持动态 connector 协议机制,使它同时支持 web、移动、PC、untiy3d 等各类客户端。开发无缝衍接各类客户端的高时应用在 pomelo 里面只是个配置问题
  • pomelo 在可伸缩性和扩展上具有很强的优势,这也是 pomelo 设计的最根本目标

以上的比较并不说明 pomelo 比 meteor 优秀, 它们是完全定位不同的两个实时应用框架。相信用户会根据自己的需求做出选择。

五、未来与展望

pomelo 在开社区才刚刚起步, 仅仅不到半年时间 pomelo 已经在 github 和各类社区上积累了强大的人气,1700 多的 watcher 在 github 已经是相当不错的战绩。但这仅仅只是个起步,pomelo 的真正的暴发期还未到来。

pomelo 将会在分布式开发方面下更大的功夫,在加强高可用、负载均衡、过载保护、运维机制等方面做得更好.

pomelo 也逐渐在世界的开源社区推广。LXJS 2013 的组织者邀请了笔者于 2013 年 10 月去葡萄牙里斯本做英文演讲,可见 pomelo 已经逐渐受到了国际 node 社区的牛人关注。当然这还只是个开始。

你可能感兴趣的:(网游)