聊聊API網關的做用

在這篇文章中將咱們一塊兒來探討當前的API網關的做用。 

1、API網關的用處

API網關個人分析中會用到如下三種場景。 

1. Open API。 企業須要將自身數據、能力等做爲開發平臺向外開放，一般會以rest的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的QQ開發平臺、微信開放平臺。 Open API開放平臺必然涉及到客戶應用的接入、API權限的管理、調用次數管理等，必然會有一個統一的入口進行管理，這正是API網關能夠發揮做用的時候。
2. 微服務網關。微服務的概念最先在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年後獲得了大力發展。 在微服務架構中，有一個組件能夠說是必不可少的，那就是微服務網關，微服務網關處理了負載均衡，緩存，路由，訪問控制，服務代理，監控，日誌等。API網關在微服務架構中正是以微服務網關的身份存在。 
3. API服務管理平臺。上述的微服務架構對企業來講有可能實施上是困難的，企業有不少遺留系統，要所有抽取爲微服務器改動太大，對企業來講成本過高。可是因爲不一樣系統間存在大量的API服務互相調用，所以須要對系統間服務調用進行管理，清晰地看到各系統調用關係，對系統間調用進行監控等。 API網關能夠解決這些問題，咱們能夠認爲若是沒有大規模的實施微服務架構，那麼對企業來講微服務網關就是企業的API服務管理平臺。

2、API網關在企業總體架構中的地位

一個企業隨着信息系統複雜度的提升，必然出現外部合做夥伴應用、企業自身的公網應用、企業內網應用等，在架構上應該將這三種應用區別開，三種應用的安排級別、訪問方式也不同。 所以在個人設計中將這三種應用分別用不一樣的網關進行API管理，分別是：API網關（OpenAPI合夥夥伴應用）、API網關（內部應用）、API網關（內部公網應用）。

 

3、企業中在如何應用API網關

一、對於OpenAPI使用的API網關來講，通常合做夥伴要以應用的形式接入到OpenAPI平臺，合做夥伴須要到 OpenAPI平臺申請應用。 所以在OpenAPI網關以外，須要有一個面向合做夥伴的使用的平臺用於合做夥伴，這就要求OpenAPI網關須要提供API給這個用戶平臺進行訪問。 以下架構:

 

固然若是是在簡單的場景下，可能並不須要提供一個面向合做夥伴的門戶，只須要由公司的運營人員直接添加合做夥伴應用id/密鑰等，這種狀況下也就不須要合做夥伴門戶子系統。 

二、對於內網的API網關，在起到的做用上來講能夠認爲是微服務網關，也能夠認爲是內網的API服務治理平臺。 當企業將全部的應用使用微服務的架構管理起來，那麼API網關就起到了微服務網關的做用。 而當企業只是將系統與系統之間的調用使用rest api的方式進行訪問時使用API網關對調用進行管理，那麼API網關起到的就是API服務治理的做用。 架構參考以下：

三、對於公司內部公網應用（如APP、公司的網站），若是管理上比較細緻，在架構上是可能由獨立的API網關來處理這部份內部公網應用，若是想比較簡單的處理，也能夠是使用面向合做夥伴的API網關。 若是使用獨立的API網關，有如下的好處：

• 面向合做夥伴和麪向公司主體業務的優先級不同，不一樣的API網關能夠作到業務影響的隔離。
• 內部API使用的管理流程和麪向合做夥伴的管理流程可能不同。
• 內部的API在功能擴展等方面的需求通常會大於OpenAPI對於功能的要求。

基於以上的分析，若是公司有能力，那麼仍是建議分開使用合做夥伴OPEN API網關和內部公網應用網關。

4、API網關有哪些競爭方案

一、對於Open API平臺的API網關，我分析只能選擇API網關做爲解決方案，業界沒有發現比較好的能夠用來做爲Open API平臺的入口的其餘方案。 

二、對於做爲微服務網關的API網關，業界的選擇能夠選擇的解決方案比較多，也取決於微服務器的實現方案，有一些微服務架構的實現方案是不須要微服務網關的。

• Service Mesh，這是新興的基於無API網關的架構，經過在客戶端上的代理完成屏蔽網絡層的訪問，這樣達到對應用層最小的改動，當前Service Mesh的產品還正在開發中，並無很是成熟可直接應用的產品。 發展最迅速的產品是Istio。 建議你們密切關注相關產品的研發、業務使用進展。

• 基於duboo架構，在這個架構中一般是不須要網關的，是由客戶端直接訪問服務提供方，由註冊中心向客戶端返回服務方的地址。

5、API網關解決方案

私有云開源解決方案以下：

