百億流量微服務網(wǎng)關的設計與實現(xiàn)

本文從百億流量交易系統(tǒng)微服務網(wǎng)關（API Gateway）的現(xiàn)狀和面臨的問題出發(fā)，闡述微服務架構與 API 網(wǎng)關的關系，理順流量網(wǎng)關與業(yè)務網(wǎng)關的脈絡，分享API網(wǎng)關知識與經(jīng)驗。

API網(wǎng)關概述

“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決?！?/span>

——David Wheeler

3. API網(wǎng)關的關注點

API網(wǎng)關并不是一個典型的業(yè)務系統(tǒng)，而是一個為了讓業(yè)務系統(tǒng)更專注于業(yè)務服務本身，給API服務提供更多附加能力的一個中間層。

在設計和實現(xiàn)API網(wǎng)關時，需要考慮兩個目標：

（1）開發(fā)維護簡單，節(jié)約人力成本和維護成本。即應選擇成熟的簡單可維護的技術體系。

（2）高性能，節(jié)約設備成本，提高系統(tǒng)吞吐能力。要求我們需要針對API網(wǎng)關的特點進行一些特定的設計和權衡。

當并發(fā)量小的時候，這些都不是問題。一旦系統(tǒng)的API訪問量非常大，這些都會成為關鍵的問題。

海量并發(fā)的API網(wǎng)關最重要的三個關注點：

（1）保持大規(guī)模的inbound請求接入能力（長短連接），比如基于Netty實現(xiàn)。

（2）最大限度地復用outbound的HTTP連接能力，比如基于HttpClient4的異步HttpClient實現(xiàn)。

（3）方便靈活地實現(xiàn)安全、驗證、過濾、聚合、限流、監(jiān)控等各種策略。

API網(wǎng)關的分類與技術分析

1. API網(wǎng)關的分類

如果對上述的目標和關注點進行更深入的思考，那么所有需要考慮的問題和功能可以分為兩類。

• 一類是全局性的，跟具體的后端業(yè)務系統(tǒng)和服務完全無關的部分，比如安全策略、全局性流控策略、流量分發(fā)策略等。

• 一類是針對具體的后端業(yè)務系統(tǒng)，或者是服務和業(yè)務有一定關聯(lián)性的部分，并且一般被直接部署在業(yè)務服務的前面。

隨著互聯(lián)網(wǎng)的復雜業(yè)務系統(tǒng)的發(fā)展，這兩類功能集合逐漸形成了現(xiàn)在常見的兩種網(wǎng)關系統(tǒng)：流量網(wǎng)關和業(yè)務網(wǎng)關，如圖7-5所示。

圖7-5

2. 流量網(wǎng)關與WAF

我們定義全局性的、跟具體的后端業(yè)務系統(tǒng)和服務完全無關的策略網(wǎng)關，即為流量網(wǎng)關。這樣流量網(wǎng)關關注全局流量的穩(wěn)定與安全，比如防止各類SQL注入、黑白名單控制、接入請求到業(yè)務系統(tǒng)的負載均衡等，通常有如下通用性的具體功能：

• 全局性流控；

• 日志統(tǒng)計；

• 防止SQL注入；

• 防止Web攻擊；

• 屏蔽工具掃描；

• 黑白名單控制。

通過這個功能清單，我們可以發(fā)現(xiàn)，流量網(wǎng)關的功能跟Web應用防火墻（WAF）非常類似。WAF一般是基于Nginx/OpenResty的ngx_lua模塊開發(fā)的Web應用防火墻。

一般WAF的代碼很簡單，專注于使用簡單、高性能和輕量級。簡單地說就是在Nginx本身的代理能力以外，添加了安全相關功能。用一句話描述其原理，就是解析HTTP請求（協(xié)議解析模塊），規(guī)則檢測（規(guī)則模塊），做不同的防御動作（動作模塊），并將防御過程（日志模塊）記錄下來。

一般的WAF具有如下功能：

• 防止SQL注入、部分溢出、fuzzing測試、XSS/SSRF等Web攻擊；

• 防止Apache Bench之類壓力測試工具的攻擊；

• 屏蔽常見的掃描黑客工具，比如掃描器；

• 禁止圖片附件類目錄執(zhí)行權限、防止webshell上傳；

• 支持IP白名單和黑名單功能，直接拒絕黑名單的IP訪問；

• 支持URL白名單，定義不需要過濾的URL；

• 支持User-Agent的過濾、支持CC攻擊防護、限制單個URL指定時間的訪問次數(shù)；

