怎么架構(gòu)一個合適的企業(yè)API網(wǎng)關(guān)

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

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

API網(wǎng)關(guān)的流行，源于近幾年來，移動應(yīng)用與企業(yè)間互聯(lián)需求的興起。移動應(yīng)用、企業(yè)互聯(lián)，使得后臺服務(wù)支持的對象，從以前單一的Web應(yīng)用，擴展到多種使用場景，且每種使用場景對后臺服務(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)上類似前后端分離，此時的Web App已經(jīng)不是全功能的Web App，而是根據(jù)場景定制、場景化的App。

2、面向Mobile App

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

3、面向Partner OpenAPI

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

4、面向Partner ExternalAPI

這類場景，業(yè)界提的比較少，很多時候系統(tǒng)的建設(shè)，都是為了滿足企業(yè)自身業(yè)務(wù)的需要，實現(xiàn)對企業(yè)自有業(yè)務(wù)的映射。當(dāng)互聯(lián)網(wǎng)形態(tài)逐漸影響傳統(tǒng)企業(yè)時，很多系統(tǒng)都會為了導(dǎo)入流量或者內(nèi)容，依賴外部合作伙伴的能力，一些典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平臺支付」等等，這些對于企業(yè)內(nèi)部來說，都是一些外部能力。此時的API GW就需要在邊界上，為企業(yè)內(nèi)部Service 統(tǒng)一調(diào)用外部的API做統(tǒng)一的認證、（多租戶形式的）授權(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)的各方能夠獨立、自由、高效、靈活地調(diào)整，而不用擔(dān)心給其他方面帶來影響。

第三類作用是腳手架作用，提供了一個地點，方便通過擴展機制對請求進行一系列加工和處理。

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

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

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

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

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

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

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

（7）便于擴展。

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

1、安全性問題

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

2、性能問題

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

3、高可用問題

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

4、擴展性問題

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

5、API高效運維的問題

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

6、API全生命周期的管理

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

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

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

1：Nginx + Lua

基本功能：

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

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

（3）支持fastcgi(fpm)

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

（5）支持SSL

Nginx的擴展功能：

（1）基于名稱和IP的虛擬主機

（2）支持keepalive的保持機制

（3）支持平滑升級

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

（5）支持url rewrite

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

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

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

性能和高可用性上：

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

擴展性上：

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

易用性上：

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

2：Spring Cloud Zuul

基本功能

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

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

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

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

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

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

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

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

性能和高可用性

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

擴展性上，

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

易用性上

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

3.Mashape Kong

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

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

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

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

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

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

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

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

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

1：功能需求

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

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

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

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

3）安全防護功能：

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

4）流量控制功能：

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

5）請求管理功能：

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

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

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

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

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

2：高性能設(shè)計

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

3：高可用設(shè)計

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

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

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

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

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

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

3）Slow start特性

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

4）擴展性設(shè)計

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

（1）接受到請求后

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

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

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

攔截器的處理順序，可以分為兩大類：一類為網(wǎng)關(guā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)也需要提供一種機制，可以較容易地調(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)問題的時候才需要打開。為了保證網(wǎng)關(guān)的高可用，網(wǎng)關(guān)層必須具備在線啟用或關(guān)閉攔截器的能力。一般，網(wǎng)關(guān)需要提供restful接口方式，來關(guān)閉和啟用一個攔截器。

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

對服務(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)整接口時，導(dǎo)致網(wǎng)關(guān)層的代碼很難維護。

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

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