這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)怎么架構(gòu)一個(gè)合適的企業(yè)API網(wǎng)關(guān)，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)赤坎,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):028-86922220

API Gateway（API GW / API 網(wǎng)關(guān)），顧名思義，是出現(xiàn)在系統(tǒng)邊界上的一個(gè)面向API的、串行集中式的強(qiáng)管控服務(wù)，這里的邊界是企業(yè)IT系統(tǒng)的邊界，主要起到隔離外部訪問(wèn)與內(nèi)部系統(tǒng)的作用。在微服務(wù)概念的流行之前，API網(wǎng)關(guān)的實(shí)體就已經(jīng)誕生了，例如銀行、證券等領(lǐng)域常見的前置機(jī)系統(tǒng)，它也是解決訪問(wèn)認(rèn)證、報(bào)文轉(zhuǎn)換、訪問(wèn)統(tǒng)計(jì)等問(wèn)題的。

API網(wǎng)關(guān)的流行，源于近幾年來(lái)，移動(dòng)應(yīng)用與企業(yè)間互聯(lián)需求的興起。移動(dòng)應(yīng)用、企業(yè)互聯(lián)，使得后臺(tái)服務(wù)支持的對(duì)象，從以前單一的Web應(yīng)用，擴(kuò)展到多種使用場(chǎng)景，且每種使用場(chǎng)景對(duì)后臺(tái)服務(wù)的要求都不盡相同。這不僅增加了后臺(tái)服務(wù)的響應(yīng)量，還增加了后臺(tái)服務(wù)的復(fù)雜性。隨著微服務(wù)架構(gòu)概念的提出，API網(wǎng)關(guān)成為了微服務(wù)架構(gòu)的一個(gè)標(biāo)配組件。

一：網(wǎng)關(guān)的幾種使用場(chǎng)景

1、面向Web App

這類場(chǎng)景，在物理形態(tài)上類似前后端分離，此時(shí)的Web App已經(jīng)不是全功能的Web App，而是根據(jù)場(chǎng)景定制、場(chǎng)景化的App。

2、面向Mobile App

這類場(chǎng)景，移動(dòng)App是后端Service的使用者，此時(shí)的API GW還需要承擔(dān)一部分MDM（此處是指移動(dòng)設(shè)備管理，不是主數(shù)據(jù)管理）的職能。

3、面向Partner OpenAPI

這類場(chǎng)景，主要為了滿足業(yè)務(wù)形態(tài)對(duì)外開放，與企業(yè)外部合作伙伴建立生態(tài)圈，此時(shí)的API GW需要增加配額、流控、令牌等一系列安全管控功能。

4、面向Partner ExternalAPI

這類場(chǎng)景，業(yè)界提的比較少，很多時(shí)候系統(tǒng)的建設(shè)，都是為了滿足企業(yè)自身業(yè)務(wù)的需要，實(shí)現(xiàn)對(duì)企業(yè)自有業(yè)務(wù)的映射。當(dāng)互聯(lián)網(wǎng)形態(tài)逐漸影響傳統(tǒng)企業(yè)時(shí)，很多系統(tǒng)都會(huì)為了導(dǎo)入流量或者內(nèi)容，依賴外部合作伙伴的能力，一些典型的例子就是使用「合作方賬號(hào)登錄」、「使用第三方支付平臺(tái)支付」等等，這些對(duì)于企業(yè)內(nèi)部來(lái)說(shuō)，都是一些外部能力。此時(shí)的API GW就需要在邊界上，為企業(yè)內(nèi)部Service 統(tǒng)一調(diào)用外部的API做統(tǒng)一的認(rèn)證、（多租戶形式的）授權(quán)、以及訪問(wèn)控制。

在我們講的微服務(wù)架構(gòu)下的API網(wǎng)關(guān)，一般指的是前三類使用場(chǎng)景。即，主要是把企業(yè)內(nèi)部的API能力，暴露給其他應(yīng)用或合作伙伴使用。網(wǎng)關(guān)層作為客戶端與服務(wù)端的一層擋板，主要起到了三大類作用：

第一類作用是隔離作用，作為企業(yè)系統(tǒng)邊界，隔離外網(wǎng)系統(tǒng)與內(nèi)網(wǎng)系統(tǒng)。

