(馬蜂窩技術原創內容，公眾號 ID：mfwtech)

Part 1 背景

大交通業務需要對接機票、火車票、租車、接送機等業務的外部供應鏈，供應商的資料介面大部分通過 HTTP、HTTPS 等協議進行通訊。

為了保證開發進度並支援整合測試時進行多場景支援，我們往往需要對供應商介面進行 MOCK。之前我們在開發環境和測試環境對外部介面的呼叫沒有統一管控，無法實現呼叫開關，也無法對呼叫量進行統計和限制。

為了解決這些問題，我們設計了接入 API 資源隔離系統 JARVIS（Join Api Resource Virtual Isolation System），希望它可以像鋼鐵俠中的 Jarvis 一樣幫我們解決資源的管控問題。

 

Part 2 設計原則

1. 圖形化操作，提供管理後臺，對開發和測試同學的互動要友好。

2. 對業務無侵入，無需修改業務系統程式碼，保證測試的程式碼和釋出的是一致的。

3. 業務關聯，這個系統是為業務服務的，需要提供必要的業務關聯性。

4. 支援豐富的匹配規則，可以用於絕大部分使用場景。

5. 所配即所得，管理規則可以即時生效。

6. 請求響應可追溯，提供詳細的日誌記錄和查詢功能。

 

Part 3 設計與實現

整體思路

供應商資源管控系統位於內部接入閘道器和外部供應商介面之間，在開發和測試環境對外部供應商資源提供了全域性的代理，在系統中的位置如下：

 

資源管控系統系統分兩大部分：

1. Config Center：主要實現業務線、環境、供應商、供應商 API 和 API 對應的 MOCK 規則的配置管理。

2. API Server：主要負責請求的接受、MOCK 規則匹配、MOCK 規則的響應和日誌記錄。

關鍵功能

• 採用配置中心和 API 伺服器分離的結構，支援叢集部署

• 同時支援模擬響應和代理訪問兩種響應方式

• 支援 Mock 規則修改後即時生效

• 自動適應上游服務的環境隔離

• 同一 API 在同一環境下支援多種場景，並且有優先順序區分

• Mock 規則會關聯業務系統，如業務線、環境、供應商、供應商的 API 等

• 會進行 Mock 請求呼叫次數的計數，並且支援超量熔斷和超量報警

• 支援 Mock 呼叫的日誌記錄和視覺化查詢。

規則配置與管理

主要包含業務線資訊配置、環境配置、供應商配置、供應商所屬 API 配置、Mock 規則配置。業務資訊之間的關係如下 ：

1. 「業務線」指的是如國內機票、國際機票、火車票、租車、接送機等業務型別

2. 「環境」包含兩層含義：

• 一為部署環境，分為 dev 開發環境、qa 測試環境、sim 預發環境、prod 生產環境四種，可以理解為以下四個互相隔離的叢集。

• 二為在 qa 環境下為了區分多個專案進行了環境隔離，如開放平臺代號為 kfpt，乘機人代號為 cjr。

3. 「供應商」是指業務接入的各種商家，商家可以歸屬到某條業務線

4. 「供應商」 API 是指供應商提供的一系列基於 HTTP 或 HTTPS 的介面

5.「 MOCK 規則」是指為了對供應商介面進行模擬或代理而配置的規則，用於後續的規則匹配和返回響應資訊。MOCK 規則會歸屬某個供應商 API，同時歸屬於某個環境。

6.「 場景」是用來區分同一供應商 API 且在同一環境下面不同場景的區分，分為通用場景和具象場景兩大類，在規則匹配時優先匹配具象場景，如果具象場景未匹配成功則進行通用場景匹配。

響應規則的匹配和響應過程

規則匹配和內容響應的流程如下：

1. 規則載入和重新整理，接收到內部系統的呼叫後，會判斷當前的規則快取是否為空，如果為空則會載入全部可用的 MOCK 規則載入到快取中。

2. 環境隔離標識自適應， 內部的服務通常是採用環境隔離方式部署，環境隔離標識（envTag）會影響到規則的匹配。

3. 規則匹配 ，根據請求的 URL 對規則進行匹配，最終可能匹配多條規則。將匹配到的規則分為具象場景規則和通用場景規則兩組。對具象場景的 MOCK 規則根據請求引數進行匹配，如果命中則返回。對通用場景的 MOCK 規則根據請求引數進行匹配，如果命中則返回。

