architecture - 多区域时的 AWS 架构

Question

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

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

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

但是，出现了新问题:如果将请求分派(dispatch)到东京 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 等的请求将在同一区域内，因此速度非常快。