• 支持支持Cookie過濾，URL與URL參數(shù)過濾；

• 支持日志記錄，將所有拒絕的操作記錄到日志中。

以上WAF的內容主要參考如下兩個項目：

• https://github.com/unixhot/waf；

• https://github.com/loveshell/ngx_lua_waf。

流量網(wǎng)關的開源實例還可以參考著名的開源項目Kong（基于OpenResty）。

3. 業(yè)務網(wǎng)關

我們定義針對具體的后端業(yè)務系統(tǒng)，或者是服務和業(yè)務有一定關聯(lián)性的策略網(wǎng)關，即為業(yè)務網(wǎng)關。比如，針對某個系統(tǒng)、某個服務或某個用戶分類的流控策略，針對某一類服務的緩存策略，針對某個具體系統(tǒng)的權限驗證方式，針對某些用戶條件判斷的請求過濾，針對具體幾個相關API的數(shù)據(jù)聚合封裝，等等。

業(yè)務網(wǎng)關一般部署在流量網(wǎng)關之后、業(yè)務系統(tǒng)之前，比流量網(wǎng)關更靠近業(yè)務系統(tǒng)。我們大部分情況下說的API網(wǎng)關，狹義上指的是業(yè)務網(wǎng)關。如果系統(tǒng)的規(guī)模不大，我們也會將兩者合二為一，使用一個網(wǎng)關來處理所有的工作。

開源網(wǎng)關的分析與調研

常見的開源網(wǎng)關介紹

常見的開源網(wǎng)關如圖7-6所示。

圖7-6

目前常見的開源網(wǎng)關大致上按照語言分類有如下幾類。

• Nginx+Lua：Open Resty、Kong、Orange、Abtesting Gateway等；

• Java：Zuul/Zuul 2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul等；

• Go：Janus、fagongzi、Grpc-Gateway；

• .NET：Ocelot；

• Node.js：Express Gateway、MicroGateway。

按照使用范圍、成熟度等來劃分，主流的有4個：OpenResty、Kong、Zuul/Zuul 2、Spring Cloud Gateway，此外fagongzi API網(wǎng)關最近也獲得不少關注。

1. Nginx+Lua網(wǎng)關

OpenResty

項目地址：http://openresty.org/

OpenResty基于Nginx，集成了Lua語言和Lua的各種工具庫、可用的第三方模塊，這樣我們就在Nginx既有的高效HTTP處理的基礎上，同時獲得了Lua提供的動態(tài)擴展能力。因此，我們可以做出各種符合我們需要的網(wǎng)關策略的Lua腳本，以其為基礎實現(xiàn)網(wǎng)關系統(tǒng)。

Kong

項目地址：https://konghq.com/與https://github.com/kong/kong

Kong基于OpenResty，是一個云原生、快速、可擴展、分布式的微服務抽象層（MicroserviceAbstraction Layer），也叫API網(wǎng)關（API Gateway），在Service Mesh里也叫API中間件（API Middleware）。

Kong開源于2015年，核心價值在于其高性能和擴展性。從全球5000強的組織統(tǒng)計數(shù)據(jù)來看，Kong是現(xiàn)在依然在維護的、在生產環(huán)境使用最廣泛的網(wǎng)關。

核心優(yōu)勢如下。

• 可擴展：可以方便地通過添加節(jié)點實現(xiàn)水平擴展，這意味著可以在很低的延遲下支持很大的系統(tǒng)負載。

• 模塊化：可以通過添加新的插件來擴展Kong的能力，這些插件可以通過RESTful Admin API來安裝和配置。

• 在任何基礎架構上運行：Kong在任何地方都能運行，比如在云或混合環(huán)境中部署Kong，或者單個/全球的數(shù)據(jù)中心。

ABTestingGateway

項目地址：https://github.com/CNSRE/ABTestingGateway

ABTestingGateway是一個可以動態(tài)設置分流策略的網(wǎng)關，關注與灰度發(fā)布相關的領域，基于Nginx和ngx-lua開發(fā)，使用Redis作為分流策略數(shù)據(jù)庫，可以實現(xiàn)動態(tài)調度功能。

