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

成都創(chuàng)新互聯(lián)是專業(yè)的海鹽網(wǎng)站建設(shè)公司，海鹽接單;提供成都網(wǎng)站建設(shè)、網(wǎng)站制作,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行海鹽網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

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

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

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

1、面向Web App

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

2、面向Mobile App

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

3、面向Partner OpenAPI

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

4、面向Partner ExternalAPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、安全性問題

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

2、性能問題

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

3、高可用問題

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

4、擴(kuò)展性問題

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

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

API在上線、發(fā)布過程中，都需要涉及到網(wǎng)關(guān)層的配合，例如，需要網(wǎng)關(guān)層知道API發(fā)布的地址，API的接口形式、報(bào)文格式，也需要網(wǎng)關(guān)層對后臺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ā)、測試、上線發(fā)布；服務(wù)使用的申請、開通；服務(wù)分類分級別的管理、服務(wù)使用情況的監(jiān)控、計(jì)費(fèi)等等。

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

四：業(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ī)制，支持過濾器zip壓縮，SSI以及圖像大小調(diào)整

（5）支持SSL

Nginx的擴(kuò)展功能：

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

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

（3）支持平滑升級

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

（5）支持url rewrite

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

（7）支持基于IP以及用戶的訪問控制

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

性能和高可用性上：

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

擴(kuò)展性上：

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

易用性上：

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

2：Spring Cloud Zuul

基本功能

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

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

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

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

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

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

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

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

性能和高可用性

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

擴(kuò)展性上，

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

易用性上

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

3.Mashape Kong

Kong的一個非常誘人的地方就是提供了大量的插件來擴(kuò)展應(yīng)用，通過設(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（訪問控制）、CORS（跨域資源共享）、動態(tài)SSL、IP限制、爬蟲檢測實(shí)現(xiàn)。

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

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

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

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

從對上面三種方案的比較中可以看到，Spring Cloud Zuul非常適合創(chuàng)業(yè)初期的團(tuán)隊(duì)，快速搭建一個“基本可用”的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è)級API網(wǎng)關(guān)能力的公司。

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

1：功能需求

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

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

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

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

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

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

4）流量控制功能：

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

5）請求管理功能：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）接受到請求后

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

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

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

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

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

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

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

對服務(wù)管理來說，分為前端服務(wù)管理與后端服務(wù)管理。前端服務(wù)指的是網(wǎng)關(guān)層暴露給客戶端使用的服務(wù)API，后端服務(wù)指的是服務(wù)層提供的業(yè)務(wù)服務(wù)API。一個服務(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ù)。

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

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

當(dāng)前標(biāo)題：怎么架構(gòu)一個合適的企業(yè)API網(wǎng)關(guān)-創(chuàng)新互聯(lián)
文章位置：http://aaarwkj.com/article2/cdhiic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、自適應(yīng)網(wǎng)站、企業(yè)網(wǎng)站制作、網(wǎng)站改版、軟件開發(fā)、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)