对我而言,这完全取决于您拥有的服务器类型以及在后台执行的进程。
数据隔离是我最不关心的问题。如果您的不同服务使用相同的数据,即使它们不在同一台服务器上,您也会遇到冲突,并且您必须查看Paxos以达成共识。你可以看看 筏 为此,这是非常好的解释,已经有一些实现。
如果您担心安全问题,那么您需要保护的最重要部分显然是您的数据,存储在您当前拥有的任何数据库中。托管数据库的服务器应与运行Web和后台服务的服务器隔离,因为它会迫使攻击者破坏第一层上公开的服务,而不是直接针对您的数据库。见 最近的攻击 暴露在服务器上的MongoDB上。
这让我回到了解决CPU,Ram和浪涌问题的第一点。这些要点只能通过了解您可以使用的预算,您期望的流量以及您正在运行的工作类型来回答。
但是,如果您确实希望将它们托管在同一台服务器上,并且您对它很灵活,则可以通过暂停或为后台任务分配较少的资源并恢复它们来防止用户在流量高峰期间出现任何停机/减速一旦它稳定下来。您还可以考虑每小时分析一下您的流量模式,并在您知道此时不会出现任何问题时运行这些工作。
在线,短期请求 - 响应操作(如API)和计划后台任务(如维护作业或数据管理操作)之间的资源使用模式非常不同。
出于这个原因,通常最好将这些任务隔离在尽可能低的级别上,在不同的VM甚至物理机器上运行它们。
如果正在使用相同的JVM实例,那么占用大量内存然后释放它的批处理作业将导致垃圾收集暂停执行在线请求降低响应时间。
这可以通过在其自己的JVM上运行每种类型的操作来减轻其影响 阻止世界 影响。
如果后台任务在与在线请求相同的数据上运行,那么您可以重复使用至少一些数据访问和映射层代码,从而可能以牺牲在数据层引入耦合为代价来节省一些工作。
如果批处理作业是CPU或内存绑定,那么它将影响在线请求的性能,除非您对每个进程可以使用的CPU /内存共享设置一些限制。这可以在VM,容器或进程级别完成。
如果批处理作业使用大量带宽,则会影响在线请求向客户端发送内容的能力。与CPU和内存一样,每个应用程序也可以限制带宽以减轻这种影响。
传统上,面向客户的应用程序(如API)应该得到适当的审核和强化,以避免漏洞。预定的后台批处理过程通常具有较小的攻击面,因为它们不需要暴露给客户端,因此更难以妥协。
当然,根据部署的性质,为两个应用程序共享相同的基础结构将增加批处理作业的风险。