【分享】什麼是API網關？大公司爲何都有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網關解決方案
私有云解決方案以下：
• Kong是基於Nginx+Lua進行二次開發的方案
https://konghq.com/
• Eolinker和Kong比較接近，可是由於是國內公司開發的，後續的技術支持和培訓比較友好。
https://www.eolinker.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的方案，能夠看到Eolinker，Kong，orange都是基於這個方案。
• 基於Netty、非阻塞IO模型。經過網上搜索能夠看到國內的宜人貸等一些公司是基於這種方案。
• 基於Node.js的方案。這種方案是應用了Node.js天生的非阻塞的特性。
• 基於java Servlet的方案。zuul基於的就是這種方案，這種方案的效率不高，這也是zuul老是被詬病的緣由。
5、企業怎麼選擇API網關
如今的亞馬遜、阿里、騰訊雲都在提供基礎公有云的API網關，固然這些網關的基礎功能確定是沒有問題，可是二次開發，擴展功能、監控功能可能就不能知足部分用戶的定製需求了。
另外不少企業由於自身信息安全的緣由，不能使用外網公有網的API網關服務，這樣就只有選擇私有云的方案了。
在需求上若是基於公有云的API網關只能作到由內部人員爲外網人員申請應用，沒法作到定製的合做夥伴門戶，這也不適合於部分企業的需求。
若是做爲微服務網關，大多數狀況下是但願網關服務器和服務提供方服務器是要在內網的，在這裏狀況下也只有私有云的API網關才能知足需求。
綜合上面的分析，基礎公有云的API網關只有知足一部分簡單客戶的需求，對於不少企業來講私有云的API網關纔是正確的選擇。