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

Question

我正在研究大公司如何管理他们的公共API.我正在考虑拥有成熟的API的公司,如谷歌,Facebook,Twitter和亚马逊.

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

例如:可以在此层处理限制和身份验证,而不是在每个API群集中实现它.

问题:是否有人在其API前使用垫片或反向代理来处理常见任务？对于API服务器集群而言,反向代理是一个好主意还是坏主意的用例是什么？

Answer 1

大多数大公司都在探索各种各样的东西来处理服务器上的流量和负载.粗略地说:

1. 负载均衡器位于入口点和实际客户端之间.
2. 反向代理通常位于这些之间以处理静态文件,预先计算/呈现的视图以及其他这样的静态资产.
3. 任何强制转换都用于DNS目的,因此您将路由到最近的处理该URL的服务器.
4. 在系统中采用背压来限制通过单个管道馈送的请求量,从而使服务不会翻倒.
5. Memcached,Redis等用作短期缓存.也就是说,如果它每5秒大致相同的结果,那么该结果可以缓存在内存中以便更快地传递.某些代理可以配置为读出这些代理.

如果您真的很感兴趣,请开始阅读一些Netflix博客.看看他们使用的一些开源,如Hystrix或Zuul.您还可以查看他们的一些视频.他们大量使用代理,并内置了一些非常先进的分布式行为.

至于反向代理是一个好主意,请考虑失败.如果您的服务通过直接路由呼叫另一个API并且该服务失败,那么您的服务将失败并向上级联到最终用户.另一方面,如果它正在命中反向代理,那么可以配置该代理甚至自动检测故障并将流量转移到备份服务器.

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

像这样的黛西链接呈现出自己特别的小地狱,但它有时是不可避免的.如果你可以不惜一切代价避免它,那么缺点就是缺乏确定性行为.有时候最愚蠢的事情会让你的服务器崩溃.愚蠢的,我的意思是,真的,非常愚蠢的东西,你从未想过一百万年可能会咬你的屁股(认为服务器时钟不同步.)你必须开始使用滚动部署的代码,手动取下服务器或如果他们停止响应,并强制保持这些代理配置良好.

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

最后,在代理中添加还有一件事情会破坏(不能,将会).你必须像平台的任何一块一样监视它们,聚合它们的日志,并对它们运行模拟练习.