久久狠狠色狠狠色综合,国产在线观看免费视频软件,国产在线91精品入口首页

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

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

提升研發效率
- 業務研發人員只需要通過配置的方式即可快速開放服務接口。
- Shepherd統一提供鑒權、限流、熔斷等非業務基礎能力。
- Shepherd支持業務研發人員通過開發自定義組件的方式擴展API網關能力。
降低溝通成本
- 業務研發人員配置好API，可以自動生成API的前后端交互文檔和客戶端SDK，方便前后端開發人員進行交互、聯調。
提升資源利用率
- 基于Serverless的架構思想，實現API全托管，業務研發人員無需關心機器資源問題。

二、技術設計與實現

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指標提供7×24小時的專業守護，如下表：

多維度告警

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

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的流程是：

引入服務的接口包依賴。
拿到服務參數類定義。
編寫Testcase生成JSON模板。
填寫參數映射規則。
最后手工錄入管理平臺，發布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?？焖賱摻ˋPI的功能當前分為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服務端和海盜服務上，即可開始使用服務編排能力。整體的交互架構圖如下：

三、未來規劃

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

3.1 云原生架構演進

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

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