[[407688]]

什么是網(wǎng)關(guān)

網(wǎng)關(guān)，很多地方將網(wǎng)關(guān)比如成門，沒什么問題，但是需要區(qū)分網(wǎng)關(guān)與網(wǎng)橋的區(qū)別。

網(wǎng)橋工作在數(shù)據(jù)鏈路層，在不同或相同類型的LAN之間存儲(chǔ)并轉(zhuǎn)發(fā)數(shù)據(jù)幀，必要時(shí)進(jìn)行鏈路層上的協(xié)議轉(zhuǎn)換。可連接兩個(gè)或多個(gè)網(wǎng)絡(luò)，在其中傳送信息包。

網(wǎng)關(guān)是一個(gè)大概念，不具體特指一類產(chǎn)品，只要連接兩個(gè)不同的網(wǎng)絡(luò)都可以叫網(wǎng)關(guān),網(wǎng)橋一般只轉(zhuǎn)發(fā)信息，而網(wǎng)關(guān)可能進(jìn)行包裝。

網(wǎng)關(guān)通俗理解

根據(jù)網(wǎng)關(guān)的特性，舉個(gè)例子：

假如你要去找集團(tuán)老板（這兒只是舉個(gè)例子），大家都知道老板肯定不是誰想見就能見的，也怕壞人嘛，那么你去老板所在的辦公樓，假如是集團(tuán)總部，大樓這個(gè)門就充當(dāng)了網(wǎng)關(guān)的角色，大門一般都有看門員，看門員會(huì)做哪些事情呢？

首先所有想見老板的人肯定都得從這個(gè)門進(jìn)（ 統(tǒng)一入口 ），這個(gè)門相當(dāng)于將辦公室和外界隔離了，主要為了保護(hù)里面的安全以及正常工作，來到這個(gè)門之后，門衛(wèi)肯定會(huì)讓你出示相關(guān)證件（ 鑒權(quán)檢驗(yàn) ），意思就是判斷你要見老板這個(gè)請(qǐng)求是否合理，如果不合理直接就拒絕了，讓你回家等消息，如果鑒權(quán)之后，發(fā)現(xiàn)你找老板其實(shí)只是為了和他談?wù)剝稍甑纳猓T衛(wèi)會(huì)跟你說這個(gè)用不著找老板，你去集團(tuán)投資部就行了（ 動(dòng)態(tài)路由 ，將請(qǐng)求路由到不同的后端集群中），此時(shí)會(huì)對(duì)你進(jìn)行一些 包裝 ，例如給你出具一個(gè)訪問證類似的，然后告訴你路該怎么走，等等。

你看看，網(wǎng)關(guān)的作用是不是就是這三個(gè)，最終目的就是減少你與集團(tuán)的耦合，具體到計(jì)算機(jī)上就是減少客戶端與服務(wù)端的耦合，如果沒有網(wǎng)關(guān)意味著所有請(qǐng)求都會(huì)直接調(diào)用服務(wù)器上的資源，這樣耦合太強(qiáng)了，服務(wù)器出了問題，客戶端會(huì)直接報(bào)錯(cuò)，例如老板換工作的地方了，如果沒有網(wǎng)關(guān)你直接去原來的地方找，肯定會(huì)被告知老板不在這兒。

為什么需要網(wǎng)關(guān)

當(dāng)使用單體應(yīng)用程序架構(gòu)時(shí)，客戶端（Web 或移動(dòng)端）通過向后端應(yīng)用程序發(fā)起一次 REST 調(diào)用來獲取數(shù)據(jù)。負(fù)載均衡器將請(qǐng)求路由給 N 個(gè)相同的應(yīng)用程序?qū)嵗械囊粋€(gè)。然后應(yīng)用程序會(huì)查詢各種數(shù)據(jù)庫表，并將響應(yīng)返回給客戶端。微服務(wù)架構(gòu)下，單體應(yīng)用被切割成多個(gè)微服務(wù)，如果將所有的微服務(wù)直接對(duì)外暴露，勢(shì)必會(huì)出現(xiàn)安全方面的各種問題，另外內(nèi)外耦合嚴(yán)重。

客戶端可以直接向每個(gè)微服務(wù)發(fā)送請(qǐng)求，其問題主要如下：

• 客戶端需求和每個(gè)微服務(wù)暴露的細(xì)粒度API不匹配。
• 部分服務(wù)使用的協(xié)議不是Web友好協(xié)議?？赡苁褂肨hrift 二進(jìn)制 RPC，也可能使用AMQP消息傳遞協(xié)議。
• 微服務(wù)難以重構(gòu)。如果合并兩個(gè)服務(wù)，或者將一個(gè)服務(wù)拆分成兩個(gè)或更多服務(wù)，這類重構(gòu)就非常困難了。

服務(wù)端的各個(gè)服務(wù)直接暴露給客戶端調(diào)用勢(shì)必會(huì)引起各種問題。同時(shí)，服務(wù)端的各個(gè)服務(wù)可擴(kuò)展和伸縮性很差。API 網(wǎng)關(guān)是微服務(wù)架構(gòu)中的基礎(chǔ)組件，位于接入層之下和業(yè)務(wù)服務(wù)層之上，如前所述的這些功能適合在 API 網(wǎng)關(guān)實(shí)現(xiàn)。

網(wǎng)關(guān)與服務(wù)器集群

