Rails、RabbitMQ 和 Sidekiq 架构

Question

我有一个非常微不足道的 - 我猜 - 情况，以及几个实现选择。我有一个 Rails 应用程序（称为 Core），它根据用户请求从 Internet 抓取数据。爬虫没有任何业务逻辑 - 至少现在 - 但是获取和持久化数据是一项需要时间的工作，我不希望它被阻塞。

我考虑过不同的架构，但是我不确定当事情扩大时哪一个最有效。选项：

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

Answer 1

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

• Sidekiq OSS：我真的相信 sidekiq OSS 版本将完全满足您的需求。它有几个特性来支持 Redis 支持的后台作业。我建议您阅读其文档以了解最佳实践以及应该避免的内容。
• 微服务是实现可扩展性的良好架构选择，因为它促进了功能分解，您可以就如何单独扩展每个服务做出具体决定。但是，它会以多种方式增加系统的复杂性，要​​求您高度自动化您的基础设施。我建议您阅读Martin Fowler 网页上的这篇文章。他讨论了与采用微服务相关的权衡。
• 使用RabbitMQ的优点是可以实现多个服务之间可靠的异步通信，支持可扩展性，并提供灵活的发布/订阅和RPC等通信方式。如果您保持微服务的想法，这是正确的方法。否则，单体 Rails 应用程序将只需要使用 sidekiq。
• 如果您使用 RabbitMQ，则应使用适当的RabbitMQ 客户端。对于 ruby​​，在发布者和消费者服务中都使用Bunny，因为它将提供一个很好的 API 来在 RabbitMQ上发布数据，并且还将支持接收数据的后台处理。因此，无需使用 sidekiq 来消费 Fetcher 服务中的数据。
• 当您要进行异步处理时，您的客户端将不知道他们的请求与您的 HTTP 响应的最终结果。因此，当您的应用程序异步处理完任务（即，通过用户页面上的状态更新）时，使用一种允许应用程序通知他们的机制会很有趣。为此，您可以使用Websockets，它已通过 Action Cable 在 Rails 中得到支持。

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