4. 結果響應，如果沒有匹配到 Mock 規則，直接返回預設的錯誤資訊。如果匹配到 Mock 規則，先判斷是 Mock 型別還是 Proxy 型別，對於 Mock 型別會按照規則的配置返回狀態碼和響應內容，如果是 Proxy 型別則先呼叫供應商的真實介面再將獲取到的內容返回給呼叫方。對介面當日的呼叫次數進行顯示，如果超過閾值則會觸發報警並進行服務熔斷。

主要 Feature

1. 多種匹配條件

支援根據 header、param、JsonPath、body 等多種方式進行引數提取和匹配。

2. Mock 規則熱生效

Mock 規則新增或修改後會熱生效，實現所配即所得。在訊息新增和修改後會觸發規則變更的切面，進而通過 RocketMQ 傳送規則變更訊息，訊息以廣播的形式進行傳送，API Server 會監聽該訊息，收到後會觸發規則的重新整理。

3. 環境隔離支援

內部的閘道器服務通常是採用環境隔離方式部署，我們採用在 HttpHeader 中增加 envTag 屬性來傳遞環境標識。會判斷 envTag 是否為空，如果為空則不進行 URL 的重新組裝，如果為空則會將上述 URL 中的 {env} 部分替換為實際對應的 envTag。

環境隔離主要是分為兩步來實現：

• 在我們接入閘道器層面，通過 join-common 自動提取並傳遞來自上游的環境隔離標識 envTag，並將其寫入到 HTTP Header 中。

• 在 API Server 我們接收到請求後會判斷請求是否攜帶 envTag 標識，如果攜帶會將 URL 中的 {env} 部分替換為實際對應的 envTag，最終匹配到環境對應的規則上面。如果沒有攜帶 envTag 則會去匹配預設的環境規則。

4. 多場景支援

• 每個規則對應一個環境和一個供應商介面，但是會分為請求成功、請求失敗等場景

• 多個人在同一個專案中進行開發和測試的時候會產生衝突

為應對這種問題，我們提出了「場景」的概念，分為通用場景和具象場景：

• 通用場景故名思義就是用來應對正常的請求，一般會放開 Proxy 開關，直接請求到供應商的介面

• 具象場景用於對應某個具體的 Case，比如北京飛上海 1 成人 1 兒童的查詢，我們通過更加詳細的引數進行匹配

在匹配層級上面優先匹配具象場景的規則，如果匹配失敗才會繼續匹配通用場景的規則。

5.  超限熔斷與報警

根據在供應商 API 層面設定的請求上限進行校驗，如果當日的請求超限，會進行規則的降級，並通過企業微信傳送報警資訊。

6. 報文自動加密與解密

有些供應商的報文傳輸是密文的形式，我們在 JARVIS 系統中根據對應的供應商在編輯時是明文，在儲存的時候會根據協議加密為密文。

7.  請求日誌記錄與查詢

對所有的請求都會記錄請求報文、響應報文、命中規則等資訊，由於報文體積較大且呼叫量較大，我們使用 ElasticSearch 進行儲存。

 

Part 4 專案實戰

目前已經在開發和測試環境代理了全部的供應商介面:

1. 國內開放平臺開發支援

近期我們在國內機票開放平臺，前期由我方提供標準接，口由供應商介面並沒有完全實現，我們根據文件生成了全部的 Mock 資料並針對每個介面的各種場景定製了 Mock 規則，保障了專案的開發進度並且實現了多場景的覆蓋。

2. 暑期壓力測試支援

近期進行了暑運壓力測試，測試時通過 Mock 功能隔離了對外部供應商的訪問，並通過設定響應延遲時間模擬了供應商介面不同狀況下的響應時間。

 

Part 5 後續路線圖

後續主要計劃在以下方向進行改進和優化：

1. 供應商介面管理，實現介面 Schema 的定義與管理，並實現對請求引數和響應內容校驗。

2. 增加模版化響應，減少人工配置，提高使用效率。

3. 完善統計系統，實現資源使用情況的視覺化。

4. 易用性優化，收集大家在使用過程中遇到的問題進行持續改進，做到可用、易用、好用。

 

Part 6 結語

目前國際機票、國內機票、接送機等業務全部接入了 JARVIS 系統，也經歷了幾個大專案開發和測試過程的檢驗，在效能和可用性方面也做了多次優化，目前還存在很大的改進空間，我們也會持續進行完善。

最後，大交通團隊正在招聘 Java 架構師，有興趣的同學歡迎傳送簡歷至：[email protected]

本文作者：安自東，馬蜂窩大交通團隊研發技術專家。

相關推薦