ABTestingGateway是新浪微博內部的動態(tài)路由系統(tǒng)dygateway的一部分，目前已經(jīng)開源。在以往的基于Nginx實現(xiàn)的灰度系統(tǒng)中，分流邏輯往往通過rewrite階段的if和rewrite指令等實現(xiàn)，優(yōu)點是性能較高，缺點是功能受限、容易出錯，以及轉發(fā)規(guī)則固定，只能靜態(tài)分流。ABTestingGateway則采用 ngx-lua，通過啟用lua-shared-dict和lua-resty-lock作為系統(tǒng)緩存和緩存鎖，系統(tǒng)獲得了較為接近原生Nginx轉發(fā)的性能。

功能特性如下。

• 支持多種分流方式，目前包括iprange、uidrange、uid尾數(shù)和指定uid分流；

• 支持多級分流，動態(tài)設置分流策略，即時生效，無須重啟；

• 可擴展性，提供了開發(fā)框架，開發(fā)者可以靈活添加新的分流方式，實現(xiàn)二次開發(fā)；

• 高性能，壓測數(shù)據(jù)接近原生Nginx轉發(fā)；

• 灰度系統(tǒng)配置寫在Nginx配置文件中，方便管理員配置；

• 適用于多種場景：灰度發(fā)布、AB測試和負載均衡等。

據(jù)了解，美團網(wǎng)內部的Oceanus也是基于Nginx和ngx-lua擴展實現(xiàn)的，主要提供服務注冊與發(fā)現(xiàn)、動態(tài)負載均衡、可視化管理、定制化路由、安全反扒、Session ID復用、熔斷降級、一鍵截流和性能統(tǒng)計等功能。

2. 基于Java語言的網(wǎng)關

Zuul/Zuul2

項目地址：https://github.com/Netflix/zuul

Zuul是Netflix開源的API網(wǎng)關系統(tǒng)，它的主要設計目標是動態(tài)路由、監(jiān)控、彈性和安全。

Zuul的內部原理可以簡單看作很多不同功能filter的集合（作為對比，ESB也可以簡單被看作管道和過濾器的集合）。這些過濾器（filter）可以使用Groovy或其他基于JVM的腳本編寫（當然Java也可以編寫），放置在指定的位置，然后可以被Zuul Server輪詢，發(fā)現(xiàn)變動后動態(tài)加載并實時生效。Zuul目前有1.x和2.x兩個版本，這兩個版本的差別很大。

Zuul 1.x基于同步I/O，也是Spring Cloud全家桶的一部分，可以方便地配合Spring Boot/SpringCloud配置和使用。

在Zuul 1.x里，F(xiàn)ilter的種類和處理流程如圖7-7所示，最主要的就是pre、routing、post這三種過濾器，分別作用于調用業(yè)務服務API之前的請求處理、直接響應、調用業(yè)務服務API之后的響應處理。

Zuul 2.x最大的改進就是基于Netty Server實現(xiàn)了異步I/O來接入請求，同時基于Netty Client實現(xiàn)了到后端業(yè)務服務API的請求。這樣就可以實現(xiàn)更高的性能、更低的延遲。此外也調整了Filter類型，將原來的三個核心Filter顯式命名為Inbound Filter、Endpoint Filter和Outbound Filter，如圖7-8所示。

圖7-7

圖7-8

Zuul 2.x的核心功能：服務發(fā)現(xiàn)、負載均衡、連接池、狀態(tài)分類、重試、請求憑證、HTTP/2、TLS、代理協(xié)議、GZip、WebSocket。

SpringCloud Gateway

項目地址：https://github.com/spring-cloud/spring-cloud-gateway/

Spring Cloud Gateway基于Java 8、Spring 5.0、Spring Boot 2.0、Project Reactor，發(fā)展得比Zuul 2要早，目前也是Spring Cloud全家桶的一部分。

Spring Cloud Gateway可以看作一個Zuul 1.x的升級版和代替品，比Zuul 2更早地使用Netty實現(xiàn)異步I/O，從而實現(xiàn)了一個簡單、比Zuul 1.x更高效的、與Spring Cloud緊密配合的API網(wǎng)關。

Spring Cloud Gateway里明確地區(qū)分了Router和Filter，內置了非常多的開箱即用功能，并且都可以通過Spring Boot配置或手工編碼鏈式調用來使用。

比如內置了10種Router，直接配置就可以隨心所欲地根據(jù)Header、Path、Host或Query來做路由。

核心特性：

• 通過請求參數(shù)匹配路由；

• 通過斷言和過濾器實現(xiàn)路由；

• 與Hystrix熔斷集成；

• 與Spring Cloud DiscoveryClient集成；

• 非常方便地實現(xiàn)斷言和過濾器；

• 請求限流；

• 路徑重寫。

graviteeGateway