回到我們服務(wù)器上，下面圖介紹了網(wǎng)關(guān)（Gateway）作用，可知Gateway方式下的架構(gòu)，可以細(xì)到為每一個(gè)服務(wù)的實(shí)例配置一個(gè)自己的Gateway，也可以粗到為一組服務(wù)配置一個(gè)，甚至可以粗到為整個(gè)架構(gòu)配置一個(gè)接入的Gateway。于是，整個(gè)系統(tǒng)架構(gòu)的復(fù)雜度就會(huì)變得簡(jiǎn)單可控起來。

這張圖展示了一個(gè)多層Gateway架構(gòu)，其中有一個(gè)總的Gateway接入所有的流量（ 流量網(wǎng)關(guān) ），并分發(fā)給不同的子系統(tǒng)，還有第二級(jí)Gateway用于做各個(gè)子系統(tǒng)的接入Gateway（ 業(yè)務(wù)網(wǎng)關(guān) ）?？梢钥吹?，網(wǎng)關(guān)所管理的服務(wù)粒度可粗可細(xì)。通過網(wǎng)關(guān)，我們可以把分布式架構(gòu)組織成一個(gè)星型架構(gòu)，由網(wǎng)絡(luò)對(duì)服務(wù)的請(qǐng)求進(jìn)行路由和分發(fā)。下面來聊聊好的網(wǎng)關(guān)應(yīng)該具備哪些功能，也就是網(wǎng)關(guān)設(shè)計(jì)模式。

網(wǎng)關(guān)設(shè)計(jì)思路

一個(gè)網(wǎng)關(guān)需要有以下的功能：

請(qǐng)求路由

網(wǎng)關(guān)一定要有請(qǐng)求路由的功能。這樣一來，對(duì)于調(diào)用端來說，也是一件非常方便的事情。因?yàn)檎{(diào)用端不需要知道自己需要用到的其它服務(wù)的地址，全部統(tǒng)一地交給Gateway來處理。

服務(wù)注冊(cè)

為了能夠代理后面的服務(wù)，并把請(qǐng)求路由到正確的位置上，網(wǎng)關(guān)應(yīng)該有服務(wù)注冊(cè)功能，也就是后端的服務(wù)實(shí)例可以把其提供服務(wù)的地址注冊(cè)、取消注冊(cè)。一般來說，注冊(cè)也就是注冊(cè)一些API接口。比如，HTTP的Restful請(qǐng)求，可以注冊(cè)相應(yīng)API的URI、方法、HTTP頭。 這樣，Gateway就可以根據(jù)接收到的請(qǐng)求中的信息來決定路由到哪一個(gè)后端的服務(wù)上。

負(fù)載均衡

因?yàn)橐粋€(gè)網(wǎng)關(guān)可以接收多個(gè)服務(wù)實(shí)例，所以網(wǎng)關(guān)還需要在各個(gè)對(duì)等的服務(wù)實(shí)例上做負(fù)載均衡策略。簡(jiǎn)單點(diǎn)就是直接Round-Robin輪詢，復(fù)雜點(diǎn)的可以設(shè)置上權(quán)重進(jìn)行分發(fā)，再?gòu)?fù)雜一點(diǎn)還可以做到session粘連。

彈力設(shè)計(jì)

網(wǎng)關(guān)還可以把彈力設(shè)計(jì)中的那些異步、重試、冪等、流控、熔斷、監(jiān)視等都可以實(shí)現(xiàn)進(jìn)去。這樣，同樣可以像Service Mesh那樣，讓應(yīng)用服務(wù)只關(guān)心自己的業(yè)務(wù)邏輯（或是說數(shù)據(jù)面上的事）而不是控制邏輯（控制面）。

安全方面

SSL加密及證書管理、Session驗(yàn)證、授權(quán)、數(shù)據(jù)校驗(yàn)，以及對(duì)請(qǐng)求源進(jìn)行惡意攻擊的防范。錯(cuò)誤處理越靠前的位置就是越好，所以，網(wǎng)關(guān)可以做到一個(gè)全站的接入組件來對(duì)后端的服務(wù)進(jìn)行保護(hù)。當(dāng)然，網(wǎng)關(guān)還可以做更多更有趣的事情，比如：灰度發(fā)布、API聚合、API編排。

灰度發(fā)布

網(wǎng)關(guān)完全可以做到對(duì)相同服務(wù)不同版本的實(shí)例進(jìn)行導(dǎo)流，還可以收集相關(guān)的數(shù)據(jù)。這樣對(duì)于軟件質(zhì)量的提升，甚至產(chǎn)品試錯(cuò)都有非常積極的意義。

API 聚合

使用網(wǎng)關(guān)可以將多個(gè)單獨(dú)請(qǐng)求聚合成一個(gè)請(qǐng)求。在微服務(wù)體系的架構(gòu)中，因?yàn)榉?wù)變小了，所以一個(gè)明顯的問題是，客戶端可能需要多次請(qǐng)求才能得到所有的數(shù)據(jù)。這樣一來，客戶端與后端之間的頻繁通信會(huì)對(duì)應(yīng)用程序的性能和規(guī)模產(chǎn)生非常不利的影響。于是，我們可以讓網(wǎng)關(guān)來幫客戶端請(qǐng)求多個(gè)后端的服務(wù)（有些場(chǎng)景下完全可以并發(fā)請(qǐng)求），然后把后端服務(wù)的響應(yīng)結(jié)果拼裝起來，回傳給客戶端（當(dāng)然，這個(gè)過程也可以做成異步的，但這需要客戶端的配合）。

API編排

同樣在微服務(wù)的架構(gòu)下，要走完一個(gè)完整的業(yè)務(wù)流程，我們需要調(diào)用一系列API，就像一種工作流一樣，這個(gè)事完全可以通過網(wǎng)頁來編排這個(gè)業(yè)務(wù)流程。我們可能通過一個(gè)DSL來定義和編排不同的API，也可以通過像AWS Lambda服務(wù)那樣的方式來串聯(lián)不同的API。

