您如何使用 EC2 在多个服务器上分发您的应用程序？

Posted 2023-03-04

【中文标题】您如何使用 EC2 在多个服务器上分发您的应用程序？

【英文标题】：How do you distribute your app across multiple servers using EC2?

【发布时间】：2012-11-06 15:02:15

【问题描述】：

我第一次开发需要大量扩展的应用程序，我以前从未有过需要在多个实例上运行的应用程序。

这通常是如何实现的？我是否集群 SQL 服务器，然后在所有服务器上镜像编程并使用负载平衡？

或者我是否应该分离出在一台服务器上运行一些在另一台服务器上运行的功能？

另外，我如何将代码推送到我的所有 EC2 Windows 实例？

【参考方案1】：

这取决于您的要求。但作为一般准则（我假设是一个网站），我会将数据库、网络服务器、缓存服务器等分离到不同的实例，并将s3(+cloudfont) 用于静态资产。我还会确保适当的速率限制到位，以便基础架构上只有合法负载。

对于 RDBMS 服务器，我可能会设置一个主从数据库设置（RDS 使这更容易），使用数据库分片等。数据库集群解决方案也存在，它的设置将更加复杂，但简化了应用程序程序员的数据库访问。我还将检查所有数据库查询并相应地调整 db/sql 查询。在某些情况下，纯 NoSQL 类型的数据库可能比 RDBMS 或两者的混合更好，应用程序根据所需的数据在它们之间切换。

对于网络服务器，我将设置一个负载平衡器，然后在负载平衡器后面的网络服务器实例上使用自动缩放。如果有的话，类似的东西将适用于应用服务器。我还将调整网络服务器设置。

缓存服务器也将被分离到其实例集群中。 ElastiCache 似乎是一项不错的服务。 Redis 具有与 memcache 相当的性能，但具有更多功能（如列表、集合等），在扩展时可能会派上用场。

【参考方案2】：

免责声明 - 我不会提及任何 Windows 细节，因为我一直在 Unix 机器上工作。这些指南相当通用。

这是一个主观问题，每个人都会以独特的风格定制自己的系统。以下是我遵循的一些准则。

如果是 Web 应用程序，请将表示层（前端）、中间件 (API) 和数据库层分开。与单体应用程序相比，切片架构的扩展性最好。

数据库 - Amazon 为 SQL 和 NoSQL 数据存储提供出色且高度可用的服务（除非您位于 us-east 可用区）。您可能想查看 RDS 的关系数据库和 DynamoDb 的 NoSQL。两者都可以很好地扩展，一旦启动它们，您就不必担心管理和加载数据存储的分片/集群。 中间件 API - 这是一个关键部分。拥有一组将后端功能公开为服务的 API（最好是 REST，但您几乎可以在这里使用任何东西）非常重要。面向服务的架构可以很容易地扩展以满足多个前端客户端的需求，例如网络、移动、桌面、第三方小部件等。中间件 API 通常不应该是处理业务逻辑的地方 ，其中大部分（或全部）应转换为数据库查找/查询以获得更高的性能。可以对这些服务进行负载平衡以实现高可用性。亚马逊的Elastic Load Balancers (ELB) 非常适合初学者。如果您想进行更多自定义，例如阻止特定 IP 地址集的流量、执行Blue/Green deployments，那么也许您应该考虑将 HAProxy 负载平衡器部署到单独的实例。 前端 - 这是您的表示层应该驻留的地方。它应该避免任何直接的数据库查询，除了那些仅限于前端范围的查询，例如：一个简单的 Redis 调用来获取前端片段的最新缓存键。在这里，您几乎可以执行大量缓存，从服务调用到前端片段。您可以将AWS CloudFront 用于静态资产交付，将AWS ElastiCache 用于您的缓存存储。 ElastiCache 只不过是一个托管的 memcached 集群。您甚至应该考虑对 ELB 后面的前端节点进行负载平衡。

所有这些都可以使用AWS Elastic Beanstalk 与 AutoScaling 捆绑和部署。它目前支持 ASP .NET、php、Python、Java 和 Ruby 容器。 AWS Elastic Beanstalk 仍然有其自身的局限性，但它是一种非常酷的方式来管理您的基础设施，同时监控、扩展和负载平衡的麻烦最少。

提示：识别应用程序的读取和写入密集区域有很大帮助。然后，您可以继续对您的基础架构进行相应的切片，并一次执行所需的优化，并以读取或写入为重点。

总而言之，Amazon AWS 拥有几乎所有您可以用来制作服务器拓扑的东西。您可以选择组件。

希望这会有所帮助！

【参考方案3】：

我的做法是，将 1 台服务器作为数据库服务器，并在其上运行 mysql。我在 memcached 上的所有数据，它可以跨越多个服务器和我的客户端，只需一个简单的“如果不在 memcached 上，则从 db 读取，将其放在 memcached 上并返回”。

与数据库相比，Memcached 非常易于扩展。数据库扩展需要大量的管理工作。让它正确和工作是一件痛苦的事。所以我选择了memcached。事实上，我有额外的 memcached 服务器，只是为了管理停机时间（如果有我的 memcached 服务器）。

我的数据主要是读取，很少写入。当写入发生时，我也将数据推送到 memcached。总而言之，这对我来说更好，代码，管理，回退，故障转移，负载平衡方式。都赢了。你只需要更好地编写“一点”代码。

集群 mysql 更有吸引力，因为它似乎更容易编码、部署、维护以及跟上和执行。记住 mysql 是基于硬盘的，而 memcached 是基于内存的，所以本质上它更快（至少 10 倍）。而且由于它接管了数据库的所有读取负载，因此您的数据库配置非常简单。

我真的希望有人在这里指出一个相反的论点，我很想听听。