编排中的线程与容器

Posted

技术标签:

【中文标题】编排中的线程与容器【英文标题】:Threading vs Containers in Orchestration 【发布时间】:2020-11-14 01:24:28 【问题描述】:

我正在重新设计一个现有的 Spring Boot 应用程序,该应用程序试图自动执行公司目前由其员工手动完成的一系列工作。它有一个主应用程序,几乎可以作为一个编排应用程序工作,因为它是一个服务,它将调用其他应用程序来完成整个工作。它有 7 个要调用的子系统,其中 3 个系统需要以某种顺序调用,并在调用其他 4 个之前完成,但它们可以异步调用。

所有这些子系统现在都已移至 Spring Microservices,我正在处理的应用程序必须调用这些微服务(有些是按顺序调用的,有些是异步调用的),我的应用程序可能会在同时,我需要考虑每个子系统可能需要多个容器。我已经实现了 Open-Feign 来调用每个微服务。

他们还计划在不久的将来将其移至 AWS ECS/Fargate,但目前它将在 Linux 虚拟机中运行,并且容器在同一个专用网络上创建以进行通信。我想知道我是否应该完全删除 ThreadPoolTask​​Executor 并为对我的应用程序的每个同时请求调用一个新容器,但是我读过一个进程上的线程仍然更快并且比在容器上创建一个进程的开销更少并考虑不会同时调用很多容器我对最佳方法感到困惑。

任何建议将不胜感激。

【问题讨论】:

您是否考虑过这种方法中每个请求的容器启动时间? 只需为我的应用程序的每个同时请求调用一个新容器 嗨,Muhammad,我确实考虑过,但这是一个内部应用程序,正在将完成整个工作的当前时间范围从 2 周缩短到 40 分钟左右,因此,即使速度快是我的目标要考虑它仍然大大减少了整体时间。此外,由于这不会公开曝光,我们不会与客户等打交道,因为这会额外失去 30 秒左右的耐心。谢谢 【参考方案1】:

除非每个请求将应用程序中的内存消耗线性增加至少 1Gb(那么新的 pod 基本内存不会与它相比那么多),否则为每个请求启动一个新的 pod 是一种过度杀伤力。 .. 每个请求需要 200Mb 的额外内存,我看不出有什么好处也没有必要。

【讨论】:

以上是关于编排中的线程与容器的主要内容,如果未能解决你的问题,请参考以下文章

Kubernetes编排工具

Docker-compose编排微服务顺序启动

Docker 容器技术 — Compose 编排

Docker 容器技术 — Compose 编排

容器 10 年,Docker 6 年

微服务架构中的编排与编排[关闭]