美团技术：百亿规模API网关服务Shepherd的设计与实现
在微服務(wù)架構(gòu)下，服務(wù)拆分會讓API的規(guī)模成倍增長，使用API網(wǎng)關(guān)來管理API逐漸成為一種趨勢。美團統(tǒng)一API網(wǎng)關(guān)服務(wù)Shepherd就是在這種背景下應(yīng)運而生，適用于美團業(yè)務(wù)且完全自研，用于替換傳統(tǒng)的Web層網(wǎng)關(guān)應(yīng)用，業(yè)務(wù)研發(fā)人員通過配置的方式即可對外開放功能和數(shù)據(jù)。本文將介紹美團統(tǒng)一API網(wǎng)關(guān)誕生的背景、關(guān)鍵的技術(shù)設(shè)計和實現(xiàn)，以及API網(wǎng)關(guān)未來的規(guī)劃，希望能給大家?guī)硪恍椭蛘邌l(fā)。
一、背景介紹
1.1 API網(wǎng)關(guān)是什么？
1.2 為什么要做Shepherd API網(wǎng)關(guān)？
1.3 使用Shepherd帶來的收益是什么？
二、技術(shù)設(shè)計與實現(xiàn)
2.1 整體架構(gòu)
2.2 高可用設(shè)計
2.3 易用性設(shè)計
2.4 可擴展性設(shè)計
三、未來規(guī)劃
3.1 云原生架構(gòu)演進
3.2 靜態(tài)網(wǎng)站托管
3.3 組件市場
作者簡介
招聘信息
一、背景
1.1 API網(wǎng)關(guān)是什么？
API網(wǎng)關(guān)是隨著微服務(wù)（Microservice）概念興起的一種架構(gòu)模式。原本一個龐大的單體應(yīng)用（All in one）業(yè)務(wù)系統(tǒng)被拆分成許多微服務(wù)（Microservice）系統(tǒng)進行獨立的維護和部署，服務(wù)拆分帶來的變化是API的規(guī)模成倍增長，API的管理難度也在日益增加，使用API網(wǎng)關(guān)發(fā)布和管理API逐漸成為一種趨勢。一般來說，API網(wǎng)關(guān)是運行于外部請求與內(nèi)部服務(wù)之間的一個流量入口，實現(xiàn)對外部請求的協(xié)議轉(zhuǎn)換、鑒權(quán)、流控、參數(shù)校驗、監(jiān)控等通用功能。
1.2 為什么要做Shepherd API網(wǎng)關(guān)？
在沒有Shepherd API網(wǎng)關(guān)之前，美團業(yè)務(wù)研發(fā)人員如果要將內(nèi)部服務(wù)輸出為對外的HTTP API接口。通常要搭建一個Web應(yīng)用，用于完成基礎(chǔ)的鑒權(quán)、限流、監(jiān)控日志、參數(shù)校驗、協(xié)議轉(zhuǎn)換等工作，同時需要維護代碼邏輯、基礎(chǔ)組件的升級，研發(fā)效率相對比較低。此外，每個Web應(yīng)用都需要維護機器、配置、數(shù)據(jù)庫等，資源利用率也非常差。
美團內(nèi)部一些業(yè)務(wù)線苦于沒有現(xiàn)成的解決方案，根據(jù)自身業(yè)務(wù)特點，研發(fā)了業(yè)務(wù)相關(guān)的API網(wǎng)關(guān)。放眼業(yè)界，亞馬遜、阿里巴巴、騰訊等公司也都有成熟的API網(wǎng)關(guān)解決方案。
因此，Shepherd API網(wǎng)關(guān)項目正式立項，我們目標是為美團提供高性能、高可用、可擴展的統(tǒng)一API網(wǎng)關(guān)解決方案，讓業(yè)務(wù)研發(fā)人員通過配置的方式即可對外開放功能和數(shù)據(jù)。
圖 11.3 使用Shepherd帶來的收益是什么？
從業(yè)務(wù)研發(fā)人員的角度來看，接入Shepherd API網(wǎng)關(guān)，能帶來哪些收益呢？簡而言之包括三個方面。
提升研發(fā)效率
業(yè)務(wù)研發(fā)人員只需要通過配置的方式即可快速開放服務(wù)接口。
Shepherd統(tǒng)一提供鑒權(quán)、限流、熔斷等非業(yè)務(wù)基礎(chǔ)能力。
Shepherd支持業(yè)務(wù)研發(fā)人員通過開發(fā)自定義組件的方式擴展API網(wǎng)關(guān)能力。
降低溝通成本
業(yè)務(wù)研發(fā)人員配置好API，可以自動生成API的前后端交互文檔和客戶端SDK，方便前后端開發(fā)人員進行交互、聯(lián)調(diào)。
提升資源利用率
基于Serverless的架構(gòu)思想，實現(xiàn)API全托管，業(yè)務(wù)研發(fā)人員無需關(guān)心機器資源問題。
二、技術(shù)設(shè)計與實現(xiàn)
2.1 整體架構(gòu)
我們先來看看Shepherd API網(wǎng)關(guān)的整體架構(gòu)，如下圖所示：
圖 2Shepherd API網(wǎng)關(guān)的控制面由Shepherd管理平臺和Shepherd監(jiān)控中心組成。管理平臺主要完成API的全生命周期管理以及配置下發(fā)的工作，監(jiān)控中心完成API請求監(jiān)控數(shù)據(jù)的收集和業(yè)務(wù)告警功能。
Shepherd API網(wǎng)關(guān)的配置中心主要完成控制面與數(shù)據(jù)面的信息交互，通過美團統(tǒng)一配置服務(wù)Lion來實現(xiàn)。
Shepherd API網(wǎng)關(guān)的數(shù)據(jù)面也就是Shepherd 服務(wù)端。一次完整的API請求，可能是從移動應(yīng)用、Web應(yīng)用，合作伙伴或內(nèi)部系統(tǒng)發(fā)起，經(jīng)過Nginx負載均衡系統(tǒng)后，到達服務(wù)端。服務(wù)端集成了一系列的基礎(chǔ)功能組件和業(yè)務(wù)自定義組件，通過泛化調(diào)用請求后端RPC服務(wù)、HTTP服務(wù)、函數(shù)服務(wù)或服務(wù)編排服務(wù)，最后返回響應(yīng)結(jié)果。
下面我們將針對這三個主要模塊做詳細的介紹。
2.1.1 控制面
使用API網(wǎng)關(guān)的控制面，業(yè)務(wù)研發(fā)人員可以輕松的完成API的全生命周期管理，如下圖所示：
圖 3業(yè)務(wù)研發(fā)人員從創(chuàng)建API開始，完成參數(shù)錄入、DSL腳本生成；接著可以通過文檔和MOCK功能進行API測試；API測試完成后，為了保證上線穩(wěn)定性，Shepherd管理平臺提供了發(fā)布審批、灰度上線、版本回滾等一系列安全保證措施；API運行期間會監(jiān)控API的調(diào)用失敗情況、記錄請求日志，一旦發(fā)現(xiàn)異常及時發(fā)出告警；最后，對于不再使用的API進行下線操作后，會回收API所占用的各類資源并等待重新啟用。
整個生命周期，全部通過配置化、流程化的方式，由業(yè)務(wù)研發(fā)人員全自助管理，上手時間基本在10分鐘以內(nèi)，極大地提升了研發(fā)效率。
2.1.2 配置中心
API網(wǎng)關(guān)的配置中心存放API的相關(guān)配置信息——使用自定義的DSL（Domain-Specific?Language，領(lǐng)域?qū)Ｓ谜Z言）來描述，用于向API網(wǎng)關(guān)的數(shù)據(jù)面下發(fā)API的路由、規(guī)則、組件等配置變更。
配置中心的設(shè)計上使用統(tǒng)一配置管理服務(wù)Lion和本地緩存結(jié)合的方式，實現(xiàn)動態(tài)配置，不停機發(fā)布。API的配置如下圖所示：
圖 4API配置的詳細說明：
Name、Group：名字、所屬分組。
Request：請求的域名、路徑、參數(shù)等信息。
Response：響應(yīng)的結(jié)果組裝、異常處理、Header、Cookies信息。
Filters、FilterConfigs：API使用到的功能組件和配置信息。
Invokers：后端服務(wù)（RPC/HTTP/Function）的請求規(guī)則和編排信息。
2.1.3 數(shù)據(jù)面
API路由
API網(wǎng)關(guān)的數(shù)據(jù)面在感知到API配置后，會在內(nèi)存中建立請求路徑與API配置的路由信息。通常HTTP請求路徑上，會包含一些路徑變量，考慮到性能問題，Shepherd沒有采用正則匹配的方式，而是設(shè)計了兩種數(shù)據(jù)結(jié)構(gòu)來存儲。如下圖所示：
圖 5一種是不包含路徑變量的直接映射的MAP結(jié)構(gòu)。其中，Key就是完整的域名和路徑信息，Value是具體的API配置。
另外一種是包含路徑變量的前綴樹數(shù)據(jù)結(jié)構(gòu)。通過前綴匹配的方式，先進行葉子節(jié)點精確查找，并將查找節(jié)點入棧處理，如果匹配不上，則將棧頂節(jié)點出棧，再將同級的變量節(jié)點入棧，如果仍然找不到，則繼續(xù)回溯，直到找到（或沒找到）路徑節(jié)點并退出。
功能組件
當(dāng)請求流量命中API請求路徑進入服務(wù)端，具體處理邏輯由DSL中配置的一系列功能組件完成。網(wǎng)關(guān)提供了豐富的功能組件集成，包括鏈路追蹤、實時監(jiān)控、訪問日志、參數(shù)校驗、鑒權(quán)、限流、熔斷降級、灰度分流等，如下圖所示：
圖 6協(xié)議轉(zhuǎn)換&服務(wù)調(diào)用
API調(diào)用的最后一步，就是協(xié)議轉(zhuǎn)換以及服務(wù)調(diào)用了。網(wǎng)關(guān)需要完成的工作包括：獲取HTTP請求參數(shù)、Context本地參數(shù)，拼裝后端服務(wù)參數(shù)，完成HTTP協(xié)議到后端服務(wù)的協(xié)議轉(zhuǎn)換，調(diào)用后端服務(wù)獲取響應(yīng)結(jié)果并轉(zhuǎn)換為HTTP響應(yīng)結(jié)果。
圖 7上圖以調(diào)用后端RPC服務(wù)為例，通過JsonPath表達式獲取HTTP請求不同部位的參數(shù)值，替換RPC請求參數(shù)相應(yīng)部位的Value，生成服務(wù)參數(shù)DSL，最后借助RPC泛化調(diào)用完成本次服務(wù)調(diào)用。
2.2 高可用設(shè)計
Shepherd API網(wǎng)關(guān)作為接入層的基礎(chǔ)組件，高可用性一直是業(yè)務(wù)研發(fā)人員非常關(guān)心的部分。接下來，我們就來探索一下Shepherd在高可用設(shè)計方面的實踐。
2.2.1 排除性能隱患
一個高可用的系統(tǒng)，預(yù)防故障的發(fā)生，首先要排除性能隱患，保證高性能。
Shepherd對API請求做了全異步化處理，請求通過Jetty IO線程異步提交到業(yè)務(wù)處理線程池，調(diào)用后端服務(wù)使用RPC或HTTP框架的異步方式，釋放了由于網(wǎng)絡(luò)等待引起的線程占用，使線程數(shù)不再成為網(wǎng)關(guān)的瓶頸。下圖是使用Jetty容器時，服務(wù)端的請求線程處理邏輯：
圖 8我們通過域名壓測網(wǎng)關(guān)單機的端到端QPS，發(fā)現(xiàn)QPS在超過2000時，會出現(xiàn)很多超時錯誤，而網(wǎng)關(guān)的服務(wù)端負載與性能卻非常富余。調(diào)研發(fā)現(xiàn)，公司內(nèi)其他的Web應(yīng)用都存在這個問題，與Oceanus團隊進行聯(lián)合排查后，發(fā)現(xiàn)是Nginx與Web應(yīng)用之間的長連接功能沒有打開，且無法配置。Oceanus團隊經(jīng)過緊急排期，研發(fā)并上線長連接功能后，Shepherd端到端的QPS成功提升到了10000以上。
另外，我們對Shepherd服務(wù)端進行了API請求預(yù)熱的優(yōu)化，使得網(wǎng)關(guān)啟動時能立刻達到最佳性能，減少毛刺的發(fā)生。然后，通過壓測時的CPU熱點排查，將性能瓶頸找出，減少主鏈路上的本地日志打印，對請求日志進行異步化、遠程化改造。Shepherd端到端的QPS再次提升30%以上。
在Shepherd服務(wù)上線穩(wěn)定運行一年以后，我們再次對性能進行優(yōu)化，并且做了一次網(wǎng)絡(luò)框架升級，將Jetty容器全面替換為Netty網(wǎng)絡(luò)框架，性能提升10%以上，Shepherd端到端的QPS成功提升到15000以上。下圖是使用Netty框架時，服務(wù)端的請求線程處理邏輯：
圖 92.2.2 服務(wù)隔離
集群隔離
借鑒公司緩存、任務(wù)調(diào)度等成熟組件的經(jīng)驗，Shepherd在設(shè)計之初，就考慮了按業(yè)務(wù)線維度進行集群隔離，也支持重要業(yè)務(wù)獨立部署。如下圖所示：
圖10請求隔離
服務(wù)節(jié)點維度，Shepherd支持請求的快慢線程池隔離。快慢線程池隔離主要用于一些使用了同步阻塞組件的API，例如SSO鑒權(quán)、自定義鑒權(quán)等，可能導(dǎo)致長時間阻塞共享業(yè)務(wù)線程池。
快慢隔離的原理是統(tǒng)計API請求的處理時間，將請求處理耗時較長，超過容忍閾值的API請求隔離到慢線程池，避免影響其他正常API的調(diào)用。
除此之外，Shepherd也支持業(yè)務(wù)研發(fā)人員配置自定義線程池進行隔離。具體的線程隔離模型如下圖所示：
圖 112.2.3 穩(wěn)定性保障
Shepherd提供了一些常規(guī)的穩(wěn)定性保障手段，來保證自身和后端服務(wù)的可用性。如下圖所示：
圖12流量管控：從用戶自定義UUID限流、App限流、IP限流、集群限流等多個維度提供流量保護。
請求緩存：對于一些冪等的、查詢頻繁的、數(shù)據(jù)及時性不敏感的請求，業(yè)務(wù)研發(fā)人員可開啟請求緩存功能。
超時管理：每個API都設(shè)置了處理超時時間，對于超時的請求，進行快速失敗的處理，避免資源占用。
熔斷降級：支持熔斷降級功能，實時監(jiān)控請求的統(tǒng)計信息，達到配置的失敗閾值后，自動熔斷，返回默認值。
2.2.4 請求安全
請求安全是API網(wǎng)關(guān)非常重要的能力，Shepherd集成了豐富的安全相關(guān)的系統(tǒng)組件，包括有基礎(chǔ)的請求簽名、SSO單點登錄、基于SSO鑒權(quán)的UAC/UPM訪問控制、用戶鑒權(quán)Passport、商家鑒權(quán)EPassport、商家權(quán)益鑒權(quán)、反爬等等。業(yè)務(wù)研發(fā)人員只需要簡單配置，即可使用。
2.2.5 可灰度
API網(wǎng)關(guān)作為請求入口，往往肩負著請求流量灰度驗證的重任。
灰度場景
Shepherd在灰度能力上，支持灰度API自身邏輯，也支持灰度下游服務(wù)，也可以同時灰度API自身邏輯和下游服務(wù)。如下圖所示：
圖 13灰度API自身邏輯時，通過將流量分流到不同的API版本實現(xiàn)灰度能力；灰度下游服務(wù)時，通過給流量打標，分流到指定的下游灰度單元中。
灰度策略
Shepherd支持豐富的灰度策略，可以按照比例數(shù)灰度，也可以按照特定條件灰度。
2.2.6 監(jiān)控告警
立體化監(jiān)控
Shepherd提供360度的立體化監(jiān)控，從業(yè)務(wù)指標、機器指標、JVM指標提供7x24小時的專業(yè)守護，如下表：
多維度告警
有了全面的監(jiān)控體系，自然少不了配套的告警機制，主要的告警能力包括：
2.2.7 故障自愈
Shepherd服務(wù)端接入了彈性伸縮模塊，可根據(jù)CPU等指標進行快速擴容、縮容。除此之外，還支持快速摘除問題節(jié)點，以及更細粒度的問題組件摘除。
圖 142.2.8 可遷移
對于一些已經(jīng)在對外提供API的Web服務(wù)，業(yè)務(wù)研發(fā)人員為了減少運維成本和后續(xù)的研發(fā)提效，考慮將其遷移到Shepherd API網(wǎng)關(guān)。
對于一些非核心API，可以考慮使用Oceanus的灰度發(fā)布功能直接遷移。但是對于一些核心API，上面的灰度發(fā)布功能是機器級別的，粒度較大，不夠靈活，不能很好的支持灰度驗證過程。
解決方案
Shepherd為業(yè)務(wù)研發(fā)人員提供了一個灰度SDK，接入SDK的Web服務(wù)，可在識別灰度流量后轉(zhuǎn)發(fā)到Shepherd API網(wǎng)關(guān)進行驗證。
灰度哪些API、灰度百分比可以在Shepherd管理端動態(tài)調(diào)節(jié)，實時生效，業(yè)務(wù)研發(fā)人員還可以通過SPI的方式自定義灰度策略。灰度驗證通過后，再把API遷移到Shepherd API網(wǎng)關(guān)，保障遷移過程的穩(wěn)定性。
灰度過程
灰度前：在Shepherd管理平臺創(chuàng)建API分組，域名配置為目前使用的域名。在Oceanus上，原域名規(guī)則不變。
圖 15灰度中：在Shepherd管理平臺開啟灰度功能，灰度SDK將灰度流量轉(zhuǎn)發(fā)到網(wǎng)關(guān)服務(wù)，進行驗證。
圖 16灰度后：通過灰度流量驗證Shepherd上的API配置符合預(yù)期后再遷移。
圖 172.3 易用性設(shè)計
Shepherd API網(wǎng)關(guān)的功能強大且復(fù)雜，易用性對業(yè)務(wù)研發(fā)人員來說至關(guān)重要。我們著重來看下自動生成DSL、API操作提效的解決方案。
2.3.1 自動生成DSL
業(yè)務(wù)研發(fā)人員在實際使用網(wǎng)關(guān)管理平臺時，我們盡量通過圖形化的頁面配置來減輕DSL的編寫負擔(dān)。但服務(wù)參數(shù)轉(zhuǎn)換的DSL配置，仍然需要業(yè)務(wù)研發(fā)人員手工編寫。一般來說，生成服務(wù)參數(shù)DSL的流程是：
引入服務(wù)的接口包依賴。
拿到服務(wù)參數(shù)類定義。
編寫Testcase生成JSON模板。
填寫參數(shù)映射規(guī)則。
最后手工錄入管理平臺，發(fā)布API。
整個過程非常繁瑣，且容易出錯。如果需要錄入的API多達幾十上百個，全部由業(yè)務(wù)研發(fā)人員手工錄入的效率是非常低下的。
解決方案
那么能不能將服務(wù)參數(shù)DSL的生成過程給自動化呢？答案是可以的，業(yè)務(wù)RD只需在網(wǎng)關(guān)錄入API文檔信息，然后錄入服務(wù)的Appkey、服務(wù)名、方法名信息，Shepherd管理端會從最新發(fā)布的服務(wù)框架控制臺獲取到服務(wù)參數(shù)的JSON Schema信息，JSON Schema定義了服務(wù)參數(shù)的類型和結(jié)構(gòu)信息，管理端可根據(jù)這些信息，自動生成服務(wù)參數(shù)的JSON Mock數(shù)據(jù)。
結(jié)合API文檔的信息，自動替換參數(shù)名相同的Value值。這套DSL自動生成方案，使用過程中對業(yè)務(wù)透明、標準化，業(yè)務(wù)方只需升級最新版本服務(wù)框架即可使用，極大提升研發(fā)效率，目前受到業(yè)務(wù)研發(fā)人員的廣泛好評。
圖 182.3.2 API操作提效
快速創(chuàng)建API
API網(wǎng)關(guān)的核心能力是建立在API配置的基礎(chǔ)上的，但提供強大功能的同時帶來了較高的復(fù)雜性，不少業(yè)務(wù)研發(fā)人員吐槽API配置太繁瑣，學(xué)習(xí)成本高。快速創(chuàng)建API的功能應(yīng)運而生，業(yè)務(wù)研發(fā)人員只需要提供少量的信息就可以創(chuàng)建API。快速創(chuàng)建API的功能當(dāng)前分為4種類型（后端RPC服務(wù)API、后端HTTP服務(wù)API、SSO CallBack API、Nest API），未來會根據(jù)業(yè)務(wù)應(yīng)用場景的不同，提供更多的快速創(chuàng)建API類型。
批量操作
業(yè)務(wù)研發(fā)人員在API網(wǎng)關(guān)上，需要管理非常多的業(yè)務(wù)分組，每個業(yè)務(wù)分組，最多可以有200個API配置，多個API可能有很多相同的配置，如組件配置，錯誤碼配置和跨域配置的。每個API對于相同的配置都要配置一遍，操作重復(fù)度很高。因此Shepherd支持批量操作多個API：勾選多個API后，通過【批量操作】功能可一次性完成多個API配置更新，降低業(yè)務(wù)重復(fù)配置的操作成本。
API導(dǎo)入導(dǎo)出
Shepherd提供在不同研發(fā)環(huán)境相互導(dǎo)入導(dǎo)出API的能力，業(yè)務(wù)研發(fā)人員在線下測試完成后，只需要使用API導(dǎo)入導(dǎo)出功能，即可將配置導(dǎo)出到線上生產(chǎn)環(huán)境，避免重復(fù)配置。
2.4 可擴展性設(shè)計
一個設(shè)計良好的基礎(chǔ)組件，除了能提供強大的基礎(chǔ)能力，還需要有良好的擴展能力。Shepherd的可擴展性主要體現(xiàn)在：支持自定義組件、服務(wù)編排的能力。
2.4.1 自定義組件
Shepherd提供了豐富的系統(tǒng)組件完成鑒權(quán)、限流、監(jiān)控能力，能夠滿足大部分的業(yè)務(wù)需求。但仍有一些特殊的業(yè)務(wù)需求，如自定義驗簽、自定義結(jié)果處理等。Shepherd通過提供加載自定義組件能力，支持業(yè)務(wù)完成一些自定義邏輯的擴展。
下圖是自定義組件實現(xiàn)的一個實例。getName中填寫自定義組件申請時的名稱，invoke方法中實現(xiàn)自定義組件的業(yè)務(wù)邏輯，如繼續(xù)執(zhí)行、進行頁面跳轉(zhuǎn)、直接返回結(jié)果、拋出異常等。
圖 19目前Shepherd通過自定義組件已經(jīng)成功支持了美團優(yōu)選、外賣、餐飲、打車等重要業(yè)務(wù)，接入的自定義組件數(shù)量有200多個。
2.4.2 服務(wù)編排
一般情況下，網(wǎng)關(guān)上配置的一個API對應(yīng)后端一個RPC或者HTTP服務(wù)。如果調(diào)用端有聚合和編排后端服務(wù)的需求，那么有多少后端服務(wù)，就必須發(fā)起多少次HTTP的請求調(diào)用。由此就會帶來一些問題，調(diào)用端的HTTP請求次數(shù)過多，效率低，在調(diào)用端聚合服務(wù)的邏輯過重。
服務(wù)編排的需求應(yīng)運而生，服務(wù)編排是對既有服務(wù)進行編排調(diào)用，同時對獲取的數(shù)據(jù)進行處理。主要應(yīng)用在數(shù)據(jù)聚合場景：一次HTTP請求返回的數(shù)據(jù)需要調(diào)用多個或多次服務(wù)（RPC或HTTP）才能獲取到完整的結(jié)果。
經(jīng)過前期調(diào)研，公司已經(jīng)有一套成熟的服務(wù)編排框架，由客服團隊開發(fā)的海盜組件（參見《海盜中間件：美團服務(wù)體驗平臺對接業(yè)務(wù)數(shù)據(jù)的最佳實踐》一文）也是美團公司內(nèi)部的公共服務(wù)。
因此我們與海盜團隊合作，設(shè)計了Shepherd的服務(wù)編排支持方案。海盜通過獨立部署的方式提供服務(wù)編排能力，Shepherd與海盜之間通過RPC進行調(diào)用。這樣可以解耦Shepherd與海盜，避免因服務(wù)編排能力影響集群上的其他服務(wù)，同時多一次RPC調(diào)用并不會有明顯耗時增加。使用上對業(yè)務(wù)研發(fā)人員也是透明的，非常方便，業(yè)務(wù)研發(fā)人員在管理端配置好服務(wù)編排的API，通過配置中心同時下發(fā)到Shepherd服務(wù)端和海盜服務(wù)上，即可開始使用服務(wù)編排能力。整體的交互架構(gòu)圖如下：
圖 20三、未來規(guī)劃
目前接入Shepherd API網(wǎng)關(guān)的API數(shù)量超過18000多個，線上運行的集群數(shù)量90多個，日均總調(diào)用次數(shù)在百億以上。隨著Shepherd API網(wǎng)關(guān)業(yè)務(wù)規(guī)模的不斷增長，對我們的可用性、易用性、可擴展性必將提出更高的要求。未來一年，Shepherd的規(guī)劃重點包括有云原生架構(gòu)演進、靜態(tài)網(wǎng)站托管、組件市場等。
3.1 云原生架構(gòu)演進
Shepherd API網(wǎng)關(guān)的云原生架構(gòu)演進有三個目標：簡化接入網(wǎng)關(guān)步驟，提升業(yè)務(wù)研發(fā)人員的研發(fā)效率；減小服務(wù)端War包大小，提升安全性和穩(wěn)定性；接入Serverless彈性，降低成本，提高資源利用率。
為了實現(xiàn)這個三個目標，我們計劃整體遷移網(wǎng)關(guān)服務(wù)到公司的Serverless服務(wù)Nest（參見《美團Serverless平臺Nest的探索與實踐》一文）上，同時通過抽取Shepherd核心功能到SDK的方式集成到業(yè)務(wù)的網(wǎng)關(guān)集群，業(yè)務(wù)研發(fā)人員可以只選擇自己需要使用的自定義組件，從而大幅減小服務(wù)端的War包大小。
圖 213.2 靜態(tài)網(wǎng)站托管
依托Shepherd API網(wǎng)關(guān)實現(xiàn)靜態(tài)網(wǎng)站托管的目標是：建設(shè)通用的靜態(tài)網(wǎng)站托管解決方案，為開發(fā)者提供便捷、穩(wěn)定、高擴展性的靜態(tài)網(wǎng)站托管服務(wù)。
靜態(tài)網(wǎng)站托管解決方案能為業(yè)務(wù)研發(fā)人員提供的主要功能包括：托管靜態(tài)網(wǎng)站資源，包括存儲及訪問；管理應(yīng)用生命周期，包括自定義域配置以及身份驗證和授權(quán)；CI/CD集成等。
圖 223.3 組件市場
Shepherd API網(wǎng)關(guān)組件市場的目標是：合作共贏，形成開發(fā)生態(tài)，業(yè)務(wù)研發(fā)人員可將開發(fā)的自定義組件提供給其他有需要的業(yè)務(wù)研發(fā)團隊使用。
我們希望讓業(yè)務(wù)研發(fā)人員參與到自定義組件的開發(fā)，完善使用文檔后設(shè)置為公共組件，開放給所有使用Shepherd的業(yè)務(wù)研發(fā)人員使用，避免重復(fù)造輪子。
作者簡介
充澤、志洋、李敏等，均來自美團基礎(chǔ)技術(shù)部-基礎(chǔ)架構(gòu)團隊。
---
前端?|??算法?|?后端?|?數(shù)據(jù)
安全?|?Android?|?iOS??|?運維?|?測試
----------? END? ----------
彭榮新：喜馬拉雅自研網(wǎng)關(guān)架構(gòu)演進過程
如何憑本事搞砸公司的重大項目？
系統(tǒng)“爛”怎么辦？請看資深專家拆分改造實踐
Google和Facebook為什么不用Docker？
追根溯源 - 數(shù)據(jù)中臺概念的起源
重構(gòu) - 美股行情系統(tǒng)APP推送改造
總結(jié)
以上是生活随笔為你收集整理的美团技术：百亿规模API网关服务Shepherd的设计与实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Anchor free Detector
- 下一篇： StatisticalOutlierRe