在網上發現了一個牛X的思路，在作restful的時候，若是業務改變，須要每次都修改controller，後來方便了，直接透傳的方式，其實也比較麻煩，每次都要寫controller。需求變了接口也發生了改變，長期這樣的結果，就是維護成本愈來愈高，直接service 經過spring 讓他變成controller不就少寫不少代碼了。源碼：https://github.com/limingios/netFuture/tree/master/api網關/idig8-api-gatewayjava
背景
移動互聯時代，都在追尋一個萬能的解，其實這個解可能不存在。其實後端開發的挑戰愈來愈多。裏面不少個controller，若是系統愈來愈龐大，致使的結果維護困難。ios
什麼是API網關
API網關是一個輕量的java http 接口組件，可無縫將普通的 Serive 方法轉換成 http 接口。並從已下幾點來達到提升開發效率與接口質量的目的。git
- 去掉mvc控制器，將http請求直接無縫接入JAVA服務接口
- 統一出入參格式
- 統一異常規範
- 自動檢測服務接口規
- 負責路由協議的轉換
- 普通的http接口
- API網關接口的實現
當初一個接口開發一個控制器，1000個接口開發1000個控制器。一個一個封裝參數，質量也提升了統一規範，出問題統一的方式回饋。不規範的代碼也會被api網關攔截掉。github
代碼講解
就5個類，不到500行代碼。開發的人最喜歡又小又精湛的代碼，不容易軟。方便理解，方便使用，又粗又大的代碼，很不方便遷移，很差控制容易軟。redis
- ApiGatewayHandler.java
轉換器和調用加載器- ApiGatewayServlet.java
相似springboot的一個入口類- APIMapping.java
註解暴露類- ApiRequest.java
請求封裝類
5.ApiStore.java
API IOC 大倉庫
代碼的方式流程圖spring
- 請求參數說明：
| 名稱 | 類型 | 描述 |
|---|---|---|
| method | string | 方法名稱 |
| paramter | json | 業務參數 |
| timestamp | long | 請求時間戳 |
- 實現技術：
- java servlet
- spring Ioc
- Json 轉換工具的使用
接口安全的業務需求
-
接口安全級別分組json
- 黑名單組
個人，帳戶信息後端
- 白名單組
商品展現，商品列表
3.黑白名單組
商品詳情內的展現，已登陸和未登陸之間的區別
api
- 黑名單組
-
基於Token安全機制認證要求安全
- 登陸鑑權
- 防止業務參數串改
fiddler抓包工具。能夠實現。
- 保護用戶敏感信息
用戶Id，在網絡上是不進行傳輸的，都是用token來代替
- 防簽名僞造
客戶端和服務端都有一套token和Secret的，傳輸的時候不是用secret傳輸，是的簽名
- Token 認證機制總體架構
總體架構分爲Token生成與認證兩部分：
- Token生成指在登錄成功以後生成 Token 和密鑰，並其與用戶隱私信息、客戶端信息一塊兒存儲至Token表,同時返回Token 與Secret 至客戶端。
- Token認證指客戶端請求業務接口時，認證中心基於Token生成簽名。
- Token表結構說明:
其實若是token加入索引的話，查詢也比較快，可是相對於redis來講確定是沒有redis快的。
| 名稱 | 類型 | 描述 | 約束 |
|---|---|---|---|
| id | number | id主鍵 | 主鍵，自增加 |
| memberId | number | 會員ID | |
| accessToken | varchar(50) | Token | 索引 |
| secret | varchar(50) | 密鑰 | |
| createdTime | datetime | 建立時間 | |
| expiresTime | datetime | 有效期至 | |
| clientIp | varchar(50) | 客戶端IP | |
| clientType | varchar(50) | 客戶端類別 | |
| eCode | varchar(50) | 設備標識 | |
| uCode | varchar(50) | 設備用戶標識 |
- 業務請求具體參數：
| 名稱 | 類型 | 描述 |
|---|---|---|
| method | string | 方法名稱 |
| param | json | 業務參數 |
| token | string | token值 |
| sign | string | 簽名規則:md5(secret+method+param+token+secret+timestamp) |
| timestamp | long | 請求時間搓，容許與服務端10分鐘偏差 |
簽名規則：
- 已指定順序拼接字符串 secret+method+param+token+timestamp+secret
- 使用MD5進行加密，在轉化成大寫
簽名的目的：
- 防串改
- 防僞造
- 防重複使用簽名
服務端簽名驗證的具體流程：
簽名認證與API網關的總體認證流程
PS：代碼直接看源碼，主要是瞭解思路，對於性能我建議先別考慮，先實現以後才能談性能問題，性能問題沒有絕對的只有相對的。最主要是簽名的獲取生成的思路。