網(wǎng)關(guān)設(shè)計(jì)重點(diǎn)

網(wǎng)關(guān)設(shè)計(jì)重點(diǎn)主要是三個(gè)：

高性能

在技術(shù)設(shè)計(jì)上，網(wǎng)關(guān)不應(yīng)該也不能成為性能的瓶頸。對(duì)于高性能，最好使用高性能的編程語言來實(shí)現(xiàn)，如C、C++、Go和Java。網(wǎng)關(guān)對(duì)后端的請(qǐng)求，以及對(duì)前端的請(qǐng)求的服務(wù)一定要使用異步非阻塞的I/O來確保后端延遲不會(huì)導(dǎo)致應(yīng)用程序中出現(xiàn)性能問題。C和C++可以參看Linux下的epoll和Windows的I/O Completion Port的異步IO模型，Java下如Netty、Spring Reactor的NIO框架。

高可用

因?yàn)樗械牧髁炕蛘{(diào)用經(jīng)過網(wǎng)關(guān)，所以網(wǎng)關(guān)必須成為一個(gè)高可用的技術(shù)組件，它的穩(wěn)定直接關(guān)系到了所有服務(wù)的穩(wěn)定。網(wǎng)關(guān)如果沒有設(shè)計(jì)，就會(huì)成變一個(gè)單點(diǎn)故障。因此，一個(gè)好的網(wǎng)關(guān)至少要做到以下幾點(diǎn)。

• 集群化 。網(wǎng)關(guān)要成為一個(gè)集群，其最好可以自己組成一個(gè)集群，并可以自己同步集群數(shù)據(jù)，而不需要依賴于一個(gè)第三方系統(tǒng)來同步數(shù)據(jù)。
• 服務(wù)化 。網(wǎng)關(guān)還需要做到在不間斷的情況下修改配置，一種是像Nginx reload配置那樣，可以做到不停服務(wù)，另一種是最好做到服務(wù)化。也就是說，得要有自己的Admin API來在運(yùn)行時(shí)修改自己的配置。
• 持續(xù)化 。比如重啟，就是像Nginx那樣優(yōu)雅地重啟。有一個(gè)主管請(qǐng)求分發(fā)的主進(jìn)程。當(dāng)我們需要重啟時(shí)，新的請(qǐng)求被分配到新的進(jìn)程中，而老的進(jìn)程處理完正在處理的請(qǐng)求后就退出。

高擴(kuò)展

因?yàn)榫W(wǎng)關(guān)需要承接所有的業(yè)務(wù)流量和請(qǐng)求，所以一定會(huì)有或多或少的業(yè)務(wù)邏輯。而我們都知道，業(yè)務(wù)邏輯是多變和不確定的。比如，需要在網(wǎng)關(guān)上加入一些和業(yè)務(wù)相關(guān)的東西。因此，一個(gè)好的Gateway還需要是可以擴(kuò)展的，并能進(jìn)行二次開發(fā)的。當(dāng)然，像Nginx那樣通過 Module 進(jìn)行二次開發(fā)的固然可以。

另外，在 運(yùn)維方面 ，網(wǎng)關(guān)應(yīng)該有以下幾個(gè)設(shè)計(jì)原則。

• 業(yè)務(wù)松耦合，協(xié)議緊耦合 。在業(yè)務(wù)設(shè)計(jì)上，網(wǎng)關(guān)不應(yīng)與后面的服務(wù)之間形成服務(wù)耦合，也不應(yīng)該有業(yè)務(wù)邏輯。網(wǎng)關(guān)應(yīng)該是在網(wǎng)絡(luò)應(yīng)用層上的組件，不應(yīng)該處理通訊協(xié)議體，只應(yīng)該解析和處理通訊協(xié)議頭。另外，除了服務(wù)發(fā)現(xiàn)外，網(wǎng)關(guān)不應(yīng)該有第三方服務(wù)的依賴。
• 應(yīng)用監(jiān)視，提供分析數(shù)據(jù) 。網(wǎng)關(guān)上需要考慮應(yīng)用性能的監(jiān)控，除了有相應(yīng)后端服務(wù)的高可用的統(tǒng)計(jì)之外，還需要使用Tracing ID實(shí)施分布式鏈路跟蹤，并統(tǒng)計(jì)好一定時(shí)間內(nèi)每個(gè)API的吞吐量、響應(yīng)時(shí)間和返回碼，以便啟動(dòng)彈力設(shè)計(jì)中的相應(yīng)策略。
• 用彈力設(shè)計(jì)保護(hù)后端服務(wù) 。網(wǎng)關(guān)上一定要實(shí)現(xiàn)熔斷、限流、重試和超時(shí)等彈力設(shè)計(jì)。如果一個(gè)或多個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)間過長(zhǎng)，那么可接受超時(shí)并返回一部分?jǐn)?shù)據(jù)，或是返回一個(gè)網(wǎng)關(guān)里的緩存的上一次成功請(qǐng)求的數(shù)據(jù)。你可以考慮一下這樣的設(shè)計(jì)。
• DevOps 。因?yàn)榫W(wǎng)關(guān)這個(gè)組件太關(guān)鍵了，所以需要DevOps這樣的東西，將其發(fā)生故障的概率降到最低。這個(gè)軟件需要經(jīng)過精良的測(cè)試，包括功能和性能的測(cè)試，還有浸泡測(cè)試。還需要有一系列自動(dòng)化運(yùn)維的管控工具。

網(wǎng)關(guān)設(shè)計(jì)注意事項(xiàng)