第二類作用是解耦作用，通過(guò)解耦，使得微服務(wù)系統(tǒng)的各方能夠獨(dú)立、自由、高效、靈活地調(diào)整，而不用擔(dān)心給其他方面帶來(lái)影響。

第三類作用是腳手架作用，提供了一個(gè)地點(diǎn)，方便通過(guò)擴(kuò)展機(jī)制對(duì)請(qǐng)求進(jìn)行一系列加工和處理。

二：網(wǎng)關(guān)的好處

（1）網(wǎng)關(guān)層對(duì)外部和內(nèi)部進(jìn)行了隔離，保障了后臺(tái)服務(wù)的安全性。

（2）對(duì)外訪問(wèn)控制由網(wǎng)絡(luò)層面轉(zhuǎn)換成了運(yùn)維層面，減少變更的流程和錯(cuò)誤成本

（3） 減少客戶端與服務(wù)的耦合，服務(wù)可以獨(dú)立發(fā)展。通過(guò)網(wǎng)關(guān)層來(lái)做映射。

（4）通過(guò)網(wǎng)關(guān)層聚合，減少外部訪問(wèn)的頻次，提升訪問(wèn)效率。

（5）節(jié)約后端服務(wù)開發(fā)成本，減少上線風(fēng)險(xiǎn)。

（6）為服務(wù)熔斷，灰度發(fā)布，線上測(cè)試提供簡(jiǎn)單方案。

（7）便于擴(kuò)展。

三：API網(wǎng)關(guān)需要考慮的因素

1、安全性問(wèn)題

企業(yè)在把服務(wù)暴露給外部使用時(shí)，首先要確保服務(wù)使用的安全，防止外部的惡意訪問(wèn)對(duì)公司業(yè)務(wù)的影響，特別是涉及交易方面的服務(wù)，更是要全面考慮安全性。為確保安全，需要考慮在通訊鏈路的建立、通訊數(shù)據(jù)的加密、數(shù)據(jù)的完整性、不可抵賴性等方面。

2、性能問(wèn)題

作為企業(yè)API的入口，所有的請(qǐng)求都會(huì)經(jīng)過(guò)API網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)，可想而知，對(duì)API網(wǎng)關(guān)的訪問(wèn)壓力是巨大的，有的網(wǎng)站甚至達(dá)到每分鐘上千萬(wàn)的訪問(wèn)量。特別是在一些互聯(lián)網(wǎng)企業(yè)，海量的移動(dòng)終端每時(shí)每刻都需要與后端的服務(wù)進(jìn)行交互，如果不能保證網(wǎng)關(guān)的高性能，企業(yè)在網(wǎng)關(guān)層需要投入大量的設(shè)備和成本。曾在一家互聯(lián)網(wǎng)公司發(fā)生過(guò)，由于網(wǎng)關(guān)性能問(wèn)題，網(wǎng)關(guān)的機(jī)器數(shù)量，需要與后臺(tái)服務(wù)器的數(shù)量保持同步增長(zhǎng)。這種情況顯然是企業(yè)服務(wù)忍受的。

3、高可用問(wèn)題

API網(wǎng)關(guān)作為邏輯上的單點(diǎn)，一旦發(fā)生問(wèn)題，將造成企業(yè)服務(wù)的不可用，對(duì)企業(yè)來(lái)說(shuō)可能造成的致命的影響。計(jì)算短時(shí)間的不可用，也會(huì)給企業(yè)帶來(lái)直接的經(jīng)濟(jì)損失。所以，如何保證API網(wǎng)關(guān)的7*24小時(shí)的穩(wěn)定運(yùn)行，網(wǎng)關(guān)的自動(dòng)伸縮、API的熱更新等問(wèn)題，都是企業(yè)級(jí)的網(wǎng)關(guān)需要考慮的。

4、擴(kuò)展性問(wèn)題

