深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍
深入浅出node.js游戏服务器开发——Pomelo框架的设计动机与架构介绍
文章介绍了Pomelo框架的设计动机与架构。pomelo在开社区才刚刚起步， 仅仅不到半年时间pomelo已经在github和各类社区上积累了强大的人气，1700多的watcher在github已经是相当不错的战绩。
【/作者：谢骋超】
一、Pomelo的定义和组成
以下是Pomelo官网给出的最初定义：Pomelo是基于node.js的高性能,分布式游戏服务器框架。它包括基础的开发框架和相关的扩展组件（库和工具包），可以帮助你省去游戏开发枯燥中的重复劳动和底层逻辑的开发。
Pomelo最初的设计初衷是为了游戏服务器， 不过我们在设计、开发完成后发现pomelo是个通用的分布式实时应用开发框架。它的灵活性和可扩展性使pomelo框架有了更广阔的应用范围。 由于强大的可能伸缩性和灵活性，pomelo在很多方面甚至超越了现有的开源实时应用框架。
如果你浏览一下，会发现pomelo远远不止是一个repository， 它是由一系列松耦合的组件组合在一起的，包括了各类demo， 各类客户端，各种库和工具。
下图是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应用与游戏应用的不同运行架构：
以上的游戏服务器运行架构中只是个示意图， 现在实情况比这复杂很多。
走向分布式开发
可以看到由于web服务器的无状态性，只需要通过前端的负载均衡器可以导向任意一个进程，因此运行架构相对简单， 而且很少需要分布式开发。
而游戏服务器是蜘蛛网式的架构，每个进程都有各自的职责，这些进程的交织在一起共同完成一件任务。
因此游戏服务器是一个标准的分布式开发架构。
2.2 分布式开发与难点
几乎在很多书、演讲和文章中都可以看到这样的观点： 分布式开发是很难的。 如果把所有这些难点都合起来也许有好几本书，我们今天着重看来一下游戏服务器开发的难点吧。
多进程（服务器）的管理，重量级的架构影响开发效率
通常的游戏服务器要由很多进程共同去完成任务。当这些进程交织在一起的时候，多进程的管理并不那么容易。
如果没有统一的抽象与管理，光把这些开发环境的进程启动起来就是非常复杂的工作， 进程的启动与重启就将严重影响开发效率。
重量级的进程消耗大量的机器资源，普通的开发机支撑不了那么多进程，可能一个人的开发环境就需要多台机器。
多进程间的调试并不容易， 我们发现一个bug就要跨好几个进程。
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请求示例：
请求的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社区的牛人关注。当然这还只是个开始。
（关注更多作者观点，参与钛媒体微信互动（微信搜索“钛媒体”或“taimeiti”））
（本文系作者@ 授权钛媒体发表，并经钛媒体编辑，转载请注明出处和)
第一时间获取TMT行业新鲜资讯和深度商业分析，请在微信公众账号中搜索「钛媒体」或者「taimeiti」，或用手机扫描左方二维码，即可获得钛媒体每日精华内容推送和最优搜索体验，并参与编辑活动。
infoq 的更多文章
扫描下方二维码或者搜索二维码下方的微信公众号，随时随地获取最新鲜的TMT资讯您所在的位置： &
3.6.3　桌面应用中的JavaScript
3.6.3　桌面应用中的JavaScript
机械工业出版社
《HTML5游戏开发实践指南》第3章JavaScript概述，本章介绍JavaScript基础，以及一些对创建游戏有用的工具和库，并使用JavaScript库创建第一个游戏。本节为大家介绍桌面应用中的JavaScript。
3.6.3　桌面应用中的JavaScript
自从Mozilla Firefox的Web浏览器发布之后，JavaScript桌面应用程序正逐渐成为主流应用。开发人员现在已经开辟了浏览器的应用空间，他们正在打算开发面向桌面的相关应用程序。本节将介绍一些值得注意的来自高层的框架。
XULRunner（）是由Mozilla创建的运行时环境，其为Firefox的Web浏览器和许多Mozilla发布的多个应用程序提供了有力支持。这其中包括Mozilla Sunbird（日历/行程表）、Mozilla Thunderbird（电子邮件）等。XULRunner使用一些C++代码来运行JavaScript引擎SpiderMonkey，但是所有与用户的交互管理均由JavaScript完成。还有一种名为XPI的插件格式，其允许开发人员使用JavaScript和资源来扩展应用程序。XUL和XBL（分别是XML User Interface Language，XML用户界面语言，和XML Binding Language，XML绑定语言）用于设置应用程序布局、界面和交互方式，二者完善了XULRunner的核心特性。一些其他的公司和开源项目将XULRunner打包到跨平台应用程序中。其中，一些流行的应用程序包括互联网电视应用程序Miro、媒体库管理应用程序Songbird（其竞争对手是iTunes）等。
GLUEscript（）是一个桌面应用框架，它是wxWidgets针对JavaScript的一项革命。wxWidgets是一个基于C++的跨平台桌面应用框架，其支持绑定多种不同编程语言。因此，开发人员只要学会使用一种编程语言调用wxWidgets应用程序，那么就能够在其他语言中使用wxWidgets，而降低了学习曲线。GLUEscript使用Mozilla的SpiderMonkey引擎作为JavaScript层。在该层之上，所有用户界面代码和逻辑均可使用纯JavaScript。
XULJet（）是一个运行在XULRunner之上的桌面应用框架。虽然在后端代码调用的是XUL，但是开发人员可使用特定的基于XUL的语言。这样，开发人员所编写的将是UI代码和逻辑代码的混合代码。这种方式是否是最合适的方法，因为与之相对的，拥有清晰分层的MVC（Model-View-Controller）架构，但已经超出了本书涉及的范围。然而，这种方式实现了更为简洁和易读的用户界面代码。代码清单3-18和代码清单3-19实现了功能相同的XUL代码和XULJet DSL代码。
代码清单3-18　XUL代码
代码清单3-19　XULJet DSL代码
【责任编辑： TEL：（010）】&&&&&&
关于&&的更多文章
这本书是写给程序员和项目经理的。作者结合自身的丰富成长历程，
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
产品经理发展到一定阶段，再要成长，光靠学习一些知识
本教材以面向应用型人才培养为目标；以非传统的组织结
高效管理SQL Server的提示、技巧和解决方案
本书依据最新版《网络工程师考试大纲》的考核要求，深入研究了历年网络工程师考试试题的命题风格和试题结构，对考查的知识点进行
51CTO旗下网站您现在的位置： &
深入浅出node.js游戏服务器开发――基于Pomelo的MMO RPG开发
深入浅出node.js游戏服务器开发――基于Pomelo的MMO RPG开发
　　在上一篇文章中，我们介绍了如何使用Pomelo来搭建聊天服务器。在这篇文章中，我们为大家介绍如何使用Pomelo框架来搭建MMO RPG服务器，并分析其设计思路和实现方法。以此来帮助大家更好的理解和使用Pomelo框架，理解Pomelo框架游戏开发的基础流程，使用方法和设计理念。　　本文中的游戏服务端架构，只是为了说明Pomelo的开发理念和设计思路，并不是基于Pomelo开发的唯一方案，开发者完全可以根据自己的实际应用环境设计不同的服务端架构。开始之前Pomelo框架与MMO RPG　　我们曾在本系列第一篇文章曾介绍过pomelo的架构。我们先简单回顾一下Pomelo为我们的游戏开发提供了什么：　　可扩展的服务器架构。Pomelo中对服务器端进行了抽象，将服务器分为承载链连接的前端服务器和负责业务逻辑的后端服务器，并提供了便利，高效的分布式扩展支持，让使用者可以在少改甚至不改的前提下实现对服务端的扩展。　　完整的通信框架：Pomelo对客户端与服务器之间，服务器与服务器之间的通信进行了完整的封装。开发者只需要按照默认规则来填写服务代码就可以完成接口的发布和调用，而不用考虑内部实现。　　大量游戏开发基础库：除了基本的服务器框架之外，Pomelo还提供了很多游戏开发需要用到的基础库，如任务调度，AI控制，寻路等，而这些库还会随着Pomelo的发展进一步完善。　　基于Node.JS轻量级的开发环境，以及大量的模块。相对于传统的开发语言，Node.JS有着轻量，快捷的特性（0.3版中启动一个包括10几个服务器集成的服务端只需要不到4S）。而活跃的开源社区也提供了大量的第三方模块。　　作为Pomelo游戏开发的入门导引，本文的重点将放在游戏基础架构的搭建上，因此本文将主要介绍下面三个方面的内容：游戏服务端的构建，与客户端的通讯，服务器的扩展。本文的参考示例　　我们使用demo Treasures作为本文的参考示例，游戏的截图如下：　　　　从上图可以看出，在treasures中，玩家会进入一张遍布宝物的地图中，通过拾取宝物来获得积分。所有玩家的积分在右上角会有一个排名。下面是这个demo的关键点：　　每个玩家的行动对其他玩家来看都是实时的。　　在获取宝物时积分会更新积分榜，这个更新对所有玩家实时可见。　　宝物会定时刷新。　　相对于一般的的MMO RPG，这个demo显得十分简陋：没有持久化，没有战斗，没有AI。。。但是，其中实现了MMO RPG中最核心的亮点功能：一个可以容纳多个在线玩家的游戏场景，以及玩家之间的实时互动。那些功能的确实可以让系统的结构更加清晰明确，成为一个非常好的项目导引。搭建游戏服务端　　由于游戏逻辑十分简单，我们后端采用一台单独的场景服务器来运行整个游戏逻辑，同时加入一台连接服务器来承载用户连接，系统的设计如下：　　　　下面，我们就按照这个设计来搭建游戏服务端。编写场景服务　　游戏场景是玩家所处的虚拟环境，而场景服务器就是游戏场景在服务端的抽象，根据游戏类型和内容的不同，场景服务器的复杂程度也会千差万别。在我们的例子中，场景的构成十分简单：一张开放的游戏地图，地图中的玩家，以及定时刷新的宝物。　　首先，作为一个场景服务器，需要能够储存用户和宝物的信息，这里我们直接使用一个放在内存中的map来储存场景中的所有实体，同时，我们将所有场景中的实体都抽象为一个Entity对象，放在这个map中。　　为了能够操纵这些数据，还需要暴露出对外接口，我们使用的接口有下面三种：　　初始化的接口:我们在init方法中会设置场景信息，配置参数等,并启动场景中的时钟循环。　　实体访问接口：如AddEntity和RemoveEntity接口等，我们使用这些接口来访问和修改场景中的实体。　　刷新场景中的宝物：当满足条件时，外部事件会调用该接口来刷新地图中的宝物。　　我们通过一个无限循环的tick来驱动场景服务，在每一个tick中会更新场景中所有实体的状态信息，我们最终设计如下：　　搭建场景服务器　　在完成场景服务的代码之后，我们还需要提供一个场景服务运行的平台，在Pomelo中，我们通过搭建一个场景服务器来实现。　　Pomelo中的服务器分为两类，负责承载用户连接的前端服务器和运行逻辑的后端服务器。作为负责核心逻辑的场景服务器，自然是属于后端服务器，因此，我们在/game-sever/config/server.json中加入以下配置：　　&area&: [ & & & {&id&: &area-server-1&, &host&: &127.0.0.1&, &port&: 3250, &areaId&: 1} & & ] 　　其中的“area”是我们为场景服务器类型所起的名称，其对应的内容就是场景服务器的列表，可以看出，现在我们只加入了单台场景服务器。与聊天服务器相比，场景服务器的配置并没有明显区别，只是多了一个areaId的属性。我们使用这一属性来标明这个场景服务器对应的场景id，我们的建议设计是一个游戏服务器对应一个独立的游戏场景，这样可以大大减少场景管理的开销，并提高单场景的负载能力。Pomelo中每一个服务器就是一个独立的进程，相对于一个场景服务的开销，单独的服务器造成的开销是可以接受的。当然，这只是建议设计，框架本身完全支持一个游戏服务器对应多个游戏场景的设计。开发者可以根据具体的应用情况调整场景服务器的配置，通过加入场景管理逻辑，实现一个场景服务器和场景之间的自由配置。启动场景服务　　在加入场景服务器之后，我们还需要对服务端的运行环境进行配置，在场景服务器启动时运行对应的场景服务。为了实现这一目标，我们需要在app.js中加入如下配置：　　nfigure('production|development', 'area', function(){ & & & var areaId = app.get('curServer').areaId; & & & area.init(dataApi.area.findById(areaId)); & & }); 　　nfigure方法用来对指定的服务器进行配置，包括三个参数，前两个参数分别是运行环境和服务器类型的filter，第三个参数是在满足前面两个filter的情况下需要运行的代码。在上面的配置中，第一个参数&production|development&表示是针对线上和开发两种环境，之后的‘area’参数表示的是针对area服务器类型。 关于app.js初始化的更多内容，见Pomelo启动流程。与客户端通讯建立连接服务器　　要与客户端通信，我们需要建立一个前端服务器，用来维护与客户端之间的连接。server.json中的配置如下:　　&connector&: [ & & & {&id&: &connector-server-1&, &host&: &127.0.0.1&, &port&: 3150, &clientPort&: 3010, &frontend&: true} & & ] &其中的标志位“frontend：true”表示这是一个前端服务器，“clientPort：3010”则表示该服务器对外暴露前端。对于前端服务器，在启动时就会默认加载连接组件，因此我们不需要在app.js中进行额外的配置。在pomelo 0.3中，如果需要使用原生websocket等非默认的连接方式，则需要在app.js中加入相应配置。在客户端，我们在启动时连接对应的接口，就可以建立起与服务端的连接。处理客户端请求　　Pomelo中，我们提供了两种客户端向服务端发送请求的方法，request/response模式和notify模式。　　request/response 模式与web中的请求模式相似，是标准的请求/响应模式，对于客户端的一个请求，服务端会给出一个响应。以玩家的移动为例，当需要移动时，会发送一个请求给服务端，服务端会验证客户端的请求，并返回结果客户端，下图是具体请求流程：　　　　最上面的是客户端代码，在这里，我们向服务端发送一个移动请求。 之后，服务端会根据请求的route（area.playerHandler.move）找到对应的处理方法（/game-server/area/handler/playerHander.move），然后调用该方法来处理客户端的请求。当处理完成之后，会并在next方法中传入处理结果，结果会发回客户端，并作为回调函数的参数传回。　　notify模式的运行流程与request/response类似，只是当服务端处理请求后不会发送任何响应。客户端通过pomelo.notify方法来发出notify请求，notify请求的参数与pomelo.request相似，只是不需回调函数，notify方法的实例如下：　　``` pomelo.notify('area.playerHandler.pick', params); ``` 服务端消息推送　　与web服务不同，game服务端会有大量的推送消息，要实现这一功能，我们使用pomelo中的push模式来实现。下图以“move”为例，展示了服务端的推送流程：　　　　Treasures中的广播功能是通过一个全局的channel来实现的，在游戏中的所有玩家在加入游戏后都会加入一个全局的channel中。当需要广播消失时，服务端就会调用这个全局的channel来对所有用户进行消息推送。扩展游戏服务端　　在前面两节中，我们使用pomelo搭建了一个单节点的游戏服务器。在这一节中，将介绍如何使用Pomelo来对服务端进行扩展，搭建分布式的游戏服务。　　由于游戏服务器的复杂性，像web服务器简单的水平扩展是不现实的，而根据业务逻辑的不同，不同的服务器也有着不同的扩展方案。因此我们分别以前面介绍的连接服务器和场景服务器为例，来对他们进行扩展。连接服务器的扩展　　连接服务器作用是负责维护所有客户端的连接，负责客户端消息的接受和推送，在MMO RPG中，连接服务器往往是性能的热点之一，因此对连接服务器的扩展对于提高系统负载有很重要的现实意义。 在例子treasures中，我们通过加入一个负载均衡服务器（gate服务器），来实现连接服务器的扩展：当客户端登录时，会首先连接gate服务器，来分配一个连接服务器，之后，客户端会断开与gate服务器的连接，在与其对应的连接服务器建立连接，如下图所示：　　　　要实现这一功能，在服务端，我们首先要在nfig中加入新的前端服务器，代码如下：　　``` "gate": [
{"id": "gate-server-1", "host": "127.0.0.1", "clientPort": 3014, "frontend": true} ] ``` 　　之后，在gate服务器上编写对应的负载均衡接口，在例子中，我们采用了使用uid的crc值对服务器数目取模的方式,代码如下:　　``` module.exports.dispatch = function(uid, connectors) {
var index = Math.abs(crc.crc32(uid)) % connectors.
return connectors[index]; }; ``` 　　最后，在客户端加入对应的连接代码，就完成了对连接服务器的扩展。 在我们的例子中只用到了两台连接服务器，而在实际应用中，可以根据实际环境，编写自己的负载均衡算法，加入更多的连接服务器。场景服务器的扩展　　与连接服务器不同，场景服务器中包含着大量的状态信息，如果对单一的场景进行扩展，需要复杂的同步机制和大量远程调用。因此，在Pomelo中，我们的场景扩展是通过加入新的场景来进行的。 在设计游戏时，整个世界就被分为多个不同的场景。而在服务器端，一个场景则与一个独立的场景服务器相对应，场景服务的扩展可以通过加入新的场景来完成。下面，就以treasure为例，介绍一下场景服务的的扩展方法： 因为场景扩展是通过加入新的场景来完成的，所以首先要在server.json中加入新的场景服务器：　　在加入场景服务器之后，我们还要保证发往场景服务器的请求可以被分发到正确的场景去。而Pomelo中，对于同一类型的服务器，默认的分法方法是采用随机分配的方式，这是不能满足我们要求的。因此，我们需要加入自己的路由算法，流程如下：　　　　首先，我们编写了新的路由算法：根据用户所属的场景id进行投递。之后，我们在app.js中使用app.route方法来将我们的路由算法配置为针对area服务器的默认方法。app.route方法接受两个参数，第一个是需要自定义route的服务器类型，第二个参数就是具体的路由算法。我们分别将‘area’服务类型和我们编写的算法传入，就可以实现自定义的路由功能了。跨平台客户端　　除了原有的JS客户端之外，pomelo还提供了多种其他的客户端，而不同的客户端可能会对应着不同的长连接协议。但是经过pomelo封装之后，在Pomelo服务端，不同客户端在连接上连接上是完全对等的。因此，你可以使用pomelo框架实现跨平台联机对战的（前提是你开发了针对多个平台的游戏客户端）。最终架构　　经过扩展后，我们的最终服务器架构如图所示：　　总结　　在本文中，我们介绍了如何使用Pomelo框架来构建了一个包括连接服务器和场景服务器的MMO RPG服务端。并介绍了如何使用pomelo特性，来对游戏服务端进行扩展，并构建出了一个分布式的MMO RPG服务。 但是，这只是游戏服务端开发中最为基础的部分，MMO RPG中很多基础功能在这里都没有实现，如数据持久化，AI控制，寻路系统等。在下面的文章中，我们会进一步介绍Pomelo在游戏开发中的应用。
&&&主编推荐
&&&热门试卷
&&&最新视频
&&&热门阅读
&&&最新问答
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&&&湘教QS2-164&&增值电信业务经营许可证湘B2-