[[375497]]

簡介

• 網關主要服務于微服務/API，偏向研發人員
• 反向代理主要面向傳統靜態web應用，偏向運維
• 而未來趨勢是DevOps+網關和反向代理再次融合

發展演進史

WEB1.0/2.0時代，使用前置反向代理，由運維負責 nginx，進行反向代理和負載均衡、安全認證、限流緩存等功能。網站升級頻率較低，反向代理大多采用靜態配置方式。

微服務時代，API 服務升級頻率高，傳統的 nginx 動態配置較差，且運維執行效率低，就需要使用動態配置的網關服務，便于研發自主配置。

云原生時代提出更高要求，還需要支持灰度發布。要求網關不僅可動態配置，還要能動態編程，所以出現網關和反向代理融合的趨勢，典型產品比如 envoy 和 Traefik。

云原生時代下的可編程網關

在k8s中，和網關等價的概念叫Ingress，像kong/envoy/traefik這些可編程網關，都有支持對接Ingress。

所有不同的端，ios 安卓 h5 web，要不要分，還是要看業務和團隊規模，比如攜程內部就有超過十套以上面向不同端的網關，總網關集群規模超過百臺。對大體量多團隊的公司，網關如果分的不夠，不同團隊容易打架。微服務也是這個道理，服務分分多少多細，也主要看體量和團隊規模，小團隊不分也沒事。

安全認證要求，對于不同部門可能不一樣，比如支付部門要求更嚴格，所以可以獨立定制部署。

總之nginx偏運維，spring gateway對中國java程序員更友好。

二者概念區分

如果你意識到它們不是互斥的，則更容易考慮它們。將API網關視為特定類型的反向代理實現。

經常將兩者結合使用時，API網關被視為位于反向代理后面的應用程序層，以進行負載平衡和運行狀況檢查。一個例子就是類似WAF的三層結構，其中Web應用程序防火墻/ API網關被反向代理層夾持，其中一個反向代理層用于WAF本身，另一個用于與之對話的單個微服務。

關于差異，它們非常相似。這只是術語。當進行基本的反向代理設置并開始使用更多功能(如身份驗證，速率限制，動態配置更新和服務發現)時，人們更有可能調用該API網關。

反向代理+網關部署架構

由于架構演進的歷史原因，很多公司都是反向代理和網關并存的架構

這樣就得維護兩套系統，肯定比較復雜，所以最好是結合統一：

參考

https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy

本文轉載自微信公眾號「 JavaEdge」，可以通過以下二維碼關注。轉載本文請聯系 JavaEdge公眾號。