Gem cramping 框架业务场景

flowerwrong · 2014年09月03日 · 最后由 mimosa 回复于 2014年09月03日 · 2727 次阅读

最近在了解高并发业务场景。首当其冲就是 go 和 nodejs 了,得益于 linkedin 和 twitter 的爆炸性新闻。其次就是各家语言的实现,例如 py 的 tornado,scala 的 akka,lua+nginx,然后我发现 ruby 也有 goliath 和 cramping,当然 sinatra 也还 ok。goliath 是基于纤程的,cramping 和 nodejs 一样,基于 event io 模型。但是 nodejs 不太适合做大型复杂度高的业务,我也不喜欢语言,而 go 的语法对我来说难以接受(可能是 ruby 写久了)!!!正好项目是 ruby 的,rails,sinatra,grape 都有用一部分。实时部分在考虑用 cramping 来做…… 想了解下,社区有多少人用 cramping 这个框架? 他比较适合做哪些业务?用来做客服,实时聊天,大量 api 请求等业务是否都(注意都字)合适?例如像 nodejs 的 socket.io 和 webRPC 等等实时库非常丰富。或者还有其他什么解决方案。 thx.

你说的是 cramp 吧?他跟 goliath 都是基于 EM 的,用纤程的有基于 celluloid 的 reel 你说的都可以用来做实时聊天,不过我建议把 akka 单独区分开来而且也不要去碰他,对于小应用来说技术栈太深 如果要快速开发的话还是建议上 socket.io 或者 faye,其他框架都要自己做前端降级

还是 xmpp 吧,websocket 支撑不起来~

#1 楼 @saiga 是 cramp,也有叫他 cramping,我比较喜欢后者。 有两个问题 1.akka 技术栈太深,我只知道 scala 是一门强大但难把握的语言 2.前端降级是指?

#2 楼 @mimosa 为啥?你只指哪一方面,性能上是不错的,浏览器兼容性上 IE10+

#4 楼 @flowerwrong 我们的消息模块,通过 socket.io(后废弃)和 faye 实现实时通知,http 传递消息(文字、图片、语音);

效果均不理想:

  • 没有那么实时;
  • 和 app 配合出现耗费(手机系统)资源的问题;

node.js 就算了,golang 可以考虑

#5 楼 @mimosa 你们最后的解决方案是?xmpp 也有多种组合,包括前端和后台 client 和 server。能说说你们的选型吗?

#7 楼 @flowerwrong easemob 或 rongcloud 都可以选,我们的核心业务不是消息。

你也可以选择 ejabberd 扩展 bosh

#8 楼 @mimosa thx,暂时不打算用别人的产品。bosh 是前端的解决方案,ejabberd 是 server,还有 ruby 的 client--xmpp4r,我想最麻烦的就是用户的整合问题了。例如 rails 的数据库和 ejabberd 的用户数据表以及用户组数据表。

#10 楼 @mimosa 我想还是 ejabberd 吧,虽说 erlang 被神话了,你有没有整合的相关例子?主要是数据库方面的。例如我的一个 rails app 自带一套权限管理,怎么整合 xmpp 服务器的那一套?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号