提供API的公司是否在其API前面使用垫片或代理？

我正在研究大公司如何管理他们的公共API。我想到的是那些拥有成熟成熟API的公司，比如谷歌、Facebook、Twitter和亚马逊

这些公司向公众公开了许多不同的API。例如，谷歌有Plus、AdSense、AdWords等可公开使用的api。我想了解他们是否在这些API前面使用一组反向代理服务器来提供通用功能，这样他们的专业API服务器就不需要实现这些功能

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

---

问题：是否有人在其API前面使用垫片或反向代理来处理常见任务？哪些用例使反向代理成为API服务器集群的一个好主意或坏主意？

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

负载平衡器位于入口点和实际客户端之间

反向代理通常位于这两者之间，用于处理静态文件、预计算/渲染视图以及其他此类基本上是静态的资产

任何强制转换都用于DNS目的，因此您将被路由到最近的处理该URL的服务器

在系统中使用背压来限制通过单个管道传送的请求量，从而使服务不会倾覆

Memcached、Redis等用作短期缓存。也就是说，如果每5秒的结果大致相同，那么该结果可以缓存在内存中，以便更快地传递。一些代理可以配置为读取这些数据

如果你真的感兴趣，开始读一些Netflix的博客吧。看看他们使用过的一些开源软件，比如或。你也可以看看他们的一些产品。它们大量使用代理，并内置了一些非常高级的分布式行为

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

至于反向代理是一个好主意，请考虑负载。有时服务器只能单独处理一小部分流量，所以负载必须在多个服务器上共享。这不仅适用于CPU封顶资源，也适用于IO封顶资源（即使返回信号本身不是IO封顶的原因）

像这样的菊花链呈现出它自己特殊的小地狱，但有时是不可避免的。如果你能不惜一切代价避免它，那么它的缺点和真正糟糕的选择就是失去了确定性行为。有时最愚蠢的事情会让你的服务器停机。所谓愚蠢，我的意思是，真的，真的，真的愚蠢的东西，你从来没有想过在一百万年内会咬你的屁股（想想服务器时钟不同步）。你必须开始使用滚动部署的代码，手动或强制关闭服务器，如果他们停止响应，并保持这些代理配置的良好秩序

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

---

最后，添加代理是另一件会破坏的事情（不是can，will）。您必须像平台的任何部分一样监视它们，聚合它们的日志，并在它们上运行模拟演练

我很抱歉，我必须这么含糊，不能给出实际的系统配置，保密协议和完整的回答。