服务器通过长连接调用向客户端发消息,用pomelo做mobile app的server端, 谈谈我的想法...

目前项目基本运行ok，对pomelo主要有以下修改或者扩展：

【pomelo】-->对pomelo框架库的修改

【project】-->自己项目上层的处理1，【pomelo】socket.io配置为240秒一次心跳2，【pomelo】当业务子进程挂掉的时候，自动恢复child process3，【project】session，uid信息同步保存到mysql中，以便在多connector的时候查询到用户所处的connector，投递notify消息。放弃使用pomelo中的channel服务，调用rpcInvoke直接通过connector发送消息。4，【project】禁止非认证route，只在connector才能route到api服务器5，【project】对api服务器添加filter，只用通过认证的session才能调用接口

========old=====

这两天研究了一下pomelo,感觉是一个设计很好的框架. 而且发现基于nodejs socket.io方案可以很好的解决目前android客户端最麻烦的一个问题: 实时在线推送. (因为google的推送服务在国内网络不好用, google自己的推送基本是没指望了). socket.io和connector解决了长连接以及大量用户在线的问题. 当然附加的传输协议压缩也是一个亮点,比原始的http+json节约太多流量了,这点对移动端很重要.

但是这里有个问题还困扰着我,就是原有pomelo里面channel的概念.在push消息的时候,是基于channel的: ChannelService.prototype.pushMessageByUids()等.

但是channel又不是在整个服务器组中全局共享的,而是属于单个backend后台业务服务器. 那么就可能出现本来在同组(类似于qq群)中的用户被分配到了不同backend服务器中.那么push消息就会出问题.

解决的方案就是push是面向connector上的session的.换个角度来设计, 就是backend中完全没有channel. 类似于channel这种群组是存放在mysql中的.每个backend处理的时候,是和mysql这个数据共享者打交道,计算出要发送的对象userIdList, 最后再通过connector上存在的session把它们push出去.

提出这个问题的原因是,如果把pomelo设计为移动终端app的后台server.那么用户就不象游戏那种,单位时间上始终是在某个特定channel中的. 在这种设计中,用户是可以同时存在于多个channel(qq群)中的. 当然mysql不一定是最合适的群组管理者,但我觉得在这种应用中是需要一个全局的用户分组管理服务器的,因为在移动应用中,用户的身份圈子有太多种类了.

发这贴出来,希望能和大家讨论一下这种应用的可行性.

欢迎留言交流:)