ruby-on-rails - Delayed_job 与 Appoxy SimpleWorker

Question

当我在 Heroku 上找到 Appoxy SimpleWorker 时，我正要开始在我的应用程序上启动并运行延迟作业。

Appoxy 说它是大规模并行的，它可以上下扩展工作人员以最大限度地降低成本。但是，在我看来，使用 HireFire，delayed_job 也是如此。这是我的问题:您会选择哪个:delayed_job + HireFire 或 SimpleWorker？ (为什么？)

https://github.com/tobi/delayed_job
http://hirefireapp.com/
http://addons.heroku.com/simple_worker

我的应用程序目前很小 - 音量很低，并且应用程序的数量在很长一段时间内不应该特别多。

还有什么地方可以期望直接从这两种服务的创始人那里得到答复？谢谢迈克尔和特拉维斯!

Answer 1

嗨(这是 HireFire 的作者)

我将尝试提供一些有关服务之间差异的信息。不确定它是否对您的决定有很大帮助，但至少它是一些东西!

两种解决方案都采用不同的方法。 HireFire 仅在必要时扩展您的 Heroku 网络和工作人员测功机。您无需更改现有代码库中的任何内容，只需照常使用延迟作业。您不必为单独的环境/平台发送/编写代码，因为它在部署时在 Heroku 平台上编译为 slug，当新的 web 或 worker dyno 启动时，slug 会立即使用并运行(包含您的所有ENV 变量/设置。

与 SimpleWorker 相比，HireFire 的缺点是 HireFire 是 Heroku 特有的。因此，如果您曾经从 Heroku 切换到例如 EngineYard 或 VPS/Dedicated 盒子，那么 HireFire 将无法工作，但 SimpleWorker 会因为它没有严格绑定(bind)到 Heroku。虽然，在非 PaaS 平台上托管可能非常便宜(相比之下)，因此不一定需要或根本不需要自动缩放。

在开发 HireFire 之前，我一直是 SimpleWorker 的客户，我个人不喜欢的是，我必须将部分代码库推送到 SimpleWorker，并加载到我的 Rails 环境中，从他们的服务器位置重新连接到数据库，然后每次我想将工作发送到云时也会做 API 请求(？)(尽管现在可能已经改变了，所以我鼓励你自己检查一下，也许这不是什么大问题对你来说是一个问题，对我来说也是如此)。对我来说，每次我想添加新的作业类并且必须将所有单独的代码从我的应用程序和我的 gems 加载到作业类文件本身时，这简直是太多的麻烦/试验和错误，而运行 heroku ps:workers 1 或heroku ps:scale worker=2 将立即启动一两个工作人员并开始处理对我的代码库的零修改，这与我在本地运行它时完全相同，因为我的整个应用程序已经在 Heroku 上编译为一个 slug 它只是使用它，包括我的 ENV变量和其他设置/插件，它快速旋转。

使用 HireFire，您只需将 the hirefireapp gem 添加到您的 Gemfile，将您的 Heroku 帐户/应用程序添加到 HireFire Web 界面，自定义您的扩展需求，将您的应用程序部署到 Heroku，仅此而已。您的应用程序将被持续监控和管理/调整(按分钟或更短时间)。

HireFire 没有带有工作表及其状态(运行/完成/失败/等)的光滑界面(当然，它确实概述了每个应用程序的当前 web/worker dyno 数量和排队工作，并且可定制的缩放设置)，尽管提供此类功能确实是工作库的工作。据我所知，Delayed Job 有一个或两个你可以使用的小管理界面(开源)，它们与 HireFire 无关。因为 SimpleWorker 它既是一个托管服务，又是一个工作库，它们还为您提供了一个 Web 界面。

HireFire 还能够扩展您的网络测功机，而不仅仅是您的工作人员测功机。

两种服务都能够并行处理大量工作，因为据我所知，Heroku 和 SimpleWorker 都按比例分配到第二个。因此，无论您是在 6 秒内旋转 10 个 worker 测功机，还是在 60 秒内旋转 1 个，都不会(或几乎没有)成本。

我自己发布了 HireFire 之后就没有使用过 SimpleWorker，那是很久以前的事了，所以我不确定 SimpleWorker 这些天还提供了什么，或者他们是否从那时起简化了流程，所以我不确定我上面的陈述是否此时仍然有效。

希望这可以帮助!