1. 不要在網(wǎng)關(guān)中的代碼里內(nèi)置聚合后端服務(wù)的功能，而應(yīng)考慮將聚合服務(wù)放在網(wǎng)關(guān)核心代碼之外。可以使用Plugin的方式，也可以放在網(wǎng)關(guān)后面形成一個(gè)Serverless服務(wù)。
2. 網(wǎng)關(guān)應(yīng)該靠近后端服務(wù)，并和后端服務(wù)使用同一個(gè)內(nèi)網(wǎng)，這樣可以保證網(wǎng)關(guān)和后端服務(wù)調(diào)用的低延遲，并可以減少很多網(wǎng)絡(luò)上的問題。這里多說一句，網(wǎng)關(guān)處理的靜態(tài)內(nèi)容應(yīng)該靠近用戶（應(yīng)該放到CDN上），而網(wǎng)關(guān)和此時(shí)的動(dòng)態(tài)服務(wù)應(yīng)該靠近后端服務(wù)。
3. 網(wǎng)關(guān)也需要做容量擴(kuò)展，所以需要成為一個(gè)集群來分擔(dān)前端帶來的流量。這一點(diǎn)，要么通過DNS輪詢的方式實(shí)現(xiàn)，要么通過CDN來做流量調(diào)度，或者通過更為底層的性能更高的負(fù)載均衡設(shè)備。
4. 對(duì)于服務(wù)發(fā)現(xiàn)，可以做一個(gè)時(shí)間不長(zhǎng)的緩存，這樣不需要每次請(qǐng)求都去查一下相關(guān)的服務(wù)所在的地方。當(dāng)然，如果你的系統(tǒng)不復(fù)雜，可以考慮把服務(wù)發(fā)現(xiàn)的功能直接集成進(jìn)網(wǎng)關(guān)中。
5. 為網(wǎng)關(guān)考慮bulkhead設(shè)計(jì)方式。用不同的網(wǎng)關(guān)服務(wù)不同的后端服務(wù)，或是用不同的網(wǎng)關(guān)服務(wù)前端不同的客戶。

另外，因?yàn)榫W(wǎng)關(guān)是為用戶請(qǐng)求和后端服務(wù)的橋接裝置，所以需要考慮一些安全方面的事宜。具體如下：

1. 加密數(shù)據(jù) ?？梢园裇SL相關(guān)的證書放到網(wǎng)關(guān)上，由網(wǎng)關(guān)做統(tǒng)一的SSL傳輸管理。
2. 校驗(yàn)用戶的請(qǐng)求 。一些基本的用戶驗(yàn)證可以放在網(wǎng)關(guān)上來做，比如用戶是否已登錄，用戶請(qǐng)求中的token是否合法等。但是，我們需要權(quán)衡一下，網(wǎng)關(guān)是否需要校驗(yàn)用戶的輸入。因?yàn)檫@樣一來，網(wǎng)關(guān)就需要從只關(guān)心協(xié)議頭，到需要關(guān)心協(xié)議體。而協(xié)議體中的東西一方面不像協(xié)議頭是標(biāo)準(zhǔn)的，另一方面解析協(xié)議體還要耗費(fèi)大量的運(yùn)行時(shí)間，從而降低網(wǎng)關(guān)的性能。對(duì)此，我想說的是，看具體需求，一方面如果協(xié)議體是標(biāo)準(zhǔn)的，那么可以干；另一方面，對(duì)于解析協(xié)議所帶來的性能問題，需要做相應(yīng)的隔離。
3. 檢測(cè)異常訪問 。網(wǎng)關(guān)需要檢測(cè)一些異常訪問，比如，在一段比較短的時(shí)間內(nèi)請(qǐng)求次數(shù)超過一定數(shù)值；還比如，同一客戶端的4xx請(qǐng)求出錯(cuò)率太高……對(duì)于這樣的一些請(qǐng)求訪問，網(wǎng)關(guān)一方面要把這樣的請(qǐng)求屏蔽掉，另一方面需要發(fā)出警告，有可能會(huì)是一些比較重大的安全問題，如被黑客攻擊。

流量網(wǎng)關(guān)

流量網(wǎng)關(guān)，顧名思義就是控制流量進(jìn)入集群的網(wǎng)關(guān)，有很多工作需要在這一步做，對(duì)于一個(gè)服務(wù)集群，勢(shì)必有很多非法的請(qǐng)求或者無效的請(qǐng)求，這時(shí)候要將請(qǐng)求拒之門外，降低集群的流量壓力。

定義全局性的、跟具體的后端業(yè)務(wù)應(yīng)用和服務(wù)完全無關(guān)的策略網(wǎng)關(guān)就是上圖所示的架構(gòu)模型——流量網(wǎng)關(guān)。流量網(wǎng)關(guān)通常只專注于全局的API管理策略，比如全局流量監(jiān)控、日志記錄、全局限流、黑白名單控制、接入請(qǐng)求到業(yè)務(wù)系統(tǒng)的負(fù)載均衡等，有點(diǎn)類似防火墻。 Kong就是典型的流量網(wǎng)關(guān)。

下面是Kong的架構(gòu)圖，來自官網(wǎng)： https://konghq.com/

這里需要補(bǔ)充一點(diǎn)的是，業(yè)務(wù)網(wǎng)關(guān)一般部署在流量網(wǎng)關(guān)之后、業(yè)務(wù)系統(tǒng)之前，比流量網(wǎng)關(guān)更靠近業(yè)務(wù)系統(tǒng)。通常API網(wǎng)指的是業(yè)務(wù)網(wǎng)關(guān)。 有時(shí)候我們也會(huì)模糊流量網(wǎng)關(guān)和業(yè)務(wù)網(wǎng)關(guān)，讓一個(gè)網(wǎng)關(guān)承擔(dān)所有的工作，所以這兩者之間并沒有嚴(yán)格的界線。

