根据区域进行 Api 重定向

Posted 2023-03-28

【中文标题】根据区域进行 Api 重定向

【英文标题】：Api redirection according to region

【发布时间】：2021-12-27 12:42:36

【问题描述】：

我们的应用程序位于美国和欧盟两个地区，我们的客户可以属于任何地区。 我们有一个端点，例如： 美国 - www.example.com 欧盟 - eu.example.com

我们有一个场景，如果我们调用任何 API，例如 https://www.example.com/api/v1/getDoc?access_token=ACCESS_TOKEN 所以它将根据客户区域重定向请求。 假设上述访问令牌属于欧盟，那么请求将重定向到 eu.example.com

解决方案 1- 如果我们使用“aws lamda 函数”和一个全局表（假设 Dynamo db）来检查客户端区域，那么 如果请求包含多部分，则会导致延迟问题和 base64 字符串。

对于这种方法，我需要一些更好的解决方案。这样我们就可以克服这个延迟问题。 或者其他更好的解决方案将不胜感激。

【参考方案1】：

结合使用 CloudFront 和 Route53，可以构建和托管您的系统，以便始终从地理位置最近的 AWS 区域为最终用户提供服务。 有关 Route53 中可用路由策略的详细信息，请参阅Choosing a routing policy。 哪种策略最适合取决于您的应用程序的架构（即您是否有主动-被动设置或您的应用程序是分布式的，以及其他标准）。

因此，本质上，使用 CloudFront（可能还有 Lambda@edge），可以让美国门户网站 (www.example.com) 和欧盟门户网站 (eu.example.com) 遍布全球，以缓解（网络) 延迟问题（请参阅CloudFront features 了解 CloudFront 可以为您做什么）。

但请注意，跨多个区域托管分布式应用程序通常需要对架构以及存储（以及可能复制）数据的位置和方式进行适当的认真思考。

尚不完全清楚您的实际用例是什么，以及为什么需要划分用户的根本原因和驱动因素是什么，但这不是问题的一部分，因此是有关应用程序架构的另一个问题的主题和设计，所以我不会对此发表评论。

简而言之，使用 Route53 和 CloudFront，您可以将用户重定向到两个不同的 URL，但在适当的底层应用程序设计的情况下，通过从地理位置“接近”的位置提供两个 URL，仍然可以获得良好的用户体验。

【讨论】：

嗨@Martin，感谢您的建议，我们正在使用 cloundfront 和 lamda@Edge ...但是在多部分请求的情况下我们会遇到延迟问题。因为首先流到 lamda@edge 并从那里通过检查 dynamo db 重定向到特定区域。因此，与直接调用 eu.example.com 之类的 url 相比，此过程需要一些时间。而且我们不能根据他们的地理区域重定向请求。在 Dynamo db 中，我们记录了哪个访问令牌属于哪个区域。

有可能美国属于美国地区，但他的账户在欧盟

嗨@Govind，感谢您稍微澄清问题描述。像这样重新表述您的问题是否公平：客户正在“附近”区域与 AWS 交谈，但没有满足请求所需的资源？就像我暗示的那样，您可能想退后一步，重新考虑您的架构。您应该问自己的两个主要问题是：a）我如何获得满足那里的请求所需的计算 + 数据？，或 b）我如何（立即）将请求发送到需要计算 + 数据的地方完成请求位于？

但是关于任何架构问题的讨论（本身非常有趣）听起来更像是与原始问题分开的主题。