[[375497]]

簡介

• 網(wǎng)關(guān)主要服務(wù)于微服務(wù)/API，偏向研發(fā)人員
• 反向代理主要面向傳統(tǒng)靜態(tài)web應(yīng)用，偏向運維
• 而未來趨勢是DevOps+網(wǎng)關(guān)和反向代理再次融合

發(fā)展演進史

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

微服務(wù)時代，API 服務(wù)升級頻率高，傳統(tǒng)的 nginx 動態(tài)配置較差，且運維執(zhí)行效率低，就需要使用動態(tài)配置的網(wǎng)關(guān)服務(wù)，便于研發(fā)自主配置。

云原生時代提出更高要求，還需要支持灰度發(fā)布。要求網(wǎng)關(guān)不僅可動態(tài)配置，還要能動態(tài)編程，所以出現(xiàn)網(wǎng)關(guān)和反向代理融合的趨勢，典型產(chǎn)品比如 envoy 和 Traefik。

云原生時代下的可編程網(wǎng)關(guān)

在k8s中，和網(wǎng)關(guān)等價的概念叫Ingress，像kong/envoy/traefik這些可編程網(wǎng)關(guān)，都有支持對接Ingress。

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

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

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

二者概念區(qū)分

如果你意識到它們不是互斥的，則更容易考慮它們。將API網(wǎng)關(guān)視為特定類型的反向代理實現(xiàn)。

經(jīng)常將兩者結(jié)合使用時，API網(wǎng)關(guān)被視為位于反向代理后面的應(yīng)用程序?qū)?，以進行負載平衡和運行狀況檢查。一個例子就是類似WAF的三層結(jié)構(gòu)，其中Web應(yīng)用程序防火墻/ API網(wǎng)關(guān)被反向代理層夾持，其中一個反向代理層用于WAF本身，另一個用于與之對話的單個微服務(wù)。

關(guān)于差異，它們非常相似。這只是術(shù)語。當(dāng)進行基本的反向代理設(shè)置并開始使用更多功能(如身份驗證，速率限制，動態(tài)配置更新和服務(wù)發(fā)現(xiàn))時，人們更有可能調(diào)用該API網(wǎng)關(guān)。

反向代理+網(wǎng)關(guān)部署架構(gòu)

由于架構(gòu)演進的歷史原因，很多公司都是反向代理和網(wǎng)關(guān)并存的架構(gòu)

這樣就得維護兩套系統(tǒng)，肯定比較復(fù)雜，所以最好是結(jié)合統(tǒng)一：

參考

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

本文轉(zhuǎn)載自微信公眾號「 JavaEdge」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 JavaEdge公眾號。