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

Hanrea 发表于 2017-4-13 13:49:51 | 显示全部楼层 |阅读模式 [复制链接]
0 280
一、Pomelo的定义和组成
以下是Pomelo官网给出的最初定义:Pomelo是基于node.js的高性能,分布式游戏服务器框架。它包括基础的开发框架和相关的扩展组件(库和工具包),可以帮助你省去游戏开发枯燥中的重复劳动和底层逻辑的开发。
Pomelo最初的设计初衷是为了游戏服务器, 不过我们在设计、开发完成后发现pomelo是个通用的分布式实时应用开发框架。它的灵活性和可扩展性使pomelo框架有了更广阔的应用范围。 由于强大的可能伸缩性和灵活性,pomelo在很多方面甚至超越了现有的开源实时应用框架。
如果你浏览一下网易的github,会发现pomelo远远不止是一个repository, 它是由一系列松耦合的组件组合在一起的,包括了各类demo, 各类客户端,各种库和工具。

EngineBUS enginebus EngineBUS enginebus
下图是pomelo最初的组成图:
pomelo包括以下几部分:
  • 框架, 框架是pomelo最核心的部分。
  • 库,pomelo提供了很多库,有些是跟游戏逻辑完全相关的,如AIAOI寻路等;也有与游戏逻辑无关的,如定时任务执行数据同步
  • 工具,pomelo提供了管理控制台、命令行工具、压力测试工具等一系列工具。
  • 各类客户端, pomelo提供了各类平台的客户端,包括js, C, android, iOS, unity3d等,这些都可以从pomelo的官方主页查到。
  • Demo, 一个框架需要强大的demo来展示功能,pomelo提供了全平台的聊天demo和基于HTML5的捡宝Demo,系统还提供了一个强大的基于HTML5开发的强大的MMO游戏demo Lord Of Pomelo
    EngineBUS enginebus EngineBUS enginebus
而最妙的地方在于所有这些组件都是松耦合的,所有这些组件都可以独立使用。这使pomelo框架异常灵活,可 由于篇幅有限,本篇文章只讨论pomelo框架。
二、游戏服务器开发架构分析2.1 游戏服务器运行架构从单进程到多进程
最初的网络服务器是单进程的架构,所有的逻辑都在单台服务器内完成, 这对于同时在线要求不高的游戏是可以这么做的。由于同时在线人数的上升, 单服务器的可伸缩性必然受到挑战。
随着网络游戏对可伸缩性要求的增加,分布式是必然的趋势的。
游戏服务器与web应用的不同
游戏服务器的分布式架构与Web服务器是不同的, 以下是web服务器与游戏服务器架构的区别:
  • 长连接与短连接。web应用使用基于http的短连接以达到最大的可扩展性,游戏应用采用基于socket(websocket)的长连接,以达到最大的实时性。
  • 分区策略不同。web应用的分区可以根据负载均衡自由决定, 而游戏则是基于场景(area)的分区模式, 这使同场景的玩家跑在一个进程内, 以达到最少的跨进程调用。
  • 有状态和无状态。web应用是无状态的, 可以达到无限的扩展。 而游戏应用则是有状态的, 由于基于场景的分区策略,它的请求必须路由到指定的服务器, 这也使游戏达不到web应用同样的可扩展性。
  • 广播模式和request/response模式。web应用采用了基于request/response的请求响应模式。而游戏应用则更频繁地使用广播, 由于玩家在游戏里的行动要实时地通知场景中的其它玩家, 必须通过广播的模式实时发送。这也使游戏在网络通信上的要求高于web应用。
    EngineBUS enginebus EngineBUS enginebus
因此,同样是多进程架构,Web应用与游戏应用的运行架构也完全不同, 下图是通常web应用与游戏应用的不同运行架构:

