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

摘要: 文章介绍了Pomelo框架的设计动机与架构。pomelo在开社区才刚刚起步, 仅仅不到半年时间pomelo已经在github和各类社区上积累了强大的人气,1700多的watcher在github已经是相当不错的战绩。

InfoQ/作者:谢骋超】

一、Pomelo的定义和组成

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

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

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

下图是pomelo最初的组成图: 

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

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框架的设计动机与架构介绍

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

走向分布式开发

可以看到由于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框架来支撑。

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

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

服务器的抽象与分类

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

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

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

>负责承载客户端请求的连接

>维护session信息

>把请求转发到后端

>把后端需要广播的消息发到前端

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

>处理业务逻辑, 包括RPC和前端请求的逻辑

>把消息推送回前端

 

服务器的鸭子类型

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

服务器抽象的实现

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

以下是示例图:

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

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

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

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

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

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

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

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

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

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

上图的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社区的牛人关注。当然这还只是个开始。

 

本文系作者 infoq 授权钛媒体发表,并经钛媒体编辑,转载请注明出处、作者和本文链接
分享到:

第一时间获取TMT行业新鲜资讯和深度商业分析,请在微信公众账号中搜索「钛媒体」或者「taimeiti」,或用手机扫描左方二维码,即可获得钛媒体每日精华内容推送和最优搜索体验,并参与编辑活动。

infoq
infoq

InfoQ是一家国际性的公司,在加拿大、美国、中国和罗马尼亚均设有办公室。目前,我们运作两大品牌产品:InfoQ网站,以及QCon大会。InfoQ目前设有英文站、中文站、日文站和巴西葡文站。

评论(0

Oh! no

您是否确认要删除该条评论吗?

分享到微信朋友圈