項目地址：https://gravitee.io/與https://github.com/gravitee-io/gravitee-gateway

KaazingWebSocket Gateway

項目地址：

https://github.com/kaazing/gateway與https://kaazing.com/products/websocket-gateway/

Kaazing WebSocket Gateway是一個專門針對和處理WebSocket的網(wǎng)關，宣稱提供世界一流的企業(yè)級WebSocket服務能力。具體如下特性：

• 標準WebSocket支持，支持全雙工的雙向數(shù)據(jù)投遞；

• 線性擴展，無狀態(tài)架構意味著可以部署更多機器來擴展服務能力；

• 驗證，鑒權，單點登錄支持，跨域訪問控制；

• SSL/TLS加密支持；

• WebSocket keepalive和TCP半開半關探測；

• 通過負載均衡和集群實現(xiàn)高可用；

• Docker支持；

• JMS/AMQP等支持；

• IP白名單；

• 自動重連和消息可靠接受保證；

• Fanout處理策略；

• 實時緩存等。

Dromara soul

項目地址：https://github.com/Dromara/soul。

Soul是一個異步的、高性能的、跨語言的、響應式的API網(wǎng)關，提供了統(tǒng)一的HTTP訪問。

• 支持各種語言，無縫集成Dubbo和SpringCloud；

• 豐富的插件支持鑒權、限流、熔斷、防火墻等；

• 網(wǎng)關多種規(guī)則動態(tài)配置，支持各種策略配置；

• 插件熱插拔，易擴展；

• 支持集群部署，支持A/B Test。

3. 基于Go語言的網(wǎng)關

fagongzi

項目地址：https://github.com/fagongzi/gateway

fagongzi Gateway是一個Go實現(xiàn)的功能全面的API網(wǎng)關，自帶了一個Rails實現(xiàn)的Web UI管理界面。

功能特性：流量控制、熔斷、負載均衡、服務發(fā)現(xiàn)、插件機制、路由（分流，復制流量）、API聚合、API參數(shù)校驗、API訪問控制（黑白名單）、API默認返回值、API定制返回值、API結果Cache、JWT認證、API Metric導入Prometheus、API失敗重試、后端Server的健康檢查、開放管理API（gRPC、RESTful）、支持WebSocket協(xié)議。

Janus

項目地址：https://github.com/hellofresh/janus

Janus是一個輕量級的API網(wǎng)關和管理平臺，能實現(xiàn)控制誰、什么時候、如何訪問這些REST API，同時它也記錄了所有的訪問交互細節(jié)和錯誤。使用Go實現(xiàn)API網(wǎng)關的一個好處在于，一般只需要一個單獨的二進制文件即可運行，沒有復雜的依賴關系。功能特性：

• 熱加載配置，不需要重啟網(wǎng)關進程；

• HTTP連接的優(yōu)雅關閉；

• 支持OpenTracing，從而可以進行分布式跟蹤；

• 支持HTTP/2；

• 可以針對每一個API實現(xiàn)斷路器；

• 重試機制；

• 流控，可以針對每一個用戶或key；

• CORS過濾，可以針對具體的API；

• 多種開箱即用的驗證協(xié)議支持，比如JWT、OAuth 2.0和Basic Auth；

• Docker Image支持。

4. .NET

Ocelot

項目地址：https://github.com/ThreeMammals/Ocelot

功能特性：路由、請求聚合、服務發(fā)現(xiàn)（基于Consul或Eureka）、服務Fabric、WebSockets、驗證與鑒權、流控、緩存、重試策略與QoS、負載均衡、日志與跟蹤、請求頭、Query字符串轉換、自定義的中間處理、配置和管理REST API。

5. Node.js

Express Gateway

項目地址：

https://github.com/ExpressGateway/express-gateway與https://www.express-gateway.io/

Express Gateway是一個基于Node.js開發(fā)，使用Express和Express中間件實現(xiàn)的REST API網(wǎng)關。

功能特性：

• 動態(tài)中心化配置；

• API消費者和憑證管理；

• 插件機制；

• 分布式數(shù)據(jù)存儲；

• 命令行工具CLI。

MicroGateway

項目地址：

https://github.com/strongloop/microgateway與https://developer.ibm.com/apiconnect

StrongLoop是IBM的一個子公司，MicroGateway網(wǎng)關基于Node.js/Express和Nginx構建，作為IBM API Connect，同時也是IBM云生態(tài)的一部分。MicroGateway是一個聚焦于開發(fā)者，可擴展的網(wǎng)關框架，它可以增強我們對微服務和API的訪問能力。

