API管理的正確姿式--API Gateway

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

咱們如今已經能夠很方便的經過一些電子商城購買運營的合約機，而無需到營業廳親自辦理相關的業務，這就是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，接下來咱們逐個瞭解下。

• 認證方式

1）AppKeys

目前採用AppKeys Auth認證的公有云API Gateway和數據開放平臺居多，如阿里API Gateway，聚合數據等，這種認證模式是由API Gateway頒發一個key，或者appkey+appsecret+某種複雜的加密算法生成AppKey，調用方獲取到key後直接調用API。這個key能夠是無任何意義的一串字符。API Gateway在收到調用API請求時，首先校驗key的合法性，包括key是否失效，當前調用API是否被訂閱等等信息，若校驗成功，則請求上游服務，返回結果。此處上游服務再也不對請求作任何校驗，直接返回結果。採用AppKeys認證模式比較適合Open Service的場景。其中並不涉及到用戶信息，權限信息。

2）OAuth2

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

3）OAuth2+JWT

OAuth2 + JWT流程跟OAuth2徹底一致。瞭解OAuth2的童鞋都應該知道，OAuth2最後會給調用方頒發一個Access Token，OAuth2+JWT實際上就是將Access Token換成JWT而已。這樣作的好處僅僅是減小Token校驗時查詢DB的次數。

• OAuth2 with API Gateway

有那麼多認證方式，加入了API Gateway後，該怎麼作呢？在微服務的世界中，咱們每一個服務可能都會須要用戶信息，用戶權限來判斷當前接口或功能是否對當前用戶可用。

咱們能夠將統一認證放在API Gateway來實現，由API Gateway來作統一的攔截和鑑權，結合上文所描述的認證方式中，OAuth2協議中能夠攜帶用戶信息，故採用OAuth2。

6、採用OAuth2方式認證的

兩種部署方式

• VPC網絡部署，服務內部授信

第一種，微服務部署在單獨的VPC網絡中，同時微服務互相授信，互相調用不須要驗證請求是否合法。這種模式下，當調用請求通過API Gateway時，API Gateway會拿着調用者提供的Access Token到Authorization Server中認證，若Access Token合法，Authorization Server會返回當前Access Token所表明的基本信息，API Gateway獲取到這些基本信息後，會將這些信息放置在自定義Header中請求上游服務，上游服務可獲取這些基本信息來進行對應操做的權限判斷。若是咱們對API Gateway跟Authorization Server驗證Access token的過程當中，擔憂有性能和效率損失，咱們能夠將Access Token改成JWT token，由API Gateway持有公鑰對JWT token進行解密，減小一次HTTP請求。可是這種作法不推薦，畢竟JWT基本信息是Base64的，能夠被垂手可得的解密。

• 微服務互相不授信，不在VPC中

第二種，微服務互相不授信，彼此調用須要驗證請求的合法性，這種模式爲了更加安全，咱們須要內外token轉換。首先，調用方經過OAuth2流程，獲取到Access Token，當前Access Token是一串沒有意義的字符串，咱們將它稱爲Reference Token。當調用方調用API時，此時API Gateway會拿着調用者提供的Access Token到Authorization Server中認證置換。此時，Authorization Server不會返回基本信息，而是返回一個包含基本信息的JWT Token，咱們將它稱爲ID Token。緊接着API Gateway會將JWT Token放到Request Header中，請求上游服務。上游服務獲取到當前JWT token後，會請求Authorization Server獲取到JWK，利用JWK對當前JWT Token進行校驗，解密，最後，進行角色權限判斷。微服務之間的互相調用，也必須將JWT Token放在Request Header中。

總結來講，以上幾種方式均可以完成認證，但具體採用什麼方式認證，仍是取決於實際中對系統安全性的要求和具體的業務場景。

7、總結