EngineBUS enginebus EngineBUS enginebus
以上的游戏服务器运行架构中只是个示意图, 现在实情况比这复杂很多。
走向分布式开发
可以看到由于web服务器的无状态性,只需要通过前端的负载均衡器可以导向任意一个进程,因此运行架构相对简单, 而且很少需要分布式开发。
而游戏服务器是蜘蛛网式的架构,每个进程都有各自的职责,这些进程的交织在一起共同完成一件任务。
因此游戏服务器是一个标准的分布式开发架构。
2.2 分布式开发与难点
几乎在很多书、演讲和文章中都可以看到这样的观点: 分布式开发是很难的。 如果把所有这些难点都合起来也许有好几本书,我们今天着重看来一下游戏服务器开发的难点吧。
多进程(服务器)的管理,重量级的架构影响开发效率
通常的游戏服务器要由很多进程共同去完成任务。当这些进程交织在一起的时候,多进程的管理并不那么容易。
  • 如果没有统一的抽象与管理,光把这些开发环境的进程启动起来就是非常复杂的工作, 进程的启动与重启就将严重影响开发效率。
  • 重量级的进程消耗大量的机器资源,普通的开发机支撑不了那么多进程,可能一个人的开发环境就需要多台机器。
  • 多进程间的调试并不容易, 我们发现一个bug就要跨好几个进程。
    EngineBUS enginebus EngineBUS enginebus
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

    EngineBUS enginebus EngineBUS enginebus
如果发生接口改动,我们又需要重新修改描述文件,重新生成stub接口。对于接口不稳定的开发环境, 这种方式对开发效率影响较大。
要想让rpc调用的开发达到最简,不需生成stub接口, 无需描述文件, 我们需要一种很巧妙的方法。
分布式事务、异步化操作
尽管我们尽量把逻辑放在一个进程里处理,但分布式事务仍然是不可避免的。两阶段提交的代码,异步化的操作在普通的开发语言里并不是容易的事。
但我们会发现用了node.js之后,它的编程模式里天生就是这种模式, 两阶段提交、异步化操作这些看似复杂的工作里在node.js只是一个正常的异步执行流程。
负载均衡,高可用
由于游戏服务器的有状态性,很多请求需要通过特定的路由规则导到某台服务器;对于有些无状态的服务器,我们则可以把请求路由到负载最低的服务器。
通常对于无状态的服务器, 高可用是比较好做的。对于有状态的服务器,要做高可用会非常困难, 但也不是完全没有办法,常见的两招:
  • 将状态引出到外存,例如redis, 这样进程本身就可以无状态了。但由于所有的操作都通过redis可能带来性能损耗,有些场景是不能应会这些损耗的。
  • 通过进程互备, 将状态通过日志等方式同步到另一进程, 但这可能存在着瞬间数据丢失的问题,这种数据丢失在一些应用场景可能毫无问题, 但在另外一些应用场景可能引起严重的数据不一致。
    EngineBUS enginebus EngineBUS enginebus
有状态的高可用并不是那么好实现的,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, 可实现最大限度的代码共用。
    EngineBUS enginebus EngineBUS enginebus
三、pomelo架构分析
pomelo框架在最初设计的时候只为了一个目标:为基于长连接的分布式游戏服务器架构提供基础设施。框架的内容在逐渐扩展,但最核心的框架只为了干以下三件事:
  • 服务器(进程)的抽象与扩展
    EngineBUS enginebus EngineBUS enginebus
在web应用中, 每个服务器是无状态、对等的, 开发者无需通过框架或容器来管理服务器。 但游戏应用不同, 游戏可能需要包含多种不同类型的服务器,每类服务器在数量上也可能有不同的需求。这就需要框架对服务器进行抽象和解耦,支持服务器类型和数量上的扩展。
  • 客户端的请求、响应、广播
    EngineBUS enginebus EngineBUS enginebus
客户端的请求、响应与web应用是类似的, 但框架是基于长连接的, 实现模式与http请求有一定差别。 广播是游戏服务器最频繁的操作, 需要方便的API, 并且在性能上达到极致。
  • 服务器间的通讯、调用
    EngineBUS enginebus EngineBUS enginebus
