API 網(wǎng)關

API 網(wǎng)關出現(xiàn)的原因是微服務架構的出現(xiàn)，不同的微服務一般會有不同的網(wǎng)絡地址，而外部客戶端可能需要調(diào)用多個服務的接口才能完成一個業(yè)務需求，如果讓客戶端直接與各個微服務通信，會有以下的問題：

1. 客戶端會多次請求不同的微服務，增加了客戶端的復雜性。
2. 存在跨域請求，在一定場景下處理相對復雜。
3. 認證復雜，每個服務都需要獨立認證。
4. 難以重構，隨著項目的迭代，可能需要重新劃分微服務。例如，可能將多個服務合并成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那么重構將會很難實施。
5. 某些微服務可能使用了防火墻 / 瀏覽器不友好的協(xié)議，直接訪問會有一定的困難。

以上這些問題可以借助 API 網(wǎng)關解決。API 網(wǎng)關是介于客戶端和服務器端之間的中間層，所有的外部請求都會先經(jīng)過 API 網(wǎng)關這一層。也就是說，API 的實現(xiàn)方面更多的考慮業(yè)務邏輯，而安全、性能、監(jiān)控可以交由 API 網(wǎng)關來做，這樣既提高業(yè)務靈活性又不缺安全性，典型的架構圖如圖所示：

使用 API 網(wǎng)關后的優(yōu)點如下：

• 易于監(jiān)控?？梢栽诰W(wǎng)關收集監(jiān)控數(shù)據(jù)并將其推送到外部系統(tǒng)進行分析。
• 易于認證。可以在網(wǎng)關上進行認證，然后再將請求轉發(fā)到后端的微服務，而無須在每個微服務中進行認證。
• 減少了客戶端與各個微服務之間的交互次數(shù)。

NGINX 服務

Nginx 由內(nèi)核和模塊組成，內(nèi)核的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置文件與客戶端請求進行 URL 匹配，用于啟動不同的模塊去完成相應的工作。

下面這張圖反應的是 HTTP 請求的常規(guī)處理流程：

Nginx 的模塊直接被編譯進 Nginx，因此屬于靜態(tài)編譯方式。啟動 Nginx 后，Nginx 的模塊被自動加載，不像 Apache，首先將模塊編譯為一個 so 文件，然后在配置文件中指定是否進行加載。在解析配置文件時，Nginx 的每個模塊都有可能去處理某個請求，但是同一個處理請求只能由一個模塊來完成。

Nginx 在啟動后，會有一個 Master 進程和多個 Worker 進程，Master 進程和 Worker 進程之間是通過進程間通信進行交互的，如圖所示。Worker 工作進程的阻塞點是在像 select()、epoll_wait() 等這樣的 I/O 多路復用函數(shù)調(diào)用處，以等待發(fā)生數(shù)據(jù)可讀 / 寫事件。Nginx 采用了異步非阻塞的方式來處理請求，也就是說，Nginx 是可以同時處理成千上萬個請求的。一個 Worker 進程可以同時處理的請求數(shù)只受限于內(nèi)存大小，而且在架構設計上，不同的 Worker 進程之間處理并發(fā)請求時幾乎沒有同步鎖的限制，Worker 進程通常不會進入睡眠狀態(tài)，因此，當 Nginx 上的進程數(shù)與 CPU 核心數(shù)相等時(***每一個 Worker 進程都綁定特定的 CPU 核心)，進程間切換的代價是最小的。

Zuul

Zuul 是 Netflix 開源的微服務網(wǎng)關組件，它可以和 Eureka、Ribbon、Hystrix 等組件配合使用。Zuul 的核心是一系列的過濾器，這些過濾器可以完成以下功能：

• 身份認證與安全：識別每個資源的驗證要求，并拒絕那些與要求不符的請求。
• 審查與監(jiān)控：與邊緣位置追蹤有意義的數(shù)據(jù)和統(tǒng)計結果，從而帶來精確的生產(chǎn)視圖。
• 動態(tài)路由：動態(tài)地將請求路由到不同的后端集群。
• 壓力測試：逐漸增加指向集群的流量，以了解性能。
• 負載分配：為每一種負載類型分配對應容量，并棄用超出限定值的請求。
• 靜態(tài)響應處理：在邊緣位置直接建立部分響應，從而避免其轉發(fā)到內(nèi)部集群。
• 多區(qū)域彈性：跨越 AWS Region 進行請求路由，旨在實現(xiàn) ELB(Elastic Load Balancing，彈性負載均衡)使用的多樣化，以及讓系統(tǒng)的邊緣更貼近系統(tǒng)的使用者。

