API資源隔離系統(tǒng)的設計和實現(xiàn)

這篇文章主要介紹“API資源隔離系統(tǒng)的設計和實現(xiàn)”，在日常操作中，相信很多人在API資源隔離系統(tǒng)的設計和實現(xiàn)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”API資源隔離系統(tǒng)的設計和實現(xiàn)”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Part 1 背景

大交通業(yè)務需要對接機票、火車票、租車、接送機等業(yè)務的外部供應鏈，供應商的數(shù)據(jù)接口大部分通過 HTTP、HTTPS 等協(xié)議進行通信。

為了保證開發(fā)進度并支持集成測試時進行多場景支持，我們往往需要對供應商接口進行 MOCK。之前我們在開發(fā)環(huán)境和測試環(huán)境對外部接口的調(diào)用沒有統(tǒng)一管控，無法實現(xiàn)調(diào)用開關，也無法對調(diào)用量進行統(tǒng)計和限制。

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

Part 2 設計原則

1. 圖形化操作，提供管理后臺，對開發(fā)和測試同學的交互要友好。

2. 對業(yè)務無侵入，無需修改業(yè)務系統(tǒng)代碼，保證測試的代碼和發(fā)布的是一致的。

3. 業(yè)務關聯(lián)，這個系統(tǒng)是為業(yè)務服務的，需要提供必要的業(yè)務關聯(lián)性。

4. 支持豐富的匹配規(guī)則，可以用于絕大部分使用場景。

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

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

Part 3 設計與實現(xiàn)

整體思路

供應商資源管控系統(tǒng)位于內(nèi)部接入網(wǎng)關和外部供應商接口之間，在開發(fā)和測試環(huán)境對外部供應商資源提供了全局的代理，在系統(tǒng)中的位置如下：

資源管控系統(tǒng)系統(tǒng)分兩大部分：

1. Config Center：主要實現(xiàn)業(yè)務線、環(huán)境、供應商、供應商 API 和 API 對應的 MOCK 規(guī)則的配置管理。

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

關鍵功能

• 采用配置中心和 API 服務器分離的結構，支持集群部署

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

• 支持 Mock 規(guī)則修改后即時生效

• 自動適應上游服務的環(huán)境隔離

• 同一 API 在同一環(huán)境下支持多種場景，并且有優(yōu)先級區(qū)分

• Mock 規(guī)則會關聯(lián)業(yè)務系統(tǒng)，如業(yè)務線、環(huán)境、供應商、供應商的 API 等

• 會進行 Mock 請求調(diào)用次數(shù)的計數(shù)，并且支持超量熔斷和超量報警

• 支持 Mock 調(diào)用的日志記錄和可視化查詢。

規(guī)則配置與管理

主要包含業(yè)務線信息配置、環(huán)境配置、供應商配置、供應商所屬 API 配置、Mock 規(guī)則配置。業(yè)務信息之間的關系如下 ：

1. 「業(yè)務線」指的是如國內(nèi)機票、國際機票、火車票、租車、接送機等業(yè)務類型

2. 「環(huán)境」包含兩層含義：

• 一為部署環(huán)境，分為 dev 開發(fā)環(huán)境、qa 測試環(huán)境、sim 預發(fā)環(huán)境、prod 生產(chǎn)環(huán)境四種，可以理解為以下四個互相隔離的集群。

• 二為在 qa 環(huán)境下為了區(qū)分多個項目進行了環(huán)境隔離，如開放平臺代號為 kfpt，乘機人代號為 cjr。

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

4. 「供應商」 API 是指供應商提供的一系列基于 HTTP 或 HTTPS 的接口

5.「 MOCK 規(guī)則」是指為了對供應商接口進行仿真或代理而配置的規(guī)則，用于后續(xù)的規(guī)則匹配和返回響應信息。MOCK 規(guī)則會歸屬某個供應商 API，同時歸屬于某個環(huán)境。

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

響應規(guī)則的匹配和響應過程

規(guī)則匹配和內(nèi)容響應的流程如下：

1. 規(guī)則加載和刷新，接收到內(nèi)部系統(tǒng)的調(diào)用后，會判斷當前的規(guī)則緩存是否為空，如果為空則會加載全部可用的 MOCK 規(guī)則加載到緩存中。

2. 環(huán)境隔離標識自適應， 內(nèi)部的服務通常是采用環(huán)境隔離方式部署，環(huán)境隔離標識（envTag）會影響到規(guī)則的匹配。

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

