从多区域 AWS API 中移除隐藏的往返请求 文章

直到最近，亚马逊云科技全球路由服务的每个新客户端会话都会以一个请求开始。该请求的唯一目的是确定应使用哪个 AWS 区域进行身份验证。我们采用这一临时解决方案多年，直到最近才将其移除。推动我们这样做的原因并非出于延迟方面的考虑，而是源于一系列区域性服务中断事件。我们构建服务时的限制条件本文将要介绍的是由我和我的团队在亚马逊云科技内部运行的一项用户设置服务。该服务供其他需要快速、低延迟访问用户设置的亚马逊云科技团队在内部使用。我们的服务存储着在应用程序启动时会被调用的用户状态，可以将其看成是无论用户身处何地都需要快速加载的设置。该服务的架构如下：在两个区域内部署 API Gateway（APIGW）REST API，配置基于延迟的 Route 53 路由，并让基础设施自动决定流量的着陆点。在集成 AWS Identity and Access Management (IAM) 时，我们遇到了一个限制。由于我们是按身份存储设置，所以需要在 APIGW 中使用 IAM 身份验证。当时，唯一的选择是使用 AWS Signature Version 4 （SigV4）。SigV4 是用于受 IAM 保护的 API Gateway 请求的身份验证方案。它将每个已签名的请求与特定的服务和区域绑定。在签名过程中，区域信息会被嵌入到凭证作用域"中。也就是说，如果针对 us-west-2（俄勒冈）签名的请求到达 eu-west-1（爱尔兰），则该请求在加密层面上将被视为无效。在请求被处理之前，签名验证就会失败。这种区域绑定限制导致了一种权衡：我们希望让基础设施（DNS 服务 Route 53）来决定由哪个区域提供服务，但客户端必须先确定一个区域，才能构建出有效的请求。因此，我们围绕这一限制构建了我们的服务。作为临时解决方案，我们实现了一个云区域上线前的探测步骤。首先，客户端会调用一个轻量级的 DiscoverRegion 端点。由于其唯一作用是返回区域名称，所以不需要身份验证。这样可以确定哪个区域“最近”，将该结果缓存起来，然后使用 SigV4 对该区域内的所有后续调用进行签名。总体而言，初始请求时需要发送两个请求才能完成一项操作。这成为了我们的生产架构，并且多年来运行良好。