我想知道在这种情况下如何在物理上构建服务器。
假设我的服务在美国提供。
而且我的业务非常成功，所以我想扩大我在亚洲的业务地点。
但我不想本地化服务，所以我只是在亚洲获得了一些 API 服务器来提供服务，它只是使用位于总部的 API，但我的主要组件仍在美国。
但问题是我位于亚洲的 API 需要调用位于美国的总部 API，并且由于物理距离较远，响应往往很慢。
所以在这种情况下，我该如何克服？
在我看来，我得到了一些静态内容的 CDN。但我不知道如何改善源自物理距离的 API 响应时间问题。
如果这是一个愚蠢的问题，请理解，我是建筑师的新手。
编辑：
另外，在这种情况下如何构建数据库复制。
如果我得到一个从美国复制到亚洲的复制品，我认为复制性能很差，因为物理距离。
亚马逊或任何全球服务如何构建它？
【问题讨论】：
标签： server architecture system low-latency
复制性能可能很差。了解您的数据有多少变化非常重要，这样您就可以估计所需的带宽并了解您的复制是否可以跟上。
Amazon 和其他全球服务通过复制、边缘缓存 (CDN) 和其他使数据更接近消费者的方法的组合来解决这个问题。
作为第一步，您可能还想看看让您的 API 更粗粒度。您必须拨打的电话越少，性能就越高（因为问题可能是延迟，而不是带宽）。看看你是否可以批量处理而不是一次处理一个。
您还可以批判性地看待缓存。不要一直进行只读 API 调用，而是引入一些缓存控制标头来指定请求的可接受期限。很多数据都是非常静态的，比如用户数据、部门、产品信息等……其中一些数据可以利用缓存层来提高性能。
【讨论】：
如果您想使用 AWS 并希望在特定区域托管主要组件，那么您可以考虑在您选择的区域的 EC2(s) [作为源服务器] 中自己托管它并使用 Cloudfront (CDN)在全球范围内提供内容。 AWS 采用自己的高速骨干网络，通过减少网络跃点数来减少地理位置相距遥远的位置之间的延迟。
从缓存的角度来看，正如 Rob 所说，Cloudfront 为热对象、热对象（边缘缓存、区域缓存）执行不同的缓存机制；此外，源服务器可以通过 HTTP 标头发送最短过期时间和最长过期时间来定义缓存 TTL。
但是，如果您不想利用高速骨干网络的优势，则应考虑端点的应用程序设计和保持延迟的功能；并使用适当的 TTL 来缓存对象并定义适当的缓存策略，同时牢记应用程序的 R/W 比率。
【讨论】：