業(yè)務(wù)網(wǎng)關(guān)

當(dāng)一個(gè)單體應(yīng)用被拆分成許許多多的微服務(wù)應(yīng)用后，也帶來了一些問題。一些與業(yè)務(wù)非強(qiáng)相關(guān)的功能，比如權(quán)限控制、日志輸出、數(shù)據(jù)加密、熔斷限流等，每個(gè)微服務(wù)應(yīng)用都需要，因此存在著大量重復(fù)的代碼實(shí)現(xiàn)。而且由于系統(tǒng)的迭代、人員的更替，各個(gè)微服務(wù)中這些功能的實(shí)現(xiàn)細(xì)節(jié)出現(xiàn)了較大的差異，導(dǎo)致維護(hù)成本變高。另一方面，原先單體應(yīng)用下非常容易做的接口管理，在服務(wù)拆分后沒有了一個(gè)集中管理的地方，無法統(tǒng)計(jì)已存在哪些接口、接口定義是什么、運(yùn)行狀態(tài)如何。

網(wǎng)關(guān)就是為了解決上述問題。作為微服務(wù)體系中的核心基礎(chǔ)設(shè)施，一般需要具備接口管理、協(xié)議適配、熔斷限流、安全防護(hù)等功能，各種開源的網(wǎng)關(guān)產(chǎn)品（比如 Zuul）都提供了優(yōu)秀高可擴(kuò)展性的架構(gòu)、可以很方便的實(shí)現(xiàn)我們需要的一些功能、比如鑒權(quán)、日志監(jiān)控、熔斷限流等。

與流量網(wǎng)關(guān)相對(duì)應(yīng)的就是業(yè)務(wù)網(wǎng)關(guān),業(yè)務(wù)網(wǎng)關(guān)更靠近我們的業(yè)務(wù),也就是與服務(wù)器應(yīng)用層打交道,那么有很多應(yīng)用層需要考慮的事情就可以依托業(yè)務(wù)網(wǎng)關(guān),例如在線程模型、協(xié)議適配、熔斷限流，服務(wù)編排等。

業(yè)務(wù)網(wǎng)關(guān)主要職責(zé)以及所做的事情，目前業(yè)務(wù)網(wǎng)關(guān)比較成熟的API網(wǎng)關(guān)框架產(chǎn)品有三個(gè)，分別是：Zuul 1、Zuul 2和Spring Cloud Gateway后面再進(jìn)行對(duì)比。

常見網(wǎng)關(guān)對(duì)比

既然對(duì)比，就先宏觀上對(duì)各種網(wǎng)關(guān)有一個(gè)了解，后面再挑一些常用的或者說應(yīng)用廣泛的詳細(xì)了解。

目前常見的開源網(wǎng)關(guān)大致上按照語言分類有如下幾類：

• Nginx+Lua：OpenResty、Kong、Orange、Abtesting gateway等
• Java：Zuul/Zuul 2、Spring Cloud Gateway、Kaazing KWG、Gravitee、Dromara soul等
• Go：Janus、fagongzi、Grpc-gateway
• Dotnet：Ocelot
• NodeJS：Express Gateway、Micro Gateway

按照使用數(shù)量、成熟度等來劃分，主流的有4個(gè)：

• OpenResty
• Kong
• Zuul/Zuul 2
• Spring Cloud Gateway

OpenResty

相關(guān)連接：

• 官網(wǎng)： https://openresty.org/cn/
• B站： https://space.bilibili.com/457424101
• GitHub： https://github.com/openresty/

OpenResty是一個(gè)流量網(wǎng)關(guān)，根據(jù)前面對(duì)流量網(wǎng)關(guān)的介紹就可以知道流量網(wǎng)關(guān)的職責(zé)。

OpenResty基于 Nginx 與Lua的高性能Web平臺(tái)，其內(nèi)部集成了大量精良的Lua庫、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動(dòng)態(tài)Web應(yīng)用、Web服務(wù)和動(dòng)態(tài)網(wǎng)關(guān)。

通過揉和眾多設(shè)計(jì)良好的Nginx模塊，OpenResty有效地把Nginx服務(wù)器轉(zhuǎn)變?yōu)橐粋€(gè)強(qiáng)大的Web應(yīng)用服務(wù)器，基于它開發(fā)人員可以使用Lua編程語言對(duì)Nginx核心以及現(xiàn)有的各種Nginx C模塊進(jìn)行腳本編程，構(gòu)建出可以處理一萬以上并發(fā)請(qǐng)求的極端高性能的Web應(yīng)用。

OpenResty最早是順應(yīng)OpenAPI的潮流做的，所以O(shè)pen取自“開放”之意，而Resty便是REST風(fēng)格的意思。雖然后來也可以基于ngx_openresty實(shí)現(xiàn)任何形式的Web service或者傳統(tǒng)的Web應(yīng)用。

也就是說Nginx不再是一個(gè)簡(jiǎn)單的靜態(tài)網(wǎng)頁服務(wù)器，也不再是一個(gè)簡(jiǎn)單的反向代理了。第二代的OpenResty致力于通過一系列Nginx模塊，把Nginx擴(kuò)展為全功能的Web應(yīng)用服務(wù)器。

