这是我第一次发布 Web 应用。我将使用 Django 和 Nginx 以及一些其他已传输的脚本。我想知道我可以使用哪种自动扩展策略。
现在，我正在试用免费的 EC2 微型实例。效果很好。
我不确定我是否能负担得起专用的 RDS。我正在寻找最具成本效益的配置。我考虑使用已设置负载均衡器的微型实例进行自动扩展，但我还没有弄清楚如何在所有实例中同步数据库。
我也在考虑其他替代方案，例如 App Engine 和 Heroku，但我认为它们不会给我像 VM 那样的自由。有没有一个 PaaS 可以让普通 VM 自动扩展而不用担心？
此外，它还有一些图表可以大致告诉我微型、小型等实例各自可以承受多少流量。
有人可以解释一下吗？
答案1
扩展应用程序是您在设计应用程序时必须具备的功能 - 无论平台如何。
一些考虑因素包括：
- 使文件（例如上传、源代码更改等）可供所有节点使用
- 在所有节点之间共享会话信息
- 跨多个节点复制数据库
- 确定节点的健康状况以及何时启动新节点
我建议最好的方法是先将数据库卸载到另一个实例。如果您的数据库和应用程序在不同的实例上运行，则可以独立扩展每个实例，这样可以更轻松地管理问题。（参见本文- 有点旧，但同样有效）。
其次，您需要进行纵向和横向扩展。使用 EC2，您可以从较大的实例类型中获得更好的性能 - 就性能而言，小型实例比 3 个微型实例更好。我的建议是扩展到两个节点（用于故障转移），然后在继续横向扩展（更永久地扩展）之前开始将节点切换到较大的实例类型。不过，无论如何，请保持自动扩展功能，以便您的应用程序可以随时处理额外的负载。
单独扩展数据库 - 通常，您的应用程序需要比数据库更多的节点（您的数据库可能会受益于更高内存的实例）。另请记住，RDS 不会为您进行扩展。
亚马逊不提供“流量”图表 - 因为这完全取决于您的应用程序（高度动态且处理器密集型的应用程序可以处理的请求比在相同硬件上提供静态页面的应用程序少得多）。但是，它确实提供了有点“主观”的比较这里值得强调的一点是“I/O 性能”。此描述符包括网络带宽和磁盘 i/o。较小的实例更容易受到性能变化的影响（尤其是可用带宽）。由于 EBS 卷需要网络带宽，这也会影响其性能。
至于微型实例 - 只要您的应用程序认为有必要，就升级到小型实例。您会发现，每当您在微型实例上“爆满” CPU 时，性能都会随之下降（由顶部的“窃取”值表示）。其他实例（您不拥有的）可能会在微型实例上使用大量 CPU。
还值得一提的是，您可以将自动缩放组的大小设置为“1”，这样您就可以在实例不可用时重新启动实例。（但是，出现的问题是，由于它是从快照启动的，因此如何在新实例上恢复当前数据）。
如果您可以使用 MySQL 集群（它使用不同的存储引擎 - ndbcluster）或具有分片的 NoSQL 解决方案，那么与使用 MySQL 中的传统主从复制相比，自动扩展数据库会容易得多。（据报道，另一种解决方案也取得了一些成功，但我可能不会建议现在使用 - 使用分布式文件系统（特别是 GlusterFS）来存储数据库 - 文件系统管理文件锁定和分发，每个实例根据需要访问数据库 - 当您添加更多实例时，这会遇到问题，但使用 2 节点数据库集群可能会取得一些成功）。
因此，实际的做法可能是：
- 从 1 个包含数据库和应用程序的微实例开始
- 将数据库分离为一个实例，将应用程序分离为另一个实例
- 在您的应用程序实例上设置自动缩放。
- 添加第二个应用程序节点
- 添加第二个数据库节点并配置节点之间的复制（如果您选择使用 MySQL 集群或 NoSQL 解决方案，则您也应该能够设置自动缩放）。
- 根据需求，一次将一个实例升级到更大的实例大小
（您应该发现，对于大多数站点来说，2 个较大的实例足以运行您的数据库，特别是如果您正确实现缓存，但根据需要添加额外的从属实例应该不会太麻烦）。
上述操作过程相当好地解决了扩展问题，但在第 4 步之前确实存在单点故障（即，如果数据库节点发生故障，应用程序就会停止运行）。一个更困难但更具弹性的设置是，将应用程序和数据库放在同一个节点上，然后使用 MySQL 复制设置该节点的两个副本（并使用 MySQL 代理来处理来自负载平衡器的请求） - 您需要自行管理故障转移（使用 Heartbeat/Pacemaker 之类的东西），然后直接转到 4 个节点（2 个数据库，2 个应用程序）。