核心特性：

• 安全和控制，基于Swagger（OpenAPI）規(guī)范；

• 內置了多種網(wǎng)關策略，API Key驗證、流控、OAuth 2.0、JavaScript腳本支持；

• 使用Swagger擴展（API Assembly）實現(xiàn)網(wǎng)關策略（安全、路由、集成等）；

• 方便地自定義網(wǎng)關策略。

此外，MicroGateway還有幾個特性：

• 通過集成Swagger，實現(xiàn)基于Swagger API定義的驗證能力；

• 使用datastore來保持需要處理的API數(shù)據(jù)模型；

• 使用一個流式引擎來處理多種策略，使API設計者可以更好地控制API的生命周期。

核心架構如圖7-9所示。

圖7-9

四大開源網(wǎng)關的對比分析

1. OpenResty/Kong/Zuul 2/SpringCloud Gateway重要特性對比

各項指標對比如表7-1所示。

以限流功能為例：

• Spring Cloud Gateway目前提供了基于Redis的Ratelimiter實現(xiàn)，使用的算法是令牌桶算法，通過YAML文件進行配置；

• Zuul2可以通過配置文件配置集群限流和單服務器限流，也可通過Filter實現(xiàn)限流擴展；

• OpenResty可以使用resty.limit.count、resty.limit.conn、resty.limit.req來實現(xiàn)限流功能，可實現(xiàn)漏桶或令牌通算法；

• Kong擁有基礎限流組件，可在基礎組件源代碼基礎上進行Lua開發(fā)。

對Zuul/Zuul 2/Spring Cloud Gateway的一些功能點分析可以參考Spring Cloud Gateway作者Spencer Gibb的文章：https://spencergibb.netlify.com/preso/detroit-cf-api-gateway-2017-03/。

2. OpenResty/Kong/Zuul 2/SpringCloudGateway性能測試對比

分別使用3臺4Core、16GB內存的機器，作為API服務提供者、Gateway、壓力機，使用wrk作為性能測試工具，對OpenResty/Kong/Zuul 2/SpringCloud Gateway進行簡單小報文下的性能測試，如圖7-10所示。

圖7-10

圖中縱坐標軸是QPS，橫軸是一個Gateway的數(shù)據(jù)，每根線是一個場景下的不同網(wǎng)關數(shù)據(jù)，測試結論如下：

• 實測情況是性能SCG~Zuul 2 << OpenResty~< Kong << Direct（直連）；

• Spring Cloud Gateway、Zuul 2的性能差不多，大概是直連的40%；

• OpenResty、Kong的性能差不多，大概是直連的60%～70%；

• 大并發(fā)下，例如模擬200并發(fā)用戶、1000并發(fā)用戶時，Zuul 2會有很大概率返回出錯。

開源網(wǎng)關的技術總結

1. 開源網(wǎng)關的測試分析

脫離場景談性能，都是“耍流氓”。性能就像溫度，不同的場合下標準是不一樣的。同樣是18攝氏度，老人覺得冷，年輕人覺得合適，企鵝覺得熱，冰箱里的蔬菜可能容易壞了。

同樣基準條件下，不同的參數(shù)和軟件，相對而言的橫向比較才有價值。比如同樣的機器（比如16GB內存/4核），同樣的Server（用Spring Boot，配置路徑為api/hello，返回一個helloworld），同樣的壓測方式和工具（比如用wrk，10個線程，20個并發(fā)連接）。我們測試直接訪問Server得到的極限QPS（QPS-Direct，29K）；配置了一個Spring Cloud Gateway做網(wǎng)關訪問的極限QPS（QPS-SCG，11K）；同樣方式配置一個Zuul 2做網(wǎng)關壓測得到的極限QPS（QPS-Zuul2，13K）；Kong得到的極限QPS（QPS-Kong，21K）；OpenResty得到的極限QPS（QPS-OR，19K）。這個對比就有意義了。

Kong的性能非常不錯，非常適合做流量網(wǎng)關，并且對于service、route、upstream、consumer、plugins的抽象，也是自研網(wǎng)關值得借鑒的。

對于復雜系統(tǒng)，不建議業(yè)務網(wǎng)關用Kong，或者更明確地說是不建議在Java技術棧的系統(tǒng)深度定制Kong或OpenResty，主要是出于工程性方面的考慮。舉個例子：假如我們有多個不同業(yè)務線，鑒權方式五花八門，都是與業(yè)務多少有點相關的。這時如果把鑒權在網(wǎng)關實現(xiàn)，就需要維護大量的Lua腳本，引入一個新的復雜技術棧是一個成本不低的事情。

