Ruby 中的高负载 RESTful API（同步/异步实现）
我正在努力实现一个 RESTful API，它应该返回 JSON 响应并且应该维持非常高的负载。 最高负载将由 API 的“读取”部分生成，而 API 的“写入”部分将生成很少的负载。 我的第一次尝试是使用 Nodejs 编写整个 API。我几乎做到了，但面临 javascript 和 ruby 之间模型和逻辑的大量重复，因为 API 是更大系统的一部分。我尝试将所有逻辑移至后端（mySql），但这个想法结果更加丑陋。 我的第二次尝试是在 Ruby 生态系统中编写 API，以便在系统的所有部分之间共享模型/逻辑和测试。
我尝试单独使用 Cramp 和 Goliath，但所有这些异步内容确实很复杂的 API 实现。我只需要 2 个异步读取 url，因为它们会产生最高的负载，并且通过一直异步，我被迫以异步方式实现 API 的其余部分，这没有增加任何价值。
我目前的尝试是混合使用：使用 Thin/Sinatra/Cramp 鸡尾酒。我正在 Ruby 代码中实例化 Thinrack 句柄，并使用机架构建器将 API 拆分为 Sinatra（采用同步实现）和 Cramp（以异步方式实现 2 个 url）。
这是一个好方法吗？或者将 Sinatra 和 Cramp 放在一台 Web 服务器（瘦）中会因某种原因给我带来更多麻烦吗？
更新： 我正在尝试使用单独的 Sinatra 与rack/fibre_pool 和 em_mysql2 混合的解决方案。看来我正在扼杀两个目标——使 API 与同步实现异步。但我遇到了一个错误，我认为它很快就会得到修复。
这样做会有什么问题吗？
I'm struggling with implementing a RESTful API that should return JSON response and should sustain very high load.
The highest load will be generated by 'read' part of the API and very little load will be generated by 'write' part of the API.
My first attempt was to write whole API using nodejs. I almost did it but faced very high duplication of models and logic between javascript and ruby, because the API is a part of a bigger system. I tried moving all logic into backend (mySql), but that idea turned out even more uglier.
My second attempt is to write the API in Ruby ecosystem in order to share models/logic and tests between all parts of the system.
I tried using Cramp and Goliath alone, but all that async stuff really complicated API implementation. I only need to have 2 read urls async because they generate the highest load and by going async all the way I was forced to implement the rest of API in async fashion, which didn't add any value.
My current attempt is to go hybrid: use Thin/Sinatra/Cramp cocktail. I'm instantiating Thin rack handle right in Ruby code and using rack builder I'm splitting API between Sinatra, which is taking sync implementation, and Cramp, which is implementing 2 urls in async way.
Is this is a good way to go? Or having Sinatra and Cramp in one web server (Thin) will get me even in more trouble by some reason?
update:
I'm trying solution with sole Sinatra mixed with rack/fiber_pool and em_mysql2. Seems I'm killing two goals - making API async with sync implementation. But I'm suffering from a bug which I think will be fixed quite soon.
Were will be any gotchas going this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为在同一个瘦进程中使用同步（sinatra）和异步（cramp）应用程序不是一个好主意。如果同步部分相对简单，我建议在 Cramp 中实现。当我创作 Cramp 时，这里有点偏见:)
如果你不知道，Cramp 对 AR/光纤池有开箱即用的支持 - https://github.com/lifo/cramp/blob/master/examples/optics/long_ar_query.ru
如果您决定使用抽筋，我很乐意帮助解决任何问题，因为我最近在抽筋方面做了很多工作，而且非常兴奋！只需给我发一封电子邮件即可！
I don't think it's a good idea to have sync (sinatra) and async (cramp) apps within the same thin process. If the sync part is relatively simple, I'd suggest implementing that in Cramp. A little biased here as I authored Cramp :)
In case you didn't know, Cramp has out of box support for AR/fiber pool - https://github.com/lifo/cramp/blob/master/examples/fibers/long_ar_query.ru
If you decide to use Cramp, I'm happy to help out with any issues as I've been working a lot on cramp recently and am quite pumped up! Just throw me an email!
我很好奇你在使用 Goliath 时遇到了什么异步问题？在常见情况下，最终开发人员不应该看到异步代码。
我们是否可以采取更好的措施来减少最终用户的可见度？
I'm curious what async stuff you ran into with Goliath? In the common case there should be no async code visible to the end developer.
Is there something we can do better to make this less visible to the end user?