ngx_openresty是用戶驅(qū)動(dòng)的項(xiàng)目，后來也有不少國(guó)內(nèi)用戶的參與，從openresty.org的點(diǎn)擊量分布上看，國(guó)內(nèi)和國(guó)外的點(diǎn)擊量基本持平。

ngx_openresty 目前有兩大應(yīng)用目標(biāo)：

1. 通用目的的Web應(yīng)用服務(wù)器。在這個(gè)目標(biāo)下，現(xiàn)有的Web應(yīng)用技術(shù)都可以算是和OpenResty或多或少有些類似，比如Nodejs，PHP等等。ngx_openresty的性能（包括內(nèi)存使用和CPU效率）算是最大的賣點(diǎn)之一。
2. Nginx的腳本擴(kuò)展編程，用于構(gòu)建靈活的Web應(yīng)用網(wǎng)關(guān)和Web應(yīng)用防火墻。有些類似的是NetScaler。其優(yōu)勢(shì)在于Lua編程帶來的巨大靈活性。

Kong

相關(guān)連接：

• 官網(wǎng)： https://konghq.com/
• GitHub： https://github.com/Kong/

Kong基于OpenResty開發(fā)，也是流量層網(wǎng)關(guān), 是一個(gè)云原生、快速、可擴(kuò)展、分布式的Api 網(wǎng)關(guān)。繼承了OpenResty的高性能、易擴(kuò)展性等特點(diǎn)。Kong通過簡(jiǎn)單的增加機(jī)器節(jié)點(diǎn)，可以很容易的水平擴(kuò)展。同時(shí)功能插件化，可通過插件來擴(kuò)展其能力。而且在任何基礎(chǔ)架構(gòu)上都可以運(yùn)行。具有以下特性：

• 提供了多樣化的認(rèn)證層來保護(hù)API。
• 可對(duì)出入流量進(jìn)行管制。
• 提供了可視化的流量檢查、監(jiān)視分析API。
• 能夠及時(shí)的轉(zhuǎn)換請(qǐng)求和相應(yīng)。
• 提供log解決方案
• 可通過API調(diào)用Serverless 函數(shù)。

Kong解決了什么問題

當(dāng)我們決定對(duì)應(yīng)用進(jìn)行微服務(wù)改造時(shí)，應(yīng)用客戶端如何與微服務(wù)交互的問題也隨之而來，畢竟服務(wù)數(shù)量的增加會(huì)直接導(dǎo)致部署授權(quán)、負(fù)載均衡、通信管理、分析和改變的難度增加。

面對(duì)以上問題，API Gateway是一個(gè)不錯(cuò)的解決方案，其所提供的訪問限制、安全、流量控制、分析監(jiān)控、日志、請(qǐng)求轉(zhuǎn)發(fā)、合成和協(xié)議轉(zhuǎn)換功能，可以解放開發(fā)者去把精力集中在具體邏輯的代碼，而不是把時(shí)間花費(fèi)在考慮如何解決應(yīng)用和其他微服務(wù)鏈接的問題上。

圖片來自Kong官網(wǎng)：

可以看到Kong解決的問題。專注于全局的API管理策略，全局流量監(jiān)控、日志記錄、全局限流、黑白名單控制、接入請(qǐng)求到業(yè)務(wù)系統(tǒng)的負(fù)載均衡等。

Kong的優(yōu)點(diǎn)以及性能

在眾多API Gateway框架中，Mashape開源的高性能高可用API網(wǎng)關(guān)和API服務(wù)管理層——Kong（基于Nginx+Lua）特點(diǎn)尤為突出，它可以通過插件擴(kuò)展已有功能，這些插件（使用Lua編寫）在API請(qǐng)求響應(yīng)循環(huán)的生命周期中被執(zhí)行。于此同時(shí)，Kong本身提供包括HTTP基本認(rèn)證、密鑰認(rèn)證、CORS、TCP、UDP、文件日志、API請(qǐng)求限流、請(qǐng)求轉(zhuǎn)發(fā)及Nginx監(jiān)控等基本功能。目前，Kong在Mashape管理了超過15,000個(gè)API，為200,000開發(fā)者提供了每月數(shù)十億的請(qǐng)求支持。

Kong架構(gòu)

Kong提供一些列的服務(wù)，這就不得不談?wù)剝?nèi)部的架構(gòu)：

首先最底層是基于Nginx，Nginx是高性能的基礎(chǔ)層，一個(gè)良好的負(fù)載均衡、反向代理器，然后在此基礎(chǔ)上增加Lua腳本庫，形成了OpenResty，攔截請(qǐng)求，響應(yīng)生命周期，可以通過Lua編寫腳本，所以插件比較豐富。

關(guān)于Kong的一些插件庫以及如何配置，可以參考簡(jiǎn)書： https://www.jianshu.com/p/a68e45bcadb6

Zuul 1.0

Zuul是所有從設(shè)備和Web站點(diǎn)到Netflix流媒體應(yīng)用程序后端請(qǐng)求的前門。作為一個(gè)邊緣服務(wù)應(yīng)用程序，Zuul被構(gòu)建來支持動(dòng)態(tài)路由、監(jiān)視、彈性和安全性。它還可以根據(jù)需要將請(qǐng)求路由到多個(gè)Amazon自動(dòng)伸縮組。

Zuul使用了一系列不同類型的過濾器，使我們能夠快速靈活地將功能應(yīng)用到服務(wù)中。

過濾器

過濾器是Zuul的核心功能。它們負(fù)責(zé)應(yīng)用程序的業(yè)務(wù)邏輯，可以執(zhí)行各種任務(wù)。