API Gateway在微服務架構中起到了相當重要的做用。在文章中咱們介紹了什麼是API Gateway以及爲何須要API Gateway。API Gateway它做爲微服務系統的大門，向咱們提供了請求轉發，服務熔斷，限流流控等公共功能，它又統一整合了各個微服務，對外屏蔽了系統的複雜性和差別性。

另外，咱們介紹了目前微服務架構中幾種認證方案。結合API Gateway，咱們採用了OAuth2協議對API進行認證鑑權，同時又從在部署架構的角度上，介紹了兩種不同的認證方式。

精選提問：

問1：springcloud 用哪一個組件？

答：因爲基於SpringBoot2的Spring cloud F版還未release，現階段springcloud GA版本使用Zuul。

不過，待Spring cloud F版GA後，建議多關注下Spring Cloud Gateway。它是spring團隊基於netty重寫的API Gateway組件，相對於Zuul性能較好

問2：微服務都是在spring cloud系列下 用springcloud自帶的zuul仍是選擇其餘的好？

答：若是基於Spring cloud的話，仍是建議使用Spring cloud自帶的Zuul，能大量減小咱們對spring cloud體系下微服務治理方案的集成時間。

問3：Zuul 是 spring cloud 的apigetway 組件嗎？

答：目前，spring cloud GA版（最新爲Edgware）的API Gateway組件爲Zuul。

但即將GA的F版，Spring團隊使用netty本身實現了API Gateway對外提供，若使用F版，咱們就能夠進行選擇，zuul和spring cloud gateway均可以。

問4：微服務調用系統外部服務 是否也要走Api gateway？

答：若是相似APIGateway上能夠直接作編排的，那確實調用外部服務的某些時候，能夠直接從API gateway走，可是 API gateway自己的切面是對外提供服務，具體仍是要要看業務場景。

問5：最後一種不授信，是否意味着微服務只信任本身親自從auth Server拿到的用戶信息？

答：沒錯，最後一種狀況下，微服務都要對請求進行校驗。這裏須要說明下，不是微服務從auth server獲取用戶信息，而是微服務從auth sever獲取jwk，經過jwk解密請求中JWT來獲取信息，進行用戶信息權限校驗。

問6：api gateway 修改發佈的問題，有什麼好方法嗎？整個系統的瓶頸都集中在了apiGateway

回答：API Gateway也是一個微服務，微服務最大的特性就是能夠伸縮，集羣，高可用，系統遇到瓶頸能夠增長節點。我曾經參與的項目中，最終上線用戶達到9萬之多，此時咱們也只使用了2個API Gateway的節點。

問7：用spring cloud的話，是否是能夠用zuul整合spring cloud oauth2認證受權中心服務，全部涉及獲取token、刷新token、校驗token的操做都在zuul上處理，後端業務服務不與認證受權中心作任何耦合呢？另外，有沒有現有的比較好的api gateway整合UAA服務的項目或產品可參考呢？

答：目前，spring cloud oauth2只提供了oauth2的幾種受權模式的基本實現，咱們仍是得根據本身的實際業務邏輯，進行定製化。若是將全部的Token的操做放在zuul上處理是能夠的，如剛纔ppt講的第一種安全認證方式。目前據我瞭解的，沒有什麼好的例子夠咱們參考。

問8：認證服務器帳號信息應該放在認證服務器，仍是放在業務裏呢？

答：建議將用戶帳戶信息放在認證服務器中，成爲單獨服務，與業務解耦。

問9：請問，oauth2 認證後 用戶信息 是放在token 中加密好，仍是單獨提供接口查詢好？

回答：兩種方式均可以，一切仍是看咱們系統的具體實際業務需求。

問10：如何跟業務數據同步呢？好比你註冊個帳號，咱們可能給他送1000塊錢。這1000塊錢存在單獨的業務服務器。咱們確定是異步的吧，怎麼保證消息處理的實時性啊。

回答：業務信息跟用戶帳戶是有一個映射關係存儲的，存儲在業務中。我剛所說的用戶帳戶信息管理，只涉及到用戶基本信息，組織機構等等不涉及業務的信息