前面說(shuō)到，企業(yè)網(wǎng)關(guān)提供了一個(gè)腳手架，一些非功能性的問(wèn)題，例如日志、安全、負(fù)載均衡策略、鑒權(quán)等。這些插件會(huì)隨著企業(yè)業(yè)務(wù)規(guī)模等的變化進(jìn)行不斷的強(qiáng)化與調(diào)整。這就需要網(wǎng)關(guān)層提供這樣一種機(jī)制，使得可以靈活地進(jìn)行這些調(diào)整和變化，而不用頻繁對(duì)網(wǎng)關(guān)層進(jìn)行改動(dòng)，確保網(wǎng)關(guān)層的穩(wěn)定性。

5、API高效運(yùn)維的問(wèn)題

API在上線、發(fā)布過(guò)程中，都需要涉及到網(wǎng)關(guān)層的配合，例如，需要網(wǎng)關(guān)層知道API發(fā)布的地址，API的接口形式、報(bào)文格式，也需要網(wǎng)關(guān)層對(duì)后臺(tái)API進(jìn)行封裝。在API調(diào)整后，需要作出相應(yīng)的修改。所以，API網(wǎng)關(guān)設(shè)計(jì)時(shí)，需要明確網(wǎng)關(guān)層與服務(wù)層的職責(zé)切分與協(xié)作模式，使得API的管理、發(fā)布更加高效。

6、API全生命周期的管理

API服務(wù)的全生命周期，包括服務(wù)的開發(fā)、測(cè)試、上線發(fā)布；服務(wù)使用的申請(qǐng)、開通；服務(wù)分類分級(jí)別的管理、服務(wù)使用情況的監(jiān)控、計(jì)費(fèi)等等。

一個(gè)企業(yè)可能會(huì)暴露成百上千個(gè)API，日常也會(huì)經(jīng)常進(jìn)行API的發(fā)布、升級(jí)、改造、下架等操作。對(duì)不同的服務(wù)，不同的訪問(wèn)者，需要提供不同的服務(wù)訪問(wèn)策略。有的商業(yè)API公司，還需要對(duì)API的使用進(jìn)行付費(fèi)。所以，與API網(wǎng)關(guān)配套的，需要一套完善的自助系統(tǒng)，提供給服務(wù)的提供者、管理者、使用者，來(lái)對(duì)服務(wù)的發(fā)布、使用、和運(yùn)營(yíng)。

四：業(yè)界常用的API網(wǎng)關(guān)方案

1：Nginx + Lua

基本功能：

（1）靜態(tài)web資源服務(wù)器，能夠緩存打開的文件描述符

（2）支持http/imap/pop3/smtp的反向代理；支持緩存、負(fù)載均衡

（3）支持fastcgi(fpm)

（4）模塊化，非DSO機(jī)制，支持過(guò)濾器zip壓縮，SSI以及圖像大小調(diào)整

（5）支持SSL

Nginx的擴(kuò)展功能：

（1）基于名稱和IP的虛擬主機(jī)

（2）支持keepalive的保持機(jī)制

（3）支持平滑升級(jí)

（4）定制訪問(wèn)日志，支持使用日志緩存區(qū)提高日志存儲(chǔ)性能

（5）支持url rewrite

（6）支持路徑別名（root或alias指定）

（7）支持基于IP以及用戶的訪問(wèn)控制

（8）支持傳輸速率限制，并發(fā)限制

性能和高可用性上：

Nginx性能極高，Nginx先天的事件驅(qū)動(dòng)型設(shè)計(jì)、全異步的網(wǎng)絡(luò)I/O處理機(jī)制、極少的進(jìn)程間切換以及許多優(yōu)化設(shè)計(jì)，都使得Nginx天生善于處理高并發(fā)壓力下的互聯(lián)網(wǎng)請(qǐng)求。Nginx的穩(wěn)定性也在各大網(wǎng)站得到驗(yàn)證。官方提供的常用模塊都非常穩(wěn)定，每個(gè)worker進(jìn)程相對(duì)獨(dú)立，master進(jìn)程在1個(gè)worker進(jìn)程出錯(cuò)時(shí)可以快速“拉起”新的worker子進(jìn)程提供服務(wù)。支持熱部署，可以不停機(jī)更新配置文件、更新日志文件、更新服務(wù)器程序版本。

擴(kuò)展性上：

