容器化应用.设计模式

Question

我正致力于封装一批具有以下高层次结构的应用程序：

1. 从DB/文件系统
2. 读取数据，提取数据或执行解析(业务逻辑)
3. ，将处理后的数据写回数据存储。

让我们将这三个步骤命名为s1、s2和s3。

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

很少有人能找到我自己的笔，具体如下：

1. 为每个应用程序分离荚，每个应用程序有一个容器，其中包含s1、s2和s3作为相同代码的一部分。
   • Benefits：简单而紧凑的代码库。没有进程间/进程间communication
   • Limitation：没有代码reuse

​

1. 为每个应用程序分离荚，每个荚都有3个容器执行s1、s2和s3等不同的功能。
   • Benefits：代码reuse.
   • Limitation：进程间通信可能会增加处理latency.

​

1. 分别为s1、s2和s3的组表示sg1、sg2和sg3分别独立运行。从应用程序的角度来看，我们创建了一个新的pod，它可以与上述的3个pod组进行对话，以完成工作。
   • Benefits：代码reuse.
   • Limitation：进程间通信可能会增加处理延迟。同时，维护荚组也是一种附加的开销。增加complexity

​

如果合适的话，请提出任何其他选择。

Answer 1

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

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

关于方法2，这不是一个最佳实践。在大多数情况下，一个吊舱只包含一个容器。在某些情况下，一个吊舱中有多个容器，但其中一个是主要工作的主容器，另一个是执行辅助工作的紧密耦合的侧容器。

摘要

如果您的应用程序中有很多公共逻辑，那么方法3就有意义了，以避免代码重复。此外，它还为缩放提供了最好的粒度。pod组由部署资源管理，您将使用这些资源，即使您将每个应用程序部署为单个pod，所以这是不需要开销的。

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