基於WebAPI的開放平臺架構實踐

https://www.cnblogs.com/lucky_hu/p/9030667.html

新生代碼農如何在硝煙彌漫的商業叢林中生存和崛起？ 洞見,讓一部分先遇見未來。

關註公眾號“碼農商業參謀"，獲取更多技術幹貨和商業新風向。

背景

隨著業務的發展,越來越多不同系統之間需要數據往來,我們和外部系統之間產生了數據接口的對接。當然,有我們提供給外部系統(工具)的,也有我們調用第三方的。而這裏重點講一下我們對外的接口。

目前,我們運營和維護著諸多的對外接口,很多現有的接口服務寄宿在各個不同的項目,哪些應用在使用api也沒有管理起來。並且以前的調用模式也是比較復雜,排錯困難。

目前已經對外提供服務的有短信平臺,審核中心,ETCP,官網系列(充值,登陸,註冊),服務中心,AuterCenter,HomeAPI(即將上線)。同時內部還有工單系統,安全中心,基礎服務,GEMC等。其他的還有一些內部工具服務。

從目前的需求上看,我們對外提供接口的需求很大。當然,能夠持續對外提供服務是好事。

但是,對接標準不統一,服務寄宿不合理, 無文檔,無測試報告,無demo,無接口變更記錄都將導致api的可持續和可維護變得越來越難。

我們將更多的考慮對外服務的安全性,高可靠性,可維護性,尤其是離產品和用戶最近的那些API。 同時,盡量做到所有api及其調用關系都有數據可查。因此,對於新接入的API,提供專業、規範的設計標準和文檔規範勢在必行。

讓所有支撐服務化,所有服務標準化。

OPenAPI將作為支撐的中間件,與其他系統服務一起為運維、安全、產品和運營的各種需求提供強有力支撐。

需求

1.對服務提供方(如官網服務)及其API進行管理

2.對接入的應用進行管理

1)用戶先申請appkey,appsecrect

2)下載sdk

3)通過appkey,appsecrect生成token

_aop_timestamp String 否 請求時間戳

_aop_signature String 是 請求簽名

access_token String 否 用戶授權令牌

4)調用API

3.api規範

1)命名規範

  入參,返回值

  參考:

          https://developer.github.com/v3/

          http://cizixs.com/2016/12/12/restful-api-design-guide
 

2)API文檔規範

4.日誌記錄

1) API調用記錄

2) API調用異常記錄

3)....

5.安全

1)參數加密

2)IP白名單限制

3)接口限制

6.性能

1)客戶端緩存

2)服務端緩存

3)限流

  對於高頻訪問進行限制,如每個appkley1min調用次數

使用場景
使用場景.png

架構設計

1
基礎架構

uLinker.png

2
UML設計
ulLinker_uml2_0.png

3
認證機制

驗證（Authentication）是為了確定用戶是其申明的身份，比如提供賬戶的密碼。不然的話，任何人偽造成其他身份（比如其他用戶或者管理員）是非常危險的

這裏使用TOKEN+簽名認證 保證請求安全性

主要原理是：

   1.做一個認證服務，提供一個認證的webapi，用戶先訪問它獲取對應的token

   2.用戶拿著相應的token以及請求的參數和服務器端提供的簽名算法計算出簽名後再去訪問指定的api

   3.服務器端每次接收到請求就獲取對應用戶的token和請求參數，服務器端再次計算簽名和客戶端簽名做對比,如果驗證通過則正常訪問相應的api，驗證失敗則返回具體的失敗信息

核心實現(含代碼片段):

   1.用戶請求認證服務GetToken,將TOKEN保存在服務器端緩存中,並返回對應的TOKEN到客戶端（該請求不需要進行簽名認證）

    2.客戶端調用服務器端API,需要對請求進行簽名認證,簽名方式如下 

1
get請求：按照請求參數名稱將所有請求參數按照字母先後順序排序得到：keyvaluekeyvalue...keyvalue 字符串如：將arong=1,mrong=2,crong=3 排序為：arong=1, crong=3,mrong=2 然後將參數名和參數值進行拼接得到參數字符串：arong1crong3mrong2。 　

post請求:將請求的參數對象序列化為json格式字符串

2
在請求頭中添加timespan(時間戳),nonce(隨機數),appkey,appsecrect,signature(簽名參數）

3
根據請求參數計算本次請求的簽名,用timespan+nonc+appkey+appsecrect+token+data(請求參數字符串)，得到signStr簽名字符串,然後再進行排序和MD5加密得到最終的signature簽名字符串，添加到請求頭中

4
webapi接收到相應的請求,取出請求頭中的timespan,nonc,appkey,appsecrect,signature 數據,根據timespan判斷此次請求是否失效,根據appkey+appsecrect取出相應token判斷token是否失效，

根據請求類型取出對應的請求參數,然後服務器端按照同樣的規則重新計算請求簽名,判斷和請求頭中的signature數據是否相同,如果相同的話則是合法請求,正常返回數據,如果不相同的話,

該請求可能被惡意篡改,禁止訪問相應的數據,返回相應的錯誤信息

參與簽名的TOKEN,整個過程中TOKEN是不參與通信的,所以只要保證TOKEN不泄露,請求就不會被偽造。

然後我們通過timestamp時間戳用來驗證請求是否過期,這樣就算被人拿走完整的請求鏈接也是無效的。

Sign簽名的方式能夠在一定程度上防止信息被篡改和偽造,保障通信的安全。

4
授權
（Authorization）是為了保證用戶有對請求資源特定操作的權限。比如用戶的私人信息只能自己能訪問，其他人無法看到；有些特殊的操作只能管理員可以操作，其他用戶有只讀的權限等等

   1.IP白名單限制,平臺服務只能接受指定IP來源的app發起的請求

   2.api限制,指定app只能訪問授權訪問的api

5
Token緩存設計
服務端token視角.png

服務端視角

客戶端token視角.png

客戶端視角

6
限流
如果對訪問的次數不加控制，很可能會造成 API 被濫用，甚至被 DDos 攻擊。根據使用者不同的身份對其進行限流，可以防止這些情況，減少服務器的壓力。比如可以設置，用戶每個小時允許發送請求的最大值

7
壓測
1.自己寫程序,開啟多線程發起模擬請求

2.壓測工具，如loadrunner

總結
這次開放平臺實踐的第一版已經投入使用,不斷完善中。總體來看,收獲頗多,同時也是實現"中臺戰略"真正走出的第一步。

平臺架構