希望它可以像鋼鐵俠中的 Jarvis 一樣幫我們解決資源的管控問題。 ...
(馬蜂窩技術原創內容,公眾號 ID:mfwtech)
Part 1 背景
大交通業務需要對接機票、火車票、租車、接送機等業務的外部供應鏈,供應商的數據介面大部分通過 HTTP、HTTPS 等協議進行通信。
為了保證開發進度並支持集成測試時進行多場景支持,我們往往需要對供應商介面進行 MOCK。之前我們在開發環境和測試環境對外部介面的調用沒有統一管控,無法實現調用開關,也無法對調用量進行統計和限制。
為瞭解決這些問題,我們設計了接入 API 資源隔離系統 JARVIS(Join Api Resource Virtual Isolation System),希望它可以像鋼鐵俠中的 Jarvis 一樣幫我們解決資源的管控問題。
Part 2 設計原則
-
圖形化操作,提供管理後臺,對開發和測試同學的交互要友好。
-
對業務無侵入,無需修改業務系統代碼,保證測試的代碼和發佈的是一致的。
-
業務關聯,這個系統是為業務服務的,需要提供必要的業務關聯性。
-
支持豐富的匹配規則,可以用於絕大部分使用場景。
-
所配即所得,管理規則可以即時生效。
-
請求響應可追溯,提供詳細的日誌記錄和查詢功能。
Part 3 設計與實現
整體思路
供應商資源管控系統位於內部接入網關和外部供應商介面之間,在開發和測試環境對外部供應商資源提供了全局的代理,在系統中的位置如下:
資源管控系統系統分兩大部分:
-
Config Center:主要實現業務線、環境、供應商、供應商 API 和 API 對應的 MOCK 規則的配置管理。
-
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 後續路線圖
後續主要計劃在以下方向進行改進和優化:
-
供應商介面管理,實現介面 Schema 的定義與管理,並實現對請求參數和響應內容校驗。
-
增加模版化響應,減少人工配置,提高使用效率。
-
完善統計系統,實現資源使用情況的可視化。
-
易用性優化,收集大家在使用過程中遇到的問題進行持續改進,做到可用、易用、好用。
Part 6 結語
目前國際機票、國內機票、接送機等業務全部接入了 JARVIS 系統,也經歷了幾個大項目開發和測試過程的檢驗,在性能和可用性方面也做了多次優化,目前還存在很大的改進空間,我們也會持續進行完善。
最後,大交通團隊正在招聘 Java 架構師,有興趣的同學歡迎發送簡歷至:[email protected]
本文作者:安自東,馬蜂窩大交通團隊研發技術專家。