提供API的公司是否在他們的API之前使用墊片或代理？

Question

我正在研究大公司如何管理他們的公共API。我正在考慮擁有成熟的API（如Google，Facebook，Twitter和Amazon）的公司。

這些公司有許多不同的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。你也可以看看他們的一些videos。他們大量使用代理，並建立了一些非常先進的分佈式行爲。

至於反向代理是一個好主意，請考慮失敗。如果您的服務通過直接路由呼叫另一個API並且該服務失敗，那麼您的服務將失敗並向上級聯到最終用戶。另一方面，如果它打到反向代理，那麼可以配置該代理，甚至可以自動檢測故障並轉移流量以備份服務器。

只要反向代理是一個好主意，請考慮負載。有時服務器只能單獨處理一部分流量，因此必須在許多服務器上共享負載。這不僅僅是CPU上限，而且IO上限的資源也是如此（即使返回信號本身不會成爲IO上限的原因）。

像這樣的菊花鏈呈現出自己特殊的小地獄，但它有時是不可避免的。在不利的方面，如果你可以不惜一切代價避免它，那麼它是一個非常糟糕的選擇，這是一種確定性行爲的喪失。有時候最愚蠢的事情會導致你的服務器失效。愚蠢的，我的意思是，真正愚蠢的東西，你從未想過在一百萬年內可能會讓你陷入困境（認爲服務器時鐘不同步）。）您必須開始使用滾動部署的代碼，手動或強制停止響應服務器，並保持這些代理配置的順序。

對HTTP1.1的支持也是一個問題。並非所有的反向代理都符合規範。實際上，其中一些只覆蓋了〜50％。 HAProxy不會執行SSL。如果你只有有限的硬件，那麼基於線程的代理可能會意外地用線程淹沒系統。

最後，在代理中添加還有一件事情會中斷（不會，將會）。您必須像監視它們一樣監視它們，聚集它們的日誌，並對它們運行模擬演習。