• Type ：通常定義過濾器應(yīng)用在哪個(gè)階段
• Async ：定義過濾器是同步還是異步
• Execution Order ：執(zhí)行順序
• Criteria ：過濾器執(zhí)行的條件
• Action ：如果條件滿足，過濾器執(zhí)行的動(dòng)作

Zuul提供了一個(gè)動(dòng)態(tài)讀取、編譯和運(yùn)行這些過濾器的框架。過濾器之間不直接通信，而是通過每個(gè)請(qǐng)求特有的RequestContext共享狀態(tài)。

下面是Zuul的一些過濾器：

Incoming

Incoming過濾器在請(qǐng)求被代理到Origin之前執(zhí)行。這通常是執(zhí)行大部分業(yè)務(wù)邏輯的地方。例如:認(rèn)證、動(dòng)態(tài)路由、速率限制、DDoS保護(hù)、指標(biāo)。

Endpoint

Endpoint過濾器負(fù)責(zé)基于incoming過濾器的執(zhí)行來處理請(qǐng)求。Zuul有一個(gè)內(nèi)置的過濾器（ProxyEndpoint），用于將請(qǐng)求代理到后端服務(wù)器，因此這些過濾器的典型用途是用于靜態(tài)端點(diǎn)。例如:健康檢查響應(yīng)，靜態(tài)錯(cuò)誤響應(yīng)，404響應(yīng)。

Outgoing

Outgoing過濾器在從后端接收到響應(yīng)以后執(zhí)行處理操作。通常情況下，它們更多地用于形成響應(yīng)和添加指標(biāo)，而不是用于任何繁重的工作。例如:存儲(chǔ)統(tǒng)計(jì)信息、添加/剝離標(biāo)準(zhǔn)標(biāo)題、向?qū)崟r(shí)流發(fā)送事件、gziping響應(yīng)。

過濾器類型

下面是與一個(gè)請(qǐng)求典型的生命周期對(duì)應(yīng)的標(biāo)準(zhǔn)的過濾器類型：

• PRE ：路由到Origin之前執(zhí)行
• ROUTING ：路由到Origin期間執(zhí)行
• POST ：請(qǐng)求被路由到Origin之后執(zhí)行
• ERROR ：發(fā)生錯(cuò)誤的時(shí)候執(zhí)行

這些過濾器幫助我們執(zhí)行以下功能：

• 身份驗(yàn)證和安全性 ：識(shí)別每個(gè)資源的身份驗(yàn)證需求，并拒絕不滿足它們的請(qǐng)求
• 監(jiān)控 ：在邊緣跟蹤有意義的數(shù)據(jù)和統(tǒng)計(jì)數(shù)據(jù)，以便給我們一個(gè)準(zhǔn)確的生產(chǎn)視圖
• 動(dòng)態(tài)路由 ：動(dòng)態(tài)路由請(qǐng)求到不同的后端集群
• 壓力測(cè)試 ：逐漸增加集群的流量，以評(píng)估性能
• 限流 ：為每種請(qǐng)求類型分配容量，并丟棄超過限制的請(qǐng)求
• 靜態(tài)響應(yīng)處理 ：直接在邊緣構(gòu)建一些響應(yīng)，而不是將它們轉(zhuǎn)發(fā)到內(nèi)部集群

Zuul 1.0 請(qǐng)求生命周期

Netflix宣布了通用API網(wǎng)關(guān)Zuul的架構(gòu)轉(zhuǎn)型。Zuul原本采用同步阻塞架構(gòu)，轉(zhuǎn)型后叫作Zuul 2，采用異步非阻塞架構(gòu)。Zuul 2和Zuul 1在架構(gòu)方面的主要區(qū)別在于，Zuul 2運(yùn)行在異步非阻塞的框架上，比如Netty。Zuul 1依賴多線程來支持吞吐量的增長(zhǎng)，而Zuul 2使用的Netty框架依賴事件循環(huán)和回調(diào)函數(shù)。

Zuul 2.0

Zuul 2.0架構(gòu)圖：

上圖是Zuul2的架構(gòu)，和Zuul 1沒有本質(zhì)區(qū)別，兩點(diǎn)變化：

• 前端用Netty Server代替Servlet，目的是支持前端異步。后端用Netty Client代替Http Client，目的是支持后端異步。
• 過濾器換了一下名字，用Inbound Filters代替Pre-routing Filters，用Endpoint Filter代替Routing Filter，用Outbound Filters代替Post-routing Filters。
  
  • Inbound Filters ：路由到Origin之前執(zhí)行，可以用于身份驗(yàn)證、路由和裝飾請(qǐng)求
  • Endpoint Filters ：可用于返回靜態(tài)響應(yīng)，否則內(nèi)置的ProxyEndpoint過濾器將請(qǐng)求路由到Origin
  • Outbound Filters ：從Origin那里獲取響應(yīng)后執(zhí)行，可以用于度量、裝飾用戶的響應(yīng)或添加自定義header

有兩種類型的過濾器：sync和async。因?yàn)閆uul是運(yùn)行在一個(gè)事件循環(huán)之上的，因此從來不要在過濾中阻塞。如果你非要阻塞，可以在一個(gè)異步過濾器中這樣做，并且在一個(gè)單獨(dú)的線程池上運(yùn)行，否則可以使用同步過濾器。

上文提到過 Zuul 2開始采用了異步模型 。

優(yōu)勢(shì)是異步非阻塞模式啟動(dòng)的線程很少，基本上一個(gè)CPU core上只需啟一個(gè)事件環(huán)處理線程，它使用的線程資源就很少，上下文切換（Context Switch）開銷也少。非阻塞模式可以接受的連接數(shù)大大增加，可以簡(jiǎn)單理解為請(qǐng)求來了只需要進(jìn)隊(duì)列，這個(gè)隊(duì)列的容量可以設(shè)得很大，只要不超時(shí)，隊(duì)列中的請(qǐng)求都會(huì)被依次處理。