Nginx的設(shè)計(jì)極具擴(kuò)展性，它完全是由多個(gè)不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當(dāng)對(duì)某一個(gè)模塊修復(fù)Bug或進(jìn)行升級(jí)時(shí)，可以專注于模塊自身，無(wú)須在意其他

易用性上：

Nginx使用最自由的BSD許可協(xié)議，允許用戶在自己的項(xiàng)目中直接使用或修改Nginx源碼，有大量的插件可以利用。但是，Nginx模塊需要用C開發(fā)，而且必須符合一系列復(fù)雜的規(guī)則。雖然通過(guò)第三方模塊，可以支持Nginx與Perl、Lua等腳本語(yǔ)言集成工作，但對(duì)使用者的要求還是很高。

2：Spring Cloud Zuul

基本功能

驗(yàn)證與安全保障: 識(shí)別面向各類資源的驗(yàn)證要求并拒絕那些與要求不符的請(qǐng)求。

審查與監(jiān)控: 在邊緣位置追蹤有意義數(shù)據(jù)及統(tǒng)計(jì)結(jié)果，從而為我們帶來(lái)準(zhǔn)確的生產(chǎn)狀態(tài)結(jié)論。

動(dòng)態(tài)路由: 以動(dòng)態(tài)方式根據(jù)需要將請(qǐng)求路由至不同后端集群處。

壓力測(cè)試: 逐漸增加指向集群的負(fù)載流量，從而計(jì)算性能水平。

負(fù)載分配: 為每一種負(fù)載類型分配對(duì)應(yīng)容量，并棄用超出限定值的請(qǐng)求。

靜態(tài)響應(yīng)處理: 在邊緣位置直接建立部分響應(yīng)，從而避免其流入內(nèi)部集群。

Netflix公司還利用Zuul的功能通過(guò)金絲雀版本實(shí)現(xiàn)精確路由與壓力測(cè)試。

雖然提供的功能還算豐富，但都比較弱，很難滿足高要求的場(chǎng)景。

性能和高可用性

Zuul處理每個(gè)請(qǐng)求的方式是針對(duì)每個(gè)請(qǐng)求是用一個(gè)線程來(lái)處理。通常情況下，為了提高性能，所有請(qǐng)求會(huì)被放到處理隊(duì)列中，從線程池中選取空閑線程來(lái)處理該請(qǐng)求。2016年底，Netflix將它們的網(wǎng)關(guān)服務(wù)Zuul進(jìn)行了升級(jí)，全新的Zuul 2將HTTP請(qǐng)求的處理方式從同步變成了異步，以提升其處理性能。除了Netflix公司，目前Zuul在企業(yè)中用的還比較少，性能和穩(wěn)定性方面還有待進(jìn)一步觀察。

擴(kuò)展性上，

從Zuul的架構(gòu)圖上可以看出，Zuul更像是一個(gè)過(guò)濾器框架，其自身的路由、日志、反向代理、ddos預(yù)防等功能都是通過(guò)過(guò)濾器實(shí)現(xiàn)的。提供了PRE、ROUTING、POST和ERROR四個(gè)擴(kuò)展點(diǎn)，可以很容易的添加自定義的過(guò)濾器。

易用性上

Zuul的搭建非常簡(jiǎn)便，使用和配置也很簡(jiǎn)單。Zuul的開源社區(qū)比較活躍，一直在更新狀態(tài)，但版本不算太穩(wěn)定，在使用的過(guò)程中，還有一些坑要踩。例如重定向問(wèn)題、異常處理問(wèn)題，還沒有解決的很好，需要自己重寫一些filter。

3.Mashape Kong

Kong的一個(gè)非常誘人的地方就是提供了大量的插件來(lái)擴(kuò)展應(yīng)用，通過(guò)設(shè)置不同的插件可以為服務(wù)提供各種增強(qiáng)的功能。Kong默認(rèn)插件插件包括：

l 身份認(rèn)證：Kong提供了Basic Authentication、Key authentication、OAuth3.0 authentication、HMAC authentication、JWT、LDAP authentication認(rèn)證實(shí)現(xiàn)。

l 安全：ACL（訪問(wèn)控制）、CORS（跨域資源共享）、動(dòng)態(tài)SSL、IP限制、爬蟲檢測(cè)實(shí)現(xiàn)。