上面提及的這些特性是 Nigix 所沒有的，這是因為 Netflix 公司創(chuàng)造 Zuul 是為了解決云端的諸多問題(特別是幫助 AWS 解決跨 Region 情況下的這些特性實現(xiàn))，而不僅僅是做一個類似于 Nigix 的反向代理，當然，我們可以僅使用反向代理功能，這里不多做描述。

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

Zuul2 的巨大區(qū)別是它運行在異步和無阻塞框架上，每個 CPU 核一個線程，處理所有的請求和響應，請求和響應的生命周期是通過事件和回調(diào)來處理的，這種方式減少了線程數(shù)量，因此開銷較小。又由于數(shù)據(jù)被存儲在同一個 CPU 里，可以復用 CPU 級別的緩存，前面提及的延遲和重試風暴問題也通過隊列存儲連接數(shù)和事件數(shù)方式減輕了很多(較線程切換來說輕量級很多，自然消耗較小)。這一變化一定會大大提升性能，我們在后面的測試環(huán)節(jié)看看結果。

我們今天談的是 API 網(wǎng)關性能，這一點也涉及到高可用，簡單介紹 Zuul 的高可用特性，高可用是非常關鍵的，因為外部請求到后端微服務的流量都會經(jīng)過 Zuul，所以在生產(chǎn)環(huán)境中一般都需要部署高可用的 Zuul 來避免單點故障。一般我們有兩種部署方案：

1. Zuul 客戶端注冊到 Eureka Server

這種情況是比較簡單的情況，只需要將多個 Zuul 節(jié)點注冊到 Eureka Server 上，就可以實現(xiàn) Zuul 的高可用。事實上，這種情況下的高可用和其他服務做高可用的方案沒有什么區(qū)別。我們來看下面這張圖，當 Zuul 客戶端注冊到 Eureka Server 上時，只需要部署多個 Zuul 節(jié)點就可以實現(xiàn)高可用。Zuul 客戶端會自動從 Eureka Server 查詢 Zuul Server 列表，然后使用負載均衡組件(例如 Ribbon)請求 Zuul 集群。

2. Zuul 客戶端不能注冊到 Eureka Server

假如說我們的客戶端是手機端 APP，那么不可能通過方案 1 的方式注冊到 Eureka Server 上。這種情況下，我們可以通過額外的負載均衡器來實現(xiàn) Zuul 的高可用，例如 Nginx、HAProxy、F5 等。

如圖所示，Zuul 客戶端將請求發(fā)送到負載均衡器，負載均衡器將請求轉發(fā)到其代理的其中一個 Zuul 節(jié)點，這樣就可以實現(xiàn) Zuul 的高可用。

Spring Cloud

雖然 Spring Cloud 帶有“Cloud”，但是它并不是針對云計算的解決方案，而是在 Spring Boot 基礎上構建的，用于快速構建分布式系統(tǒng)的通用模式的工具集。

使用 Spring Cloud 開發(fā)的應用程序非常適合在 Docker 或者 PaaS 上部署，所以又叫云原生應用。云原生可以簡單理解為面向云環(huán)境的軟件架構。

既然是工具集，那么它一定包含很多工具，我們來看下面這張圖：

這里由于僅涉及到 API 網(wǎng)關的對比，因此我不逐一介紹其他工具了。

Spring Cloud 對 Zuul 進行了整合，但從 Zuul 來看，沒有大變化，但是 Spring Cloud 整個框架經(jīng)過了組件的集成，提供的功能遠多于 Netflix Zuul，可能對比時會出現(xiàn)差異。

Service Mesh 之 Linkerd

我想 Turgay Celik 博士把 Linkerd 作為對比對象之一，可能是因為 Linkerd 為云原生應用提供彈性的 Service Mesh，而 Service Mesh 能夠提供輕量級高性能網(wǎng)絡代理，并且也提供微服務框架支撐。

