作者：coolfiry
鏈接：cnblogs.com/coolfiry/p/8193768.html

在這篇文章中將我們一起來探討當(dāng)前的API網(wǎng)關(guān)的作用璧榄。

一、API網(wǎng)關(guān)的用處

API網(wǎng)關(guān)我的分析中會用到以下三種場景吧雹。

1. Open API

企業(yè)需要將自身數(shù)據(jù)骨杂、能力等作為開發(fā)平臺向外開放，通常會以rest的方式向外提供雄卷，最好的例子就是淘寶開放平臺搓蚪、騰訊公司的QQ開發(fā)平臺、微信開放平臺丁鹉。

Open API開放平臺必然涉及到客戶應(yīng)用的接入妒潭、API權(quán)限的管理、調(diào)用次數(shù)管理等揣钦，必然會有一個統(tǒng)一的入口進(jìn)行管理雳灾，這正是API網(wǎng)關(guān)可以發(fā)揮作用的時候。

2. 微服務(wù)網(wǎng)關(guān)

微服務(wù)的概念最早在2012年提出拂盯，在Martin Fowler的大力推廣下佑女，微服務(wù)在2014年后得到了大力發(fā)展。

在微服務(wù)架構(gòu)中谈竿，有一個組件可以說是必不可少的团驱，那就是微服務(wù)網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)處理了負(fù)載均衡空凸，緩存嚎花，路由，訪問控制呀洲，服務(wù)代理紊选，監(jiān)控，日志等道逗。API網(wǎng)關(guān)在微服務(wù)架構(gòu)中正是以微服務(wù)網(wǎng)關(guān)的身份存在兵罢。

3. API服務(wù)管理平臺

上述的微服務(wù)架構(gòu)對企業(yè)來說有可能實(shí)施上是困難的，企業(yè)有很多遺留系統(tǒng)滓窍，要全部抽取為微服務(wù)器改動太大卖词，對企業(yè)來說成本太高。

但是由于不同系統(tǒng)間存在大量的API服務(wù)互相調(diào)用吏夯，因此需要對系統(tǒng)間服務(wù)調(diào)用進(jìn)行管理此蜈，清晰地看到各系統(tǒng)調(diào)用關(guān)系即横，對系統(tǒng)間調(diào)用進(jìn)行監(jiān)控等。

API網(wǎng)關(guān)可以解決這些問題裆赵，我們可以認(rèn)為如果沒有大規(guī)模的實(shí)施微服務(wù)架構(gòu)东囚，那么對企業(yè)來說微服務(wù)網(wǎng)關(guān)就是企業(yè)的API服務(wù)管理平臺。

二战授、API網(wǎng)關(guān)在企業(yè)整體架構(gòu)中的地位

一個企業(yè)隨著信息系統(tǒng)復(fù)雜度的提高页藻，必然出現(xiàn)外部合作伙伴應(yīng)用、企業(yè)自身的公網(wǎng)應(yīng)用陈醒、企業(yè)內(nèi)網(wǎng)應(yīng)用等惕橙，在架構(gòu)上應(yīng)該將這三種應(yīng)用區(qū)別開，三種應(yīng)用的安排級別钉跷、訪問方式也不一樣弥鹦。

因此在我的設(shè)計中將這三種應(yīng)用分別用不同的網(wǎng)關(guān)進(jìn)行API管理，分別是：API網(wǎng)關(guān)（OpenAPI合伙伙伴應(yīng)用）爷辙、API網(wǎng)關(guān)（內(nèi)部應(yīng)用）彬坏、API網(wǎng)關(guān)（內(nèi)部公網(wǎng)應(yīng)用）。

image

三膝晾、企業(yè)中在如何應(yīng)用API網(wǎng)關(guān)

1栓始、對于OpenAPI使用的API網(wǎng)關(guān)來說，一般合作伙伴要以應(yīng)用的形式接入到OpenAPI平臺血当，合作伙伴需要到 OpenAPI平臺申請應(yīng)用幻赚。

因此在OpenAPI網(wǎng)關(guān)之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴臊旭，這就要求OpenAPI網(wǎng)關(guān)需要提供API給這個用戶平臺進(jìn)行訪問落恼。

如下架構(gòu):

image

