美團百億規模API網關服務Shepherd的設計與實現

在微服務架構下，服務拆分會讓API的規模成倍增加，使用API網關來管理API逐漸成爲一種趨勢。美團統一API網關服務Shepherd就是在這種背景下應運而生，適用於美團業務且徹底自研，用於替換傳統的Web層網關應用，業務研發人員經過配置的方式便可對外開放功能和數據。本文將介紹美團統一API網關誕生的背景、關鍵的技術設計和實現，以及API網關將來的規劃，但願能給你們帶來一些幫助或者啓發。

1、背景介紹

1.1 API網關是什麼？

API網關是隨着微服務（Microservice）概念興起的一種架構模式。本來一個龐大的單體應用（All in one）業務系統被拆分紅許多微服務（Microservice）系統進行獨立的維護和部署，服務拆分帶來的變化是API的規模成倍增加，API的管理難度也在日益增長，使用API網關發佈和管理API逐漸成爲一種趨勢。通常來講，API網關是運行於外部請求與內部服務之間的一個流量入口，實現對外部請求的協議轉換、鑑權、流控、參數校驗、監控等通用功能。

1.2 爲何要作Shepherd API網關？

在沒有Shepherd API網關以前，美團業務研發人員若是要將內部服務輸出爲對外的HTTP API接口。一般要搭建一個Web應用，用於完成基礎的鑑權、限流、監控日誌、參數校驗、協議轉換等工做，同時須要維護代碼邏輯、基礎組件的升級，研發效率相對比較低。此外，每一個Web應用都須要維護機器、配置、數據庫等，資源利用率也很是差。

美團內部一些業務線苦於沒有現成的解決方案，根據自身業務特色，研發了業務相關的API網關。放眼業界，亞馬遜、阿里巴巴、騰訊等公司也都有成熟的API網關解決方案。

所以，Shepherd API網關項目正式立項，咱們的目標是爲美團提供高性能、高可用、可擴展的統一API網關解決方案，讓業務研發人員經過配置的方式便可對外開放功能和數據。

1.3 使用Shepherd帶來的收益是什麼？

從業務研發人員的角度來看，接入Shepherd API網關，能帶來哪些收益呢？簡而言之包括三個方面。

• 提高研發效率

  • 業務研發人員只須要經過配置的方式便可快速開放服務接口。
  • Shepherd統一提供鑑權、限流、熔斷等非業務基礎能力。
  • Shepherd支持業務研發人員經過開發自定義組件的方式擴展API網關能力。

• 下降溝通成本

  • 業務研發人員配置好API，能夠自動生成API的先後端交互文檔和客戶端SDK，方便先後端開發人員進行交互、聯調。

• 提高資源利用率

  • 基於Serverless的架構思想，實現API全託管，業務研發人員無需關心機器資源問題。

2、技術設計與實現

2.1 總體架構

咱們先來看看Shepherd API網關的總體架構，以下圖所示：

Shepherd API網關的控制面由Shepherd管理平臺和Shepherd監控中心組成。管理平臺主要完成API的全生命週期管理以及配置下發的工做，監控中心完成API請求監控數據的收集和業務告警功能。

Shepherd API網關的配置中心主要完成控制面與數據面的信息交互，經過美團統一配置服務Lion來實現。

Shepherd API網關的數據面也就是Shepherd 服務端。一次完整的API請求，多是從移動應用、Web應用，合做夥伴或內部系統發起，通過Nginx負載均衡系統後，到達服務端。服務端集成了一系列的基礎功能組件和業務自定義組件，經過泛化調用請求後端RPC服務、HTTP服務、函數服務或服務編排服務，最後返回響應結果。

下面咱們將針對這三個主要模塊作詳細的介紹。

2.1.1 控制面

使用API網關的控制面，業務研發人員能夠輕鬆的完成API的全生命週期管理，以下圖所示：

業務研發人員從建立API開始，完成參數錄入、DSL腳本生成；接着能夠經過文檔和MOCK功能進行API測試；API測試完成後，爲了保證上線穩定性，Shepherd管理平臺提供了發佈審批、灰度上線、版本回滾等一系列安全保證措施；API運行期間會監控API的調用失敗狀況、記錄請求日誌，一旦發現異常及時發出告警；最後，對於再也不使用的API進行下線操做後，會回收API所佔用的各種資源並等待從新啓用。

