目錄
一、API 網關的用處二内颗、API網關在企業(yè)架構中的地位三、企業(yè)中如何應用API網關四敦腔、API網關有哪些競爭方案五均澳、API網關解決方案六、企業(yè)怎么選擇API網關
一符衔、API網關的用處
API網關我的分析中會用到以下三種場景找前。
1、Open API
企業(yè)需要將自身數據判族、能力等作為開發(fā)平臺向外開放躺盛，通常會以rest的方式向外提供。最好的例子就是淘寶開放平臺形帮、騰訊公司的QQ開發(fā)平臺槽惫、微信開放平臺。
Open API開放平臺必然涉及到客戶應用的接入辩撑、API權限的管理界斜、調用次數管理等，必然會有一個統(tǒng)一的入口進行管理合冀，這正是API網關可以發(fā)揮作用的時候各薇。
2饮睬、微服務網關
微服務的概念最早在2012年提出回窘，在Martin Fowler的大力推廣下闽寡，微服務在2014年后得到了大力發(fā)展叨吮。
在微服務架構中咖城，有一個組件可以說是必不可少的仿贬，那就是微服務網關诚镰，微服務網關處理了負載均衡借笙，緩存俺泣，路由治宣，訪問控制，服務代理砌滞，監(jiān)控侮邀，日志等。
API 網關在微服務架構中正是以微服務網關的身份存在贝润。
3绊茧、API服務管理平臺
上述的微服務架構對企業(yè)來說有可能實施上是困難的，企業(yè)有很多遺留系統(tǒng)打掘，要全部抽取為微服務改動太大华畏，對企業(yè)來說成本太高鹏秋。
但是由于不同系統(tǒng)間存在大量的API服務互相調用，因此需要對系統(tǒng)間服務調用進行管理亡笑，清晰地看到各系統(tǒng)調用關系侣夷，對系統(tǒng)間調用進行監(jiān)控等。
API網關可以解決這些問題仑乌，我們可以認為如果沒有大規(guī)模的實施微服務架構百拓，那么對企業(yè)來說微服務網關就是企業(yè)的API服務管理平臺。
二晰甚、API網關在企業(yè)架構中的地位
一個企業(yè)隨著信息系統(tǒng)復雜度的提高衙传，必然出現外部合作伙伴應用、企業(yè)自身的公網應用厕九、企業(yè)內網應用等蓖捶。
在架構上應該將這三種應用區(qū)別開，三種應用的安排級別扁远、訪問方式也不一樣俊鱼。
因此在我的設計中將這三種應用分別用不同的網關進行API管理，分別是：API網關（OpenAPI合伙伙伴應用）畅买、API網關（內部應用）亭引、API網關（內部公網應用）。
如下圖所示：
三皮获、企業(yè)中如何應用API網關
1焙蚓、對于OpenAPI使用的API網關來說，一般合作伙伴要以應用的形式接入到OpenAPI平臺洒宝，合作伙伴需要到 OpenAPI平臺申請應用购公。
因此在OpenAPI網關之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴雁歌，這就要求OpenAPI網關需要提供API給這個用戶平臺進行訪問宏浩。
如下架構:
當然如果是在簡單的場景下，可能并不需要提供一個面向合作伙伴的門戶靠瞎，只需要由公司的運營人員直接添加合作伙伴應用id/密鑰等比庄，這種情況下也就不需要合作伙伴門戶子系統(tǒng)。
2乏盐、對于內網的API網關佳窑，在起到的作用上來說可以認為是微服務網關，也可以認為是內網的API服務治理平臺父能。
當企業(yè)將所有的應用使用微服務的架構管理起來神凑，那么API網關就起到了微服務網關的作用。
而當企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調用使用rest api的方式進行訪問時使用API網關對調用進行管理，那么API網關起到的就是API服務治理的作用溉委。
架構參考如下：
3鹃唯、對于公司內部公網應用（如APP、公司的網站）瓣喊，如果管理上比較細致坡慌，在架構上可能由獨立的API網關來處理這部分內部公網應用
如果想比較簡單的處理，也可以是使用面向合作伙伴的API網關藻三。
如果使用獨立的API網關洪橘，有以下的好處：
面向合作伙伴和面向公司主體業(yè)務的優(yōu)先級不一樣，不同的API網關可以做到業(yè)務影響的隔離趴酣。
內部API使用的管理流程和面向合作伙伴的管理流程可能不一樣。
內部的API在功能擴展等方面的需求一般會大于OpenAPI對于功能的要求坑夯。
基于以上的分析岖寞，如果公司有能力，那么還是建議分開使用合作伙伴OPEN API網關和內部公網應用網關柜蜈。
四仗谆、API網關有哪些競爭方案
1、對于Open API平臺的API網關淑履，我分析只能選擇API網關作為解決方案.
業(yè)界沒有發(fā)現比較好的可以用來作為Open API平臺的入口的其他方案隶垮。
2、對于作為微服務網關的API網關秘噪，業(yè)界的選擇可以選擇的解決方案比較多狸吞，也取決于微服務器的實現方案，有一些微服務架構的實現方案是不需要微服務網關的指煎。
(1)Service Mesh
這是新興的基于無API網關的架構蹋偏，通過在客戶端上的代理完成屏蔽網絡層的訪問，這樣達到對應用層最小的改動
當前Service Mesh的產品還正在開發(fā)中至壤，并沒有非常成熟可直接應用的產品威始。發(fā)展最迅速的產品是Istio。建議大家密切關注相關產品的研發(fā)像街、業(yè)務使用進展黎棠。
(2)基于duboo架構
在這個架構中通常是不需要網關的，是由客戶端直接訪問服務提供方镰绎，由注冊中心向客戶端返回服務方的地址脓斩。
五、API網關解決方案
公有云解決方案：
Amazon API Gateway：
https://aws.amazon.com/cn/api-gateway/
阿里云API網關：
https://www.aliyun.com/product/apigateway/
騰訊云API網關：
https://cloud.tencent.com/product/apigateway
自開發(fā)解決方案：
基于Nginx+Lua+ OpenResty的方案畴栖，可以看到Kong,orange都是基于這個方案
基于Netty俭厚、非阻塞IO模型。通過網上搜索可以看到國內的宜人貸等一些公司是基于這種方案驶臊，是一種成熟的方案挪挤。
基于Node.js的方案叼丑。這種方案是應用了Node.js天生的非阻塞的特性。
基于java Servlet的方案扛门。zuul基于的就是這種方案鸠信，這種方案的效率不高，這也是zuul總是被詬病的原因论寨。
六星立、企業(yè)怎么選擇API網關
如果要選擇一款已有的API網關，需要從以下幾個方面去考慮葬凳。
1绰垂、性能與可用性
如果一旦采用了API網關，那么API網關就會作為企業(yè)應用核心火焰，因此性能和可用性是必須要求的劲装。
從性能上來說，需要讓網關增加的時間消耗越短越好昌简，個人覺得需要10ms以下占业。
系統(tǒng)需要采用非阻塞的IO，如epoll纯赎，NIO等谦疾，網關和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統(tǒng)的高可用性犬金，如：Node.js的響應式編程和基于java體現的RxJava和Future念恍。
網關必須支持集群部署，任務一臺服務器的crash都應該不影響整體系統(tǒng)的可用性晚顷。
多套網關應該支持同一管理平臺和同一監(jiān)控中心樊诺。如：一個企業(yè)的OpenAPI網關和內部應用的多個系統(tǒng)群的不同的微服務網關可以在同一監(jiān)控中心進行監(jiān)控。
2音同、可擴展性词爬、可維護性
一款產品總有不能滿足生產需求的地方，因此需求思考產品在如何進行二次開發(fā)和維護权均，是否方便公司團隊接手維護產品顿膨。
3、需求匹配度
需要評估各API網關在需求上是否能滿足叽赊。
比如：如果是OpenAPI平臺需要使用API網關恋沃，那么需要看API網關在合作伙伴應用接入、合作伙伴門戶集成必指、訪問次數限額等OpenAPI核心需求上去思考產品是否能滿足要求囊咏。
如果是微服務網關，那么要從微服務的運維、監(jiān)控梅割、管理等方面去思考產品是否足夠強大霜第。
4、是否開源户辞？公司是否有自開發(fā)的能力泌类？
現有的開源產品如kong，zuul底燎，orange都有基礎的API網關的核心功能刃榨，這些開源產品大多離很好的使用有一定的距離
比如：沒有提供管理功能的UI界面、監(jiān)控功能弱小双仍，不支持OpenAPI平臺枢希，沒有公司運營與運維的功能等。
當然開源產品能獲取源代碼朱沃，如果公司有比較強的研發(fā)能力苞轿，能hold住這些開源產品，經過二次開發(fā)kong为流、zuul應該還是適應一些公司呕屎，不過需求注意以下一些點：
kong是基于ngnix+lua的让簿，從公司的角度比較難于找到能去維護這種架構產品的人敬察。需求評估當前公司是否有這個能力去維護這個產品。
zuul因為架構的原因在高并發(fā)的情況下性能不高尔当，同時需要去基于研究整合開源的適配zuul的監(jiān)控和管理系統(tǒng)莲祸。
orange由于沒有被大量使用，同時是國內個人在開源椭迎，在可持續(xù)性和社區(qū)資源上不夠豐富锐帜，出了問題后可能不容易找到人問。
另外kong提供企業(yè)版本的API網關畜号，當然也是基于ngnix+lua的缴阎，企業(yè)版本可以購買他們的技術支持、培訓等服務简软、以及擁有界面的管理蛮拔、監(jiān)控等功能。
5痹升、公有云還是私有云
現在的亞馬遜建炫、阿里、騰訊云都在提供基礎公有云的API網關疼蛾，當然這些網關的基礎功能肯定是沒有問題肛跌，但是二次開發(fā)，擴展功能、監(jiān)控功能可能就不能滿足部分用戶的定制需求了衍慎。
另外很多企業(yè)因為自身信息安全的原因转唉，不能使用外網公有網的API網關服務，這樣就只有選擇私有云的方案了西饵。
在需求上如果基于公有云的API網關只能做到由內部人員為外網人員申請應用酝掩，無法做到定制的合作伙伴門戶，這也不適合于部分企業(yè)的需求眷柔。
如果作為微服務網關期虾，大多數情況下是希望網關服務器和服務提供方服務器是要在內網的，在這里情況下也只有私有云的API網關才能滿足需求驯嘱。
綜合上面的分析镶苞，基礎公有云的API網關只有滿足一部分簡單客戶的需求，對于很多企業(yè)來說私有云的API網關才是正確的選擇鞠评。
