【POMELO】深入浅出node.js游戏服务器开发

游戏服务器概述

没开发过游戏的人会觉得游戏服务器是很神秘的东西。但事实上它并不比web服务器复杂，无非是给客户端提供网络请求服务，本质上它只是基于长连接的socket服务器。当然在逻辑复杂性、消息量、实时性方面有更高的要求。

游戏服务器是复杂的socket服务器。

如果说web服务器的本质是http服务器，那么游戏服务器的本质就是socket服务器。 它利用socket通讯来实现服务器与客户端之间的交互。事实上有不少游戏是直接基于原生socket来开发的。 相对于简单的socket服务器，它承受着更加烦重的任务：

后端承载着极复杂的游戏逻辑。
网络流量与消息量巨大，且实时性要求极高。
通常一台socket服务器无法支撑复杂的游戏逻辑，因此在socket服务器的背后还有一个服务器群。

为什么纯粹的socket服务器还不够好？

很多web应用不会基于原生的http服务器搭建，一般都会基于某类应用服务器（如tomcat）搭建，而且还会利用一些开发框架来简化web开发。 同样，一般游戏服务器的开发都会在socket服务器上封装出一套框架或类似的应用服务器。为什么使用原生的socket接口开发不够好呢?

抽象程度。原生的socket抽象程度过低，接口过于底层，很多机制都需要自己封装，如Session、filter、请求抽象、广播等机制都要自已实现，工作量很大，容易出错，且有很多的重复劳动。
可伸缩性。高可伸缩性需考虑很多问题，消息密度、存储策略、进程架构等因素都需要考虑。用原生的socket要达到高可伸缩性，需要在架构上花费大量的功夫，而且效果也未必能达到开源框架的水准。
服务端的监控、管理。很多服务器的数据需要监控，例如消息密度、在线人数、机器压力、网络压力等，如果采用原生socket，所有这些都要自己开发，代价很大。

用框架来简化游戏服务器开发

一个好的框架可以大大简化游戏服务器的工作。除了游戏自身的逻辑外，大部分的工作都可以用框架来解决。服务端的抽象，可伸缩性，可扩展性这些问题都可以通过框架来解决。 游戏服务器框架也承担了应用服务器的功能。可以把框架看成容器，只要把符合容器标准的代码扔进去，容器就运行起来了。它自然具备了抽象能力、可伸缩性和监控、管理等能力。

游戏服务器框架介绍

在开源社区里充斥了数不清的web服务器框架，游戏客户端的框架和库也有一大堆，但唯独游戏服务器框架少之又少，零星有一些类库，但完整的解决方案几乎没有。我们只好从商用的解决方案中拿出一些框架进行类比：

Sun RedDwarf

RedDwarf是唯一一个能找到的完整的开源游戏服务器框架，由sun出品。可惜在它合并到Oracle以后已经停止开发了。 在设计上，RedDwarf是个分布式架构，它在分布式数据存储和任务管理上投入了太多精力，而且做的过于理想化，如动态任务迁移功能的实现非常复杂，但实际应用中根本用不到。而在可伸缩性和性能的设计上不太理想。因此RedDwarf夭折了。

SmartfoxServer

SmartfoxServer是由意大利的一家游戏公司gotoAndPlay()推出的商用游戏服务器。 它是基于java开发的，与web应用服务器如Tomcat看上去很类似。Smartfox支持各种客户端，且有一些成功案例。它在服务端封装和监控管理方面实现得很完善。 但在可伸缩性上并不是太理想，尽管Smartfox也支持Cluster模式，但它的扩展方式是基于jvm内存复制的。也没有实现传统MMORPG基于场景分区的解决方案。 Smartfox有免费版本，但完全不开源。而且它的免费版本(达不到高并发用户要求)很大程度是为了吸引开发者最终购买它的收费版本。不限在线人数的收费版本价格达到3500美刀。

BigWorld

Bigworld是澳大利亚Bigworld公司开发的全套3d MMORPG游戏解决方案，解决方案包含了客户端和服务端。Bigworld功能非常强大，在动态负载均衡和容错性做了很多工作。可扩展性非常强大。 它的缺点是过于重量级，对硬件要求高，且价格非常昂贵。Bigworld是专门为3d MMORPG游戏定制，但并不适用于中小型游戏的开发。

Pomelo

Pomelo是网易于2012年11月推出的开源游戏服务器。它是基于node.js开发的高性能、可伸缩、轻量级游戏服务器框架。 它的主要优势有以下几点：

