docker - 容器化应用程序-设计模式

Question

我正在对一系列具有以下结构的应用程序进行高层容器化:

从数据库/文件系统读取

提取数据或进行一些解析(业务逻辑)

将处理后的数据写回到数据存储中。

让这3个步骤分别命名为s1，s2和s3。

在代码重用和使解决方案过于复杂之间取得平衡的最佳方法是什么？换句话说，实现行业认可的这种解决方案的最佳设计模式/实践是什么？

我几乎不愿提出的建议如下:

每个应用程序使用单独的容器，每个容器具有一个容器，并且s1，s2和s3作为同一代码的一部分。

的好处:简单而紧凑的代码库。没有进程间/容器通信

限制:无代码重用

每个应用程序具有单独的容器，每个容器具有3个容器，分别具有s1，s2和s3的功能。

好处:代码重用。

限制:进程间通信可能会增加处理延迟。

分别针对s1，s2和s3的荚单独的组的 pod 表示sg1，sg2和sg3分别独立运行。从应用程序的 Angular 来看，我们创建一个新的pod，与上述3个pod组进行对话以完成工作。

好处:代码重用。

限制:进程间通信可能会增加处理延迟。同样，维护Pod组是一项额外的开销。复杂性增加

要求建议其他合适的替代方法。

Answer 1

如果您的应用程序是整体式的，最明显的方法是将每个应用程序作为一个进程打包到容器镜像中，然后将容器作为Pod(每个Pod一个容器)部署到Kubernetes(由Deployment资源管理)(允许您复制Pod)并进行滚动更新)。这对应于列表的方法1 。

如果您的应用程序组件之间已经松散耦合，则可以选择微服务类型的体系结构。例如，您可以将所有应用程序的s1，s2和s3的通用逻辑提取到单独的微服务中，将每个应用程序打包为容器镜像，然后将它们作为Pod在Kubernetes上运行(每个Pod一个容器，由Deployment管理) 。每个应用程序的核心将是其自己的“微服务”，打包为容器镜像，并作为由Deployment管理的Pod部署到Kubernetes。然后，这些“核心”容器将使用s1，s2和s3容器提供的服务作为客户端。这将对应于列表中的方法3 。

关于方法2 ，这不是最佳实践。在大多数情况下， pods 仅包含一个容器。在某些情况下，一个 pods 中有多个容器，但是其中一个是主要容器，是主要任务，另一个是紧密相连的侧车容器，它们可以完成辅助任务。

摘要

如果您的应用程序之间有很多共同的逻辑，那么方法3是有道理的，以避免代码重复。它还为缩放提供了最好的粒度。 Pod组由Deployment资源管理，即使您将每个应用程序部署为一个Pod，您也将一直使用它们。因此，这没有任何开销。

如果通用逻辑不是那么大，则方法1是最简单的解决方案。