Server 如果远程服务器位于很远的物理距离，如何提高响应时间

我想知道在这种情况下如何实际构建服务器

假设我的服务在美国提供

我的生意非常成功，所以我想扩大我在亚洲的业务

但我不想本地化服务，所以我在亚洲找到了一些API服务器来提供服务，只是使用总部的API，但我的主要组件仍然在美国

但问题是，我的API位于亚洲，需要调用位于美国的head-quater API，而且由于物理距离远，响应通常很慢

那么在这种情况下，我该如何克服呢

在我看来，我得到了一些静态内容的CDN。但是，我不知道如何改善源于物理距离的API响应时间问题

如果这是一个愚蠢的问题，请理解，我是一个相当新的建筑师

编辑： 另外，在这种情况下，如何构造数据库复制。
如果我在亚洲得到一个来自美国的复制品，我认为由于物理距离的原因，复制性能相当差。

---

亚马逊或任何全球服务公司是如何构建它的

复制性能可能非常差。了解您的数据有多少在变化是很重要的，这样您就可以估计所需的带宽，并了解您的复制是否能够跟上

Amazon和其他全球服务通过复制、边缘缓存（CDN）和其他使数据更接近消费者的方法相结合来处理这一问题

作为第一步，您可能还想看看如何使API更粗粒度。您拨打的电话越少，性能就越高（因为问题可能是延迟，而不是带宽）。看看你是否能把事情分批处理，而不是一次一个地处理

---

您还可以仔细研究缓存。与其一直进行只读API调用，不如引入一些缓存控制头来指定请求的可接受期限。很多数据都是静态的，比如用户数据、部门、产品信息等。。。其中一些数据可以利用缓存层来提高性能。

如果您想使用AWS并在特定区域托管主要组件，那么您可以考虑将其自己托管在您选择的区域的EC2中[作为源服务器]，并使用Cloudfront（CDN）在全球范围内为内容提供服务。AWS采用自己的高速主干网，通过减少网络跳数来减少地理位置遥远的位置之间的延迟

从缓存的角度来看，正如Rob所说，Cloudfront对热对象、热对象（边缘缓存、区域缓存）执行不同的缓存机制；此外，源服务器还可以通过HTTP头发送最小过期时间和最大过期时间，以定义缓存TTL

如果你不想利用高速骨干网络的优势，你应该考虑你的端点的应用设计和功能保持延迟作为约束；并使用适当的TTL缓存对象，并定义适当的缓存策略，同时牢记应用程序的R/W比率