开发模型快速、易上手，基于Convention over configuration的原则，让代码达到最大的简化。
架构的可伸缩性和可扩展性好，pomelo在服务器扩展和应用扩展上实现得非常方便。
轻量级，虽然是分布式架构，但启动非常迅速，占用资源少。
参考全面，框架不仅提供了完整的中英文档，还提供了完整的MMO demo代码(客户端html5)，可以作为很好的开发参考。

Pomelo目前的主要缺点是推出时间尚短，一些功能还在完善中，支持的客户端类型还有限，目前已支持HTML5、ios、android、untiy3d等4类客户端，未来还会支持更多的客户端类型。

游戏服务器的可伸缩性探讨

不管是web应用还是游戏服务器，可伸缩性始终是最重要的指标，也是最棘手的问题，它涉及到系统运行架构的搭建，各种优化策略。 只有把可伸缩性设计好了，游戏的规模、同时在线人数、响应时间等参数才能得到保证。

为什么游戏服务器的可伸缩性远远不及web?

相比web应用几乎无限扩展的架构（前提是架构设计得好），游戏服务器的可伸缩性相比就着差远了。那么是哪些因素导致游戏无法达到web应用的扩展能力呢？ 说明：本文提到的web应用不包括类似于聊天这样的高实时web应用，高实时web可认为是一种逻辑较简单的游戏。

长连接和响应实时性

web应用都是基于request/response的短连接模式。占用的资源要比一直hold长连接的游戏服务器要少很多。Web应用能使用短连接模式的原因如下：

通讯的单向性，普通web应用一般只有拉模式
响应的实时性要求不高，一般web应用的响应时间在3秒以内都算响应比较及时的。

而游戏应用只能使用长连接，原因如下：

通讯的双向性，游戏应用不仅仅是推拉模式，而且推送的数据量要远远大于拉的数据量
响应的实时性要求极高，一般游戏应用要求推送的消息实时反映，而实时响应的最大时间是100ms。

在高并发长连接服务的解决方案中，目前除了传统的C语言（过于重量级）实现，用的最多的是erlang与node.js。两者的性能指标差不多，而node.js在易用性方面毫无疑问胜出太多。

最近微博上看到时go的能撑起100万的并发连接，node.js也能达到同样的数据，
Node.js w/1M concurrent connections!有node.js的长连接数据，它占用了16G内存，但CPU还远没跑满。

交互的相邻性与分区策略

普通的web应用在交互上没有相邻性的概念，所有用户之间的交互都是平等，交互频率也不受地域限制。 而游戏则不然，游戏交互跟玩家所在地图（场景）上的位置关系非常大，如两个玩家在相邻的地方可以互相PK或组队打怪。这种相邻的交互频率非常高，对实时性的要求也非常高，这就必须要求相邻玩家在分布在同一个进程里。 于是就有了按场景分区的策略，如图所示：



一个进程里可以有一个场景，也可以有多个场景。这种实现带来了以下问题：

游戏的可伸缩性受到场景进程的限制，如果某个场景过于烦忙可能会把进程撑爆，也就把整个游戏撑爆。
场景服务器是有状态的，每个用户请求必须发回原来的场景服务器。服务器的有状态带来一系列的问题：场景进程的可伸缩，高可用性等都比不上web服务器。目前只能通过游戏服务器的隔离来缓解这些问题。

广播

游戏中广播的代价是非常大的。玩家的输入与输出是不对等的，玩家自己简单地动一下，就需要将这个消息实时推送给所有看到这个玩家的其他玩家。 假如场景里面人较少，广播发送的消息数还不多，但如果人数达到很密集的程度，则广播的频度将呈平方级增长。如图所示：



假如场景中1000个玩家，每人发1条消息，如果需要其它玩家都看到的话，消息的推送量将高达1,000,000条，这足以把任何服务器撑爆。

解决这个问题的方案：

减少消息数量---消息只发送给能看到的玩家。玩家能看到的只是屏幕的大小，而不是整张地图的大小，这样推送消息的时候可以只推给对自己的状态感兴趣的玩家。这个可以用AOI（area of interested）算法来实现，在pomelo的库pomelo-aoi中实现了简单的灯塔算法。
分担负载，将消息推送的进程与具体的逻辑进程分离。如图：



这样广播逻辑与具体的进程逻辑就不会相互影响了，而且由于只有后端的场景服务器是有状态的，前端负责广播的服务器还是无状态的，因此前端服务器可以无限扩展。

实时Tick

