如何設計實現一個輕量的開放API網關

本篇文章給大家分享的是有關如何設計實現一個輕量的開放API網關，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

前言

隨著業務的發展, 所對接的第三方越來越多, 各個業務系統面臨著同樣一個問題: 如何讓第三方安全快速接入. 此時有一個集驗簽、鑒權、限流、降級等功能于一身的API網關服務變得尤為重要.

接下來將分享如何設計實現一個輕量級的API開放網關, 包括接口設計、數據庫設計、簽名驗簽方案、鑒權等. 本文側重于總體設計, 具體實現細節將陸續在后續的文章中分享.

API網關簡介

API網關在微服務中尤為重要, 其抽象了鑒權、限流、降級等各個業務系統通用的功能. 作為眾多內部業務系統外的一層屏障.

基本需求

1. 簽名及驗簽

2. 鑒權

3. 路由

4. 權限及資源管理

總體設計

驗簽、鑒權等功能以職責鏈的方式進行處理, 網關根據配置進行路由并附加參數用以配合業務系統進行處理(如數據過濾等). 簡要請求處理流程如下:

接口設計

網關最基本的功能是轉發請求, 常見的方式是根據配置中的路由規則將請求轉發給內部服務, 如:

將/order/*的請求轉發給內部的訂單系統、/user/*的請求轉發給內部的用戶系統, 這種做法常用于對整個業務系統負責的基礎網關.

而本文所設計的是服務于第三方的開放API網關, 并未使用上述做法, 而是將請求的資源作為參數放到請求體中, 其原因如下:

1. 開放API服務于第三方, 屏蔽內部路徑, 有利于提供命名統一且規范的接口.

2. 請求接口的映射由網關的路由表維護, 內部接口升級甚至切換到新服務對外接口不變.

3. 能夠更細粒度地針對接口進行權限控制、限流、統計等.

地址

開放API網關對外提供唯一入口, 具體請求的資源作為參數傳入.

公共參數

為了簡化簽名和驗簽的操作, 同時也提高靈活度, 唯一入口的約定了固定的公共參數和返回值, 如下:

公共請求參數

• app_id: 應用ID, 應用ID是授權的主體, 是調用方的身份標識

• method: 請求方法, 與內部URL對應, 由網關的路由表維護.

• timestamp和nonce用來防重放攻擊.

• biz_content: 業務參數, 這個參數將轉發給內部業務系統.

公共返回參數

• biz_content: 返回業務參數, 網關轉發業務系統的返回值.

[版權聲明]

本文發布于樸瑞卿的博客, 允許非商業用途轉載, 但轉載必須保留原作者樸瑞卿 及鏈接:http://blog.piaoruiqing.com. 如有授權方面的協商或合作, 請聯系郵箱: piaoruiqing@gmail.com.

簽名方案

調用方和服務方均生成2048位RSA秘鑰, 交換公鑰. 私鑰用于簽名, 公鑰用于驗簽, 開放API網關對外接口使用https, 故暫不需額外做加密處理.

簽名算法

簽名規則

簽名參數內容

剔除sign之后的全部參數.

簽名參數排序

按照參數名的ASCII碼遞增排序(字母升序排序).

簽名生成方式

排序后的參數列表組合成參數名a=參數值a&參數名b=參數值b&...&參數名z=參數值z的字符串, 并使用私鑰生成sign.

數據庫設計

數據庫用于存儲秘鑰權限等配置, 程序和數據庫之間有多級緩存用以提高訪問速度. 簡要ER圖如下:

• app: 調用方主體, 用于標識請求方身份.

• group: 組, app分組, 可通過group統一進行授權.

• subject: 主體(app/group).

• resource: 資源, 維護請求資源與內部接口的映射關系, url+http_method 對應唯一的resource_id.

技術選型

網關除了滿足功能上的需求外, 性能上的需求也需要著重考慮, 畢竟作為各個業務系統對外的唯一入口, 網關的性能可能會成為整個業務系統的瓶頸. 業務并不復雜, 性能要求高, 響應式編程正是一個不錯的選擇.

• Spring WebFlux + netty: 響應式Web框架.

• Spring Data Reactive Redis + Lettuce: 響應式redis客戶端.

• Guava: Google工具包, 使用LoadingCache作為進程內緩存.

以上就是如何設計實現一個輕量的開放API網關，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。