Docker 关于单片与微服务体系结构的问题

我现在正在重新考虑我计划的一个架构。 因此，假设我有一个系统，其中大约有8个不同的服务与单个数据库交互。有些服务会监听数据库事件并做出反应，还可以发送短信等。 然后，数据库顶部有一个API层，前端连接到此API。所以在我的理解中，这是相当单一的

事实上，我不认为在这种情况下使用容器有任何好处。他们真正的优势是可以交换出去，对吗？我的直觉告诉我，这样做通常没有任何意义，除了可能在API级别上进行一些负载平衡。取而代之的是，许多公司似乎只是盲目地跳上了集装箱化的炒作列车

现在问题来了，docker是适合这种情况的工具吗？在每个论坛中，人们都避免使用docker仅仅是为了一个资源效率更高的“VM”，将所有服务聚合到一个容器中。然而，这是我在使用docker时看到的唯一真正的优势（在推出系统时，所有客户的计算机上的环境，例如alpine linux，都是相同的）

即使docker compose也没有将容器作为一个完整的系统“分组”在一起，只公开端口443，而是启动多个交互容器的基础结构。通常情况下，Kubernetes等服务用于在“节点”（即VM）上部署这些基础设施

然而，在我看来，如果有一个独立的容器而不将它们放入VM中，那就太好了。该容器将包括仅暴露一个端口的所有必要服务，例如443

既然我现在很困惑，我真的很感激你的帮助

---

提前谢谢

Kubernetes做了很多事情，有很多有用的特性。但Kubernetes也要求你的应用程序架构遵循原则。这里重要的一点是，你的应用程序是无状态的

• 当应用程序处于无状态时，很容易水平扩展，这也可以在负载增加时自动完成

• 当应用程序处于无状态时，可以轻松进行滚动部署，将应用程序升级到新版本，而无需停机

• 您可以在裸机Linux服务器上运行容器，但这大部分是非常大的服务器。如果您使用云，您可能需要更多的VM实例，但要分布到3个可用性区域，以提高可用性

• “独立容器-暴露一个端口”。对于Kubernetes，您通常使用专用网络，并且仅通过单个负载平衡器公开服务—通常在端口上，但不同的URL将流量发送到不同的服务

有些服务会监听数据库事件并做出反应，还可以发送短信等

正如我所说的，当它是水平可伸缩的时，很多事情都会变得更容易，但是这种应用程序——倾听事件并做出反应——是少数几个你不能水平伸缩的例子之一。但它非常适合无服务器架构，可能在Kubernetes上使用

现在问题来了，docker是适合这种情况的工具吗

---

我的意见是，大多数工作负载将在容器中运行。这更多的是关于如何在Kubernetes（一个或多个副本）中运行它的问题。无状态、有状态或其他方式。

谢谢您的回答！我将进一步研究这个方向！