实时游戏的服务端一般都需要一个定时tick来执行定时任务，为了游戏的实时性，一般要求这个tick时间在100ms之内。这些任务包括以下逻辑:

遍历场景中的实体(包括玩家、怪物等)，进行定时操作，如移动、复活、消失等逻辑。
定期补充场景中被杀掉的怪的数量。
定期执行AI操作，如怪物的攻击、逃跑等逻辑。

由于实时100ms的限制，这个实时tick的执行时间必须要远少于100ms，因此单进程内很多数据都会受到限制。

场景内实体的数量受限制，因为要遍历所有实体
注意更新的算法，所有的算法，包括AI在内都要在几十毫秒全部完成
注意GC，full GC最好永远不要发生。一般full GC的时间都会高于100ms，幸好node.js在内存少于500M时表现良好，只有小GC。因此一定要控制内存大小。
尽量分进程，进程的粒度越少，出现tick超时或full GC的可能越少。在多核时代里，CPU是最廉价的资源。

高可伸缩的运行架构

经过以上这些分析。我们可以得到现在的运行架构，如下图：



运行架构说明：

客户端通过websocket长连接连到connector服务器群。
connector负责承载连接，并把请求转发到后端的服务器群。
后端的服务器群主要包括按场景分区的场景服务器(area)、聊天服务器(chat)和状态服务器等(status)，这些服务器负责各自的业务逻辑。真实的案例中还会有各种其它类型的服务器。
后端服务器处理完逻辑后把结果返回给connector，再由connector广播回给客户端。 master负责统一管理这些服务器，包括各服务器的启动、监控和关闭等功能。

这个运行架构符合了刚才提到的几个伸缩性原则：

前后端进程分离，把承载连接和广播的压力尽量分出去。
进程的粒度尽量小，把功能细分到各个服务器
按场景分区

前面提到4个游戏服务器框架，只有bigworld和pomelo符合这样的架构，当然bigworld实现的还要更复杂。 现在的问题是，这个运行架构是个分布式架构，而且并不简单，那就带来以下问题：

需要多少的代码来实现这样的运行架构？
服务器类型、数量管理和扩展有点复杂，该怎么管理？
服务器之间会有一堆的相互rpc调用，实现起来怎么简化？
分布式的开发和调试并不容易，消耗资源量过大，过于重量级，多进程bug定位困难，该怎么解决？ Pomelo和node.js将很轻松地帮我们解决这些难题，我们下一节将讨论。

node.js、pomelo与游戏服务器

Node.js的特点与游戏服务器极其符合。列举如下:

对网络IO的处理能力，node.js生来就是为IO而生的，而游戏服务器刚好是网络密集型的应用。
单线程的应用模型，node.js的单线程处理能力远比其它语言强大，而单线程处理游戏逻辑是最简单，最不容易出错，而且不可能出现死锁、锁竞争的情况。
语言与轻量的开发模型。Javascript语言已经不是昔日的吴下阿蒙，它不仅由于脚本语言的轻量、简单带来了开发效率的提升。还可以与一些类型的客户端共享部分代码，如html5，unity3d的js客户端等。
语言的动态性带来了很多框架设计的便利，如设计DSL，实现Convention over configuration。尽管这方面比ruby稍差，但在pomelo框架中使用已经足够好了。

Pomelo是基于node.js搭建的游戏服务器框架，它在灵活性、扩展能力，轻量级调试方面具有无可比拟的优势。我们先简单回答第三章最末的几个问题：

用pomelo来实现以上的运行架构几乎是零代码的，因为它在设计时天生就具备这样的架构。
服务器类型、数量的管理极简单，利用鸭子类型、目录定义，只要一个简单json配置文件就可以实现所有服务器的管理。
rpc调用可以实现完全零配置，也不用生成stub。感谢js语言的动态性，基于Convention over configuration的原则，可以直接实现rpc调用。
分布式的开发和调试只占用很少的资源，启动极其迅速，十几个进程只用10秒不到的时间完全启动。多进程调试与单进程调试没有任何区别，只在一个console里搞定。

在本系列文章后面将会陆续讨论pomelo是怎么实现以上如此方便的特性， 以及这些设计带来的启发。

小结

本文分析了游戏服务器框架的市场现状，一个高可伸缩游戏服务器架构的设计原则及运行架构。Node.js与pomelo在解决高并发和分布式架构中起到的作用。下文我们将深入分析pomelo在解决复杂的游戏服务器运行架构中提供了哪些便利。

一、Pomelo的定义和组成

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

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

如果你浏览一下网易的github，会发现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调用

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