當(dāng)然如果是在簡單的場景下，可能并不需要提供一個面向合作伙伴的門戶离熏，只需要由公司的運(yùn)營人員直接添加合作伙伴應(yīng)用id/密鑰等佳谦，這種情況下也就不需要合作伙伴門戶子系統(tǒng)。

2滋戳、對于內(nèi)網(wǎng)的API網(wǎng)關(guān)钻蔑，在起到的作用上來說可以認(rèn)為是微服務(wù)網(wǎng)關(guān)，也可以認(rèn)為是內(nèi)網(wǎng)的API服務(wù)治理平臺奸鸯。

當(dāng)企業(yè)將所有的應(yīng)用使用微服務(wù)的架構(gòu)管理起來咪笑，那么API網(wǎng)關(guān)就起到了微服務(wù)網(wǎng)關(guān)的作用。

而當(dāng)企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進(jìn)行訪問時使用API網(wǎng)關(guān)對調(diào)用進(jìn)行管理娄涩，那么API網(wǎng)關(guān)起到的就是API服務(wù)治理的作用蒲肋。

架構(gòu)參考如下：

image

3、對于公司內(nèi)部公網(wǎng)應(yīng)用（如APP、公司的網(wǎng)站）兜粘，如果管理上比較細(xì)致，在架構(gòu)上是可能由獨(dú)立的API網(wǎng)關(guān)來處理這部分內(nèi)部公網(wǎng)應(yīng)用弯蚜，如果想比較簡單的處理孔轴，也可以是使用面向合作伙伴的API網(wǎng)關(guān)。

如果使用獨(dú)立的API網(wǎng)關(guān)碎捺，有以下的好處：

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

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

四、API網(wǎng)關(guān)有哪些競爭方案

1拧额、對于Open API平臺的API網(wǎng)關(guān)碑诉，我分析只能選擇API網(wǎng)關(guān)作為解決方案，業(yè)界沒有發(fā)現(xiàn)比較好的可以用來作為Open API平臺的入口的其他方案侥锦。

2进栽、對于作為微服務(wù)網(wǎng)關(guān)的API網(wǎng)關(guān)，業(yè)界的選擇可以選擇的解決方案比較多恭垦，也取決于微服務(wù)器的實(shí)現(xiàn)方案快毛，有一些微服務(wù)架構(gòu)的實(shí)現(xiàn)方案是不需要微服務(wù)網(wǎng)關(guān)的。

• Service Mesh番挺，這是新興的基于無API網(wǎng)關(guān)的架構(gòu)唠帝，通過在客戶端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問，這樣達(dá)到對應(yīng)用層最小的改動建芙，當(dāng)前Service Mesh的產(chǎn)品還正在開發(fā)中没隘，并沒有非常成熟可直接應(yīng)用的產(chǎn)品。發(fā)展最迅速的產(chǎn)品是Istio禁荸。建議大家密切關(guān)注相關(guān)產(chǎn)品的研發(fā)右蒲、業(yè)務(wù)使用進(jìn)展。

image

• 基于duboo架構(gòu)赶熟，在這個架構(gòu)中通常是不需要網(wǎng)關(guān)的瑰妄，是由客戶端直接訪問服務(wù)提供方，由注冊中心向客戶端返回服務(wù)方的地址映砖。

image

五间坐、API網(wǎng)關(guān)解決方案

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

• Kong kong是基于Nginx+Lua進(jìn)行二次開發(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)關(guān)蜈七， https://www.aliyun.com/product/apigateway/
• 騰訊云API網(wǎng)關(guān)秒拔， https://cloud.tencent.com/product/apigateway

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

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

六伊诵、企業(yè)怎么選擇API網(wǎng)關(guān)

如果是要選擇一款已有的API網(wǎng)關(guān)，那么需要從以下幾個方面去考慮回官。

1曹宴、性能與可用性

如果一旦采用了API網(wǎng)關(guān)，那么API網(wǎng)關(guān)就會作為企業(yè)應(yīng)用核心歉提，因此性能和可用性是必須要求的笛坦。

從性能上來說，需要讓網(wǎng)關(guān)增加的時間消耗越短越好苔巨，個人覺得需要10ms以下版扩。系統(tǒng)需要采用非阻塞的IO，如epoll侄泽，NIO等礁芦。

