在生产节点服务器上部署cron服务的最佳实践?

cron服务是否应该在同一个节点服务器上运行?

如果cron服务不需要访问现有节点中的任何活动状态。js服务器,则您可以自由地将其包含在现有服务器中,或将其分解为自己的流程,更类似于微服务体系结构,在该体系结构中,您可以分解不必耦合的内容。这只是一个设计选择,取决于一系列不同的东西。

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

通常,您会根据复杂性做出这种权衡决策。如果电子邮件代码相当简单,并且不会对内存或CPU使用产生太大影响,那么创建另一个服务器来管理实际上没有什么特别的好处,就像您不会考虑从服务器中分离出其他小东西一样。但是,如果有真正的理由单独管理它,或者您可以通过将它的内存和CPU使用量从主服务器进程中移出来更容易地进行扩展,那么一定要将它拆分到自己的服务器中。

我会给你举几个例子来说明极端情况。

假设服务器中有20行代码,每天为您执行一次维护操作(假设是日志文件管理)。它们运行大约需要10秒钟,一点也不复杂。你能把它换成另一个节点吗。js服务器。可能不是因为打破它没有什么主要好处,但现在又有另一个流程需要运行和管理,这增加了复杂性。

现在想象一下,您有一个在晚上某个时间启动的流程,该流程对100家关联公司的整个网站进行爬网,从他们的网站收集信息。由于这些站点的大小,它可以运行数小时,并且可能需要大量的CPU、内存、带宽和数据库周期来存储它所发现的内容。这里有真正的可扩展性和管理性原因,可以将其放在单独的流程中,在该流程中可以单独管理和扩展,并且运行它不需要影响其他服务器有效执行其工作的能力。

cron服务应该在单独的EC2节点js或AWS Lambda上运行吗?

这实际上取决于您的规模和管理需要。参见以上示例。

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

一种可能的解决方案是,我更改Docker/Convalx配置,使其具有用于“暂存”的单独节点环境,并防止cron作业在其中运行。

这似乎是一个与你其余问题完全不同的问题。似乎有一个单独的环境变量来指示登台是有用的。这样,只关心生产和开发之间差异的代码就可以只查看一个现有的环境变量(而您不必更改任何已经这样做的代码)。但是,想要知道暂存和生产之间的区别的代码可以检查新变量。