整個生命週期，所有經過配置化、流程化的方式，由業務研發人員全自助管理，上手時間基本在10分鐘之內，極大地提高了研發效率。

2.1.2 配置中心

API網關的配置中心存放API的相關配置信息——使用自定義的DSL（Domain-Specific Language，領域專用語言）來描述，用於向API網關的數據面下發API的路由、規則、組件等配置變動。

配置中心的設計上使用統一配置管理服務Lion和本地緩存結合的方式，實現動態配置，不停機發布。API的配置以下圖所示：

API配置的詳細說明：

• Name、Group：名字、所屬分組。
• Request：請求的域名、路徑、參數等信息。
• Response：響應的結果組裝、異常處理、Header、Cookies信息。
• Filters、FilterConfigs：API使用到的功能組件和配置信息。
• Invokers：後端服務(RPC/HTTP/Function)的請求規則和編排信息。

2.1.3 數據面

API路由

API網關的數據面在感知到API配置後，會在內存中創建請求路徑與API配置的路由信息。一般HTTP請求路徑上，會包含一些路徑變量，考慮到性能問題，Shepherd沒有采用正則匹配的方式，而是設計了兩種數據結構來存儲。以下圖所示：

一種是不包含路徑變量的直接映射的MAP結構。其中，Key就是完整的域名和路徑信息，Value是具體的API配置。

另一種是包含路徑變量的前綴樹數據結構。經過前綴匹配的方式，先進行葉子節點精確查找，並將查找節點入棧處理，若是匹配不上，則將棧頂節點出棧，再將同級的變量節點入棧，若是仍然找不到，則繼續回溯，直到找到（或沒找到）路徑節點並退出。

功能組件

當請求流量命中API請求路徑進入服務端，具體處理邏輯由DSL中配置的一系列功能組件完成。網關提供了豐富的功能組件集成，包括鏈路追蹤、實時監控、訪問日誌、參數校驗、鑑權、限流、熔斷降級、灰度分流等，以下圖所示：

協議轉換&服務調用

API調用的最後一步，就是協議轉換以及服務調用了。網關須要完成的工做包括：獲取HTTP請求參數、Context本地參數，拼裝後端服務參數，完成HTTP協議到後端服務的協議轉換，調用後端服務獲取響應結果並轉換爲HTTP響應結果。

上圖以調用後端RPC服務爲例，經過JsonPath表達式獲取HTTP請求不一樣部位的參數值，替換RPC請求參數相應部位的Value，生成服務參數DSL，最後藉助RPC泛化調用完成本次服務調用。

2.2 高可用設計

Shepherd API網關做爲接入層的基礎組件，高可用性一直是業務研發人員很是關心的部分。接下來。咱們就來探索一下Shepherd在高可用設計方面的實踐。

2.2.1 排除性能隱患

一個高可用的系統，預防故障的發生，首先要排除性能隱患，保證高性能。

Shepherd對API請求作了全異步化處理，請求經過Jetty IO線程異步提交到業務處理線程池，調用後端服務使用RPC或HTTP框架的異步方式，釋放了因爲網絡等待引發的線程佔用，使線程數再也不成爲網關的瓶頸。下圖是使用Jetty容器時，服務端的請求線程處理邏輯：

咱們經過域名壓測網關單機的端到端QPS，發現QPS在超過2000時，會出現不少超時錯誤，而網關的服務端負載與性能卻很是富餘。調研發現，公司內其餘的Web應用都存在這個問題，與Oceanus團隊進行聯合排查後，發現是Nginx與Web應用之間的長鏈接功能沒有打開，且沒法配置。Oceanus團隊通過緊急排期，研發並上線長鏈接功能後，Shepherd端到端的QPS成功提高到了10000以上。

另外，咱們對Shepherd服務端進行了API請求預熱的優化，使得網關啓動時能馬上達到最佳性能，減小毛刺的發生。而後，經過壓測時的CPU熱點排查，將性能瓶頸找出，減小主鏈路上的本地日誌打印，對請求日誌進行異步化、遠程化改造。Shepherd端到端的QPS再次提高30%以上。

在Shepherd服務上線穩定運行一年之後，咱們再次對性能進行優化，而且作了一次網絡框架升級，將Jetty容器全面替換爲Netty網絡框架，性能提高10%以上，Shepherd端到端的QPS成功提高到15000以上。下圖是使用Netty框架時，服務端的請求線程處理邏輯：

