api - 提供 API 的公司是否在其 API 之前使用填充程序或代理？

Question

我正在研究大公司如何管理其公共(public) API。我想到的是拥有成熟 API 的公司，例如 Google、Facebook、Twitter 和 Amazon。

这些公司向公众公开了许多不同的 API。例如，Google 拥有可供公开使用的 Plus、AdSense、AdWords 等 API。我想了解他们是否在这些 API 前面使用反向代理服务器集群来提供通用功能，以便他们的专业 API 服务器不需要实现该功能。

例如:节流和身份验证可以在这一层处理，而不是在每个 API 集群中实现。

问题:是否有人在 API 之前使用填充程序或反向代理来处理常见任务？对于 API 服务器集群来说，哪些用例使反向代理成为好主意或坏主意？

Answer 1

大多数大公司都会探索各种方法来处理其服务器上的流量和负载。粗略地说:

1. 负载均衡器位于入口点和实际客户端之间。
2. 反向代理通常位于它们之间来处理静态文件、预先计算/渲染的 View 以及其他此类大部分静态资源。
3. 任何转换都会用于 DNS 目的，以便您被路由到处理该网址的最近的服务器。
4. 系统中采用背压来限制通过单个管道传输的请求量，确保服务不会崩溃。
5. Memcached、Redis 等用作短期缓存。也就是说，如果每 5 秒结果大致相同，则可以将该结果缓存在内存中以加快交付速度。某些代理可以配置为读取这些内容。

如果您真的感兴趣，请开始阅读 Netflix 博客的一些内容。看看他们使用过的一些开源代码，例如 Hystrix或Zuul 。您还可以看看他们的一些videos 。他们大量使用代理并内置了一些非常先进的分布式行为。

就反向代理是否是个好主意而言，请从失败的角度进行思考。如果您的服务通过直接路由调用另一个 API 并且该服务失败，那么您的服务将失败并向上级联到最终用户。另一方面，如果它遇到反向代理，则可以配置该代理，甚至可以自动检测故障并将流量转移到备份服务器。

就反向代理是否是一个好主意而言，请从负载方面考虑。有时，服务器只能单独处理一小部分流量，因此必须在许多服务器上共享负载。这不仅适用于 CPU 上限，也适用于 IO 上限资源(即使返回信号本身不是 IO 上限的原因。)

像这样的菊花链有其特殊的小 hell ，但有时是不可避免的。不利的一面是，如果你可以不惜一切代价避免它，那么它是一个非常糟糕的选择，那就是失去了确定性行为。有时最愚蠢的事情会让你的服务器瘫痪。所谓愚蠢，我的意思是，真的，真的愚蠢的东西，你从未想过一百万年可能会咬你的屁股(认为服务器时钟不同步。)你必须开始使用代码的滚动部署，手动关闭服务器或如果他们停止响应，请强制执行，并保持这些代理配置处于良好状态。

HTTP1.1 支持也可能是一个问题。并非所有反向代理都遵守规范。事实上，其中一些仅覆盖约 50%。 HAProxy 不执行 SSL。如果您的硬件有限，那么基于线程的代理可能会意外地用线程淹没系统。

最后，添加代理是另一件会破坏的事情(不是可以，而是会破坏)。您必须像平台的任何部分一样监视它们，聚合它们的日志，并对它们运行模拟演练。