l 流量控制：請(qǐng)求限流（基于請(qǐng)求計(jì)數(shù)限流）、上游響應(yīng)限流（根據(jù)upstream響應(yīng)計(jì)數(shù)限流）、請(qǐng)求大小限制。限流支持本地、redis和集群限流模式。

l 分析監(jiān)控：Galileo（記錄請(qǐng)求和響應(yīng)數(shù)據(jù)，實(shí)現(xiàn)API分析）、Datadog（記錄API Metric如請(qǐng)求次數(shù)、請(qǐng)求大小、響應(yīng)狀態(tài)和延遲，可視化API Metric）、Runscope（記錄請(qǐng)求和響應(yīng)數(shù)據(jù)，實(shí)現(xiàn)API性能測(cè)試和監(jiān)控）。

l 轉(zhuǎn)換：請(qǐng)求轉(zhuǎn)換、響應(yīng)轉(zhuǎn)換

Kong本身也是基于Nginx的，所以在性能和穩(wěn)定性上都沒有問(wèn)題。Kong作為一款商業(yè)軟件，在Nginx上做了很擴(kuò)展工作，而且還有很多付費(fèi)的商業(yè)插件。Kong本身也有付費(fèi)的企業(yè)版，其中包括技術(shù)支持、使用培訓(xùn)服務(wù)以及 API 分析插件。

從對(duì)上面三種方案的比較中可以看到，Spring Cloud Zuul非常適合創(chuàng)業(yè)初期的團(tuán)隊(duì)，快速搭建一個(gè)“基本可用”的API網(wǎng)關(guān)。Nginx適合有較強(qiáng)研發(fā)團(tuán)隊(duì)，自主開發(fā)企業(yè)自己的API網(wǎng)關(guān)。Kong適合于沒有自身研發(fā)團(tuán)隊(duì)，但需要擁有企業(yè)級(jí)API網(wǎng)關(guān)能力的公司。

五：如何設(shè)計(jì)一個(gè)好的企業(yè)級(jí)API網(wǎng)關(guān)產(chǎn)品

1：功能需求

1）API 生命周期管理功能：

覆蓋 API 的定義、測(cè)試、發(fā)布的整個(gè)生命周期管理，便捷的日常管理、版本管理，支持熱升級(jí)和快速回滾

2）開發(fā)和使用支持功能：

提供頁(yè)面調(diào)試工具，自動(dòng)生成 API 文檔和 SDK，大大降低人力成本。

3）安全防護(hù)功能：

API 請(qǐng)求到達(dá)網(wǎng)關(guān)需要經(jīng)過(guò)嚴(yán)格的身份認(rèn)證、權(quán)限認(rèn)證，才能到達(dá)后端服務(wù)。支持算法簽名，支持 SSL 加密。

4）流量控制功能：

可控制單位時(shí)間內(nèi) API 允許被調(diào)用次數(shù)。用來(lái)保護(hù)企業(yè)的后端服務(wù)，實(shí)現(xiàn)業(yè)務(wù)分級(jí)和用戶分級(jí)。 支持對(duì) API 流控，您可以根據(jù) API 的重要程度來(lái)配置不同流控，從而保障重要業(yè)務(wù)的穩(wěn)定運(yùn)行； 支持用戶、應(yīng)用和例外流控，您可以根據(jù)用戶的重要性來(lái)配置不同流控，從而可以保證大用戶的權(quán)益； 流控粒度：分鐘、小時(shí)、天。

5）請(qǐng)求管理功能：

可根據(jù)配置進(jìn)行參數(shù)類型、參數(shù)值（范圍、枚舉、正則、Json Schema）的校驗(yàn)，減少后端對(duì)非法請(qǐng)求、無(wú)效請(qǐng)求的資源消耗和處理成本?？梢栽?API 網(wǎng)關(guān)定義參數(shù)映射規(guī)則，網(wǎng)關(guān)通過(guò)映射規(guī)則將后端服務(wù)通過(guò)映射翻譯成任何形式，以滿足不同用戶的不同需求，從而避免功能重復(fù)開發(fā)。