2.2.2 服務隔離

集羣隔離

借鑑公司緩存、任務調度等成熟組件的經驗，Shepherd在設計之初，就考慮了按業務線維度進行集羣隔離，也支持重要業務獨立部署。以下圖所示：

請求隔離

服務節點維度，Shepherd支持請求的快慢線程池隔離。快慢線程池隔離主要用於一些使用了同步阻塞組件的API，例如SSO鑑權、自定義鑑權等，可能致使長時間阻塞共享業務線程池。

快慢隔離的原理是統計API請求的處理時間，將請求處理耗時較長，超過容忍閾值的API請求隔離到慢線程池，避免影響其餘正常API的調用。

除此以外，Shepherd也支持業務研發人員配置自定義線程池進行隔離。具體的線程隔離模型以下圖所示：

2.2.3 穩定性保障

Shepherd提供了一些常規的穩定性保障手段，來保證自身和後端服務的可用性。以下圖所示：

• 流量管控：從用戶自定義UUID限流、App限流、IP限流、集羣限流等多個維度提供流量保護。
• 請求緩存：對於一些冪等的、查詢頻繁的、數據及時性不敏感的請求，業務研發人員可開啓請求緩存功能。
• 超時管理：每一個API都設置了處理超時時間，對於超時的請求，進行快速失敗的處理，避免資源佔用。
• 熔斷降級：支持熔斷降級功能，實時監控請求的統計信息，達到配置的失敗閾值後，自動熔斷，返回默認值。

2.2.4 請求安全

請求安全是API網關很是重要的能力，Shepherd集成了豐富的安全相關的系統組件，包括有基礎的請求籤名、SSO單點登陸、基於SSO鑑權的UAC/UPM訪問控制、用戶鑑權Passport、商家鑑權EPassport、商家權益鑑權、反爬等等。業務研發人員只須要簡單配置，便可使用。

2.2.5 可灰度

API網關做爲請求入口，每每肩負着請求流量灰度驗證的重任。

灰度場景

Shepherd在灰度能力上，支持灰度API自身邏輯，也支持灰度下游服務，也能夠同時灰度API自身邏輯和下游服務。以下圖所示：

灰度API自身邏輯時，經過將流量分流到不一樣的API版本實現灰度能力；灰度下游服務時，經過給流量打標，分流到指定的下游灰度單元中。

灰度策略

Shepherd支持豐富的灰度策略，能夠按照比例數灰度，也能夠按照特定條件灰度。

2.2.6 監控告警

立體化監控

Shepherd提供360度的立體化監控，從業務指標、機器指標、JVM指標提供7x24小時的專業守護，以下表：

	監控模塊	主要功能
1	統一監控Raptor	實時上報請求調用信息、系統指標，負責應用層（JVM）監控、系統層（CPU、IO、網絡）監控
2	鏈路追蹤Mtrace	負責全鏈路參數透傳、全鏈路追蹤監控
3	日誌監控Logscan	監控本地日誌異常關鍵字：如5xx狀態碼、空指針異常等
4	遠程日誌中心	API請求日誌、Debug日誌、組件日誌等可上報遠程日誌中心
5	健康檢查Scanner	對網關節點進行心跳檢測和API狀態檢測，及時發現異常節點和異常API

多維度告警

有了全面的監控體系，天然少不了配套的告警機制，主要的告警能力包括：

	告警類型	觸發時機
1	限流告警	API請求達到限流規則閾值觸發限流告警
2	請求失敗告警	鑑權失敗、請求超時、後端服務異常等觸發請求失敗告警
3	組件異常告警	自定義組件處理耗時長、失敗率高告警
4	API異常告警	API發佈失敗、API檢查異常時觸發API異常告警
5	健康檢查失敗告警	API心跳檢查失敗、網關節點不通時觸發健康檢查失敗告警

2.2.7 故障自愈

Shepherd服務端接入了彈性伸縮模塊，可根據CPU等指標進行快速擴容、縮容。除此以外，還支持快速摘除問題節點，以及更細粒度的問題組件摘除。

2.2.8 可遷移

對於一些已經在對外提供API的Web服務，業務研發人員爲了減小運維成本和後續的研發提效，考慮將其遷移到Shepherd API網關。

