前言

由于互聯(lián)網(wǎng)的高速發(fā)展，網(wǎng)絡(luò)數(shù)據(jù)請求數(shù)激增，使得服務(wù)器承受的壓力越來越大。在早期的系統(tǒng)架構(gòu)中，為減輕單臺服務(wù)器的壓力，通常使用 Load Balancer 來將網(wǎng)絡(luò)流量平攤到多個服務(wù)器中。如今后端服務(wù)的種類和數(shù)量在不斷變多，傳統(tǒng)的 Load Balancer 為主的系統(tǒng)架構(gòu)的局限性就變得明顯起來，于是一款主要工作在七層且具有豐富擴(kuò)展能力的基礎(chǔ)設(shè)施便應(yīng)運(yùn)而生，那便是API Gateway。

什么是API網(wǎng)關(guān)

API網(wǎng)關(guān)簡單來說是一種主要工作在七層、專門用于 API 的管理和流量轉(zhuǎn)發(fā)的基礎(chǔ)設(shè)施，并擁有強(qiáng)大的擴(kuò)展性。

網(wǎng)關(guān)的角色是作為一個API架構(gòu)，用來保護(hù)、增強(qiáng)和控制對于API服務(wù)的訪問。它是一個處于應(yīng)用程序或服務(wù)（提供REST API接口服務(wù)）之前的系統(tǒng)，用來管理授權(quán)、訪問控制和流量限制等。這樣REST API接口服務(wù)就被網(wǎng)關(guān)保護(hù)起來，對所有的調(diào)用者透明。因此，隱藏在API網(wǎng)關(guān)后面的業(yè)務(wù)系統(tǒng)就可以專注于創(chuàng)建和管理服務(wù)，無需關(guān)心這些策略性的請求。

網(wǎng)關(guān)工作流程如下圖：

網(wǎng)關(guān)必須具備的特點(diǎn)

1.高性能

對于高性能而言，網(wǎng)關(guān)不應(yīng)該也不能成為性能的瓶頸，最好使用高性能的編程語言來實(shí)現(xiàn)，如 C、C++、Go 和 Java。網(wǎng)關(guān)對后端的請求，以及對前端的請求的服務(wù)一定要使用異步非阻塞的 I/O 來確保后端延遲不會導(dǎo)致應(yīng)用程序中出現(xiàn)性能問題。C 和 C++ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。

2.高可用

所有的流量或調(diào)用都要經(jīng)過網(wǎng)關(guān)，所以網(wǎng)關(guān)必須成為一個高可用的組件，它的穩(wěn)定直接關(guān)系到了所有服務(wù)的穩(wěn)定。不能出現(xiàn)單點(diǎn)故障，因此，一個好的網(wǎng)關(guān)至少做到以下幾點(diǎn)。

集群化。網(wǎng)關(guān)要成為一個集群，并可以自己同步集群數(shù)據(jù)，而不需要依賴于第三方系統(tǒng)來同步數(shù)據(jù)。

服務(wù)化。網(wǎng)關(guān)還需要做到在不間斷的情況下修改配置，一種是像 Nginx reload 配置那樣，可以做到不停服務(wù)，另一種是最好做到服務(wù)化。也就是說，得要有自己的 Admin API 來在運(yùn)行時修改配置。

持續(xù)化。比如重啟，就是像 Nginx 那樣優(yōu)雅地重啟。有一個主管請求分發(fā)的主進(jìn)程。當(dāng)我們需要重啟時，新的請求被分配到新的進(jìn)程中，而老的進(jìn)程處理完正在處理的請求后就退出。

3.高擴(kuò)展

網(wǎng)關(guān)要承接所有的業(yè)務(wù)流量和請求，所以一定存在或多或少的業(yè)務(wù)邏輯。而業(yè)務(wù)邏輯是多變和不確定的，比如，需要在網(wǎng)關(guān)上加入一些和業(yè)務(wù)相關(guān)的東西。因此一個好的網(wǎng)關(guān)還需要是可以擴(kuò)展的，并能進(jìn)行二次開發(fā)。當(dāng)然，像 Nginx 那樣通過 Module 進(jìn)行二次開發(fā)的也是可以的。

網(wǎng)關(guān)主要功能

路由功能：路由是微服務(wù)網(wǎng)關(guān)的核心能力。通過路由功能微服務(wù)網(wǎng)關(guān)可以將請求轉(zhuǎn)發(fā)到目標(biāo)微服務(wù)。在微服務(wù)架構(gòu)中，網(wǎng)關(guān)可以結(jié)合注冊中心的動態(tài)服務(wù)發(fā)現(xiàn)，實(shí)現(xiàn)對后端服務(wù)的發(fā)現(xiàn)，調(diào)用方只需要知道網(wǎng)關(guān)對外暴露的服務(wù)API就可以透明地訪問后端微服務(wù)。

負(fù)載均衡：API網(wǎng)關(guān)結(jié)合負(fù)載均衡技術(shù)，利用Eureka或者Consul等服務(wù)發(fā)現(xiàn)工具，通過輪詢、指定權(quán)重、IP地址哈希等機(jī)制實(shí)現(xiàn)下游服務(wù)的負(fù)載均衡。

統(tǒng)一鑒權(quán)：一般而言，無論對內(nèi)網(wǎng)還是外網(wǎng)的接口都需要做用戶身份認(rèn)證，而用戶認(rèn)證在一些規(guī)模較大的系統(tǒng)中都會采用統(tǒng)一的單點(diǎn)登錄（Single Sign On）系統(tǒng)，如果每個微服務(wù)都要對接單點(diǎn)登錄系統(tǒng)，那么顯然比較浪費(fèi)資源且開發(fā)效率低。API網(wǎng)關(guān)是統(tǒng)一管理安全性的絕佳場所，可以將認(rèn)證的部分抽取到網(wǎng)關(guān)層，微服務(wù)系統(tǒng)無須關(guān)注認(rèn)證的邏輯，只關(guān)注自身業(yè)務(wù)即可。