6）監(jiān)控告警功能：

提供實(shí)時(shí)、可視化的 API 監(jiān)控，包括：調(diào)用量、調(diào)用方式、響應(yīng)時(shí)間、錯(cuò)誤率，讓您能夠清楚的了解 API 的運(yùn)行狀況和用戶的行為習(xí)慣。

支持自定義報(bào)警規(guī)則，來(lái)針對(duì)異常情況進(jìn)行報(bào)警，降低故障處理時(shí)間。

提供可訂閱的數(shù)據(jù)分析報(bào)表和智能分析。

2：高性能設(shè)計(jì)

傳統(tǒng)的基于線程的并發(fā)模型（Thread-based concurrency），為每一個(gè)請(qǐng)求分配一個(gè)線程或進(jìn)程。這種模型編程簡(jiǎn)單，可以將處理一個(gè)完整請(qǐng)求的代碼編寫在一個(gè)代碼路徑中。這種模型的弊端是，隨著線程(進(jìn)程)數(shù)的上升，操作系統(tǒng)在這些線程(進(jìn)程)之間的頻繁切換，將急劇降低系統(tǒng)的性能。

3：高可用設(shè)計(jì)

1） 無(wú)狀態(tài)設(shè)計(jì)原則。

網(wǎng)關(guān)層為保證高可以，易于伸縮，快速啟動(dòng)，需要設(shè)計(jì)成無(wú)狀態(tài)的。用戶的狀態(tài)數(shù)據(jù)我們通常使用session對(duì)象來(lái)封裝，網(wǎng)關(guān)層要設(shè)計(jì)成無(wú)狀態(tài)的，也就是說(shuō)，不能由網(wǎng)關(guān)來(lái)負(fù)責(zé)session的維護(hù)。那由誰(shuí)來(lái)維護(hù)session相關(guān)的信息呢？我們是采用cookie+session服務(wù)器的方式;

a) 用戶在登錄頁(yè)完成登錄操作后，服務(wù)器會(huì)生成一個(gè)登錄session信息，保存起來(lái)，設(shè)置個(gè)失效時(shí)間，并設(shè)置到用戶的cookie里

b) 用戶后續(xù)的每次請(qǐng)求里會(huì)帶著這個(gè)cookie信息，服務(wù)端會(huì)對(duì)這個(gè)cookie信息進(jìn)行校驗(yàn)，通過(guò)了就認(rèn)為是合法用戶，執(zhí)行請(qǐng)求操作

2）優(yōu)雅下線原則

當(dāng)需要撤掉一臺(tái)網(wǎng)關(guān)服務(wù)的時(shí)候，不是直接結(jié)束網(wǎng)關(guān)進(jìn)程，而是先關(guān)閉監(jiān)聽套接字，但是繼續(xù)為當(dāng)前連接的客戶提供服務(wù)，所有客戶端的服務(wù)完成后，在把進(jìn)程關(guān)閉。

3）Slow start特性

當(dāng)網(wǎng)關(guān)監(jiān)聽到有一臺(tái)新的服務(wù)注冊(cè)上來(lái)時(shí)，考慮到有些服務(wù)啟動(dòng)后，剛開始會(huì)有許多初始化的工作，此時(shí)服務(wù)對(duì)請(qǐng)求的響應(yīng)速度是比較慢的。如果一開始就給這臺(tái)服務(wù)分配太多的壓力，有可能導(dǎo)致服務(wù)瞬間被壓垮。為了避免這種情況，網(wǎng)關(guān)層需要考慮支持Slow Start特性。即，經(jīng)過(guò)一段時(shí)間，逐漸把壓力增加到預(yù)設(shè)的值。

4）擴(kuò)展性設(shè)計(jì)

我們知道，網(wǎng)關(guān)對(duì)請(qǐng)求的處理，可以分為三個(gè)階段：接受請(qǐng)求、路由并轉(zhuǎn)發(fā)請(qǐng)求、接受服務(wù)的返回?cái)?shù)據(jù)并返回給請(qǐng)求者，除此之外，還有一種情況是處理錯(cuò)誤。所以我們也可以在這四個(gè)地方添加擴(kuò)展點(diǎn)。

