OpenApi開放平臺架構實踐

WebAPI 開放平臺架構實踐

---

導讀

• 背景
• 需求
• 場景
• 架構設計
• 總結

---

---

背景

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

       咱們運營和維護着諸多的對外接口,不少現有的接口服務寄宿在各個不一樣的項目,哪些應用在使用api也沒有管理起來。而且之前的調用模式也是比較複雜,排錯困難。

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

       從目前的需求上看,咱們對外提供接口的需求很大。固然,可以持續對外提供服務是好事。可是,對接標準不統一,服務寄宿不合理, 無文檔,無測試報告,無demo,無接口變動記錄都將致使api的可持續和可維護變得愈來愈難。

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

       讓全部支撐服務化,全部服務標準化。

       OPenAPI將做爲支撐的中間件,與其餘系統服務一塊兒爲運維、安全、產品和運營的各類需求提供強有力支撐。

---

需求

• 對服務提供方(如官網服務)及其API進行管理
• 對接入的應用進行管理
  • 用戶先申請appkey,appsecrect
  • 下載sdk
  • 經過appkey,appsecrect生成token
  • _aop_timestamp 請求時間戳
  • _aop_signature 請求籤名
  • access_token 用戶受權令
  • 調用API
• API規範
  • 命名規範 入參,返回值 參考: https://developer.github.com/v3/ http://cizixs.com/2016/12/12/restful-api-design-guide
  • API文檔規範
• 日誌記錄
  • API調用記錄
  • API調用異常記錄
  • ...
• 安全
  • 參數加密
  • IP白名單限制
  • 接口限制
• 性能
  • 客戶端緩存
  • 服務端緩存
  • 限流,對於高頻訪問進行限制,如每一個appkley1min調用次數

使用場景

---

架構設計

• 基礎架構

• UML設計

• 認證機制

  • 驗證(Authentication)是爲了肯定用戶是其申明的身份,好比提供帳戶的密碼。否則的話,任何人僞形成其餘身份(好比其餘用戶或者管理員)是很是危險的

• 主要原理:

  • 作一個認證服務，提供一個認證的webapi，用戶先訪問它獲取對應的token
  • 用戶拿着相應的token以及請求的參數和服務器端提供的簽名算法計算出簽名後再去訪問指定的api
  • 服務器端每次接收到請求就獲取對應用戶的token和請求參數,服務器端再次計算簽名和客戶端簽名作對比,若是驗證經過則正常訪問相應的api,驗證失敗則返回具體的失敗信息

• 核心實現

  • 1.用戶請求認證服務GetToken,將TOKEN保存在服務器端緩存中,並返回對應的TOKEN到客戶端(該請求不須要進行簽名認證）
  • 2.客戶端調用服務器端API,須要對請求進行簽名認證,簽名方式以下
  • get請求:按照請求參數名稱將全部請求參數按照字母前後順序排序獲得:keyvaluekeyvalue...keyvalue,字符串如:將arong=1,mrong=2,crong=3,排序爲:arong=1,crong=3,mrong=2,而後將參數名和參數值進行拼接獲得參數字符串：arong1crong3mrong2。post請求:將請求的參數對象序列化爲json格式字符串
  • 在請求頭中添加timespan(時間戳),nonce(隨機數),appkey,appsecrect,signature(簽名參數)
  • 計算本次請求的簽名,用timespan+nonc+appkey+appsecrect+token+data(請求參數字符串)獲得signStr簽名字符串,而後再進行排序和MD5加密獲得最終的signature簽名字符串,添加到請求頭中
  • webapi接收到相應的請求,取出請求頭中的timespan,nonc,appkey,appsecrect,signature數據,根據timespan判斷這次請求是否失效,根據appkey+appsecrect取出相應token判斷token是否失效，根據請求類型取出對應的請求參數,而後服務器端按照一樣的規則從新計算請求籤名,判斷和請求頭中的signature數據是否相同,若是相同的話則是合法請求,正常返回數據,若是不相同的話,該請求可能被惡意篡改,禁止訪問相應的數據,返回相應的錯誤信息,參與簽名的TOKEN,整個過程當中TOKEN是不參與通訊的,因此只要保證TOKEN不泄露,請求就不會被僞造。而後咱們經過timestamp時間戳用來驗證請求是否過時,這樣就算被人拿走完整的請求連接也是無效的。
  • Sign簽名的方式可以在必定程度上防止信息被篡改和僞造,保障通訊的安全。

• 受權

  (Authorization)是爲了保證用戶有對請求資源特定操做的權限。好比用戶的私人信息只能本身能訪問,其餘人沒法看到;有些特殊的操做只能管理員能夠操做,其餘用戶有隻讀的權限等等

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

• Token緩存

  因此客戶端在調用API以前都會訪問GetToken方法,因此建議在服務端和客戶端都增長緩存。

  • 服務端視角

  • 客戶端視角

• 限流

  若是對訪問的次數不加控制,很能會形成API被濫用,甚至被 DDos 攻擊。 根據使用者不一樣的身份對其進行限流,能夠防止這些狀況,減小服務器的壓力。 好比能夠設置，用戶每一個小時容許發送請求的最大值

• 壓測

  • 1.本身寫程序,開啓多線程發起模擬請求
  • 2.壓測工具，如loadrunner

---

總結

熟悉阿里的童鞋應該知道,阿里有個"大中臺,小前臺"的思想。俗稱"中臺戰略"。馬雲但願讓前臺的一線業務更加敏捷,能夠更快速適應瞬息萬變的市場,而中臺則可以整合整個企業的數據能力和產品技術能力,對各個前臺業務員造成強有力的支撐。

---

參考

• REST APIv3
• 跟着Github學習Restful HTTP API 設計
• 《企業IT架構轉型之道-阿里巴巴中臺戰略思想與架構實戰》

---

微信公衆號：碼農商業參謀