對於一些非核心API，能夠考慮使用Oceanus的灰度發佈功能直接遷移。可是對於一些核心API，上面的灰度發佈功能是機器級別的，粒度較大，不夠靈活，不能很好的支持灰度驗證過程。

解決方案

Shepherd爲業務研發人員提供了一個灰度SDK，接入SDK的Web服務，可在識別灰度流量後轉發到Shepherd API網關進行驗證。

灰度哪些API、灰度百分比能夠在Shepherd管理端動態調節，實時生效，業務研發人員還能夠經過SPI的方式自定義灰度策略。灰度驗證經過後，再把API遷移到Shepherd API網關，保障遷移過程的穩定性。

灰度過程

灰度前：在Shepherd管理平臺建立API分組，域名配置爲目前使用的域名。在Oceanus上，原域名規則不變。

灰度中：在Shepherd管理平臺開啓灰度功能，灰度SDK將灰度流量轉發到網關服務，進行驗證。

灰度後：經過灰度流量驗證Shepherd上的API配置符合預期後再遷移。

2.3 易用性設計

Shepherd API網關的功能強大且複雜，易用性對業務研發人員來講相當重要，咱們着重來看下自動生成DSL、API操做提效的解決方案。

2.3.1 自動生成DSL

業務研發人員在實際使用網關管理平臺時，咱們儘可能經過圖形化的頁面配置來減輕DSL的編寫負擔。但服務參數轉換的DSL配置，仍然須要業務研發人員手工編寫。通常來講，生成服務參數DSL的流程是：

1. 引入服務的接口包依賴。
2. 拿到服務參數類定義。
3. 編寫Testcase生成JSON模板。
4. 填寫參數映射規則。
5. 最後手工錄入管理平臺，發佈API。

整個過程很是繁瑣，且容易出錯。若是須要錄入的API多達幾十上百個，所有由業務研發人員手工錄入的效率是很是低下的。

解決方案

那麼能不能將服務參數DSL的生成過程給自動化呢？ 答案是能夠的，業務RD只需在網關錄入API文檔信息，而後錄入服務的Appkey、服務名、方法名信息，Shepherd管理端會從最新發布的服務框架控制檯獲取到服務參數的JSON Schema信息，JSON Schema定義了服務參數的類型和結構信息，管理端可根據這些信息，自動生成服務參數的JSON Mock數據。結合API文檔的信息，自動替換參數名相同的Value值。 這套DSL自動生成方案，使用過程當中對業務透明、標準化，業務方只需升級最新版本服務框架便可使用，極大提高研發效率，目前受到業務研發人員的普遍好評。

2.3.2 API操做提效

快速建立API

API網關的核心能力是創建在API配置的基礎上的，但提供強大功能的同時帶來了較高的複雜性，很多業務研發人員吐槽API配置太繁瑣，學習成本高。快速建立API的功能應運而生，業務研發人員只須要提供少許的信息就能夠建立API。快速建立API的功能當前分爲4種類型（後端RPC服務API、後端HTTP服務API、SSO CallBack API、Nest API），將來會根據業務應用場景的不一樣，提供更多的快速建立API類型。

批量操做

業務研發人員在API網關上，須要管理很是多的業務分組，每一個業務分組，最多能夠有200個API配置，多個API可能有不少相同的配置，如組件配置，錯誤碼配置和跨域配置的。每一個API對於相同的配置都要配置一遍，操做重複度很高。所以Shepherd支持批量操做多個API：勾選多個API後，經過【批量操做】功能可一次性完成多個API配置更新，下降業務重複配置的操做成本。

API導入導出

Shepherd提供在不一樣研發環境相互導入導出API的能力，業務研發人員在線下測試完成後，只須要使用API導入導出功能，便可將配置導出到線上生產環境，避免重複配置。

2.4 可擴展性設計

一個設計良好的基礎組件，除了能提供強大的基礎能力，還須要有良好的擴展能力。 Shepherd的可擴展性主要體如今：支持自定義組件、服務編排的能力。

2.4.1 自定義組件

Shepherd提供了豐富的系統組件完成鑑權、限流、監控能力，可以知足大部分的業務需求。但仍有一些特殊的業務需求，如自定義驗籤、自定義結果處理等。Shepherd經過提供加載自定義組件能力，支持業務完成一些自定義邏輯的擴展。

