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

Question

我正在学习如何在银河系统上部署流星应用程序，我对所有这些容器的东西感到困惑。

我想了解何时通过增加容器大小而不是增加更多容器来缩放应用程序会更好。

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

2 x 0.5 containers = 1 x 1 container

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

我可以理解的唯一方法是： 缺少CPU和RAM，或者处理并行请求的能力都需要扩展。 如果应用程序收到太多的流量，你会得到更多的容器。 如果应用程序使用太多的CPU和RAM，则会得到更大的容器。

但是，应用程序如何变得太大而无法放入一个容器？应用程序使用的CPU和RAM不会与有多少用户正在使用该应用程序实例有关。难道你不能通过添加更多的容器和扩展用户来解决这个问题，并以这种方式减少CPU和RAM的使用。

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

Answer 1

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

但宁愿水平缩放是最好的选择。当您启动在AWS Elastic Loadbalancer后面运行的容器集群时，如果您启用了粘性会话，则聊天室中不会有任何问题。

阅读本

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html

而且这是静好读。

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch_alarm_autoscaling.html

https://aws.amazon.com/blogs/compute/powering-your-amazon-ecs-clusters-with-spot-fleet/

然后数据库的问题，我想你会使用父数据库为您的应用程序，以便所有的容器将同数据库进行阅读，所以不要担心应用更改从一个容器中查看并从其他容器中应用这些更改，如果正确进行了数据库优化，则不存在任何问题。