node.js - 在生产 Node 服务器上部署 cron 服务的最佳实践？

Question

目前，我有一个复杂的生产 NodeJS 服务器，它通过 Sendgrid 向用户发送电子邮件。按下一个按钮。然后使用 Docker 和 Convox 将该服务器部署到称为“生产”的不同生产环境中，并在“暂存”级别进行测试。

我想通过使用 cron NPM package 自动执行向用户发送电子邮件的功能。 .此 cron 作业每天在指定时间自动向客户发送电子邮件。我面临的一个问题是，暂存环境 Node 环境与生产环境(均称为“生产”)完全相同。一种可能的解决方案是我更改 Docker/Convox 配置以具有单独的 Node 环境用于“暂存”以及防止 cron 作业在那里运行。

然而，这让我开始思考 - 在我的 Node 服务器中部署具有与进程紧密耦合的功能的 cron-job 服务的最佳实践是什么？

cron 服务应该运行在同一台 Node 服务器上吗？对此提出的一个担忧是它可能会创建一个碎片更少的更“整体”的实例。

cron 服务应该在单独的 EC2 NodeJS 还是 AWS Lambda 上运行？

我正在尝试找出构建 cron 服务部署的最佳方式，以便它可以扩展和扩展。将来我希望添加更多具有类似功能级别的 cron 服务。

Answer 1

Should the cron service be running on the same Node server?

如果 cron 服务不需要访问现有 node.js 服务器中的任何实时状态，那么您可以自由地将其包含在现有服务器中，或者将其分解为更类似于微服务架构的自己的进程，其中您将不必耦合的事物分开。这只是一个设计选择，它取决于一堆不同的东西。

这实际上是在保持部署和管理简单(部署和管理一个服务器进程)与分离不需要耦合且可以独立运行/管理/编码/测试的事物之间的权衡。

通常，您会根据复杂性做出权衡决定。如果电子邮件代码相当微不足道并且不会特别影响内存或 CPU 使用率，那么创建另一个服务器来管理就真的没有什么特别的优势，就像您不会考虑从您的服务器中分离出其他小东西一样。但是，如果确实有理由单独管理它，或者您可以通过将它的内存和 CPU 使用率从主服务器进程中取出来更轻松地扩展，那么一定要将它分解到自己的服务器中。

我将向您提供几个显示极端情况的示例。

假设您的服务器中有 20 行代码每天为您执行一次维护操作(假设是日志文件管理)。它们运行大约需要 10 秒，而且一点也不复杂。你会把它分解成另一个 node.js 服务器吗？可能不是因为将其分解没有主要好处，而是因为现在要运行和管理另一个进程会增加复杂性。

现在假设您有一个在晚上某个时间启动的流程，该流程会爬行 100 家相关公司的整个网站，从他们的网站收集信息。由于这些站点的规模，这可能会运行数小时，并且可能会使用大量的 CPU、内存、带宽和数据库周期来存储它找到的内容。这里有真正的规模和管理理由，将其放在自己单独的进程中，可以单独管理和扩展，并且运行它不需要影响其他服务器有效完成其工作的能力。

Should the cron service be running on a separate EC2 NodeJS or AWS Lambda?

这实际上取决于您的规模和管理需求。请参阅上面的示例。

---

关于你的另一个话题......

One possible solution is that I change the Docker/Convox configurations to have a separate Node environment for "staging" as well to prevent the cron job from running there.

这似乎是一个与您的其他问题完全不同的问题。拥有一个指示 STAGING 的单独环境变量似乎很有用。这样，只关心生产和开发之间差异的代码就可以只查看一个现有的环境变量(并且您不必更改任何已经执行此操作的代码)。但是想要了解暂存和生产之间差异的代码可以检查新变量。