ruby-on-rails - Rails、RabbitMQ 和 Sidekiq 架构

Question

关闭。这个问题是 opinion-based .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.

关闭 4 年前。

Improve this question

我有一个非常琐碎的 - 我猜 - 情况，以及几个实现选择。我有一个 Rails 应用程序(称为 Core)，可根据用户请求从互联网上抓取数据。爬虫没有任何业务逻辑——至少现在是这样——但是获取和持久化数据是一项需要时间的工作，我不希望它被阻塞。

我考虑过不同的架构，但我不确定当事情扩大时哪一个会发挥最佳效果。选项:

1. Sidekiq:每次用户请求抓取数据时，Sidekiq 中都会生成一个后台作业并抓取数据，将它们持久化并完成作业。这里可能的缺点是我不会为 Sidekiq Pro 版本付费，而且我不确定 OSS 版本是否适合我的需求。
2. RabbitMQ:在 Rails 中开发一个微服务，我们称之为 Fetcher，它将从 RabbitMQ 消费并获取和持久化数据。我不明白在这种情况下我是否也需要后台处理，所以再说一次 Sidekiq(或 Sneakers)。如果我这样做，使用消息代理(在这种情况下)而不是让 Sidekiq 在同一个应用程序中进行后台处理有什么好处？

Answer 1

您的建筑方案正朝着正确的方向发展。

• Sidekiq OSS:我真的相信sidekiq OSS 版本能够很好地满足您的需求。它有几个特性来支持 Redis 支持的后台作业。我建议你阅读its documentation了解最佳做法以及应避免的情况。
• 微服务是 good architectural choice to achieve scalability因为它促进了功能分解，您可以就如何单独扩展每个服务做出具体决定。但是，它会以多种方式增加系统的复杂性，要​​求您高度自动化基础架构。我建议你到read this arcitle来自 Martin Fowler 网页。他讨论了与采用微服务相关的权衡取舍。
• 使用 RabbitMQ 的优点是可以在多个服务之间实现可靠的异步通信，支持可扩展性，并提供灵活的通信方式，例如 pub/sub 和 RPC。如果您保留微服务的想法，这是正确的方法。否则，一个单一的 Rails 应用程序将只需要使用 sidekiq。
• 如果你使用 RabbitMQ，你应该使用正确的 RabbitMQ client .对于 ruby ，请使用 Bunny在发布者和消费者服务中，因为它将为 publish data on RabbitMQ 提供良好的 API并且还将support background processing for receiving data .因此，Fetcher 服务中无需使用 sidekiq 来消费数据。
• 当您要进行异步处理时，您的客户端将无法通过您的 HTTP 响应知道他们的请求的最终结果。因此，使用一种机制让您的应用程序在您的应用程序完成异步处理任务时通知他们(即通过用户页面上的状态更新)会很有趣。为此，您可以使用 Websockets，Rails 已通过 Action Cable 支持该功能。

我的最后一个提示是:如果您仍在对应用程序进行原型(prototype)设计并尝试各种想法，我建议您遵循单体架构的道路，并更关注验证您的提案。但是，如果您已经有一个结构良好的提案并且知道应用程序的预期需求，那么微服务架构可能是开发可扩展且可靠的系统的不错选择。