（1）接受到請(qǐng)求后

（2）定位到一個(gè)服務(wù)，并準(zhǔn)備轉(zhuǎn)發(fā)之前

（3）接受到服務(wù)的返回?cái)?shù)據(jù)，返回給客戶端之前

（4）當(dāng)服務(wù)調(diào)用失敗后

攔截器的處理順序，可以分為兩大類：一類為網(wǎng)關(guān)平臺(tái)自帶的攔截器，例如安全校驗(yàn)、日志記錄等；一類為網(wǎng)關(guān)層邏輯開發(fā)的，例如格式轉(zhuǎn)換等。一般來(lái)說(shuō)，網(wǎng)關(guān)先執(zhí)行網(wǎng)關(guān)平臺(tái)自帶的攔截器，再執(zhí)行為了業(yè)務(wù)邏輯編寫的攔截器。當(dāng)然，網(wǎng)關(guān)也需要提供一種機(jī)制，可以較容易地調(diào)整攔截器的執(zhí)行順序。最簡(jiǎn)單的一種方法，就是給每個(gè)攔截器定義一個(gè)優(yōu)先級(jí)，網(wǎng)關(guān)按優(yōu)先級(jí)順序依次調(diào)用各攔截器。

對(duì)網(wǎng)關(guān)層來(lái)說(shuō)，它接收和處理的數(shù)據(jù)都是Request對(duì)象，網(wǎng)關(guān)層在接收到請(qǐng)求后，把請(qǐng)求封裝為Request對(duì)象，為了讓后續(xù)的filter能夠獲得這個(gè)對(duì)象，可以考慮把Request對(duì)象保存在線程變量中。

有些攔截器，例如一些調(diào)試日志的攔截器，通常情況下都是關(guān)閉的，只有在出現(xiàn)問(wèn)題的時(shí)候才需要打開。為了保證網(wǎng)關(guān)的高可用，網(wǎng)關(guān)層必須具備在線啟用或關(guān)閉攔截器的能力。一般，網(wǎng)關(guān)需要提供restful接口方式，來(lái)關(guān)閉和啟用一個(gè)攔截器。

5）API管理與動(dòng)態(tài)發(fā)布設(shè)計(jì)

對(duì)服務(wù)管理來(lái)說(shuō)，分為前端服務(wù)管理與后端服務(wù)管理。前端服務(wù)指的是網(wǎng)關(guān)層暴露給客戶端使用的服務(wù)API，后端服務(wù)指的是服務(wù)層提供的業(yè)務(wù)服務(wù)API。一個(gè)服務(wù)暴露給客戶端使用，除了網(wǎng)關(guān)層和服務(wù)層提供服務(wù)的代碼外，還需要配置前端服務(wù)與后端服務(wù)的映射關(guān)系。

網(wǎng)關(guān)層API調(diào)用服務(wù)層API，有多種方式。例如，可以由按照服務(wù)層API的服務(wù)契約，生成一段客戶端代碼，發(fā)布給網(wǎng)關(guān)層使用。這種方式的弊端是，網(wǎng)關(guān)層代碼依賴于服務(wù)層代碼，服務(wù)層頻繁修改和調(diào)整接口時(shí)，導(dǎo)致網(wǎng)關(guān)層的代碼很難維護(hù)。

可以通過(guò)配置前后端服務(wù)映射的方式，解耦網(wǎng)關(guān)層對(duì)服務(wù)層的依賴。當(dāng)服務(wù)層的API（例如服務(wù)名、參數(shù)名等）發(fā)生變化時(shí)，只需調(diào)整映射關(guān)系，無(wú)需對(duì)網(wǎng)關(guān)層的代碼進(jìn)行調(diào)整。網(wǎng)關(guān)層按照映射，自動(dòng)裝配服務(wù)層API所需要的數(shù)據(jù)格式。這樣，網(wǎng)關(guān)層團(tuán)隊(duì)與服務(wù)層團(tuán)隊(duì)可以相互不受干擾地開發(fā)各自的服務(wù)。

上述就是小編為大家分享的怎么架構(gòu)一個(gè)合適的企業(yè)API網(wǎng)關(guān)了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。