应用程序部署容器大小与数量

App Deployment Container Size vs Quantity

我正在学习如何在 galaxy 上部署 meteor 应用程序，我真的对所有这些容器的东西感到困惑。

我想知道什么时候通过增加容器大小而不是添加更多容器来扩展应用程序会更好。

如果我有一个轻量级的聊天室网站为例。如果我可以添加更多小容器，为什么我需要升级容器大小。到底是不是处理能力的总和才是最重要的？

2 x 0.5 containers = 1 x 1 container

两种方式的成本是一样的。

此外，如果用户在一个容器中使用该应用程序时修改了数据库，那么其他容器中该应用程序的其他实例运行是否需要一段时间才能注意到更改？如果不同容器上的用户在一起聊天，那将是一个问题，不是吗？你会如何避免它？

我能理解的唯一方法是：缺乏 CPU 和 RAM，或者处理并行请求的能力将产生扩展需求。如果应用程序接收到太多流量，您将获得更多容器。如果应用程序使用过多 CPU 和 RAM，您将获得更大的容器。

但是应用程序怎么会变得太大而无法容纳在一个容器中呢？应用程序使用的 CPU 和 RAM 是否与使用该应用程序实例的用户数量有关。难道你不能通过添加更多容器并分散用户并以这种方式减少 CPU 和 RAM 使用来解决问题。

以及为什么您需要获得更多容器来处理更多请求。更大的容器不会处理更多的请求吗？

您问的问题太宽泛，无法回答。在您的情况下，如果有效实施，增加容器大小（或垂直缩放）和添加更多容器（或水平缩放）的策略都将起作用。

但首选水平缩放是最佳选择。当您启动容器集群时，它们运行在 AWS Elastic Loadbalancer 后面，如果您启用粘性会话，聊天室将不会有任何问题。

读这个

另外这本书读起来很安静。

然后是数据库问题，我假设您将为您的应用程序使用父数据库，因此所有容器都将从同一个数据库中读取，因此不必担心从一个容器应用的更改并看到从中应用的这些更改其他容器，如果适当的数据库优化到位，就不会有任何问题。