多区域时的 AWS 架构

Question

最近有人向我介绍了 AWS，我非常喜欢它。但是，我在问自己一些关于多区域架构的问题（这可能很愚蠢）。

假设一个应用程序被欧洲人和亚洲人使用。我的第一个想法是在欧洲添加 EC2 实例，以及用于保存静态数据的 S3 存储桶以及在欧洲添加 SQS 队列和 ElastiCache。对于欧洲人来说，这将是非常快的，但对于亚洲人来说会慢一些。

为了解决这个问题，我会为静态数据添加 CloudFront，以便为亚洲人快速提供图像。但是，对服务器的请求（Ajax 请求...）仍然会有一些延迟，因此解决方案是在新加坡/东京地区也添加一个 EC2 实例。

但是，出现了新问题：如果将请求分派到东京 EC2 实例，那么它是否需要从存储在欧洲的 SQS 接收消息或访问 ElastiCache 数据 => 再次延迟 + 区域间传输的成本。所以我们也需要在亚洲添加一个 SQS 和 ElastiCache 吗？

也许我错过了什么，跨区域的 AWS 请求非常快，但据我了解，如果我们想要多区域的快速体验，我们基本上需要在每个区域复制所有服务（S3 除外）也许，因为我们可以为此使用 CloudFront，而且我想如果亚洲的 SQS 作业需要访问欧洲的 S3 资源，我们可以忍受延迟）。

无论如何，我理解正确吗？您是否有任何有关如何构建面向多区域的应用程序的资源？

谢谢:)

Answer 1

这些根本不是愚蠢的问题！这部分是绝对正确的：

Maybe I miss something, and cross-regions AWS requests are super-fast, but from
what I've understood, if we want fast experience for multi-regions, we basically
need to duplicate all services too every regions

跨区域请求将受到光速和区域之间网络拓扑的限制。我预计来自亚洲的请求将在大约 1/4 秒的往返时间内到达欧洲应用程序。大多数请求会更快，但您不能保证所有请求都会更快，因此您必须相应地进行设计。如果这还不够快，那么是的，您需要部署到更近的区域并将用户路由到适当的区域。需要往返的次数取决于您的应用程序的体系结构。如果您对 Elasticache 或 SQS 有很多请求，那么这 1/4 秒将很快加起来。如果你可以批量处理请求，那可能是可以忍受的。

要将用户路由到适当的区域，您需要查看 Route 53，它是 AWS 系列的另一部分。 This announcement about Route 53 描述了您需要的区域之间基于延迟的路由。一旦用户被路由到适当的 EC2 实例，您部署到的每个区域都应该被隔离。您将使用 EC2、SQS、Elasticache 和任何其他 AWS 产品配置您的欧洲部署，这些产品均来自欧洲区域 (eu-west-1)。对于您的亚洲部署，您可以将其全部托管在 ap-southeast-1 区域中。一旦 Route 53 将亚洲用户连接到 ap-southeast-1 中的 EC2 实例，对 SQS、Elasticache 等的请求将在同一区域内，因此速度非常快。

Answer 2

Amazon Web Services 引入的实用程序模型可帮助您在多个区域部署相同的服务。相同的 CLI 命令/Web 控制台/CloudFormation 脚本在所有区域中以相同的方式运行。因此，在新加坡和欧洲推出类似的服务对您来说并不复杂。不仅如此，您还可以从同一位置管理所有这些 - 云的力量。

它也不会因为您为使用的东西付费而变得更加昂贵，并且如果您在区域之间分配负载，您将获得或多或少相同的成本。例如，如果您需要 10 台服务器来为您的用户提供服务，那么您可以在欧洲拥有 5 台服务器，在新加坡拥有 5 台服务器。超过;您可以使用auto-scaling 根据负载小时数在不同区域拥有不同数量的服务器。例如，欧洲醒着的时候欧洲有 8 个服务器，晚上新加坡只有 2 个，反之亦然。

通过将上述多区域服务（EC2、S3、ElasticCache、RDS...）与 Amazon CloudFront (CDN) 和 Route 53 (DNS) 相结合，您可以创建一个非常可扩展且价格合理的服务，并具有出色的延迟全球（欧洲、亚洲、北美和南美...）。