限流熔斷：在某些場景下需要控制客戶端的訪問次數(shù)和訪問頻率，一些高并發(fā)系統(tǒng)有時還會有限流的需求。在網(wǎng)關(guān)上可以配置一個閾值，當(dāng)請求數(shù)超過閾值時就直接返回錯誤而不繼續(xù)訪問后臺服務(wù)。當(dāng)出現(xiàn)流量洪峰或者后端服務(wù)出現(xiàn)延遲或故障時，網(wǎng)關(guān)能夠主動進(jìn)行熔斷，保護(hù)后端服務(wù)，并保持前端用戶體驗(yàn)良好。

灰度發(fā)布：微服務(wù)網(wǎng)關(guān)可以根據(jù)HTTP請求中的特殊標(biāo)記和后端服務(wù)列表元數(shù)據(jù)標(biāo)識進(jìn)行流量控制，實(shí)現(xiàn)在用戶無感知的情況下完成灰度發(fā)布。

日志審計(jì)：微服務(wù)網(wǎng)關(guān)可以作為統(tǒng)一的日志記錄和收集器，對服務(wù)URL粒度的日志請求信息和響應(yīng)信息進(jìn)行攔截。

指標(biāo)監(jiān)控：網(wǎng)關(guān)可以統(tǒng)計(jì)后端服務(wù)的請求次數(shù)，并且可以實(shí)時地更新當(dāng)前的流量健康狀態(tài)，可以對URL粒度的服務(wù)進(jìn)行延遲統(tǒng)計(jì)，也可以使用Hystrix Dashboard查看后端服務(wù)的流量狀態(tài)及是否有熔斷發(fā)生。

協(xié)議轉(zhuǎn)換：API網(wǎng)關(guān)的一大作用在于構(gòu)建異構(gòu)系統(tǒng)，API網(wǎng)關(guān)作為單一入口，通過協(xié)議轉(zhuǎn)換整合后臺基于REST、AMQP、Dubbo等不同風(fēng)格和實(shí)現(xiàn)技術(shù)的微服務(wù)，面向Web Mobile、開放平臺等特定客戶端提供統(tǒng)一服務(wù)。

黑白名單：微服務(wù)網(wǎng)關(guān)可以使用系統(tǒng)黑名單，過濾HTTP請求特征，攔截異?？蛻舳说恼埱螅鏒DoS攻擊等侵蝕帶寬或資源迫使服務(wù)中斷等行為，可以在網(wǎng)關(guān)層面進(jìn)行攔截過濾。比較常見的攔截策略是根據(jù)IP地址增加黑名單。在存在鑒權(quán)管理的路由服務(wù)中可以通過設(shè)置白名單跳過鑒權(quán)管理而直接訪問后端服務(wù)資源。

文檔中心：網(wǎng)關(guān)結(jié)合Swagger，可以將后端的微服務(wù)暴露給網(wǎng)關(guān)，網(wǎng)關(guān)作為統(tǒng)一的入口給接口的使用方提供查看后端服務(wù)的API規(guī)范，不需要知道每一個后端微服務(wù)的Swagger地址，這樣網(wǎng)關(guān)起到了對后端API聚合的效果。

目前主流的網(wǎng)關(guān)

Spring Cloud Gateway：是springcloud的全新API網(wǎng)關(guān)項(xiàng)目，旨在替換zuul的網(wǎng)關(guān)服務(wù)，基于spring framework5.0+springboot 2.0+webFlux開發(fā)，其也實(shí)現(xiàn)了異步非阻塞的特性，有較高的性能，其有豐富的過濾器類型，可以根據(jù)自身需求來自定義過濾器。

Zuul 2.0: 采用Netty實(shí)現(xiàn)異步非阻塞編程模型，一個CPU一個線程，能夠處理所有的請求和響應(yīng)，請求響應(yīng)的生命周期通過事件和回調(diào)進(jìn)行處理，減少線程數(shù)量，開銷較小。相比于zuul 1.0，zuul 2.0實(shí)現(xiàn)的異步非阻塞的特性，在性能上有較大提升。

OpenResty: OpenResty基于 Nginx與 Lua 的高性能 Web 平臺，其內(nèi)部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動態(tài) Web 應(yīng)用、Web 服務(wù)和動態(tài)網(wǎng)關(guān)。

Kong: 基于OpenResty（Nginx + Lua模塊）編寫的高可用、易擴(kuò)展的，性能高效且穩(wěn)定，支持多個可用插件（限流、鑒權(quán)）等，開箱即可用，只支持HTTP協(xié)議，且二次開發(fā)擴(kuò)展難，缺乏更易用的管理和配置方式

網(wǎng)關(guān)之間的對比如下圖：

總結(jié)

總體而言，API Gateway 主要用于作為后端的 API 接口代理，提供對外訪問不同種類 API 的一個單獨(dú)入口，并且可以提供獨(dú)立于后端服務(wù)的限流、認(rèn)證、監(jiān)控等功能。

在合理的架構(gòu)設(shè)計(jì)下，一般都將 API Gateway 和 Load Balancer 配合使用，使用 Load Balancer 作為整個系統(tǒng)的網(wǎng)絡(luò)出入口，將流量分發(fā)到多個 API Gateway 實(shí)例，然后每個 API Gateway 實(shí)例分別對請求進(jìn)行路由、認(rèn)證、鑒權(quán)等操作，這樣可以使得整個網(wǎng)絡(luò)更加穩(wěn)健、可靠、可擴(kuò)展。

審核編輯：劉清