尽管框架尽量避免跨进程调用,但进程间的通讯是不可避免的, 因此需要一个方便好用的RPC框架来支撑。
下面分别对这三个目标进行详细的分析:
服务器(进程)的抽象与扩展介绍服务器的抽象与分类
该架构把游戏服务器做了抽象, 抽象成为两类:前端服务器和后端服务器, 如图:
前端服务器(frontend)的职责:
  • 负责承载客户端请求的连接
  • 维护session信息
  • 把请求转发到后端
  • 把后端需要广播的消息发到前端
    EngineBUS enginebus EngineBUS enginebus
后端服务器(backend)的职责:
  • 处理业务逻辑, 包括RPC和前端请求的逻辑
  • 把消息推送回前端
    EngineBUS enginebus EngineBUS enginebus
服务器的鸭子类型
动态语言的面向对象有个基本概念叫鸭子类型 服务器的抽象也同样可以比喻为鸭子, 服务器的对外接口只有两类, 一类是接收客户端的请求, 叫做handler, 一类是接收RPC请求, 叫做remote, handler和remote的行为决定了服务器长什么样子。 因此我们只要定义好handler和remote两类的行为, 就可以确定这个服务器的类型。
服务器抽象的实现
利用目录结构与服务器对应的形式, 可以快速实现服务器的抽象。
以下是示例图:
图中的connector, connector, gate三个目录代表三类服务器类型, 每个目录下的handler与remote决定了这个服务器的行为(对外接口)。 开发者只要往handler与remote目录填代码, 就可以实现某一类的服务器。这让服务器实现起来非常方便。 让服务器动起来, 只要填一份配置文件servers.json就可以让服务器快速动起来。 配置文件和对应的进行架构如下所示:
客户端请求与响应、广播的抽象介绍
所有的web应用框架都实现了请求与响应的抽象。尽管游戏应用是基于长连接的, 但请求与响应的抽象跟web应用很类似。 下图的代码是一个request请求示例:
请求的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最关注的是开发效率
    EngineBUS enginebus EngineBUS enginebus
但是我们的问题是:
  • 现在的实时应用有多少是只面向web端的?
  • 规模稍大的实时应用,瓶颈是在可伸缩性、性能还是在开发效率?
    EngineBUS enginebus EngineBUS enginebus
我们给出的答案是:
  • 同时支持移动端、web端、PC端的实时应用已经是主流
  • 相比开发效率,可伸缩性、性能是规模较大的实时应用更有可能出现的瓶颈
    EngineBUS enginebus EngineBUS enginebus
而pomelo在这两方面具有明显的优势:
  • pomelo支持动态connector协议机制,使它同时支持web、移动、PC、untiy3d等各类客户端。开发无缝衍接各类客户端的高时应用在pomelo里面只是个配置问题
  • pomelo在可伸缩性和扩展上具有很强的优势,这也是pomelo设计的最根本目标
    EngineBUS enginebus EngineBUS enginebus
以上的比较并不说明pomelo比meteor优秀, 它们是完全定位不同的两个实时应用框架。相信用户会根据自己的需求做出选择。
五、未来与展望
pomelo在开社区才刚刚起步, 仅仅不到半年时间pomelo已经在github和各类社区上积累了强大的人气,1700多的watcher在github已经是相当不错的战绩。但这仅仅只是个起步,pomelo的真正的暴发期还未到来。
pomelo将会在分布式开发方面下更大的功夫,在加强高可用、负载均衡、过载保护、运维机制等方面做得更好.

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

EngineBUS enginebus EngineBUS enginebus
EngineBUS enginebus EngineBUS enginebus
您需要登录后才可以回帖 登录 | Sign Up

本版积分规则

推荐阅读

QQ| Archiver|手机版|小黑屋| 引擎巴士 EngineBUS  

Powered by Discuz! X3.2© 2001-2013 Comsenz Inc.  

返回顶部 返回列表