目錄
一、API 網(wǎng)關(guān)的用處二骡尽、API網(wǎng)關(guān)在企業(yè)架構(gòu)中的地位三、企業(yè)中如何應(yīng)用API網(wǎng)關(guān)四擅编、API網(wǎng)關(guān)有哪些競(jìng)爭(zhēng)方案五攀细、API網(wǎng)關(guān)解決方案六、企業(yè)怎么選擇API網(wǎng)關(guān)
一爱态、API網(wǎng)關(guān)的用處
API網(wǎng)關(guān)我的分析中會(huì)用到以下三種場(chǎng)景谭贪。
1、Open API
企業(yè)需要將自身數(shù)據(jù)锦担、能力等作為開(kāi)發(fā)平臺(tái)向外開(kāi)放俭识，通常會(huì)以rest的方式向外提供。最好的例子就是淘寶開(kāi)放平臺(tái)洞渔、騰訊公司的QQ開(kāi)發(fā)平臺(tái)套媚、微信開(kāi)放平臺(tái)。
Open API開(kāi)放平臺(tái)必然涉及到客戶(hù)應(yīng)用的接入磁椒、API權(quán)限的管理堤瘤、調(diào)用次數(shù)管理等，必然會(huì)有一個(gè)統(tǒng)一的入口進(jìn)行管理浆熔，這正是API網(wǎng)關(guān)可以發(fā)揮作用的時(shí)候本辐。
2、微服務(wù)網(wǎng)關(guān)
微服務(wù)的概念最早在2012年提出医增，在Martin Fowler的大力推廣下慎皱，微服務(wù)在2014年后得到了大力發(fā)展。
在微服務(wù)架構(gòu)中叶骨，有一個(gè)組件可以說(shuō)是必不可少的宝冕，那就是微服務(wù)網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)處理了負(fù)載均衡邓萨，緩存地梨，路由，訪問(wèn)控制缔恳，服務(wù)代理宝剖，監(jiān)控，日志等歉甚。
API 網(wǎng)關(guān)在微服務(wù)架構(gòu)中正是以微服務(wù)網(wǎng)關(guān)的身份存在万细。
3、API服務(wù)管理平臺(tái)
上述的微服務(wù)架構(gòu)對(duì)企業(yè)來(lái)說(shuō)有可能實(shí)施上是困難的，企業(yè)有很多遺留系統(tǒng)赖钞，要全部抽取為微服務(wù)改動(dòng)太大腰素，對(duì)企業(yè)來(lái)說(shuō)成本太高。
但是由于不同系統(tǒng)間存在大量的API服務(wù)互相調(diào)用雪营，因此需要對(duì)系統(tǒng)間服務(wù)調(diào)用進(jìn)行管理弓千，清晰地看到各系統(tǒng)調(diào)用關(guān)系，對(duì)系統(tǒng)間調(diào)用進(jìn)行監(jiān)控等献起。
API網(wǎng)關(guān)可以解決這些問(wèn)題洋访，我們可以認(rèn)為如果沒(méi)有大規(guī)模的實(shí)施微服務(wù)架構(gòu)，那么對(duì)企業(yè)來(lái)說(shuō)微服務(wù)網(wǎng)關(guān)就是企業(yè)的API服務(wù)管理平臺(tái)谴餐。
二姻政、API網(wǎng)關(guān)在企業(yè)架構(gòu)中的地位
一個(gè)企業(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ū)別開(kāi)厌殉，三種應(yīng)用的安排級(jí)別食绿、訪問(wèn)方式也不一樣。
因此在我的設(shè)計(jì)中將這三種應(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)用）熏兄。
如下圖所示：
三、企業(yè)中如何應(yīng)用API網(wǎng)關(guān)
1树姨、對(duì)于OpenAPI使用的API網(wǎng)關(guān)來(lái)說(shuō)摩桶，一般合作伙伴要以應(yīng)用的形式接入到OpenAPI平臺(tái)，合作伙伴需要到 OpenAPI平臺(tái)申請(qǐng)應(yīng)用帽揪。
因此在OpenAPI網(wǎng)關(guān)之外硝清，需要有一個(gè)面向合作伙伴的使用的平臺(tái)用于合作伙伴，這就要求OpenAPI網(wǎng)關(guān)需要提供API給這個(gè)用戶(hù)平臺(tái)進(jìn)行訪問(wèn)转晰。
如下架構(gòu):
當(dāng)然如果是在簡(jiǎn)單的場(chǎng)景下芦拿，可能并不需要提供一個(gè)面向合作伙伴的門(mén)戶(hù)，只需要由公司的運(yùn)營(yíng)人員直接添加合作伙伴應(yīng)用id/密鑰等查邢，這種情況下也就不需要合作伙伴門(mén)戶(hù)子系統(tǒng)蔗崎。
2、對(duì)于內(nèi)網(wǎng)的API網(wǎng)關(guān)扰藕，在起到的作用上來(lái)說(shuō)可以認(rèn)為是微服務(wù)網(wǎng)關(guān)缓苛，也可以認(rèn)為是內(nèi)網(wǎng)的API服務(wù)治理平臺(tái)。
當(dāng)企業(yè)將所有的應(yīng)用使用微服務(wù)的架構(gòu)管理起來(lái)邓深，那么API網(wǎng)關(guān)就起到了微服務(wù)網(wǎng)關(guān)的作用未桥。
而當(dāng)企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進(jìn)行訪問(wèn)時(shí)使用API網(wǎng)關(guān)對(duì)調(diào)用進(jìn)行管理笔刹，那么API網(wǎng)關(guān)起到的就是API服務(wù)治理的作用。
架構(gòu)參考如下：
3冬耿、對(duì)于公司內(nèi)部公網(wǎng)應(yīng)用（如APP舌菜、公司的網(wǎng)站），如果管理上比較細(xì)致淆党，在架構(gòu)上可能由獨(dú)立的API網(wǎng)關(guān)來(lái)處理這部分內(nèi)部公網(wǎng)應(yīng)用
如果想比較簡(jiǎn)單的處理酷师，也可以是使用面向合作伙伴的API網(wǎng)關(guān)。
如果使用獨(dú)立的API網(wǎng)關(guān)染乌，有以下的好處：
面向合作伙伴和面向公司主體業(yè)務(wù)的優(yōu)先級(jí)不一樣山孔，不同的API網(wǎng)關(guān)可以做到業(yè)務(wù)影響的隔離。
內(nèi)部API使用的管理流程和面向合作伙伴的管理流程可能不一樣荷憋。
內(nèi)部的API在功能擴(kuò)展等方面的需求一般會(huì)大于OpenAPI對(duì)于功能的要求台颠。
基于以上的分析，如果公司有能力勒庄，那么還是建議分開(kāi)使用合作伙伴OPEN API網(wǎng)關(guān)和內(nèi)部公網(wǎng)應(yīng)用網(wǎng)關(guān)串前。
四、API網(wǎng)關(guān)有哪些競(jìng)爭(zhēng)方案
1实蔽、對(duì)于Open API平臺(tái)的API網(wǎng)關(guān)荡碾，我分析只能選擇API網(wǎng)關(guān)作為解決方案.
業(yè)界沒(méi)有發(fā)現(xiàn)比較好的可以用來(lái)作為Open API平臺(tái)的入口的其他方案。
2局装、對(duì)于作為微服務(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)的拨脉。
(1)Service Mesh
這是新興的基于無(wú)API網(wǎng)關(guān)的架構(gòu)，通過(guò)在客戶(hù)端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問(wèn)宣增，這樣達(dá)到對(duì)應(yīng)用層最小的改動(dòng)
當(dāng)前Service Mesh的產(chǎn)品還正在開(kāi)發(fā)中玫膀，并沒(méi)有非常成熟可直接應(yīng)用的產(chǎn)品。發(fā)展最迅速的產(chǎn)品是Istio爹脾。建議大家密切關(guān)注相關(guān)產(chǎn)品的研發(fā)帖旨、業(yè)務(wù)使用進(jìn)展。
(2)基于duboo架構(gòu)
在這個(gè)架構(gòu)中通常是不需要網(wǎng)關(guān)的灵妨，是由客戶(hù)端直接訪問(wèn)服務(wù)提供方解阅，由注冊(cè)中心向客戶(hù)端返回服務(wù)方的地址。
五闷串、API網(wǎng)關(guān)解決方案
公有云解決方案：
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
自開(kāi)發(fā)解決方案：
基于Nginx+Lua+ OpenResty的方案瓮钥，可以看到Kong,orange都是基于這個(gè)方案
基于Netty、非阻塞IO模型。通過(guò)網(wǎng)上搜索可以看到國(guó)內(nèi)的宜人貸等一些公司是基于這種方案碉熄，是一種成熟的方案桨武。
基于Node.js的方案。這種方案是應(yīng)用了Node.js天生的非阻塞的特性锈津。
基于java Servlet的方案呀酸。zuul基于的就是這種方案，這種方案的效率不高琼梆，這也是zuul總是被詬病的原因性誉。
六、企業(yè)怎么選擇API網(wǎng)關(guān)
如果要選擇一款已有的API網(wǎng)關(guān)茎杂，需要從以下幾個(gè)方面去考慮错览。
1、性能與可用性
如果一旦采用了API網(wǎng)關(guān)煌往，那么API網(wǎng)關(guān)就會(huì)作為企業(yè)應(yīng)用核心倾哺，因此性能和可用性是必須要求的。
從性能上來(lái)說(shuō)刽脖，需要讓網(wǎng)關(guān)增加的時(shí)間消耗越短越好羞海，個(gè)人覺(jué)得需要10ms以下。
系統(tǒng)需要采用非阻塞的IO曲管，如epoll却邓，NIO等，網(wǎng)關(guān)和各種依賴(lài)的交互也需要是非阻塞的院水，這樣才能保證整體系統(tǒng)的高可用性腊徙，如：Node.js的響應(yīng)式編程和基于java體現(xiàn)的RxJava和Future。
網(wǎng)關(guān)必須支持集群部署衙耕，任務(wù)一臺(tái)服務(wù)器的crash都應(yīng)該不影響整體系統(tǒng)的可用性昧穿。
多套網(wǎng)關(guān)應(yīng)該支持同一管理平臺(tái)和同一監(jiān)控中心勺远。如：一個(gè)企業(yè)的OpenAPI網(wǎng)關(guān)和內(nèi)部應(yīng)用的多個(gè)系統(tǒng)群的不同的微服務(wù)網(wǎng)關(guān)可以在同一監(jiān)控中心進(jìn)行監(jiān)控橙喘。
2、可擴(kuò)展性胶逢、可維護(hù)性
一款產(chǎn)品總有不能滿(mǎn)足生產(chǎn)需求的地方厅瞎，因此需求思考產(chǎn)品在如何進(jìn)行二次開(kāi)發(fā)和維護(hù)，是否方便公司團(tuán)隊(duì)接手維護(hù)產(chǎn)品初坠。
3和簸、需求匹配度
需要評(píng)估各API網(wǎng)關(guān)在需求上是否能滿(mǎn)足。
比如：如果是OpenAPI平臺(tái)需要使用API網(wǎng)關(guān)碟刺，那么需要看API網(wǎng)關(guān)在合作伙伴應(yīng)用接入锁保、合作伙伴門(mén)戶(hù)集成、訪問(wèn)次數(shù)限額等OpenAPI核心需求上去思考產(chǎn)品是否能滿(mǎn)足要求。
如果是微服務(wù)網(wǎng)關(guān)爽柒，那么要從微服務(wù)的運(yùn)維吴菠、監(jiān)控、管理等方面去思考產(chǎn)品是否足夠強(qiáng)大浩村。
4做葵、是否開(kāi)源？公司是否有自開(kāi)發(fā)的能力心墅？
現(xiàn)有的開(kāi)源產(chǎn)品如kong酿矢，zuul，orange都有基礎(chǔ)的API網(wǎng)關(guān)的核心功能怎燥，這些開(kāi)源產(chǎn)品大多離很好的使用有一定的距離
比如：沒(méi)有提供管理功能的UI界面瘫筐、監(jiān)控功能弱小，不支持OpenAPI平臺(tái)铐姚，沒(méi)有公司運(yùn)營(yíng)與運(yùn)維的功能等严肪。
當(dāng)然開(kāi)源產(chǎn)品能獲取源代碼，如果公司有比較強(qiáng)的研發(fā)能力谦屑，能hold住這些開(kāi)源產(chǎn)品驳糯，經(jīng)過(guò)二次開(kāi)發(fā)kong、zuul應(yīng)該還是適應(yīng)一些公司氢橙，不過(guò)需求注意以下一些點(diǎn)：
kong是基于ngnix+lua的酝枢，從公司的角度比較難于找到能去維護(hù)這種架構(gòu)產(chǎn)品的人。需求評(píng)估當(dāng)前公司是否有這個(gè)能力去維護(hù)這個(gè)產(chǎn)品悍手。
zuul因?yàn)榧軜?gòu)的原因在高并發(fā)的情況下性能不高帘睦，同時(shí)需要去基于研究整合開(kāi)源的適配zuul的監(jiān)控和管理系統(tǒng)。
orange由于沒(méi)有被大量使用坦康，同時(shí)是國(guó)內(nèi)個(gè)人在開(kāi)源竣付，在可持續(xù)性和社區(qū)資源上不夠豐富，出了問(wèn)題后可能不容易找到人問(wèn)滞欠。
另外kong提供企業(yè)版本的API網(wǎng)關(guān)古胆，當(dāng)然也是基于ngnix+lua的，企業(yè)版本可以購(gòu)買(mǎi)他們的技術(shù)支持筛璧、培訓(xùn)等服務(wù)逸绎、以及擁有界面的管理、監(jiān)控等功能夭谤。
5棺牧、公有云還是私有云
現(xiàn)在的亞馬遜、阿里朗儒、騰訊云都在提供基礎(chǔ)公有云的API網(wǎng)關(guān)颊乘，當(dāng)然這些網(wǎng)關(guān)的基礎(chǔ)功能肯定是沒(méi)有問(wèn)題参淹，但是二次開(kāi)發(fā)，擴(kuò)展功能乏悄、監(jiān)控功能可能就不能滿(mǎn)足部分用戶(hù)的定制需求了承二。
另外很多企業(yè)因?yàn)樽陨硇畔踩脑颍荒苁褂猛饩W(wǎng)公有網(wǎng)的API網(wǎng)關(guān)服務(wù)纲爸，這樣就只有選擇私有云的方案了亥鸠。
在需求上如果基于公有云的API網(wǎng)關(guān)只能做到由內(nèi)部人員為外網(wǎng)人員申請(qǐng)應(yīng)用，無(wú)法做到定制的合作伙伴門(mén)戶(hù)识啦，這也不適合于部分企業(yè)的需求负蚊。
如果作為微服務(wù)網(wǎng)關(guān)，大多數(shù)情況下是希望網(wǎng)關(guān)服務(wù)器和服務(wù)提供方服務(wù)器是要在內(nèi)網(wǎng)的颓哮，在這里情況下也只有私有云的API網(wǎng)關(guān)才能滿(mǎn)足需求家妆。
綜合上面的分析，基礎(chǔ)公有云的API網(wǎng)關(guān)只有滿(mǎn)足一部分簡(jiǎn)單客戶(hù)的需求冕茅，對(duì)于很多企業(yè)來(lái)說(shuō)私有云的API網(wǎng)關(guān)才是正確的選擇伤极。