不足是異步模式讓編程模型變得復(fù)雜。一方面Zuul 2本身的代碼要比Zuul 1復(fù)雜很多，Zuul 1的代碼比較容易看懂，Zuul 2的代碼看起來就比較費(fèi)勁。另一方面異步模型沒有一個(gè)明確清晰的請(qǐng)求->處理->響應(yīng)執(zhí)行流程（call flow），它的流程是通過事件觸發(fā)的，請(qǐng)求處理的流程隨時(shí)可能被切換斷開，內(nèi)部實(shí)現(xiàn)要通過一些關(guān)聯(lián)id機(jī)制才能把整個(gè)執(zhí)行流再串聯(lián)起來，這就給開發(fā)調(diào)試運(yùn)維引入了很多復(fù)雜性，比如你在IDE里頭調(diào)試異步請(qǐng)求流就非常困難。另外ThreadLocal機(jī)制在這種異步模式下就不能簡(jiǎn)單工作，因?yàn)橹挥幸粋€(gè)事件環(huán)線程，不是每個(gè)請(qǐng)求一個(gè)線程，也就沒有線程局部的概念，所以對(duì)于CAT這種依賴于ThreadLocal才能工作的監(jiān)控工具，調(diào)用鏈埋點(diǎn)就不好搞（實(shí)際可以工作但需要進(jìn)行特殊處理）。

總體上，異步非阻塞模式比較適用于IO密集型（IO bound）場(chǎng)景，這種場(chǎng)景下系統(tǒng)大部分時(shí)間在處理IO，CPU計(jì)算比較輕，少量事件環(huán)線程就能處理。

Zuul與Zuul 2性能對(duì)比

圖片來源： https://www.slideshare.net/art ... cking

Netflix給出了一個(gè)比較模糊的數(shù)據(jù)， 大致Zuul 2的性能比Zuul 1好20%左右 ，這里的性能主要指每節(jié)點(diǎn)每秒處理的請(qǐng)求數(shù)。為什么說模糊呢？因?yàn)檫@個(gè)數(shù)據(jù)受實(shí)際測(cè)試環(huán)境，流量場(chǎng)景模式等眾多因素影響，你很難復(fù)現(xiàn)這個(gè)測(cè)試數(shù)據(jù)。即便這個(gè)20%的性能提升是確實(shí)的，其實(shí)這個(gè)性能提升也并不大，和異步引入的復(fù)雜性相比，這20%的提升是否值得是個(gè)問題。Netflix本身在其博文22和ppt11中也是有點(diǎn)含糊其詞，甚至自身都有一些疑問的。

Spring Cloud Gateway

相關(guān)鏈接：

• 官網(wǎng)： https://spring.io/projects/spring-cloud-gateway
• 中文官方文檔： https://cloud.tencent.com/deve ... 03887

Spring Cloud Gateway是Spring Cloud的一個(gè)全新項(xiàng)目，該項(xiàng)目是基于Spring 5.0，Spring Boot 2.0和Project Reactor等技術(shù)開發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡(jiǎn)單有效的統(tǒng)一的API路由管理方式。

Spring Cloud Gateway作為Spring Cloud生態(tài)系統(tǒng)中的網(wǎng)關(guān)，目標(biāo)是替代Zuul，在Spring Cloud 2.0以上版本中，沒有對(duì)新版本的Zuul 2.0以上最新高性能版本進(jìn)行集成，仍然還是使用的Zuul 2.0之前的非Reactor模式的老版本。而為了提升網(wǎng)關(guān)的性能，Spring Cloud Gateway是基于WebFlux框架實(shí)現(xiàn)的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway的目標(biāo)，不僅提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/指標(biāo)，和限流。

Spring Cloud Gateway底層使用了高性能的通信框架Netty。

SpringCloud Gateway特征

Spring Cloud官方，對(duì)Spring Cloud Gateway特征介紹如下：

• 基于Spring Framework 5，Project Reactor和Spring Boot 2.0
• 集成Hystrix斷路器
• 集成Spring Cloud DiscoveryClient
• Predicates和Filters作用于特定路由，易于編寫的Predicates和Filters
• 具備一些網(wǎng)關(guān)的高級(jí)功能：動(dòng)態(tài)路由、限流、路徑重寫

從以上的特征來說，和Zuul的特征差別不大。Spring Cloud Gateway和Zuul主要的區(qū)別，還是在底層的通信框架上。

簡(jiǎn)單說明一下上文中的三個(gè)術(shù)語：

Filter（過濾器）

和Zuul的過濾器在概念上類似，可以使用它攔截和修改請(qǐng)求，并且對(duì)上游的響應(yīng)，進(jìn)行二次處理。過濾器為org.springframework.cloud.gateway.filter.GatewayFilter類的實(shí)例。

Route（路由）

網(wǎng)關(guān)配置的基本組成模塊，和Zuul的路由配置模塊類似。一個(gè) Route模塊 由一個(gè)ID，一個(gè)目標(biāo)URI，一組斷言和一組過濾器定義。如果斷言為真，則路由匹配，目標(biāo)URI會(huì)被訪問。

Predicate（斷言）

這是一個(gè)Java 8的Predicate，可以使用它來匹配來自HTTP請(qǐng)求的任何內(nèi)容，例如headers或參數(shù)。 斷言的 輸入類型是一個(gè)ServerWebExchange。

幾種網(wǎng)關(guān)的對(duì)比