4. 結果響應，如果沒有匹配到 Mock 規(guī)則，直接返回默認的錯誤信息。如果匹配到 Mock 規(guī)則，先判斷是 Mock 類型還是 Proxy 類型，對于 Mock 類型會按照規(guī)則的配置返回狀態(tài)碼和響應內(nèi)容，如果是 Proxy 類型則先調(diào)用供應商的真實接口再將獲取到的內(nèi)容返回給調(diào)用方。對接口當日的調(diào)用次數(shù)進行顯示，如果超過閾值則會觸發(fā)報警并進行服務熔斷。

主要 Feature

1. 多種匹配條件

支持根據(jù) header、param、JsonPath、body 等多種方式進行參數(shù)提取和匹配。

2. Mock 規(guī)則熱生效

Mock 規(guī)則新增或修改后會熱生效，實現(xiàn)所配即所得。在消息新增和修改后會觸發(fā)規(guī)則變更的切面，進而通過 RocketMQ 發(fā)送規(guī)則變更消息，消息以廣播的形式進行發(fā)送，API Server 會監(jiān)聽該消息，收到后會觸發(fā)規(guī)則的刷新。

3. 環(huán)境隔離支持

內(nèi)部的網(wǎng)關服務通常是采用環(huán)境隔離方式部署，我們采用在 HttpHeader 中增加 envTag 屬性來傳遞環(huán)境標識。會判斷 envTag 是否為空，如果為空則不進行 URL 的重新組裝，如果為空則會將上述 URL 中的 {env} 部分替換為實際對應的 envTag。

環(huán)境隔離主要是分為兩步來實現(xiàn)：

• 在我們接入網(wǎng)關層面，通過 join-common 自動提取并傳遞來自上游的環(huán)境隔離標識 envTag，并將其寫入到 HTTP Header 中。

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

4. 多場景支持

• 每個規(guī)則對應一個環(huán)境和一個供應商接口，但是會分為請求成功、請求失敗等場景

• 多個人在同一個項目中進行開發(fā)和測試的時候會產(chǎn)生沖突

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

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

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

在匹配層級上面優(yōu)先匹配具象場景的規(guī)則，如果匹配失敗才會繼續(xù)匹配通用場景的規(guī)則。

5.  超限熔斷與報警

根據(jù)在供應商 API 層面設置的請求上限進行校驗，如果當日的請求超限，會進行規(guī)則的降級，并通過企業(yè)微信發(fā)送報警信息。

6. 報文自動加密與解密

有些供應商的報文傳輸是密文的形式，我們在 JARVIS 系統(tǒng)中根據(jù)對應的供應商在編輯時是明文，在保存的時候會根據(jù)協(xié)議加密為密文。

7.  請求日志記錄與查詢

對所有的請求都會記錄請求報文、響應報文、命中規(guī)則等信息，由于報文體積較大且調(diào)用量較大，我們使用 ElasticSearch 進行存儲。

Part 4 項目實戰(zhàn)

目前已經(jīng)在開發(fā)和測試環(huán)境代理了全部的供應商接口:

1. 國內(nèi)開放平臺開發(fā)支持

近期我們在國內(nèi)機票開放平臺，前期由我方提供標準接，口由供應商接口并沒有完全實現(xiàn)，我們根據(jù)文檔生成了全部的 Mock 數(shù)據(jù)并針對每個接口的各種場景定制了 Mock 規(guī)則，保障了項目的開發(fā)進度并且實現(xiàn)了多場景的覆蓋。

2. 暑期壓力測試支持

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

Part 5 后續(xù)路線圖

后續(xù)主要計劃在以下方向進行改進和優(yōu)化：

1. 供應商接口管理，實現(xiàn)接口 Schema 的定義與管理，并實現(xiàn)對請求參數(shù)和響應內(nèi)容校驗。

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

3. 完善統(tǒng)計系統(tǒng)，實現(xiàn)資源使用情況的可視化。

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

Part 6 結語

目前國際機票、國內(nèi)機票、接送機等業(yè)務全部接入了 JARVIS 系統(tǒng)，也經(jīng)歷了幾個大項目開發(fā)和測試過程的檢驗，在性能和可用性方面也做了多次優(yōu)化，目前還存在很大的改進空間，我們也會持續(xù)進行完善。

到此，關于“API資源隔離系統(tǒng)的設計和實現(xiàn)”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>