-     API 網(wǎng)關的用處     -

在這篇文章中將我們一起來探討當前的API網(wǎng)關的作用。
API網(wǎng)關我的分析中會用到以下三種場景。
Open API 企業(yè)需要將自身數(shù)據(jù)、能力等作為開發(fā)平臺向外開放，通常會以rest的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的QQ開發(fā)平臺、微信開放平臺。
Open API開放平臺必然涉及到客戶應用的接入、API權限的管理、調(diào)用次數(shù)管理等，必然會有一個統(tǒng)一的入口進行管理，這正是API網(wǎng)關可以發(fā)揮作用的時候。
微服務網(wǎng)關 微服務的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年后得到了大力發(fā)展。在微服務架構中，有一個組件可以說是必不可少的，那就是微服務網(wǎng)關，微服務網(wǎng)關處理了負載均衡，緩存，路由，訪問控制，服務代理，監(jiān)控，日志等。API網(wǎng)關在微服務架構中正是以微服務網(wǎng)關的身份存在。
API服務管理平臺 上述的微服務架構對企業(yè)來說有可能實施上是困難的，企業(yè)有很多遺留系統(tǒng)，要全部抽取為微服務器改動太大，對企業(yè)來說成本太高。但是由于不同系統(tǒng)間存在大量的API服務互相調(diào)用，因此需要對系統(tǒng)間服務調(diào)用進行管理，清晰地看到各系統(tǒng)調(diào)用關系，對系統(tǒng)間調(diào)用進行監(jiān)控等。
API網(wǎng)關可以解決這些問題，我們可以認為如果沒有大規(guī)模的實施微服務架構，那么對企業(yè)來說微服務網(wǎng)關就是企業(yè)的API服務管理平臺。

-     API 網(wǎng)關在企業(yè)整體架構中的地位     -

一個企業(yè)隨著信息系統(tǒng)復雜度的提高，必然出現(xiàn)外部合作伙伴應用、企業(yè)自身的公網(wǎng)應用、企業(yè)內(nèi)網(wǎng)應用等，在架構上應該將這三種應用區(qū)別開，三種應用的安排級別、訪問方式也不一樣。
因此在我的設計中將這三種應用分別用不同的網(wǎng)關進行API管理，分別是：API網(wǎng)關（OpenAPI合伙伙伴應用）、API網(wǎng)關（內(nèi)部應用）、API網(wǎng)關（內(nèi)部公網(wǎng)應用）。

-     企業(yè)如何應用 API 網(wǎng)關     -

1、對于OpenAPI使用的API網(wǎng)關來說，一般合作伙伴要以應用的形式接入到OpenAPI平臺，合作伙伴需要到 OpenAPI平臺申請應用。
因此在OpenAPI網(wǎng)關之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴，這就要求OpenAPI網(wǎng)關需要提供API給這個用戶平臺進行訪問。
當然如果是在簡單的場景下，可能并不需要提供一個面向合作伙伴的門戶，只需要由公司的運營人員直接添加合作伙伴應用id/密鑰等，這種情況下也就不需要合作伙伴門戶子系統(tǒng)。
2、對于內(nèi)網(wǎng)的API網(wǎng)關，在起到的作用上來說可以認為是 微服務網(wǎng)關 ，也可以認為是內(nèi)網(wǎng)的API服務治理平臺。當企業(yè)將所有的應用使用微服務的架構管理起來，那么API網(wǎng)關就起到了微服務網(wǎng)關的作用。
而當企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進行訪問時使用API網(wǎng)關對調(diào)用進行管理，那么API網(wǎng)關起到的就是API服務治理的作用。
3、對于公司內(nèi)部公網(wǎng)應用（如APP、公司的網(wǎng)站），如果管理上比較細致，在架構上是可能由獨立的API網(wǎng)關來處理這部分內(nèi)部公網(wǎng)應用，如果想比較簡單的處理，也可以是使用面向合作伙伴的API網(wǎng)關。
如果使用獨立的API網(wǎng)關，有以下的好處：

• 面向合作伙伴和面向公司主體業(yè)務的優(yōu)先級不一樣，不同的API網(wǎng)關可以做到業(yè)務影響的隔離。
• 內(nèi)部API使用的管理流程和面向合作伙伴的管理流程可能不一樣。
• 內(nèi)部的API在功能擴展等方面的需求一般會大于OpenAPI對于功能的要求。

基于以上的分析，如果公司有能力，那么還是建議分開使用合作伙伴OPEN API網(wǎng)關和內(nèi)部公網(wǎng)應用網(wǎng)關。

-     API 網(wǎng)關有哪些競爭方案     -

1、對于Open API平臺的API網(wǎng)關，我分析只能選擇API網(wǎng)關作為解決方案，業(yè)界沒有發(fā)現(xiàn)比較好的可以用來作為Open API平臺的入口的其他方案。
2、對于作為微服務網(wǎng)關的API網(wǎng)關，業(yè)界的選擇可以選擇的解決方案比較多，也取決于微服務器的實現(xiàn)方案，有一些微服務架構的實現(xiàn)方案是不需要微服務網(wǎng)關的。
Service Mesh ，這是新興的基于無API網(wǎng)關的架構，通過在客戶端上的代理完成屏蔽網(wǎng)絡層的訪問，這樣達到對應用層最小的改動，當前Service Mesh的產(chǎn)品還正在開發(fā)中，并沒有非常成熟可直接應用的產(chǎn)品。發(fā)展最迅速的產(chǎn)品是Istio。建議大家密切關注相關產(chǎn)品的研發(fā)、業(yè)務使用進展。
基于dubbo架構，在這個架構中通常是不需要網(wǎng)關的，是由客戶端直接訪問服務提供方，由注冊中心向客戶端返回服務方的地址。