下圖是自定義組件實現的一個實例。getName中填寫自定義組件申請時的名稱，invoke方法中實現自定義組件的業務邏輯，如繼續執行、進行頁面跳轉、直接返回結果、拋出異常等。

目前Shepherd經過自定義組件已經成功支持了美團優選、外賣、餐飲、打車等重要業務，接入的自定義組件數量有200多個。

2.4.2 服務編排

通常狀況下，網關上配置的一個API對應後端一個RPC或者HTTP服務。若是調用端有聚合和編排後端服務的需求，那麼有多少後端服務，就必須發起多少次HTTP的請求調用。由此就會帶來一些問題，調用端的HTTP請求次數過多，效率低，在調用端聚合服務的邏輯太重。

服務編排的需求應運而生，服務編排是對既有服務進行編排調用，同時對獲取的數據進行處理。主要應用在數據聚合場景：一次HTTP請求返回的數據須要調用多個或屢次服務（RPC或HTTP）才能獲取到完整的結果。

通過前期調研，公司已經有一套成熟的服務編排框架，由客服團隊開發的海盜組件（參見《海盜中間件：美團服務體驗平臺對接業務數據的最佳實踐》一文），也是美團內部的公共服務。

所以咱們與海盜團隊合做，設計了Shepherd的服務編排支持方案。海盜經過獨立部署的方式提供服務編排能力，Shepherd與海盜之間經過RPC進行調用。這樣能夠解耦Shepherd與海盜，避免因服務編排能力影響集羣上的其餘服務，同時多一次RPC調用並不會有明顯耗時增長。使用上對業務研發人員也是透明的，很是方便，業務研發人員在管理端配置好服務編排的API，經過配置中心同時下發到Shepherd服務端和海盜服務上，便可開始使用服務編排能力。總體的交互架構圖以下：

3、將來規劃

目前接入Shepherd API網關的API數量超過18000多個，線上運行的集羣數量90多個，日均總調用次數在百億以上。隨着Shepherd API網關業務規模的不斷增加，對咱們的可用性、易用性、可擴展性必將提出更高的要求。將來一年，Shepherd的規劃重點包括有云原生架構演進、靜態網站託管、組件市場等。

3.1 雲原生架構演進

Shepherd API網關的雲原生架構演進有三個目標：簡化接入網關步驟，提高業務研發人員的研發效率；減少服務端War包大小，提高安全性和穩定性；接入Serverless彈性，下降成本，提升資源利用率。

爲了實現這個三個目標，咱們計劃總體遷移網關服務到公司的Serverless服務Nest（參見《美團Serverless平臺Nest的探索與實踐》一文）上，同時經過抽取Shepherd核心功能到SDK的方式集成到業務的網關集羣，業務研發人員能夠只選擇本身須要使用的自定義組件，從而大幅減少服務端的War包大小。

3.2 靜態網站託管

依託Shepherd API網關實現靜態網站託管的目標是：建設通用的靜態網站託管解決方案，爲開發者提供便捷、穩定、高擴展性的靜態網站託管服務。

靜態網站託管解決方案能爲業務研發人員提供的主要功能包括：託管靜態網站資源，包括存儲及訪問；管理應用生命週期，包括自定義域配置以及身份驗證和受權；CI/CD集成等。

3.3 組件市場

Shepherd API網關組件市場的目標是：合做雙贏，造成開發生態，業務研發人員可將開發的自定義組件提供給其餘有須要的業務研發團隊使用。

咱們但願讓業務研發人員參與到自定義組件的開發，完善使用文檔後設置爲公共組件，開放給全部使用Shepherd的業務研發人員使用，避免重複造輪子。

做者簡介

充澤、志洋、李敏等，均來自美團基礎技術部-基礎架構團隊。

招聘信息

美團基礎技術部-基礎架構團隊誠招高級、資深技術專家，Base北京、上海。咱們致力於建設美團全公司統一的高併發高性能分佈式基礎架構平臺，涵蓋數據庫、分佈式監控、服務治理、高性能通訊、消息中間件、基礎存儲、容器化、集羣調度等基礎架構主要的技術領域。歡迎有興趣的同窗投送簡歷至：edp.itu.zhaopin@meituan.com。

閱讀美團技術團隊更多技術文章合集

前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試

| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品，著做權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明「內容轉載自美團技術團隊」。本文未經許可，不得進行商業性轉載或者使用。任何商用行爲，請發送郵件至tech@meituan.com申請受權。