?一、API網關的用處
API網關我的分析中會用到以下三種場景，
1、Open API
企業需要將自身資料、能力等作為開發平臺向外開放，通常會以rest的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的QQ開發平臺、微信開放平臺，
Open API開放平臺必然涉及到客戶應用的接入、API權限的管理、呼叫次數管理等，必然會有一個統一的入口進行管理，這正是API網關可以發揮作用的時候，
2、微服務網關
微服務的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年后得到了大力發展，
在微服務架構中，有一個組件可以說是必不可少的，那就是微服務網關，微服務網關處理了負載均衡，快取，路由，訪問控制，服務代理，監控，日志等，
API 網關在微服務架構中正是以微服務網關的身份存在，
3、API服務管理平臺
上述的微服務架構對企業來說有可能實施上是困難的，企業有很多遺留系統，要全部抽取為微服務改動太大，對企業來說成本太高，
但是由于不同系統間存在大量的API服務互相呼叫，因此需要對系統間服務呼叫進行管理，清晰地看到各系統呼叫關系，對系統間呼叫進行監控等，
API網關可以解決這些問題，我們可以認為如果沒有大規模的實施微服務架構，那么對企業來說微服務網關就是企業的API服務管理平臺，
二、API網關在企業架構中的地位
一個企業隨著資訊系統復雜度的提高，必然出現外部合作伙伴應用、企業自身的公網應用、企業內網應用等，
在架構上應該將這三種應用區別開，三種應用的安排級別、訪問方式也不一樣，
因此在我的設計中將這三種應用分別用不同的網關進行API管理，分別是：API網關（OpenAPI合伙伙伴應用）、API網關（內部應用）、API網關（內部公網應用），
如下圖所示：
三、企業中如何應用API網關
1、對于OpenAPI使用的API網關來說，一般合作伙伴要以應用的形式接入到OpenAPI平臺，合作伙伴需要到 OpenAPI平臺申請應用，
因此在OpenAPI網關之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴，這就要求OpenAPI網關需要提供API給這個用戶平臺進行訪問，
如下架構:
當然如果是在簡單的場景下，可能并不需要提供一個面向合作伙伴的門戶，只需要由公司的運營人員直接添加合作伙伴應用id/密鑰等，這種情況下也就不需要合作伙伴門戶子系統，
2、對于內網的API網關，在起到的作用上來說可以認為是微服務網關，也可以認為是內網的API服務治理平臺，
當企業將所有的應用使用微服務的架構管理起來，那么API網關就起到了微服務網關的作用，
而當企業只是將系統與系統之間的呼叫使用rest api的方式進行訪問時使用API網關對呼叫進行管理，那么API網關起到的就是API服務治理的作用，
架構參考如下：
3、對于公司內部公網應用（如APP、公司的網站），如果管理上比較細致，在架構上可能由獨立的API網關來處理這部分內部公網應用，
如果想比較簡單的處理，也可以是使用面向合作伙伴的API網關，
如果使用獨立的API網關，有以下的好處：
-
面向合作伙伴和面向公司主體業務的優先級不一樣，不同的API網關可以做到業務影響的隔離，
-
內部API使用的管理流程和面向合作伙伴的管理流程可能不一樣，
-
內部的API在功能擴展等方面的需求一般會大于OpenAPI對于功能的要求，
基于以上的分析，如果公司有能力，那么還是建議分開使用合作伙伴OPEN API網關和內部公網應用網關，
四、API網關有哪些競爭方案
1、對于Open API平臺的API網關，我分析只能選擇API網關作為解決方案，
業界沒有發現比較好的可以用來作為Open API平臺的入口的其他方案，
2、對于作為微服務網關的API網關，業界的選擇可以選擇的解決方案比較多，也取決于微服務器的實作方案，有一些微服務架構的實作方案是不需要微服務網關的，
(1)Service Mesh
這是新興的基于無API網關的架構，通過在客戶端上的代理完成屏蔽網路層的訪問，這樣達到對應用層最小的改動，
當前Service Mesh的產品還正在開發中，并沒有非常成熟可直接應用的產品，發展最迅速的產品是Istio，建議大家密切關注相關產品的研發、業務使用進展，
(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
自開發解決方案：
基于Nginx+Lua+OpenResty的方案，可以看到Kong,orange都是基于這個方案
基于Netty、非阻塞IO模型，通過網上搜索可以看到國內的宜人貸等一些公司是基于這種方案，是一種成熟的方案，
基于Node.js的方案，這種方案是應用了Node.js天生的非阻塞的特性，
基于java Servlet的方案，zuul基于的就是這種方案，這種方案的效率不高，這也是zuul總是被詬病的原因，
六、企業怎么選擇API網關
如果要選擇一款已有的API網關，需要從以下幾個方面去考慮，
1、性能與可用性
如果一旦采用了API網關，那么API網關就會作為企業應用核心，因此性能和可用性是必須要求的，
從性能上來說，需要讓網關增加的時間消耗越短越好，個人覺得需要10ms以下，
系統需要采用非阻塞的IO，如epoll，NIO等，網關和各種依賴的互動也需要是非阻塞的，這樣才能保證整體系統的高可用性，如：Node.js的回應式編程和基于java體現的RxJava和Future，
網關必須支持集群部署，任務一臺服務器的crash都應該不影響整體系統的可用性，
多套網關應該支持同一管理平臺和同一監控中心，如：一個企業的OpenAPI網關和內部應用的多個系統群的不同的微服務網關可以在同一監控中心進行監控，
2、可擴展性、可維護性
一款產品總有不能滿足生產需求的地方，因此需求思考產品在如何進行二次開發和維護，是否方便公司團隊接手維護產品，
3、需求匹配度
需要評估各API網關在需求上是否能滿足，
比如：如果是OpenAPI平臺需要使用API網關，那么需要看API網關在合作伙伴應用接入、合作伙伴門戶集成、訪問次數限額等OpenAPI核心需求上去思考產品是否能滿足要求，
如果是微服務網關，那么要從微服務的運維、監控、管理等方面去思考產品是否足夠強大，
4、是否開源？公司是否有自開發的能力？
現有的開源產品如kong，zuul，orange都有基礎的API網關的核心功能，這些開源產品大多離很好的使用有一定的距離
比如：沒有提供管理功能的UI界面、監控功能弱小，不支持OpenAPI平臺，沒有公司運營與運維的功能等，
當然開源產品能獲取源代碼，如果公司有比較強的研發能力，能hold住這些開源產品，經過二次開發kong、zuul應該還是適應一些公司，不過需求注意以下一些點：
kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護這種架構產品的人，需求評估當前公司是否有這個能力去維護這個產品，
zuul因為架構的原因在高并發的情況下性能不高，同時需要去基于研究整合開源的適配zuul的監控和管理系統，
orange由于沒有被大量使用，同時是國內個人在開源，在可持續性和社區資源上不夠豐富，出了問題后可能不容易找到人問，
另外kong提供企業版本的API網關，當然也是基于ngnix+lua的，企業版本可以購買他們的技術支持、培訓等服務、以及擁有界面的管理、監控等功能，
5、公有云還是私有云
現在的亞馬遜、阿里、騰訊云都在提供基礎公有云的API網關，當然這些網關的基礎功能肯定是沒有問題，但是二次開發，擴展功能、監控功能可能就不能滿足部分用戶的定制需求了，
另外很多企業因為自身資訊安全的原因，不能使用外網公有網的API網關服務，這樣就只有選擇私有云的方案了，
在需求上如果基于公有云的API網關只能做到由內部人員為外網人員申請應用，無法做到定制的合作伙伴門戶，這也不適合于部分企業的需求，
如果作為微服務網關，大多數情況下是希望網關服務器和服務提供方服務器是要在內網的，在這里情況下也只有私有云的API網關才能滿足需求，
綜合上面的分析，基礎公有云的API網關只有滿足一部分簡單客戶的需求，對于很多企業來說私有云的API網關才是正確的選擇，
來源：https://www.cnblogs.com/coolfiry/p/8193768.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/26002.html
標籤：架構設計