Ruby China

Gem cramping 框架业务场景

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

最近在了解高并发业务场景。首当其冲就是 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.

1 个赞
saiga #1 2014年09月03日

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

mimosa #2 2014年09月03日

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

flowerwrong #3 2014年09月03日

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

flowerwrong #4 2014年09月03日

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

mimosa #5 2014年09月03日

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

效果均不理想：

  • 没有那么实时；
  • 和 app 配合出现耗费（手机系统）资源的问题；
lidashuang #6 2014年09月03日

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

flowerwrong #7 2014年09月03日

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

mimosa #8 2014年09月03日

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

你也可以选择 ejabberd 扩展 bosh

flowerwrong #9 2014年09月03日

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

flowerwrong #11 2014年09月03日

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

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