Spring Cloud Gateway/Zuul 2對于Java技術棧來說比較方便，可以依賴業(yè)務系統(tǒng)的一些通用的類庫。Lua不方便，不光是語言的問題，更是復用基礎設施的問題。另外，對于網(wǎng)關系統(tǒng)來說，性能不會差一個數(shù)量級，問題不大，多加2臺機器就可以“搞定”。

從測試的結果來看，如果后端API服務的延遲都較低（例如2ms級別），直連的吞吐量假如是100QPS，Kong可以達到60QPS，OpenResty是50QPS，Zuul 2和Spring CloudGateway大概是35QPS，如果服務本身的延遲（latency）大一點，那么這些差距會逐步縮小。

目前來看Zuul 2的“坑”還是比較多的：

（1）剛出不久，不成熟，沒什么文檔，還沒有太多的實際應用案例。

（2）高并發(fā)時出錯率較高，1000并發(fā)時我們的測試場景有近50%的出錯率。

簡單使用或輕度定制業(yè)務網(wǎng)關系統(tǒng)，目前建議使用Spring CloudGateway作為基礎骨架。

2. 各類網(wǎng)關的Demo與測試

以上測試用到的模擬服務和網(wǎng)關Demo代碼，大部分可以在這里找到：

https://github.com/ kimmking/atlantis。

我們使用Vert.x實現(xiàn)了一個簡單網(wǎng)關，性能跟Zuul 2和Spring Cloud Gateway差不多。另外也簡單模擬了一個Node.js做的網(wǎng)關Demo，加了keep-alive和pool，Demo的性能測試結果大概是直連的1/9，也就是Spring Cloud Gateway或Zuul 2的1/4左右。

百億流量交易系統(tǒng)API網(wǎng)關設計

百億流量交易系統(tǒng)API網(wǎng)關的現(xiàn)狀和面臨問題

1. 百億流量系統(tǒng)面對的業(yè)務現(xiàn)狀

百億流量系統(tǒng)面對的業(yè)務現(xiàn)狀如圖7-11所示。

 圖7-11

我們目前面臨的現(xiàn)狀是日常十幾萬的并發(fā)在線長連接數(shù)（不算短連接），每天長連接總數(shù)為3000萬+，每天API的調用次數(shù)超過100億次，每天交易訂單數(shù)為1.5億個。

在這種情況下，API網(wǎng)關設計的一個重要目標就是：如何借助API網(wǎng)關為各類客戶提供精準、專業(yè)、個性化的服務，保障客戶實時地獲得業(yè)務系統(tǒng)的數(shù)據(jù)和業(yè)務能力。

2. 網(wǎng)關系統(tǒng)與其他系統(tǒng)的關系

某交易系統(tǒng)的API網(wǎng)關系統(tǒng)與其他系統(tǒng)的關系大致如圖7-12所示。

圖7-12

3. 網(wǎng)關系統(tǒng)典型的應用場景

我們的API網(wǎng)關系統(tǒng)為Web端、移動App端客戶提供服務，也為大量API客戶提供API調用服務，同時支持REST API和WebSocket協(xié)議。

作為實時交易系統(tǒng)的前置系統(tǒng)，必須精準及時為客戶提供最新的行情和交易信息。一旦出現(xiàn)數(shù)據(jù)的延遲或錯誤，都會給客戶造成無法挽回的損失。

另外針對不同的客戶和渠道，網(wǎng)關系統(tǒng)需要提供不同的安全、驗證、流控、緩存策略，同時可以隨時聚合不同視角的數(shù)據(jù)進行預處理，保障系統(tǒng)的穩(wěn)定可靠和數(shù)據(jù)的實時精確。

4. 交易系統(tǒng)API的特點

作為一個全球性的交易系統(tǒng)，我們的API特點總結如下。

• 訪問非常集中：最核心的一組API占據(jù)了訪問量的一半以上；

• 訪問非常頻繁：QPS非常高，日均訪問量非常大；

• 數(shù)據(jù)格式固定：交易系統(tǒng)處理的數(shù)據(jù)格式非常固定；

• 報文數(shù)據(jù)量?。好看握埱髠鬏?shù)臄?shù)據(jù)一般不超過10KB；

• 用戶全世界分布：客戶分布在全世界的各個國家；

