普元雲計算-API管理的正確姿式--API Gatewa

編者按：

 

數字化生態，以創新客戶體驗爲核心，全部咱們身邊能感知到的變化都來自於漸近的創新。這些創新須要試錯，須要不斷的升級，而且創新每每與咱們熟知的功能分離開來分別呈現。微服務對於傳統單體架構的優點之一就在於，服務的拆分帶來了更新、部署、管理的隔離性，讓一些單獨的服務能夠進行創新和實驗。從而支撐了用戶體驗的不斷升級，爲實現企業數字化轉型的過程，提供了技術架構層面的支撐。

 

咱們如今已經能夠很方便的經過一些電子商城購買運營的合約機，而無需到營業廳親自辦理相關的業務，這就是API Gateway的一種底層支撐。因爲運營商經過API Gateway向第三方的商務平臺開放了與套餐、機型銷售等服務，並經過流控、鑑權等機制保障相關的安全性，才使得這樣方便流暢的購物體驗得以實現。

 

對於MOBA手遊類玩家來講，「王者榮耀」是一款頗受歡迎的遊戲。在一些場景下，咱們會感知到「不停機更新」「體驗服更新」這兩種不一樣方式的更新形態，在底層，就是API Gateway或者相似技術的實現，支撐灰度發佈，讓一些新特性發布給體驗服（好比傳說中露娜的二技能變化，僅在體驗服更新，實際上並未如傳說中同樣在S11賽季更新到正式服），或者特定的遊戲用戶，待功能完善或者穩定運行，再向正式服或者所有用戶發佈，讓遊戲玩家的體驗能夠更加流暢，甚至是無感知的升級。

 

這些只是微服務架構或者API Gateway所支撐的萬千業務場景中的滄海一粟。

 

但微服務自己也會帶來諸多問題，粒度小難以管理就是其中之一，本文即從這個角度，闡述了API Gateway所起到的做用和一些關鍵的技術要素。

 

以微服務爲核心的分佈式框架貫穿了普元數字化企業技術平臺的APaaS層面，本文所介紹的API Gateway是其中的關鍵組成部分（圖中標黃的部分）。

 

 

 

引言：

 

隨着微服務的大紅大紫，你們紛紛使用微服務架構來實現新系統或進行老系統的改造。固然，微服務帶給咱們太多的好處，同時也帶給咱們許多的問題須要解決。採用微服務後，全部的服務都變成了一個個細小的API，那麼這些服務API該怎麼正確的管理？API認證受權如何實現？如何實現服務的負載均衡，熔斷，灰度發佈，限流流控？如何合理的治理這些API服務尤爲重要。在微服務架構中，API Gateway做爲總體架構的重要組件，它抽象了微服務中都須要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度發佈，統一認證，限流流控，日誌統計等豐富的功能，幫助咱們解決不少API管理難題。

 

目錄：

 

1、什麼是API Gateway

2、爲何須要API Gateway

3、API Gateway中一些重要的功能

4、API Gateway vs 反向代理

5、API Gateway對API的認證及鑑權

6、採用OAuth2方式認證的兩種部署方式

7、總結

 

1、什麼是API Gateway

 

 

這張圖，很是形象的解釋了API Gateway和微服務的關係。作爲聽衆，咱們只想聽到美妙動人的音樂旋律，徹底不會在意音樂是怎麼演奏的。而指揮家則根據樂譜負責指揮好每個演奏者，使每個演奏者之間配合默契，共同完成這場音樂演出。在微服務的世界裏，API Gateway就如同一位指揮家，「指揮」着不一樣的「演奏人」(微服務)。

 

 

 

咱們知道在微服務架構中，大型服務都被拆分紅了獨立的微服務，每一個微服務一般會以RESTFUL API的形式對外提供服務。可是在UI方面，咱們可能須要在一個頁面上顯示來自不一樣微服務的數據，此時就會須要一個統一的入口來進行API的調用。上圖中咱們能夠看到，API Gateway就在此場景下充當了多個服務的大門，系統的統一入口，從面向對象設計的角度看，它與外觀模式相似，API Gateway封裝了系統的內部複雜結構，同時它還可能具備其餘API管理/調用的通用功能，如認證，限流，流控等功能。

 

 

2、爲何須要API Gateway

 

 

 

首先，Chris Richardson在http://microservices.io/中也說起到，在微服務的架構模式下，API Gateway是微服務架構中一個很是通用的模式，利用API Gateway能夠解決調用方如何調用獨立的微服務這個問題。

 

 

 

從部署結構上說，上圖是不採用API Gateway的微服務部署模式，咱們能夠清晰看到，這種部署模式下，客戶端與負載均衡器直接交互，完成服務的調用。但這是這種模式下，也有它的不足。

 

不支持動態擴展，系統每多一個服務，就須要部署或修改負載均衡器。

沒法作到動態的開關服務，若要下線某個服務，須要運維人員將服務地址從負載均衡器中移除。

對於API的限流，安全等控制，須要每一個微服務去本身實現，增長了微服務的複雜性，同時也違反了微服務設計的單一職責原則。

 

 

