開放API網關實踐(一) ——設計一個API網關

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

文章地址: blog.piaoruiqing.com/blog/2019/0…

前言

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

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

API網關簡介

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

基本需求

1. 簽名及驗籤
2. 鑑權
3. 路由
4. 權限及資源管理

整體設計

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

接口設計

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

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

而本文所設計的是服務於第三方的開放API網關, 並未使用上述作法, 而是將請求的資源做爲參數放到請求體中, 其緣由以下:

1. 開放API服務於第三方, 屏蔽內部路徑, 有利於提供命名統一且規範的接口.
2. 請求接口的映射由網關的路由表維護, 內部接口升級甚至切換到新服務對外接口不變.
3. 可以更細粒度地針對接口進行權限控制、限流、統計等.

地址

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

公共參數

爲了簡化簽名和驗籤的操做, 同時也提升靈活度, 惟一入口的約定了固定的公共參數和返回值, 以下:

公共請求參數

參數名稱	是否必須	類型	示例	備註
app_id	是	string		應用ID
method	是	string	aaa.bbb.ccc	請求方法
charset	是	string	UTF-8	編碼
format	是	string	JSON	業務參數格式
sign_type	是	string	RSA2	簽名類型
sign	是	string		簽名
timestamp	是	number	1564929661796	時間戳, 單位: 毫秒
nonce	是	string	63DCB93D270E44D49499F9E5D55705FE	隨機字串(建議使用UUID)
version	是	string	1.0	接口版本
biz_content	是	string	{"start_time":"1564929661796", ...}	請求業務參數

• app_id: 應用ID, 應用ID是受權的主體, 是調用方的身份標識
• method: 請求方法, 與內部URL對應, 由網關的路由表維護.
• timestamp和nonce用來防重放攻擊.
• biz_content: 業務參數, 這個參數將轉發給內部業務系統.

公共返回參數

參數名稱	是否必須	類型	示例	備註
code	是	number	0	錯誤碼
message	否	string		錯誤信息
charset	是	string	UTF-8	編碼
format	是	string	JSON	返回參數格式
sign_type	是	string	RSA2	簽名類型
sign	是	string		簽名
timestamp	是	number		時間戳, 單位: 毫秒
biz_content	是	string	{"id":"1564929661796", ...}	返回業務參數

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

[版權聲明]
本文發佈於 樸瑞卿的博客, 容許非商業用途轉載, 但轉載必須保留原做者 樸瑞卿 及連接: blog.piaoruiqing.com. 若有受權方面的協商或合做, 請聯繫郵箱: piaoruiqing@gmail.com.

簽名方案

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

簽名算法

簽名算法名稱	標準簽名算法名稱	備註
RSA2	SHA256WithRSA	強制要求 RSA 密鑰的長度至少爲 2048

簽名規則

簽名參數內容

剔除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網關實踐(一) ——設計一個API網關
• 開放API網關實踐(二) —— 重放攻擊及防護
• 開放API網關實踐(三) —— 限流

歡迎關注公衆號:

[版權聲明]
本文發佈於 樸瑞卿的博客, 容許非商業用途轉載, 但轉載必須保留原做者 樸瑞卿 及連接: blog.piaoruiqing.com. 若有受權方面的協商或合做, 請聯繫郵箱: piaoruiqing@gmail.com.