如果远程服务器的物理距离非常遥远，如何改善响应时间

Question

我想知道在这种情况下如何物理构建服务器。

让我们假设我的服务在美国提供。

我的业务非常成功，所以我想扩大在亚洲的业务范围。

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

但是问题是我位于亚洲的API需要调用位于美国的总部API，而且由于物理距离较远，响应速度通常很慢。

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

我认为我得到了一些CDN的静态内容。但我不知道如何改善源自物理距离的API响应时间问题。

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

编辑： 另外，在这种情况下如何构造数据库复制。
如果我得到的复制品是从亚洲的美国复制过来的，则由于物理距离，我认为复制性能相当差。
亚马逊或任何全球服务如何构建它？

Answer 1

复制性能可能很差。了解您要更改的数据量非常重要，这样您就可以估算所需的带宽并了解复制是否可以跟上。

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

第一步，您可能还想看看仅使您的API更粗糙。您必须进行的呼叫越少，性能就越高（因为问题可能是延迟，而不是带宽）。看看是否可以分批处理而不是一次处理。

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

Answer 2

如果您想使用AWS并希望在特定区域内托管主要组件，则可以考虑将其自己托管在所选区域的EC2中（作为Origin Server）并使用Cloudfront（CDN）在全球范围内投放内容。 AWS利用自己的高速骨干网，通过减少网络跳数来减少地理位置相距较远的位置之间的延迟。

从缓存的角度来看，正如Rob正确说的那样，Cloudfront对热对象，热对象（边缘缓存，区域缓存）执行不同的缓存机制。原始服务器还可以通过HTTP标头发送最小到期时间和最大到期时间，以定义缓存TTL。

但是，如果您不想利用高速骨干网的优势，则应考虑端点的应用程序设计和功能性，并将延迟作为限制；并使用适当的TTL来缓存对象并定义适当的缓存策略，同时牢记应用程序的R / W比。