Rails、RabbitMQ和Sidekiq体系结构

Question

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

我已经考虑过不同的体系结构，但是我不确定当事情发展的时候哪种体系结构会运行得最好。选项：

1. Sidekiq:每当用户请求要爬行的数据时，Sidekiq中的后台作业就会生成并抓取数据，并将其保存下来，然后完成工作。这里可能的缺点是，我不会支付Sidekiq专业版，我不确定开放源码软件的版本是否符合我的需要。
2. RabbitMQ:在Rails中再次开发一个微服务，我们称之为Fetcher，它将从RabbitMQ中消耗，并获取和持久化数据。我不知道在这种情况下，我是否也需要后台处理，所以同样的，Sidekiq (或运动鞋)。如果是这样的话，使用message (在本例中)而不是让Sidekiq在同一个应用程序中进行后台处理有什么好处呢？

Answer 1

你的建筑建议正朝着正确的方向发展。

• Sidekiq开放源码软件：我真的相信sidekiq版本会很好地满足您的需要。它有几个特性来支持Redis支持的后台作业。我建议您阅读其文件以了解最佳实践以及应该避免的内容。
• Microservices是一种促进功能分解的良好的架构选择以实现可伸缩性，您可以就如何单独扩展每个服务做出具体决定。但是，它将以多种方式增加系统的复杂性，要求您高度自动化您的基础设施。我建议您从Martin网页到读这条弧线。他讨论了与采用微型服务有关的权衡。
• 使用RabbitMQ的优点是能够在多个服务之间启用可靠的异步通信，支持可伸缩性，并提供灵活的通信方式，如pub/sub和RPC。如果你坚持微型服务的想法，这是正确的方法。否则，单块Rails应用程序只需要使用sidekiq。
• 如果使用RabbitMQ，则应该使用适当的RabbitMQ客户端。对于ruby，在发布服务器和消费者服务中都使用邦尼，因为它将为在RabbitMQ上发布数据和支持接收数据的后台处理提供一个很好的API。因此，没有必要在Fetcher服务中使用sidekiq来使用数据。
• 当您要进行异步处理时，您的客户端将不知道其请求的最终结果和HTTP响应。因此，使用一种允许应用程序在应用程序异步完成任务处理时(即通过用户页面上的状态更新)通知他们的机制会很有趣。为了实现这个目标，您可以使用Websockets，Rails通过动作电缆已经支持它。

我的最后一个建议是:如果您仍然在对应用程序进行原型化并尝试各种想法，我建议您遵循单块体系结构的方法，并更多地关注验证您的建议。但是，如果您已经有了一个结构良好的方案，并且知道了对应用程序的预期需求，那么微服务架构可能是开发一个可扩展和可靠的系统的一个很好的选择。