從介紹來看，linkerd 是我們面向微服務的開源 RPC 代理，它直接立足于 Finagle(Twitter 的內(nèi)部核心庫，負責管理不同服務間之通信流程。事實上，Twitter 公司的每一項在線服務都立足于 Finagle 構建而成，而且其支持著每秒發(fā)生的成百上千萬條 RPC 調(diào)用)構建而成，設計目標在于幫助用戶簡化微服務架構下的運維，它是專用于處理時間敏感的服務到服務的通信基礎設施層。

和 Spring Cloud 類似，Linkerd 也提供了負載均衡、熔斷機器、服務發(fā)現(xiàn)、動態(tài)請求路由、重試和離線、TLS、HTTP 網(wǎng)關集成、透明代理、gRPC、分布式跟蹤、運維等諸多功能，功能是相當全了，為微服務框架的技術選型又增加了一個。由于沒有接觸過 Linkerd，所以暫時無法從架構層面進行分析，后續(xù)會補充這方面的內(nèi)容，自己來做一次技術選型。

性能測試結果

Turgay Çelik 博士的那篇文章里使用了 Apache 的 HTTP 服務器性能評估工具 AB 作為測試工具。注意，由于他是基于亞馬遜(AWS)公有云的進行的測試，可能和你實際物理機上的測試結果有出入。

實驗中啟動了客戶端和服務端兩臺機器，分別安裝多個待測試服務，客戶端通過幾種方式分別訪問，嘗試獲取資源。測試方案如下圖所示：

測試選擇了三個環(huán)境，分別是：

1. 單 CPU 核，1GB 內(nèi)存：用于比較 Nginx 反向代理和 Zuul(去除***次運行后的平均結果);
2. 雙 CPU 核，8GB 內(nèi)存：用于比較 Nginx 反向代理和 Zuul(去除***次運行后的平均結果);
3. 8 個核 CPU，32GB 內(nèi)存：用于比較 Nginx 反向代理、Zuul(去除***次運行后的平均結果)、Spring Cloud Zuul、Linkerd。

測試過程均采用 200 個并行線程發(fā)送總共 1 萬次請求，命令模板如下所示：

ab -n 10000 -c 200 HTTP://<server-address>/<path to resource> 

注意：由于 Turgay Çelik 博士的測試過程中是基于 Zuul 1 進行的測試，所以性能上較差，不能真實反映當前 Zuul 版本的性能狀況。

從上面的結果來看，單核環(huán)境下，Zuul 的性能最差(950.57 次 /s)，直接訪問方式性能***(6519.68 次 /s)，采用 Nginx 反向代理方式較直接訪問方式損失 26% 的性能(4888.24 次 /s)。在雙核環(huán)境下，Nginx 的性能較 Zuul 性能強接近 3 倍(分別是 6187.14 次 /s 和 2099.93 次 /s)。在較強的測試環(huán)境下(8 核)，直接訪問、Nginx、Zuul 差距不大，但是 Spring Cloud Zuul 可能由于內(nèi)部整體消耗，導致每秒的請求數(shù)只有 873.14。

最終結論

從產(chǎn)品思維來看，API 網(wǎng)關負責服務請求路由、組合及協(xié)議轉換?？蛻舳说乃姓埱蠖际紫冉?jīng)過 API 網(wǎng)關，然后由它將請求路由到合適的微服務。API 網(wǎng)關經(jīng)常會通過調(diào)用多個微服務并合并結果來處理一個請求，它可以在 Web 協(xié)議(如 HTTP 與 WebSocket)與內(nèi)部使用的非 Web 友好協(xié)議之間轉換，所以說作用還是很大的，因此技術方案選型對于整個系統(tǒng)來說也有一定重要性。

從我所理解的這四款組件的設計原理來看，Zuul1 的設計模式和 Nigix 較像，每次 I/O 操作都是從工作線程中選擇一個執(zhí)行，請求線程被阻塞直到工作線程完成，但是差別是 Nginx 用 C++ 實現(xiàn)，Zuul 用 Java 實現(xiàn)，而 JVM 本身有***次加載較慢的情況。Zuul2 的性能肯定會較 Zuul1 有較大的提升，此外，Zuul 的***次測試性能較差，但是從第二次開始就好了很多，可能是由于 JIT(Just In Time)優(yōu)化造成的吧。而對于 Linkerd，它本身是對于資源比較敏感的一種網(wǎng)關設計，所以在通用環(huán)境下拿它和其他網(wǎng)關實現(xiàn)相比較，可能會出現(xiàn)不準確的結果。