網(wǎng)關(guān)和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統(tǒng)的高可用性悼尾，如：Node.js的響應(yīng)式編程和基于java體現(xiàn)的RxJava和Future柿扣。網(wǎng)關(guān)必須支持集群部署，任務(wù)一臺服務(wù)器的crash都應(yīng)該不影響整體系統(tǒng)的可用性闺魏。多套網(wǎng)關(guān)應(yīng)該支持同一管理平臺和同一監(jiān)控中心未状。如：一個企業(yè)的OpenAPI網(wǎng)關(guān)和內(nèi)部應(yīng)用的多個系統(tǒng)群的不同的微服務(wù)網(wǎng)關(guān)可以在同一監(jiān)控中心進(jìn)行監(jiān)控。

2析桥、可擴(kuò)展性司草、可維護(hù)性

一款產(chǎn)品總有不能滿足生產(chǎn)需求的地方艰垂，因此需求思考產(chǎn)品在如何進(jìn)行二次開發(fā)和維護(hù)，是否方便公司團(tuán)隊接手維護(hù)產(chǎn)品埋虹。

3猜憎、需求匹配度

需要評估各API網(wǎng)關(guān)在需求上是否能滿足，如：如果是OpenAPI平臺需要使用API網(wǎng)關(guān)吨岭，那么需要看API網(wǎng)關(guān)在合作伙伴應(yīng)用接入拉宗、合作伙伴門戶集成、訪問次數(shù)限額等OpenAPI核心需求上去思考產(chǎn)品是否能滿足要求辣辫。

如果是微服務(wù)網(wǎng)關(guān)，那么要從微服務(wù)的運(yùn)維魁巩、監(jiān)控急灭、管理等方面去思考產(chǎn)品是否足夠強(qiáng)大。

4谷遂、是否開源葬馋？公司是否有自開發(fā)的能力？

現(xiàn)有的開源產(chǎn)品如kong肾扰，zuul畴嘶，orange都有基礎(chǔ)的API網(wǎng)關(guān)的核心功能，這些開源產(chǎn)品大多離很好的使用有一定的距離集晚。

如：沒有提供管理功能的UI界面窗悯、監(jiān)控功能弱小，不支持OpenAPI平臺偷拔，沒有公司運(yùn)營與運(yùn)維的功能等蒋院。

當(dāng)然開源產(chǎn)品能獲取源代碼，如果公司有比較強(qiáng)的研發(fā)能力莲绰，能hold住這些開源產(chǎn)品欺旧，經(jīng)過二次開發(fā)kong、zuul應(yīng)該還是適應(yīng)一些公司蛤签，不過需求注意以下一些點(diǎn)：

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

另外kong提供企業(yè)版本的API網(wǎng)關(guān)马昨，當(dāng)然也是基于ngnix+lua的竞帽，企業(yè)版本可以購買他們的技術(shù)支持、培訓(xùn)等服務(wù)鸿捧、以及擁有界面的管理屹篓、監(jiān)控等功能。

5匙奴、公有云還是私有云

現(xiàn)在的亞馬遜堆巧、阿里、騰訊云都在提供基礎(chǔ)公有云的API網(wǎng)關(guān)泼菌，當(dāng)然這些網(wǎng)關(guān)的基礎(chǔ)功能肯定是沒有問題谍肤，但是二次開發(fā)，擴(kuò)展功能哗伯、監(jiān)控功能可能就不能滿足部分用戶的定制需求了荒揣。

另外很多企業(yè)因?yàn)樽陨硇畔踩脑颍荒苁褂猛饩W(wǎng)公有網(wǎng)的API網(wǎng)關(guān)服務(wù)焊刹，這樣就只有選擇私有云的方案了系任。

在需求上如果基于公有云的API網(wǎng)關(guān)只能做到由內(nèi)部人員為外網(wǎng)人員申請應(yīng)用，無法做到定制的合作伙伴門戶虐块，這也不適合于部分企業(yè)的需求俩滥。

如果作為微服務(wù)網(wǎng)關(guān)，大多數(shù)情況下是希望網(wǎng)關(guān)服務(wù)器和服務(wù)提供方服務(wù)器是要在內(nèi)網(wǎng)的贺奠，在這里情況下也只有私有云的API網(wǎng)關(guān)才能滿足需求霜旧。

綜合上面的分析，基礎(chǔ)公有云的API網(wǎng)關(guān)只有滿足一部分簡單客戶的需求敞嗡，對于很多企業(yè)來說私有云的API網(wǎng)關(guān)才是正確的選擇颁糟。