应用部署容器大小与数量答案

【问题标题】：App Deployment Container Size vs Quantity应用部署容器大小与数量
【发布时间】：2016-07-24 09:18:20
【问题描述】：

我正在学习如何在galaxy 上部署一个流星应用程序，我真的被所有这些容器的东西弄糊涂了。

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

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

2 x 0.5 containers = 1 x 1 container

两种方法的成本都是一样的。

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

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

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

你为什么需要更多的容器来处理更多的请求。更大的容器不是也能处理更多的请求吗？

【问题讨论】：

【解决方案1】：

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

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

阅读本文

这本书也很好读。

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

【讨论】：