• 分內部調用和外部調用：除了API客戶直接調用的API，其他的API都是由內部其他系統(tǒng)調用的；

• 7×24小時不間斷服務：系統(tǒng)需要提供高可用、不間斷的服務能力，以滿足不同時區(qū)客戶的交易和自動化策略交易；

• 外部用戶有一定技術能力：外部API客戶，一般是集成我們的API，實現(xiàn)自己的交易系統(tǒng)。

5. 交易系統(tǒng)API網(wǎng)關面臨的問題

問題1：流量不斷增加。

如何合理控制流量，如何應對突發(fā)流量，如何最大限度地保障系統(tǒng)穩(wěn)定，都是重要的問題。特別是網(wǎng)關作為一個直接面對客戶的系統(tǒng)，出現(xiàn)的任何問題都會放大百倍。很多千奇百怪的從來沒人遇到的問題隨時都可能出現(xiàn)。

問題2：網(wǎng)關系統(tǒng)越來越復雜。

現(xiàn)有的業(yè)務網(wǎng)關經(jīng)過多年發(fā)展，里面有大量的業(yè)務嵌入，并且存在多個不同的業(yè)務網(wǎng)關，相互之間沒有任何關系，也沒有沉淀出基礎設施。

同時技術債務太多，系統(tǒng)里硬編碼實現(xiàn)了全局性網(wǎng)關策略及很多業(yè)務規(guī)則，導致維護成本較大。

問題3：API網(wǎng)關管理比較困難。

海量并發(fā)下API的監(jiān)控指標設計和數(shù)據(jù)的收集也是一個不小的問題。7×24小時運行的技術支持也導致維護成本較高。

問題4：選擇推送還是拉取。

使用短連接還是長連接，REST API還是WebSocket？業(yè)務渠道較多（多個不同產品線的Web、App、API等形成十幾個不同的渠道），導致用戶的使用行為難以控制。

業(yè)務網(wǎng)關的設計與最佳實踐

1. API網(wǎng)關1.0

我們的API網(wǎng)關1.0版本是多年前開發(fā)的，是直接使用OpenResty定制的，全局的安全測試、流量的路由轉發(fā)策略、針對不同級別的限流等都是直接用Lua腳本實現(xiàn)。

這樣就導致在經(jīng)歷了業(yè)務飛速發(fā)展以后，系統(tǒng)里存在非常多的相同功能或不同功能的Lua腳本，每次上線或維護都需要找到受影響的其中幾個或幾十個Lua腳本，進行策略調整，非常不方便，策略控制的粒度也不夠細。

2. API網(wǎng)關2.0

在區(qū)分了流量網(wǎng)關和業(yè)務網(wǎng)關以后，2017年開始實現(xiàn)了流量網(wǎng)關和業(yè)務網(wǎng)關的分離，流量網(wǎng)關繼續(xù)使用OpenResty定制，只保留少量全局性、不經(jīng)常改動的配置功能和對應的Lua腳本。

業(yè)務網(wǎng)關使用Vert.x實現(xiàn)的Java系統(tǒng)，部署在流量網(wǎng)關和后端業(yè)務服務系統(tǒng)之間，利用Vert.x的響應式編程能力和異步非阻塞I/O能力、分布式部署的擴展能力，初步解決了問題1和問題2，如圖7-13所示。

圖7-13

Vert.x是一個基于事件驅動和異步非阻塞I/O、運行于JVM上的框架，如圖7-14所示。在Vert.x里，Verticle是最基礎的開發(fā)和部署單元，不同的Vert.x可以通過Event Bus傳遞數(shù)據(jù)，進而方便地實現(xiàn)高并發(fā)性能的網(wǎng)絡程序。關于Vert.x原理的分析可以參考阿里架構師宿何的blog：

https://www.sczyh40.com/tags/Vert-x/。

圖7-14

Vert.x同時很好地支持了WebSocket協(xié)議，所以可以方便地實現(xiàn)支持REST API和WebSocket、完全異步的網(wǎng)關系統(tǒng)，如圖7-15所示。

圖7-15

一個高性能的API網(wǎng)關系統(tǒng)，緩存是必不可少的部分。無論分發(fā)冷熱數(shù)據(jù)，降低對業(yè)務系統(tǒng)的壓力，還是作為中間數(shù)據(jù)源，為服務聚合提供高效可復用的業(yè)務數(shù)據(jù)，緩存都發(fā)揮了巨大作用。

3. API網(wǎng)關的日常監(jiān)控