• Kong kong是基於Nginx+Lua進行二次開發的方案， https://konghq.com/
• Netflix Zuul，zuul是spring cloud的一個推薦組件，https://github.com/Netflix/zuul
• orange,這個開源程序是國人開發的， http://orange.sumory.com/

公有云解決方案：

• Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
• 阿里雲API網關，https://www.aliyun.com/product/apigateway/
• 騰訊雲API網關， https://cloud.tencent.com/product/apigateway

自開發解決方案：

• 基於Nginx+Lua+ OpenResty的方案，能夠看到Kong,orange都是基於這個方案
• 基於Netty、非阻塞IO模型。 經過網上搜索能夠看到國內的宜人貸等一些公司是基於這種方案，是一種成熟的方案。
• 基於Node.js的方案。 這種方案是應用了Node.js天生的非阻塞的特性。
• 基於java Servlet的方案。 zuul基於的就是這種方案，這種方案的效率不高，這也是zuul老是被詬病的緣由。

6、企業怎麼選擇API網關

若是是要選擇一款已有的API網關，那麼須要從如下幾個方面去考慮。 

一、性能與可用性
若是一旦採用了API網關，那麼API網關就會做爲企業應用核心，所以性能和可用性是必需要求的。

• 從性能上來講，須要讓網關增長的時間消耗越短越好，我的以爲須要10ms如下。 系統須要採用非阻塞的IO，如epoll，NIO等。網關和各類依賴的交互也須要是非阻塞的，這樣才能保證總體系統的高可用性，如：Node.js的響應式編程和基於java體現的RxJava和Future。
• 網關必須支持集羣部署，任務一臺服務器的crash都應該不影響總體系統的可用性。
• 多套網關應該支持同一管理平臺和同一監控中心。 如： 一個企業的OpenAPI網關和內部應用的多個系統羣的不一樣的微服務網關能夠在同一監控中心進行監控。

二、可擴展性、可維護性
一款產品總有不能知足生產需求的地方，所以需求思考產品在如何進行二次開發和維護，是否方便公司團隊接手維護產品。
三、需求匹配度
須要評估各API網關在需求上是否能知足，如： 若是是OpenAPI平臺須要使用API網關，那麼須要看API網關在合做夥伴應用接入、合做夥伴門戶集成、訪問次數限額等OpenAPI核心需求上去思考產品是否能知足要求。 若是是微服務網關，那麼要從微服務的運維、監控、管理等方面去思考產品是否足夠強大。
四、是否開源？公司是否有自開發的能力？
現有的開源產品如kong，zuul，orange都有基礎的API網關的核心功能，這些開源產品大多離很好的使用有必定的距離，如：沒有提供管理功能的UI界面、監控功能弱小，不支持OpenAPI平臺，沒有公司運營與運維的功能等。 固然開源產品能獲取源代碼，若是公司有比較強的研發能力，能hold住這些開源產品，通過二次開發kong、zuul應該仍是適應一些公司，不過需求注意如下一些點：

• kong是基於ngnix+lua的，從公司的角度比較難於找到能去維護這種架構產品的人。 需求評估當前公司是否有這個能力去維護這個產品。
• zuul由於架構的緣由在高併發的狀況下性能不高，同時須要去基於研究整合開源的適配zuul的監控和管理系統。
• orange因爲沒有被大量使用，同時是國內我的在開源，在可持續性和社區資源上不夠豐富，出了問題後可能不容易找到人問。

另外kong提供企業版本的API網關，固然也是基於ngnix+lua的，企業版本能夠購買他們的技術支持、培訓等服務、以及擁有界面的管理、監控等功能。

五、公有云仍是私有云
如今的亞馬遜、阿里、騰訊雲都在提供基礎公有云的API網關，固然這些網關的基礎功能確定是沒有問題，可是二次開發，擴展功能、監控功能可能就不能知足部分用戶的定製需求了。另外不少企業由於自身信息安全的緣由，不能使用外網公有網的API網關服務，這樣就只有選擇私有云的方案了。
在需求上若是基於公有云的API網關只能作到由內部人員爲外網人員申請應用，沒法作到定製的合做夥伴門戶，這也不適合於部分企業的需求。
若是做爲微服務網關，大多數狀況下是但願網關服務器和服務提供方服務器是要在內網的，在這裏狀況下也只有私有云的API網關才能知足需求。

綜合上面的分析，基礎公有云的API網關只有知足一部分簡單客戶的需求，對於不少企業來講私有云的API網關纔是正確的選擇。

 

文章做者介紹：
來自於小豹科技的顏詩超-公司專一於軟件基礎研發平臺，目前公司正在研發一款基於Netty的插件式的API網關-小豹API網關。 但願與對OpenAPI、微服務、API網關、Service Mesh等感興趣的朋友多交流。 有興趣的朋友請加QQ羣244054462。