rest - 如何在 Heroku 上使用 REST API 后端优化静态文件服务

Question

这个问题可能有点主观，但我认为会提供一些有值(value)的具体信息和解决方案来代理到 heroku 和调试延迟问题。

我有一个使用 Sinatra/Mongo 构建的应用程序，它在 api.example.com 公开了一个 REST API。它在 Heroku Cedar 上。通常，我通过 www 上的 nginx 提供静态文件，并将对/api 的请求代理到 api 子域，以避免跨域浏览器投诉。我有一个 rackspace 云实例，所以我将前端暂时放在 nginx 上并设置代理。现在代理时的延迟非常可怕，每 3 或 4 个请求花费的时间超过 1 分钟，否则约为 150 毫秒。直接访问 API(浏览器访问 api.example.com)时，平均延迟约为 40 毫秒。虽然我知道设置并不理想，但我没想到会这么糟糕。

我认为这部分是由于从机架空间代理 - 服务器很可能位于西海岸 - 到 amazon ec2 east 上的 heroku。我目前的想法是获取一个亚马逊 ec2 实例并将其代理到我的 heroku 应用程序可以缓解这个问题，但我想以某种方式验证这一点而不是盲目猜测(它也更昂贵)。有什么合理的方法可以确定长延迟的来源吗？此外，关于如何构建此应用程序的任何其他建议？我知道我可以在 Heroku 上提供静态文件，但我不喜欢我的 API 为我的前端服务的想法，我宁愿这些能够相互独立地扩展。

Answer 1

由于您使用 Heroku 来运行您的 API，我建议将您的静态文件放入 Amazon S3 中。存储桶，名为“myapp-static”的东西，然后使用 Amazon Cloudfront通过 DNS CNAME 记录 (static.myapp.com) 代理您的静态文件。

在 Rackspace 上使用 S3 的好处在于:

• 您可以更快地从 Heroku 上传文件，因为您的应用程序和存储位于同一网络 (AWS) 上。
• S3 是为直接提供静态文件而构建的，没有运行您自己的服务器代理请求的开销。

使用 Cloudfront 的好处在于，它会根据需要缓存静态文件(减少多个 HTTP 请求)，并从离用户最近的端点提供文件。 EG:如果加利福尼亚的用户发出 API 请求并从您那里获取静态文件，他们将从 AWS 加利福尼亚服务器而不是您的东海岸 Heroku 实例提供该文件。

最后，您将在您的应用程序端做的是在您的 REST API 中向用户发送一个指向您的静态 Assets (例如:http://static.myapp.com/images/background.png)的链接，这样客户端负责直接下载内容，并将能够尽快下载 Assets 。