我們使用多種工具對API進行監(jiān)控和管理，包括全鏈路訪問跟蹤、連接數(shù)統(tǒng)計分析、全世界重要國家和城市的波測訪問統(tǒng)計。網(wǎng)關技術團隊每時每刻都關注著數(shù)據(jù)的變化趨勢。各個業(yè)務系統(tǒng)研發(fā)團隊每天安排專人關注自己系統(tǒng)的API性能（吞吐量和延遲），推進性能問題解決和持續(xù)優(yōu)化。這就初步解決了問題3。

4. 推薦外部客戶使用WebSocket和API SDK

由于外部客戶需要自己通過API網(wǎng)關調用API服務來集成業(yè)務服務能力到自己的系統(tǒng)。各個客戶的技術能力和系統(tǒng)處理能力有較大差異，使用行為也不同。對于不斷發(fā)展變動的交易業(yè)務數(shù)據(jù)，客戶調用API頻率太低會影響數(shù)據(jù)實時性，調用頻率太高則可能會浪費雙方的系統(tǒng)資源。同時利用WebSocket的消息推送特點，我們可以在網(wǎng)關系統(tǒng)控制客戶接收消息的頻率、單個用戶的連接數(shù)量等，隨時根據(jù)業(yè)務系統(tǒng)的情況動態(tài)進行策略調整。綜合考慮，WebSocket是一個比REST API更加實時可靠、更加易于管理的方式。另外對于習慣使用REST API的客戶，我們也通過將各種常見使用場景封裝成多種不同語言的API SDK（包括Java/C++/C#/Python），進而統(tǒng)一用戶的API調用方式和行為。在研發(fā)、產品、運營各方的配合下，逐步協(xié)助客戶使用WebSocket協(xié)議和API SDK，基本解決了問題4。

5. API網(wǎng)關的性能優(yōu)化

API網(wǎng)關系統(tǒng)作為API服務的統(tǒng)一接入點，為了給用戶提供最優(yōu)質的用戶體驗，必須長期做性能優(yōu)化工作。不僅API網(wǎng)關自己做優(yōu)化，同時可以根據(jù)監(jiān)控情況，時刻發(fā)現(xiàn)各業(yè)務系統(tǒng)的API服務能力，以此為出發(fā)點，推動各個業(yè)務系統(tǒng)不斷優(yōu)化API性能。

舉一個具體的例子，某個網(wǎng)關系統(tǒng)連接經(jīng)常強烈抖動（如圖7-16所示），嚴重影響系統(tǒng)的穩(wěn)定性、浪費系統(tǒng)資源，經(jīng)過排除發(fā)現(xiàn)：

（1）有爬蟲IP不斷爬取我們的交易數(shù)據(jù)，而且這些IP所在網(wǎng)段都沒有在平臺產生任何實際交易，最高單爬蟲IP的每日新建連接近100萬次，平均每秒十幾次。

（2）有部分API客戶的程序存在bug，而且處理速度有限，不斷地重復“斷開并重新連接”，再嘗試重新對API數(shù)據(jù)進行處理，嚴重影響了客戶的用戶體驗。

針對如上分析，我們采取了如下處理方式：

（1）對于每天認定的爬蟲IP，加入黑名單，直接在流量網(wǎng)關限制其訪問我們的API網(wǎng)關。

（2）對于存在bug的API客戶，協(xié)助對方進行問題定位和bug修復，增強客戶使用信心。

（3）對于處理速度和技術能力有限的客戶，基于定制的WebSocket服務，使用滑動時間窗口算法，在業(yè)務數(shù)據(jù)變化非常大時，對分發(fā)的消息進行批量優(yōu)化。

圖7-16

（4）對于未登錄和識別身份的API調用，流量網(wǎng)關實現(xiàn)全局的流控策略，增加緩存時間和限制調用次數(shù)，保障系統(tǒng)穩(wěn)定。

（5）業(yè)務網(wǎng)關根據(jù)API服務的重要等級和客戶的分類，進一步細化和實時控制網(wǎng)關策略，最大限度地保障核心業(yè)務和客戶的使用。

從監(jiān)控圖表可以看到，優(yōu)化之后的效果非常明顯，系統(tǒng)穩(wěn)定，連接數(shù)平穩(wěn)。

本文節(jié)選自《高可用可伸縮微服務架構：基于Dubbo、Spring Cloud和Service Mesh》一書，程超，梁桂釗，秦金衛(wèi)，方志斌，張逸等著。