Bea*_*ian 6 cron automation web-services node.js web
目前，我有一个复杂的生产 NodeJS 服务器，只需按一下按钮就可以通过Sendgrid向用户发送电子邮件。然后使用 Docker 和 Convox 将该服务器部署到称为“生产”的不同生产环境中，并在“暂存”级别进行测试。
我想使用cronNPM 包自动化向用户发送电子邮件的功能。此 cron 作业每天在指定时间自动向客户发送电子邮件。我面临的一个问题是，登台环境 Node 环境与生产环境（都称为“生产”）完全相同。一种可能的解决方案是，我将 Docker/Convox 配置更改为有一个单独的 Node 环境用于“暂存”，以防止 cron 作业在那里运行。
然而，这让我开始思考 - 部署具有与我的 Node 服务器中的进程紧密耦合的功能的 cron-job 服务的最佳实践是什么？
cron 服务应该运行在同一个 Node 服务器上吗？对此提出的一个担忧是，它可能会创建一个更“单一”的实例，而碎片更少。
cron 服务应该在单独的 EC2 NodeJS 还是 AWS Lambda 上运行？
我试图找出构建 cron 服务部署的最佳方法，使其具有可扩展性和可伸缩性。将来我希望添加更多具有类似功能级别的 cron 服务。
cron 服务应该在同一个 Node 服务器上运行吗？
如果 cron 服务不需要访问现有 node.js 服务器中的任何实时状态，那么您可以自由地将其包含在现有服务器中，或者将其分解为自己的流程，更类似于您拆分的微服务架构不需要耦合的东西。这只是一个取决于许多不同事物的设计选择。
It's really a tradeoff between keeping things simple for deployment and management (one server process to deploy and manage) versus separating out things that don't need to be coupled and can be run/managed/coded/tested independently.
Typically, you'd make this tradeoff decision based on complexity. If the email code is fairly trivial and doesn't particularly impact the memory or CPU usage much, then there's really no particular advantage to creating another server to manage just like you wouldn't think about breaking out other small things from your server. But, if there's a real reason to manage it separately or you can scale easier by getting it's memory and CPU usage out of your main server process, then by all means break it out into its own server.
I'll offer you a couple examples that show the extremes.
Imagine you had 20 lines of code in your server that did some maintenance operation for you once a day (imagine it was log file management). They take about 10 seconds to run and really aren't complicated at all. Would you break that out into another node.js server. Probably not because there's no main benefit to breaking it out, yet there is added complexity to now have yet another process to run and manage.
Now imagine you had a process that was kicked off at a certain time at night that crawled the entire sites of 100 related companies gathering information from their sites. Because of the size of these sites, this could run for hours and could use a fair amount of CPU, memory, bandwidth and database cycles storing what it finds. Here there are real scale and management reasons to put this in its own separate process where it can be managed and scaled separately and where running it doesn't need to affect the ability of your other server to do its job effectively.
Should the cron service be running on a separate EC2 NodeJS or AWS Lambda?
This really depends upon your scale and management needs. See the above examples.
On your other topic...
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.
This seems to be a completely separate issue from what the rest of your question is about. It seems like it would be useful to have a separate environment variable that indicates STAGING. That way code that only cares about the difference between production and development can just look at the one existing environment variable (and you don't have to change any of that code that already does this). But code that wants to know the difference between staging and production can then examine the new variable.