貓頭鷹的深夜翻譯：API閘道器的重要性
前言
在非技術術語中，“閘道器或門是進入一個由牆圍住的封閉空間的入口點。”同理，API閘道器是指位於防火牆或網際網路後面
的服務的入口點。在微服務的世界中，閘道器坐鎮於API前面，直接面向客戶並進行反向代理。
越來越多的應用程式正在從單片架構遷移到微服務架構。API閘道器已成為微服務架構模式中的關鍵元件之一。請
注意，本文不是關於任何特定閘道器，而是討論閘道器的一般功能。
作為代理的閘道器
在瞭解閘道器及其職責之前，讓我們先來看看代理是如何工作的。代理伺服器充當網橋，使內部網路對網際網路不可見。代理伺服器有兩種型別：轉發代理和反向代理。
轉發代理是面向網際網路並從網際網路檢索資料。與此相反的，反向代理位於內部網路中，接受來自Internet的請求，並將它們轉發到內部網路中的伺服器。
閘道器是一種反向代理模式，可以保護對專用網路上伺服器的訪問，儘管它們不是互斥的。
API閘道器模式
API閘道器有許多功能，現在讓我們深入瞭解閘道器的職責。
安全性
您可能認為已經為您的體系結構設定了安全層，例如使用HTTPS加密請求。我為我的私人網路設定了防火牆。我已經為我的請求等添加了身份驗證等等。
但是閘道器還可以從其他安全方面幫助管理來自客戶端的請求。
CORS
閘道器可以實現CORS（跨源資源共享）過濾器並具有處理跨域請求的能力。 CORS 是支援跨域請求，允許訪問受限資源的機制。根據瀏覽器提交的原始URL，
大多數閘道器攔截傳入的HTTP請求並識別它們是否是跨域的，並在將請求轉發到跨域資源之前使用請求頭中所需要的資訊。
DDoS和SQL注入
由於所有流量都通過閘道器路由，因此有一個額外的優勢就是過濾掉了不安全的請求。許多閘道器都善於清理SQL注入等常見的危險的輸入。
閘道器提供了一種防禦機制來識別 DDoS 攻擊，例如當請求轟炸伺服器時能防止中斷核心服務。
你可以進行多層保護。比如，AWS提供AWS護盾的服務，在請求到達閘道器或者ELB之前識別使用峰值。閘道器就類似於這樣的一層防護，可以利用其功能來防止攻擊。
授權和認證
由於閘道器是請求的入口點，因此它始終是授權和驗證終端使用者的更好地方。這有助於保持後端服務的完整性，因為無效的請求甚至都無法到達業務層。
在API閘道器進行授權和認證管理最好的方法就在於使用OAuth並建立握手。
證書管理
API閘道器可以使用自己的keyStore和trustStore管理證書。許多商業閘道器都可以在商店中建立/匯入證書，並在客戶端和閘道器之間建立SSL。
如果您有API閘道器作為後端服務的入口點，那麼最佳做法之一是在您的閘道器和後端服務之間使用SSL。由於Gateway和後端服務位於內部網路中，因此除了SSL之外，您不需要額外的安全層。
如果您有一個大規模分散式叢集以獲得高效效能，您甚至可以在流量到達閘道器後在負載均衡器上執行終止SSL。
API控制和管理
請求限制和配額
你的API請求可能來自多個渠道，你可能希望根據與渠道或客戶的服務協議對請求進行限制。最初，你與渠道或客戶簽訂服務水平協議（SLA），以確保滿足他們的期望並確定他們不會遇到任何中斷的情況。
此外，這將有助於隔離渠道，並根據商定的交易或非功能性需求相應收取費用。例如，你可能會收到來自移動端的大量請求，您可以根據傳入流量啟用TPS，並記下可以收取費用的交易量。
這樣，API貨幣化可以專門針對客戶端完成。
還可以通過配額管理，規定指定時間間隔內可以提交的最大請求數。這通常稱為配額限制，在上述與客戶簽訂服務協議的情況下非常有用。
那麼，還有那些東西是可以通過API閘道器限定的呢？由於所有請求都流經閘道器，因此您可以在入口點非同步記錄所有事務，並在以後跟蹤以進行審計，以滿足合同的要求。
因此，API閘道器減輕了從應用程式的功能層管理客戶端需求的負擔。
監控
僅管可以在應用程式中插入許多APM工具，但閘道器也可以提供實時API監控，以便分析其使用趨勢。
API主機
那麼，閘道器如何知道它應該接受哪個API以及拒絕哪個API？其實我們可以將API附到閘道器上，在上面配置請求引數，應用路由策略（如果需要），附加其他請求等。
正如我們之前討論的那樣，可能有多個渠道的請求流入應用程式，但並非所有渠道都需要訪問所有的API。在這種API治理方案中，您可以配置客戶端特定要求，
並將流量路由到客戶端要訪問的那些API。預設情況下，可以在閘道器上強制拒絕所有策略，並將那些預先加入的API列入白名單。
編排
您可能希望與來自不同微服務的不同API進行互動，然後聚合資訊。您可以通過解除安裝組合服務的編排來在閘道器中編寫實現此邏輯。但這不是推薦的方式，因為這會使API閘道器和應用程式緊密耦合，考慮到你可以隨時擺脫閘道器。
請求響應的過濾
什麼要在閘道器中而不是在應用程式，比如Java中的servlet過濾器中過濾響應，？讓我們參考一個例子。
假設您希望維護一個通用的微服務，這些微服務服務於不同的地理位置，API可以從世界不同地區訪問並由不同渠道使用。每次向渠道/客戶端傳送響應時，
都會發送該渠道可能根本不不需要的資訊。在這裡，我們可以使用閘道器的功能，過濾響應，並僅傳送特定渠道所需的內容。注意：通過對渠道到響應對映執行額外的查詢，可能會帶來一定的延遲。
閘道器的型別
API的廣泛採用促成了現成的API管理產品，開源專案和SaaS產品的出現。
為應用選擇哪種閘道器？
這取決於您是否要使用各種商業工具來設定API管理平臺。很多商業的Saas工具都提供管理軟體的豐富的功能。這一切都取決於你如何設計系統並使其適合微服務架構。
當選擇閘道器時，需要考慮如可擴充套件性，高可用性和彈性等因素。
開源閘道器如何？
有部分開源閘道器也提供了API管理的靈活性。這種閘道器的優勢在於它們可以與應用伺服器一起水平擴充套件，提供跨容器的分散式特性。
最後，每個商業/開源閘道器都會試圖推銷自己，如果你找到一個合適的閘道器，我建議最好不要重新發明輪子，而是利用它的功能並根據你的具體要求進行定製。
閘道器的可擴充套件性
可以通過在多個主機上部署多個API閘道器並使用標準負載平衡器對它們進行負載平衡來實現可用性和水平可伸縮性。這還取決於你在應用程式伺服器前部署的閘道器型別。
另一種常見做法是將CDN設定為閘道器前的靜態內容快取層。
閘道器反模式
我們已經討論了很多關於API閘道器及其特性的問題，現在讓我們來看看一些閘道器反模式。
- 確保API閘道器不會成為單點故障。
- 無論應用程式設計的多好，都有可能與API閘道器緊密耦合。
- 閘道器會為端到端響應時間帶來額外的延遲。
- 潛在的效能瓶頸
- 如果沒有明智地選擇閘道器，將會增加額外的運營開銷和成本。