上圖爲採用API Gateway模式，咱們經過上圖能夠看到，API Gateway作爲系通通一入口，實現了對各個微服務間的整合，同時又作到了對客戶端友好，屏蔽系統了複雜性和差別性。對比以前無API Gateway模式，API Gateway具備幾個比較重要的優勢：

 

採用API Gateway能夠與微服務註冊中心鏈接，實現微服務無感知動態擴容。

API Gateway對於沒法訪問的服務，能夠作到自動熔斷，無需人工參與。

API Gateway能夠方便的實現藍綠部署，金絲雀發佈或A/B發佈。

API Gateway作爲系通通一入口，咱們能夠將各個微服務公共功能放在API Gateway中實現，以儘量減小各服務的職責。

幫助咱們實現客戶端的負載均衡策略。

 

3、API Gateway中一些重要的功能

 

 

下面咱們用圖來講明API Gateway中一些重要的功能：

 

負載均衡

 

 

 

 

在實際的部署應用中，當應用系統面臨大量訪問，負載太高時，一般咱們會增長服務數量來進行橫向擴展，使用集羣來提升系統的處理能力。此時多個服務經過某種負載算法分攤了系統的壓力，咱們將這種多節點分攤壓力的行爲稱爲負載均衡。

 

API Gateway能夠幫助咱們輕鬆的實現負載均衡，利用服務發現知道全部Service的地址和位置，經過在API Gateway中實現負載均衡算法，就能夠實現負載均衡效果。

 

服務熔斷

 

 

在實際生產中，一些服務頗有可能由於某些緣由發生故障，若是此時不採起一些手段，會致使整個系統「雪崩」。或因系統總體負載的考慮，會對服務訪問次數進行限制。服務熔斷、服務降級就是解決上述問題的主要方式。API Gateway能夠幫助咱們實現這些功能，對於服務的調用次數的限制，當某服務達到上限時，API Gateway會自動中止向上遊服務發送請求，並像客戶端返回錯誤提示信息或一個統一的響應，進行服務降級。對於須要臨時發生故障的服務，API Gateway自動能夠打開對應服務的斷路器，進行服務熔斷，防止整個系統「雪崩」。

 

灰度發佈

 

 

 

 

服務發佈上線過程當中，咱們不可能將新版本所有部署在生產環節中，由於新版本並無接受真實用戶、真實數據、真實環境的考驗，此時咱們須要進行灰度發佈，灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，同時影響小。API Gateway能夠幫助咱們輕鬆的完成灰度發佈，只須要在API Gateway中配置咱們須要的規則，按版本，按IP段等，API Gateway會自動爲咱們完成實際的請求分流。

 

 

4、API Gateway vs 反向代理

 

 

反向代理

 

 

在傳統部署架構中，反向代理，大可能是用於多個系統模塊間的聚合，實現負載均衡，外網向內網的轉發。經過修改配置文件的方式來進行增長或刪除節點，並重啓服務纔可生效。一般來講，反向代理服務器只具有負載均衡、轉發基本功能，若要須要其餘功能，須要增長擴展或提供腳原本實現。

 

API Gateway

 

 

在API Gateway部署模式中，API Gateway能夠看做特殊的反向代理，是對反向代理服務器功能的擴充，同時API Gateway僅侷限於服務API層面，對API作進一步的管理，保護。API Gateway不只提供了負載均衡，轉發功能，還提供了灰度發佈，統一認證，熔斷，消息轉換，訪問日誌等豐富的功能。

 

如何選擇？

 

假若咱們實際運用中，不須要服務發現，服務動態擴容，服務熔斷，統一認證，消息轉換等一系列API Gateway功能，咱們徹底可使用反向代理服務器來部署微服務架構，固然若是這樣作，如遇到增長或減小服務節點時，須要修改反向代理服務器配置，重啓服務才能夠生效。而當咱們可能不只僅須要負載均衡，內外網轉發，還須要其餘功能，又同時想實現一些各服務都須要的通用的功能時，這時候就改考慮API Gateway了。

 

 

5、API Gateway對API的

認證及鑑權

 

 

目前在微服務中，咱們還須要考慮如何保護咱們的API只能被贊成受權的客戶調用。那麼對於API的保護，目前大多數採用的方式有這麼幾種，分別爲AppKeys，OAuth2 和 OAuth2+JWT，接下來咱們逐個瞭解下。

 

認證方式

 

2）OAuth2

 

 

大部分場景中，咱們仍是須要有知道誰在調用，調用者是否有對應的角色權限等。OAuth2能夠幫助咱們來完成這個工做。在OAuth2的世界中，分爲如下幾種角色：Resource Owner，Client，Authorization Server，Resource Sever。上圖是一個簡單的OAuh2流程來講明各個角色以前的關係。最終，App得到了Rory的我的信息。

 

 

 

 

關於做者：高士皓，普元SOA&雲計算部門高級軟件工程師，現主要從事普元API Gateway開發設計工做。曾在Tibco、海航科技技術研究院擔任高級軟件工程師。在海航任職期間，參與海航數字化轉型建設，帶領團隊設計開發海航API Gateway，海航統一登陸平臺等項目。

 

關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享，長按二維碼關注