-     API 網(wǎng)關解決方案     -
私有云開源解決方案如下：

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

公有云解決方案：

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

自開發(fā)解決方案：

• 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于這個方案。
• 基于Netty、非阻塞IO模型。通過網(wǎng)上搜索可以看到國內(nèi)的宜人貸等一些公司是基于這種方案，是一種成熟的方案。
• 基于Node.js的方案。這種方案是應用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。zuul基于的就是這種方案，這種方案的效率不高，這也是zuul總是被詬病的原因。
  

-     企業(yè)怎么選擇 API 網(wǎng)關     -

如果是要選擇一款已有的API網(wǎng)關，那么需要從以下幾個方面去考慮。
1、性能與可用性 如果一旦采用了API網(wǎng)關，那么API網(wǎng)關就會作為企業(yè)應用核心，因此性能和可用性是必須要求的。
從性能上來說，需要讓網(wǎng)關增加的時間消耗越短越好，個人覺得需要10ms以下。系統(tǒng)需要采用非阻塞的IO，如epoll，NIO等。網(wǎng)關和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統(tǒng)的高可用性，如：Node.js的響應式編程和基于java體現(xiàn)的RxJava和Future。
網(wǎng)關必須支持集群部署，任務一臺服務器的crash都應該不影響整體系統(tǒng)的可用性。
多套網(wǎng)關應該支持同一管理平臺和同一監(jiān)控中心。如：一個企業(yè)的OpenAPI網(wǎng)關和內(nèi)部應用的多個系統(tǒng)群的不同的微服務網(wǎng)關可以在同一監(jiān)控中心進行監(jiān)控。
2、可擴展性、可維護性 一款產(chǎn)品總有不能滿足生產(chǎn)需求的地方，因此需求思考產(chǎn)品在如何進行二次開發(fā)和維護，是否方便公司團隊接手維護產(chǎn)品。
3、需求匹配度 需要評估各API網(wǎng)關在需求上是否能滿足，如：如果是OpenAPI平臺需要使用API網(wǎng)關，那么需要看API網(wǎng)關在合作伙伴應用接入、合作伙伴門戶集成、訪問次數(shù)限額等OpenAPI核心需求上去思考產(chǎn)品是否能滿足要求。如果是微服務網(wǎng)關，那么要從微服務的運維、監(jiān)控、管理等方面去思考產(chǎn)品是否足夠強大。
4、是否開源？公司是否有自開發(fā)的能力？ 現(xiàn)有的開源產(chǎn)品如kong，zuul，orange都有基礎的API網(wǎng)關的核心功能，這些開源產(chǎn)品大多離很好的使用有一定的距離，如：沒有提供管理功能的UI界面、監(jiān)控功能弱小，不支持OpenAPI平臺，沒有公司運營與運維的功能等。
當然開源產(chǎn)品能獲取源代碼，如果公司有比較強的研發(fā)能力，能hold住這些開源產(chǎn)品，經(jīng)過二次開發(fā)kong、zuul應該還是適應一些公司，不過需求注意以下一些點：

• kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護這種架構產(chǎn)品的人。需求評估當前公司是否有這個能力去維護這個產(chǎn)品。
• zuul因為架構的原因在高并發(fā)的情況下性能不高，同時需要去基于研究整合開源的適配zuul的監(jiān)控和管理系統(tǒng)。
• orange由于沒有被大量使用，同時是國內(nèi)個人在開源，在可持續(xù)性和社區(qū)資源上不夠豐富，出了問題后可能不容易找到人問。

另外kong提供企業(yè)版本的API網(wǎng)關，當然也是基于ngnix+lua的，企業(yè)版本可以購買他們的技術支持、培訓等服務、以及擁有界面的管理、監(jiān)控等功能。
5、公有云還是私有云 現(xiàn)在的亞馬遜、阿里、騰訊云都在提供基礎公有云的API網(wǎng)關，當然這些網(wǎng)關的基礎功能肯定是沒有問題，但是二次開發(fā)，擴展功能、監(jiān)控功能可能就不能滿足部分用戶的定制需求了。另外很多企業(yè)因為自身信息安全的原因，不能使用外網(wǎng)公有網(wǎng)的API網(wǎng)關服務，這樣就只有選擇私有云的方案了。
在需求上如果基于公有云的API網(wǎng)關只能做到由內(nèi)部人員為外網(wǎng)人員申請應用，無法做到定制的合作伙伴門戶，這也不適合于部分企業(yè)的需求。
如果作為微服務網(wǎng)關，大多數(shù)情況下是希望網(wǎng)關服務器和服務提供方服務器是要在內(nèi)網(wǎng)的，在這里情況下也只有私有云的API網(wǎng)關才能滿足需求。
綜合上面的分析，基礎公有云的API網(wǎng)關只有滿足一部分簡單客戶的需求，對于很多企業(yè)來說私有云的API網(wǎng)關才是正確的選擇。

作者：coolfiry