1 API網(wǎng)關(guān)基礎

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

API網(wǎng)關(guān)是一個服務器，是系統(tǒng)的唯一入口。 從面向?qū)ο笤O計的角度看，它與外觀模式類似。

API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監(jiān)控、負載均衡、緩存、協(xié)議轉(zhuǎn)換、限流熔斷、靜態(tài)響應處理。

API網(wǎng)關(guān)方式的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務，在網(wǎng)關(guān)層處理所有的非業(yè)務功能。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API。

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

微服務網(wǎng)關(guān)作為微服務后端服務的統(tǒng)一入口，它可以統(tǒng)籌管理后端服務，主要分為數(shù)據(jù)平面和控制平面：

• 數(shù)據(jù)平面主要功能是接入用戶的HTTP請求和微服務被拆分后的聚合。使用微服務網(wǎng)關(guān)統(tǒng)一對外暴露后端服務的API和契約，路由和過濾功能正是網(wǎng)關(guān)的核心能力模塊。另外，微服務網(wǎng)關(guān)可以實現(xiàn)攔截機制和專注跨橫切面的功能，包括協(xié)議轉(zhuǎn)換、安全認證、熔斷限流、灰度發(fā)布、日志管理、流量監(jiān)控等。

• 控制平面主要功能是對后端服務做統(tǒng)一的管控和配置管理。例如，可以控制網(wǎng)關(guān)的彈性伸縮；可以統(tǒng)一下發(fā)配置；可以對網(wǎng)關(guān)服務添加標簽；可以在微服務網(wǎng)關(guān)上通過配置Swagger功能統(tǒng)一將后端服務的API契約暴露給使用方，完成文檔服務，提高工作效率和降低溝通成本。

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

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

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

