溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“API資源隔離系統的設計和實現”，在日常操作中，相信很多人在API資源隔離系統的設計和實現問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”API資源隔離系統的設計和實現”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
大交通業務需要對接機票、火車票、租車、接送機等業務的外部供應鏈，供應商的數據接口大部分通過 HTTP、HTTPS 等協議進行通信。
為了保證開發進度并支持集成測試時進行多場景支持，我們往往需要對供應商接口進行 MOCK。之前我們在開發環境和測試環境對外部接口的調用沒有統一管控，無法實現調用開關，也無法對調用量進行統計和限制。
為了解決這些問題，我們設計了接入 API 資源隔離系統 JARVIS（Join Api Resource Virtual Isolation System），希望它可以像鋼鐵俠中的 Jarvis 一樣幫我們解決資源的管控問題。
圖形化操作，提供管理后臺，對開發和測試同學的交互要友好。
對業務無侵入，無需修改業務系統代碼，保證測試的代碼和發布的是一致的。
業務關聯，這個系統是為業務服務的，需要提供必要的業務關聯性。
支持豐富的匹配規則，可以用于絕大部分使用場景。
所配即所得，管理規則可以即時生效。
請求響應可追溯，提供詳細的日志記錄和查詢功能。
供應商資源管控系統位于內部接入網關和外部供應商接口之間，在開發和測試環境對外部供應商資源提供了全局的代理，在系統中的位置如下：
資源管控系統系統分兩大部分：
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 類型則先調用供應商的真實接口再將獲取到的內容返回給調用方。對接口當日的調用次數進行顯示，如果超過閾值則會觸發報警并進行服務熔斷。
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 進行存儲。
目前已經在開發和測試環境代理了全部的供應商接口:
1. 國內開放平臺開發支持
近期我們在國內機票開放平臺，前期由我方提供標準接，口由供應商接口并沒有完全實現，我們根據文檔生成了全部的 Mock 數據并針對每個接口的各種場景定制了 Mock 規則，保障了項目的開發進度并且實現了多場景的覆蓋。
2. 暑期壓力測試支持
近期進行了暑運壓力測試，測試時通過 Mock 功能隔離了對外部供應商的訪問，并通過設置響應延遲時間模擬了供應商接口不同狀況下的響應時間。
后續主要計劃在以下方向進行改進和優化：
供應商接口管理，實現接口 Schema 的定義與管理，并實現對請求參數和響應內容校驗。
增加模版化響應，減少人工配置，提高使用效率。
完善統計系統，實現資源使用情況的可視化。
易用性優化，收集大家在使用過程中遇到的問題進行持續改進，做到可用、易用、好用。
目前國際機票、國內機票、接送機等業務全部接入了 JARVIS 系統，也經歷了幾個大項目開發和測試過程的檢驗，在性能和可用性方面也做了多次優化，目前還存在很大的改進空間，我們也會持續進行完善。
到此，關于“API資源隔離系統的設計和實現”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