• 協(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等不同風格和實現(xiàn)技術(shù)的微服務，面向Web Mobile、開放平臺等特定客戶端提供統(tǒng)一服務。

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

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

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

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

• 流量染色：和灰度發(fā)布的原理相似，網(wǎng)關(guān)可以根據(jù)HTTP請求的Host、Head、Agent等標識對請求進行染色，有了網(wǎng)關(guān)的流量染色功能，我們可以對服務后續(xù)的調(diào)用鏈路進行跟蹤，對服務延遲及服務運行狀況進行進一步的鏈路分析。

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

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

2 API網(wǎng)關(guān)選型

2.1 常用API網(wǎng)關(guān)

先簡單看一下市面上常用的API網(wǎng)關(guān)：

Nginx

Nginx是一個高性能的HTTP和反向代理服務器。Nginx一方面可以做反向代理，另外一方面可以做靜態(tài)資源服務器，接口使用Lua動態(tài)語言可以完成靈活的定制功能。

Nginx 在啟動后，會有一個 Master 進程和多個 Worker 進程，Master 進程和 Worker 進程之間是通過進程間通信進行交互的，如圖所示。Worker 工作進程的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路復用函數(shù)調(diào)用處，以等待發(fā)生數(shù)據(jù)可讀 / 寫事件。Nginx 采用了異步非阻塞的方式來處理請求，也就是說，Nginx 是可以同時處理成千上萬個請求的。

Zuul

Zuul 是 Netflix 開源的一個API網(wǎng)關(guān)組件，它可以和 Eureka、Ribbon、Hystrix 等組件配合使用。社區(qū)活躍，融合于 SpringCloud 完整生態(tài)，是構(gòu)建微服務體系前置網(wǎng)關(guān)服務的最佳選型之一。

Zuul 的核心是一系列的過濾器，這些過濾器可以完成以下功能：

• 統(tǒng)一鑒權(quán) + 動態(tài)路由 + 負載均衡 + 壓力測試

• 審查與監(jiān)控：與邊緣位置追蹤有意義的數(shù)據(jù)和統(tǒng)計結(jié)果，從而帶來精確的生產(chǎn)視圖。

• 多區(qū)域彈性：跨越 AWS Region 進行請求路由，旨在實現(xiàn) ELB（Elastic Load Balancing，彈性負載均衡）使用的多樣化，以及讓系統(tǒng)的邊緣更貼近系統(tǒng)的使用者。

Zuul 目前有兩個大的版本：Zuul1 和 Zuul2

Zuul1 是基于 Servlet 框架構(gòu)建，如圖所示，采用的是阻塞和多線程方式，即一個線程處理一次連接請求，這種方式在內(nèi)部延遲嚴重、設備故障較多情況下會引起存活的連接增多和線程增加的情況發(fā)生。

Netflix 發(fā)布的 Zuul2 有重大的更新，它運行在異步和無阻塞框架上，每個 CPU 核一個線程，處理所有的請求和響應，請求和響應的生命周期是通過事件和回調(diào)來處理的，這種方式減少了線程數(shù)量，因此開銷較小。

Spring Cloud GetWay

Spring Cloud Gateway 是Spring Cloud的一個全新的API網(wǎng)關(guān)項目，目的是為了替換掉Zuul1，它基于Spring5.0 + SpringBoot2.0 + WebFlux（基于?性能的Reactor模式響應式通信框架Netty，異步?阻塞模型）等技術(shù)開發(fā)，性能?于Zuul，官?測試，Spring Cloud GateWay是Zuul的1.6倍，旨在為微服務架構(gòu)提供?種簡單有效的統(tǒng)?的API路由管理?式。

Spring Cloud Gateway可以與Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等組件配合使用，實現(xiàn)路由轉(zhuǎn)發(fā)、負載均衡、熔斷、鑒權(quán)、路徑重寫、?志監(jiān)控等，并且Gateway還內(nèi)置了限流過濾器，實現(xiàn)了限流的功能。

Kong

Kong是一款基于OpenResty（Nginx + Lua模塊）編寫的高可用、易擴展的，由Mashape公司開源的API Gateway項目。Kong是基于NGINX和Apache Cassandra或PostgreSQL構(gòu)建的，能提供易于使用的RESTful API來操作和配置API管理系統(tǒng)，所以它可以水平擴展多個Kong服務器，通過前置的負載均衡配置把請求均勻地分發(fā)到各個Server，來應對大批量的網(wǎng)絡請求。

Kong主要有三個組件：

• Kong Server ：基于Nginx的服務器，用來接收API請求。

• Apache Cassandra/PostgreSQL ：用來存儲操作數(shù)據(jù)。

• Kong dashboard：官方推薦UI管理工具，也可以使用 restfull 方式管理admin api。

Kong采用插件機制進行功能定制，插件集（可以是0或N個）在API請求響應循環(huán)的生命周期中被執(zhí)行。插件使用Lua編寫，目前已有幾個基礎功能：HTTP基本認證、密鑰認證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日志、API請求限流、請求轉(zhuǎn)發(fā)以及Nginx監(jiān)控。

Kong網(wǎng)關(guān)具有以下的特性：

• 可擴展性: 通過簡單地添加更多的服務器，可以輕松地進行橫向擴展，這意味著您的平臺可以在一個較低負載的情況下處理任何請求；

• 模塊化: 可以通過添加新的插件進行擴展，這些插件可以通過RESTful Admin API輕松配置；

• 在任何基礎架構(gòu)上運行: Kong網(wǎng)關(guān)可以在任何地方都能運行。您可以在云或內(nèi)部網(wǎng)絡環(huán)境中部署Kong，包括單個或多個數(shù)據(jù)中心設置，以及public，private 或invite-only APIs。

Traefik

Tr?f?k 是一個為了讓部署微服務更加便捷而誕生的現(xiàn)代HTTP反向代理、負載均衡工具。它支持多種后臺 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來自動化、動態(tài)的應用它的配置文件設置。

重要特性：

• 它非?？?，無需安裝其他依賴，通過Go語言編寫的單一可執(zhí)行文件；

• 多種后臺支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd；

• 支持支持Rest API、Websocket、HTTP/2、Docker鏡像；

• 監(jiān)聽后臺變化進而自動化應用新的配置文件設置；

• 配置文件熱更新，無需重啟進程；

• 后端斷路器、負載均衡、容錯機制；

• 清爽的前端頁面，可監(jiān)控服務指標。

關(guān)于Traefik的更多內(nèi)容，可以查看官網(wǎng)：https://traefik.cn/

2.2 API網(wǎng)關(guān)對比

上面是網(wǎng)關(guān)對比截圖，偷個懶，大家主要關(guān)注Kong、Traefik和Zuul即可：

• 從開源社區(qū)活躍度來看，無疑是Kong和Traefik較好；

• 從成熟度來看，較好的是Kong、Tyk、Traefik；

• 從性能來看，Kong要比其他幾個領先一些；

• 從架構(gòu)優(yōu)勢的擴展性來看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用度也很高，近年來Istio服務網(wǎng)格的流行，Ambassador因為能夠和Istio無縫集成也是相當大的優(yōu)勢。

下面是其它網(wǎng)友的思考結(jié)論，可供參考：

• 性能：Nginx+Lua形式必然是高于Java語言實現(xiàn)的網(wǎng)關(guān)的，Java技術(shù)棧里面Zuul1.0是基于Servlet實現(xiàn)的，剩下都是基于webflux實現(xiàn)，性能是高于基于Servlet實現(xiàn)的。在性能方面我覺得選擇網(wǎng)關(guān)可能不算那么重要，多加幾臺機器就可以搞定。

• 可維護性和擴展性：Nginx+Lua這個組合掌握的人不算多，如果團隊有大神，大佬們就隨意了，當沒看到這段話，對于一般團隊來說的話，選擇自己團隊擅長的語言更重要。Java技術(shù)棧下的3種網(wǎng)關(guān)，對于Zuul和Spring Cloud Getway需要或多或少要搞一些集成和配置頁面來維護，但是對于Soul我就無腦看看文章，需要哪個搬哪個好了，尤其是可以無腦對接Dubbo美滋滋，此外Soul2.0以后版本可以擺脫ZK，在我心里再無詬病，我就喜歡無腦操作。

• 高可用：對于網(wǎng)關(guān)高可用基本都是統(tǒng)一的策略都是采用多機器部署的方式，前面掛一個負載，對于而外需要用的一些組件大家注意一下。

3 基于Traefik自研的微服務網(wǎng)關(guān)

3.1 技術(shù)棧選型

• Traefik：一款開源的反向代理與負載均衡工具，它最大的優(yōu)點是能夠與常見的微服務系統(tǒng)直接整合，可以實現(xiàn)自動化動態(tài)配置。traefik較為輕量，非常易于使用和設置，性能比較好，已在全球范圍內(nèi)用于生產(chǎn)環(huán)境。

• Etcd：一個Go言編寫的分布式、高可用的一致性鍵值存儲系統(tǒng)，用于提供可靠的分布式鍵值存儲、配置共享和服務發(fā)現(xiàn)等功能。（更多內(nèi)容可以查看文章 肝了一個月的ETCD，從Raft原理到實踐 ）

• Go：并發(fā)能力強，性能媲美C，處理能力是PHP的4倍，效率高，語法簡單，易上手，開發(fā)效率接近PHP。

3.3 網(wǎng)關(guān)框架

整個網(wǎng)關(guān)框架分為3塊：

• 網(wǎng)關(guān)后臺（hal-fe和hal-admin）：用于應用、服務和插件的配置，然后將配置信息發(fā)布到ETCD；

• Traefik：讀取ETCD配置，根據(jù)配置信息對請求進行路由分發(fā)，如果需要鑒權(quán)，會直接通過hal-agent模塊進行統(tǒng)一鑒權(quán)。鑒權(quán)完畢后，如果是Http請求，直接打到下游服務，如果是Grpc和Thrift協(xié)議，會通過hal-proxy模塊進行協(xié)議轉(zhuǎn)換。

• 協(xié)議轉(zhuǎn)換模塊：讀取ETCD配置，對Traefik分發(fā)過來的請求，進行Grpc和Thrift協(xié)議轉(zhuǎn)換（更多內(nèi)容可以查看文章 RPC框架：從原理到選型，一文帶你搞懂RPC），并通過服務發(fā)現(xiàn)機制，獲取服務下游機器，并通過負載均衡，將轉(zhuǎn)換后的數(shù)據(jù)打到下游服務機器。

3.4 網(wǎng)關(guān)后臺

主要由3大模塊組成：

• 應用：主要包括應用名、域名、路徑前綴、所屬組、狀態(tài)等，比如印度海外商城、印度社區(qū)；

• 服務：主要包括服務名、注冊方式、協(xié)議類型、所屬組、狀態(tài)等，比如評論服務、地址服務、搜索服務。

• 插件：主要包括插件名稱、插件類型、插件屬性配置等，比如路徑前綴替換插件、鑒權(quán)插件。

一個應用只能綁定一個服務，但是可以綁定多個插件。 通過后臺完成網(wǎng)關(guān)配置后，將這些配置信息生成Config文件，發(fā)布到ETCD中，Config文件需要遵循嚴格的數(shù)據(jù)格式，比如Traefix配置需要遵循官方的文件配置格式，才能被Traefik識別。

3.5 協(xié)議轉(zhuǎn)換模塊

hal-proxy模塊是整個微服務網(wǎng)關(guān)最復雜，也是技術(shù)含量最高的模塊，所以給大家詳細講解一下。

問題引入

在講這個模塊前，我們先看下面幾個問題：

• 當請求從上游的trafik過來時，需要知道訪問下游的機器IP和端口，才能將請求發(fā)送給下游，這些機器如何獲取呢？

• 有了機器后，我們需要和下游機器建立連接，如果連接用一次就直接釋放，肯定對服務會造成很大的壓力，這就需要引入Client緩存池，那這個Client緩存池我們又該如何實現(xiàn)呢？

• 最后就是需要對協(xié)議進行轉(zhuǎn)換，因為不同的下游服務，支持的協(xié)議類型是不一樣的，這個網(wǎng)關(guān)又是如何動態(tài)支持的呢？

實現(xiàn)原理

我們還是先看一下hal-proxy內(nèi)部有哪些模塊，首先是Resolver模塊，這個模塊的是什么作用呢？這里我簡單介紹一下，目前公司內(nèi)部通過服務獲取到機器列表的方式有多種，比如MIS平臺、服務樹等，也就是有的是通過平臺配置的，有的是直接掛在服務樹下，無論哪種方式，我們都通過服務名，通過一定的方式，找到該服務下面所有的主機。

所以Resolver模塊的作用，其實就是通過服務名，找到該服務下的所有機器的IP和服務端口，然后持久化到內(nèi)存中，并定時更新。

協(xié)議模塊就是支持不同的協(xié)議轉(zhuǎn)換，每個協(xié)議類型的轉(zhuǎn)換，都需要單獨實現(xiàn)，這些協(xié)議轉(zhuǎn)換，無非就是先通過機器IP和端口初始化Client，然后再將數(shù)據(jù)進行轉(zhuǎn)換后，直接發(fā)送到下游的機器。

最后就是連接池，之前我們其實也用到go自帶的pool來做，但是當對pool數(shù)據(jù)進行更新時，需要加鎖，所以性能一直起不來，后來改成了環(huán)形隊列，然后對數(shù)據(jù)的操作全部通過原子操作方式，就實現(xiàn)了無鎖操作，大大提高的并發(fā)性能。

實現(xiàn)邏輯

這個是hal-proxy的邏輯實現(xiàn)圖