導(dǎo)讀API網(wǎng)關(guān)◎API網(wǎng)關(guān)的意義◎API網(wǎng)關(guān)的職責(zé)◎API網(wǎng)關(guān)的缺點(diǎn)◎使用API網(wǎng)關(guān)認(rèn)證身份◎API網(wǎng)關(guān)技術(shù)實(shí)戰(zhàn)網(wǎng)關(guān)的英文是Gateway，翻譯為門、方法、通道....API網(wǎng)關(guān)

◎ API網(wǎng)關(guān)的意義

◎ API網(wǎng)關(guān)的職責(zé)

◎ API網(wǎng)關(guān)的缺點(diǎn)

◎ 使用API網(wǎng)關(guān)認(rèn)證身份

◎ API網(wǎng)關(guān)技術(shù)實(shí)戰(zhàn)

網(wǎng)關(guān)的英文是Gateway，翻譯為門、方法、通道、途徑。API網(wǎng)關(guān)就是接口的通道或接口的大門。要想訪問API，就必須通過API網(wǎng)關(guān)，為什么要有API網(wǎng)關(guān)，這樣做有什么作用？帶著這些問題，我們來學(xué)習(xí)本章的內(nèi)容。

API網(wǎng)關(guān)的意義

API網(wǎng)關(guān)并沒有引申含義，通俗來講，它就是應(yīng)用系統(tǒng)所有接口的唯一關(guān)卡，就像一道門，想要調(diào)用到接口，就必須從這扇門進(jìn)入。為什么要有這樣一道門？

在微服務(wù)中，服務(wù)端被拆分成一組職責(zé)單一的微小服務(wù)，這樣做的好處不再贅述。但我們的服務(wù)由少變多，必然會(huì)增加系統(tǒng)的復(fù)雜度。原先客戶端只需關(guān)心與一個(gè)單體的服務(wù)交互即可，現(xiàn)在需要去了解每個(gè)服務(wù)的具體信息，包括認(rèn)證規(guī)則、主機(jī)地址、集群方式等。即便擁有再完善的服務(wù)注冊(cè)與發(fā)現(xiàn)機(jī)制，客戶端也需要對(duì)后端服務(wù)的各個(gè)職責(zé)劃分，才能知道哪個(gè)API應(yīng)該調(diào)用哪個(gè)服務(wù)。在大型項(xiàng)目中，客戶端往往需要花費(fèi)巨大的工作量來集成這些后端。

設(shè)想一下，在一個(gè)沒有API網(wǎng)關(guān)的系統(tǒng)中，前后端調(diào)用關(guān)系如圖5.1所示。

復(fù)雜的調(diào)用關(guān)系讓客戶端難以維護(hù)，光看就覺得很亂。假設(shè)我們要開發(fā)移動(dòng)端的代碼，調(diào)用后端的服務(wù)，就需要維護(hù)與各個(gè)服務(wù)的調(diào)用關(guān)系。服務(wù)的個(gè)數(shù)一旦增加，如系統(tǒng)中有幾十個(gè)，甚至上百個(gè)服務(wù)，關(guān)系維護(hù)起來將花費(fèi)相當(dāng)多的時(shí)間。最主要的是，前端根本不想關(guān)心這些問題，對(duì)于前端開發(fā)來講，只想調(diào)用可用的接口，這本身是后端服務(wù)的架構(gòu)邏輯，前端會(huì)因?yàn)檫@種架構(gòu)模式變得異常復(fù)雜，而且這個(gè)復(fù)雜度會(huì)在每個(gè)客戶端中重復(fù)出現(xiàn)。

同時(shí)，認(rèn)證規(guī)則無法復(fù)用，圖5.1所示為一個(gè)商場(chǎng)系統(tǒng)，一般情況下，系統(tǒng)會(huì)根據(jù)不同的終端設(shè)計(jì)不同的用戶認(rèn)證規(guī)則，如PC端可以通過用戶名密碼的方式進(jìn)行用戶認(rèn)證，移動(dòng)端可以使用手機(jī)號(hào)加短信驗(yàn)證碼的方式進(jìn)行用戶認(rèn)證，第三方可以通過證書密鑰等方式進(jìn)行用戶認(rèn)證，那么這些認(rèn)證方式通常都由后端服務(wù)來實(shí)現(xiàn)。

如果客戶端直接調(diào)用用戶敏感的接口，這些接口所在的服務(wù)必須擁有認(rèn)證的能力才行。換句話說，這些后端服務(wù)都需要實(shí)現(xiàn)多套用戶認(rèn)證的邏輯，并且還需要根據(jù)不同終端的請(qǐng)求使用不同的認(rèn)證方式。

為了使微服務(wù)更加通用，后端服務(wù)的代碼中就必然會(huì)被耦合上一些客戶端的判斷邏輯，因而顯得不夠單純，再者每個(gè)服務(wù)都存在著大量重復(fù)的認(rèn)證邏輯，一旦有些客戶端的認(rèn)證方式發(fā)生變化，就需要去維護(hù)每個(gè)服務(wù)中的認(rèn)證代碼，如圖5.2所示。

前端受到后端架構(gòu)的“污染”，職責(zé)增加，開發(fā)難度增大。當(dāng)然，可能有不少系統(tǒng)都與圖5.1所示的系統(tǒng)類似或更加簡(jiǎn)單，服務(wù)也就幾個(gè)甚至更少，系統(tǒng)本身就只有一個(gè)客戶端，或者根本沒有做前后端分離，這樣的系統(tǒng)調(diào)用鏈就很簡(jiǎn)單，客戶端維護(hù)服務(wù)信息也很容易。

即使這樣仍然需要API網(wǎng)關(guān)，首先在生產(chǎn)環(huán)境中，服務(wù)都是多實(shí)例部署，以增加系統(tǒng)的可用度，一旦服務(wù)部署了多個(gè)實(shí)例，就需要有負(fù)載均衡的策略。

在微服務(wù)架構(gòu)中，一般都采用客戶端負(fù)載均衡的方式。也就是說，需要前端來負(fù)責(zé)負(fù)載均衡，有了負(fù)載均衡，還需要考慮服務(wù)熔斷、降級(jí)、恢復(fù)等情況，這些服務(wù)治理職責(zé)都將交由前端來承擔(dān)，如圖5.3所示。

雖然如今前端的能力越來越強(qiáng)，一些框架也能夠處理復(fù)雜的服務(wù)治理邏輯，但前端更應(yīng)該關(guān)注用戶的交互、數(shù)據(jù)的渲染等表現(xiàn)層的邏輯，而不應(yīng)被后端的架構(gòu)所影響，從而做很多不擅長或不應(yīng)該負(fù)責(zé)的工作。

API網(wǎng)關(guān)的出現(xiàn)就很好地解決了這些問題。首先，前端不再面對(duì)復(fù)雜的調(diào)用關(guān)系，只需請(qǐng)求API網(wǎng)關(guān)即可；其次，系統(tǒng)本身不需要重復(fù)地關(guān)心客戶端的認(rèn)證方式，可以將認(rèn)證邏輯放到API網(wǎng)關(guān)來做；最后，服務(wù)管理的職責(zé)也和前端解耦，可以在API網(wǎng)關(guān)集成Spring CloudNetflix Hystrix等組件，就能輕松擁有相關(guān)的服務(wù)治理能力，API網(wǎng)關(guān)架構(gòu)圖如圖5.4所示。

API網(wǎng)關(guān)起到了很好的前后端隔離作用，既保護(hù)后端服務(wù)不會(huì)摻雜前端的判斷邏輯，也隔離前端與微服務(wù)治理相關(guān)的職責(zé)，通過統(tǒng)一的網(wǎng)關(guān)，對(duì)所有的請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)、過濾和治理，早期我們?cè)趩误w式架構(gòu)中常用的Nginx也是一種API網(wǎng)關(guān)模式的實(shí)現(xiàn)。

API網(wǎng)關(guān)的職責(zé)

在解釋了為什么要使用API網(wǎng)關(guān)之后，其職責(zé)也體現(xiàn)出來了。API網(wǎng)關(guān)的職責(zé)主要有3個(gè)：請(qǐng)求路由、請(qǐng)求過濾和服務(wù)治理。

請(qǐng)求路由

API網(wǎng)關(guān)本身并不具有服務(wù)的能力，一旦接收到客戶端的請(qǐng)求，API網(wǎng)關(guān)會(huì)根據(jù)一定的規(guī)則（我們稱它為路由規(guī)則）將這些請(qǐng)求轉(zhuǎn)發(fā)給后端的微服務(wù)。

客戶端不需要關(guān)心后端有幾個(gè)微服務(wù)，也不需要關(guān)心這些服務(wù)的主機(jī)地址，只需維護(hù)一個(gè)API網(wǎng)關(guān)的地址。通過API網(wǎng)關(guān)，將請(qǐng)求路由到對(duì)應(yīng)的服務(wù)端，通常我們會(huì)采用URL的路由規(guī)則，例如，將請(qǐng)求路徑/users/ **轉(zhuǎn)發(fā)給用戶服務(wù)，將請(qǐng)求地址/goods/ **轉(zhuǎn)發(fā)給商品服務(wù)，API網(wǎng)關(guān)URL路由示意圖如圖5.5所示。

除了請(qǐng)求路徑的路由規(guī)則，我們還可以通過Reqest Header、Cookie等方式來設(shè)置路由的規(guī)則。例如，在Request Header或Cookie中可以設(shè)置Service-ID的鍵值，然后API網(wǎng)關(guān)就可以通過RequestHeader或Cookie來轉(zhuǎn)發(fā)這些請(qǐng)求。總而言之，客戶端只需將請(qǐng)求發(fā)送到API網(wǎng)關(guān)即可，不需要關(guān)心不同的服務(wù)地址或端口。當(dāng)然，服務(wù)端通常會(huì)與前端定義好契約，其中包括URL或其他路由規(guī)則的定義，這樣客戶端不需要任何成本就可以使用服務(wù)端的接口。

請(qǐng)求過濾

我們已經(jīng)知道API網(wǎng)關(guān)的一個(gè)重要職責(zé)就是用戶認(rèn)證，即通過一定的方式將不符合條件或不安全的請(qǐng)求攔截，而大部分API網(wǎng)關(guān)都是通過過濾器的方式來實(shí)現(xiàn)請(qǐng)求的攔截。當(dāng)客戶端首次請(qǐng)求需要用戶認(rèn)證權(quán)限的接口時(shí)，會(huì)先到達(dá)API網(wǎng)關(guān)的過濾器，然后API網(wǎng)關(guān)通過自己實(shí)現(xiàn)的認(rèn)證邏輯判斷當(dāng)前請(qǐng)求的用戶是否為已經(jīng)認(rèn)證過的合法用戶，若校驗(yàn)失敗，則請(qǐng)求被攔截，若校驗(yàn)通過，則過濾器不攔截該請(qǐng)求，請(qǐng)求正常向后執(zhí)行邏輯，API網(wǎng)關(guān)請(qǐng)求認(rèn)證流程如圖5.6所示。

API網(wǎng)關(guān)也可以調(diào)用獨(dú)立的認(rèn)證服務(wù)來支撐自己的認(rèn)證邏輯，如通過查詢用戶信息來校驗(yàn)用戶名密碼、驗(yàn)證密鑰等操作，或者有時(shí)系統(tǒng)本身就沒有自己的用戶體系，需要集成第三方系統(tǒng)的單點(diǎn)登錄服務(wù)或用戶、權(quán)限等基礎(chǔ)服務(wù)，那么我們完全可以將API網(wǎng)關(guān)和認(rèn)證邏輯解耦，API網(wǎng)關(guān)依然負(fù)責(zé)攔截請(qǐng)求，但具體認(rèn)證規(guī)則的判斷可以調(diào)用后端的認(rèn)證服務(wù)來完成，API網(wǎng)關(guān)與認(rèn)證服務(wù)交互過程如圖5.7所示。

當(dāng)然，用戶的登錄認(rèn)證也可以由API網(wǎng)關(guān)來負(fù)責(zé)，關(guān)于認(rèn)證的詳細(xì)實(shí)現(xiàn)將在5.3節(jié)介紹，這里不再贅述。

其實(shí)，一旦系統(tǒng)的所有請(qǐng)求都采用統(tǒng)一的入口，除了安全認(rèn)證，我們還可以做很多事情，例如，可以通過過濾器的方式再過濾一下敏感的信息，如請(qǐng)求頭中的Cookie、Authorization等，還可以修改請(qǐng)求或響應(yīng)的信息，如限制請(qǐng)求大小、失敗重試等操作，也可以設(shè)置過濾器的順序，將不同的規(guī)則寫在過濾器中，以組合不同的功能需求，API網(wǎng)關(guān)過濾器組合使用示意圖如圖5.8所示。

服務(wù)治理

請(qǐng)求路由和請(qǐng)求過濾可以說是API網(wǎng)關(guān)的兩個(gè)重要功能，除了它們，還可以使用與后端微服務(wù)架構(gòu)更加切合的技術(shù)來使API網(wǎng)關(guān)擁有服務(wù)治理的能力。API網(wǎng)關(guān)同樣可以作為一個(gè)服務(wù)消費(fèi)者，通過集成負(fù)載均衡器、斷路器、注冊(cè)中心和健康監(jiān)控等組件完成服務(wù)的治理工作。通過將API網(wǎng)關(guān)集成注冊(cè)中心，我們可以動(dòng)態(tài)地進(jìn)行服務(wù)發(fā)現(xiàn)，從而更優(yōu)雅地完成路由、負(fù)載均衡等操作，如圖5.9所示。

在API網(wǎng)關(guān)也作為注冊(cè)中心的一個(gè)客戶端注冊(cè)到注冊(cè)中心后，就能夠動(dòng)態(tài)地發(fā)現(xiàn)與監(jiān)控各個(gè)服務(wù)的信息。例如，服務(wù)A和服務(wù)B也注冊(cè)到注冊(cè)中心，根據(jù)注冊(cè)中心提供的服務(wù)信息，API網(wǎng)關(guān)就能很方便地進(jìn)行遠(yuǎn)程調(diào)用、負(fù)載均衡等操作。

API網(wǎng)關(guān)作為服務(wù)的統(tǒng)一調(diào)用者，還可以方便地集成斷路器，做到統(tǒng)一的服務(wù)熔斷和降級(jí)，如圖5.10所示。

如果沒有API網(wǎng)關(guān)，服務(wù)熔斷就只能在服務(wù)間使用，或者需要前端瀏覽器等終端來負(fù)責(zé)，并且每個(gè)終端可能都要實(shí)現(xiàn)相同的功能；如果有API網(wǎng)關(guān)，就可以像圖5.10所示的那樣對(duì)所有的后端服務(wù)進(jìn)行統(tǒng)一的熔斷處理，包括服務(wù)降級(jí)、自動(dòng)恢復(fù)等問題就不用每個(gè)終端去實(shí)現(xiàn)，而且讓前端來做服務(wù)治理顯然是很奇葩的做法。

當(dāng)然，對(duì)于不同的客戶端，它的用戶認(rèn)證方式、服務(wù)治理策略及接口的規(guī)范可能都不一樣，這時(shí)我們可以針對(duì)不同的終端配置不同的API網(wǎng)關(guān)，多終端API網(wǎng)關(guān)示意圖如圖5.11所示。

關(guān)于多個(gè)API網(wǎng)關(guān)的架構(gòu)模式還有一個(gè)名稱：BFF（Backend For Frontend，用于前端的后端），關(guān)于BFF的實(shí)踐將在第6章中詳細(xì)介紹。

API網(wǎng)關(guān)的缺點(diǎn)

前面介紹了使用API網(wǎng)關(guān)的目的和職責(zé)，那么API網(wǎng)關(guān)有沒有缺點(diǎn)？任何架構(gòu)模式都不是萬能的，包括微服務(wù)架構(gòu)本身都存在著不足，API網(wǎng)關(guān)總體來說有兩個(gè)缺點(diǎn)：一是增加了開發(fā)的復(fù)雜度，二是有一定額外的性能消耗，如圖5.12所示。

首先，顯而易見地增加了項(xiàng)目的復(fù)雜度。在項(xiàng)目中使用過API網(wǎng)關(guān)的開發(fā)者不難發(fā)現(xiàn)，API網(wǎng)關(guān)需要進(jìn)行額外開發(fā)和維護(hù)，在開發(fā)一個(gè)接口時(shí)，以往只需和前端進(jìn)行調(diào)試，現(xiàn)在還需要和API網(wǎng)關(guān)調(diào)試，而且還涉及新的服務(wù)配置、部署和管理等工作。

其次，在前后端之間增加了一層調(diào)用鏈，哪怕只是簡(jiǎn)單的轉(zhuǎn)發(fā)，也必然增加了一定的性能消耗，而且通常我們使用HTTP進(jìn)行服務(wù)調(diào)用，HTTP的交互性能并不是很好，所以在一些對(duì)性能有極致要求的項(xiàng)目中，可能需要一些額外的優(yōu)化工作，如緩存、請(qǐng)求合并等操作。

使用API網(wǎng)關(guān)認(rèn)證身份

提到API網(wǎng)關(guān)，就不得不提及身份認(rèn)證，因?yàn)榘踩ＷC才是一個(gè)網(wǎng)關(guān)最原始和最核心的功能，5.2.2節(jié)中已經(jīng)介紹了API網(wǎng)關(guān)請(qǐng)求過濾的架構(gòu)設(shè)計(jì)，那么在與前端的交互中，API網(wǎng)關(guān)如何對(duì)請(qǐng)求進(jìn)行安全保障呢？

分清認(rèn)證與授權(quán)

通常我們說到軟件的安全管理，一般包括兩個(gè)概念：一是認(rèn)證，二是授權(quán)。這兩個(gè)概念也經(jīng)常被大家混淆，而且它們的英文單詞很像，認(rèn)證的英文是Authentication，授權(quán)的英文是Authorization，很多人在代碼中會(huì)使用簡(jiǎn)寫的Auth來替代這兩個(gè)單詞。筆者在每次遇到含有Auth簡(jiǎn)寫的代碼時(shí)都會(huì)感到異常焦躁，必須要深入解讀代碼才能知道這段代碼到底是在處理認(rèn)證還是在處理授權(quán)。

那么，什么是認(rèn)證，什么是授權(quán)？

認(rèn)證又稱身份認(rèn)證，是指通過一定的方式完成對(duì)用戶身份的確認(rèn)。在軟件系統(tǒng)中，不是所有的服務(wù)都是開放式的，大部分情況下需要識(shí)別當(dāng)前請(qǐng)求人是否為系統(tǒng)中的合法用戶，這個(gè)識(shí)別的過程就是認(rèn)證。

授權(quán)是指對(duì)資源的訪問進(jìn)行權(quán)限的定義，并通過授予用戶不同的權(quán)限做到資源的訪問控制。例如，公司的在職員工都能登錄公司的財(cái)務(wù)系統(tǒng)，但只有財(cái)務(wù)人員才能查看公司的財(cái)務(wù)報(bào)表，其他員工只能查看自己的工資條。在軟件系統(tǒng)中，授權(quán)在認(rèn)證之后，只有識(shí)別了用戶的身份，才能知道用戶的權(quán)限，并對(duì)用戶的訪問進(jìn)行控制，認(rèn)證與授權(quán)的職責(zé)示意圖如圖5.13所示。

圖5.13 認(rèn)證與授權(quán)的職責(zé)示意圖

在圖5.13中，HTTP的狀態(tài)碼幫我們定義了不同的數(shù)值來區(qū)別認(rèn)證和授權(quán)的異常，通常使用401表示認(rèn)證失敗，使用403表示沒有訪問權(quán)限。

API網(wǎng)關(guān)是否需要管理授權(quán)

認(rèn)證在一開始就已經(jīng)明確了是API網(wǎng)關(guān)的核心職責(zé)，因?yàn)檎J(rèn)證邏輯一般與不同的客戶端類型有關(guān)，有足夠的通用性，不需要基礎(chǔ)服務(wù)各自實(shí)現(xiàn)，而且在圖5.11中，API網(wǎng)關(guān)通常是和客戶端類型一對(duì)一的設(shè)計(jì)，是所有接口的唯一入口，所以認(rèn)證十分適合放在API網(wǎng)關(guān)來實(shí)現(xiàn)。

那么授權(quán)是否也可以交給API網(wǎng)關(guān)來實(shí)現(xiàn)呢？

首先，我們要明白授權(quán)需要做哪些事情。授權(quán)是對(duì)資源訪問權(quán)限的控制，大致上可以分為資源路徑授權(quán)和資源授權(quán)兩種類型，又稱URL授權(quán)和數(shù)據(jù)授權(quán)。

例如，一款游戲軟件只有VIP會(huì)員才能修改頭像，假設(shè)現(xiàn)在有修改頭像的接口A，只允許角色是VIP會(huì)員的用戶才能訪問，這就是URL級(jí)別的授權(quán)，資源路徑的授權(quán)把權(quán)限放在接口層面，控制請(qǐng)求能訪問的具體接口。所謂資源授權(quán)，其實(shí)就是比資源的接口更深層次的權(quán)限控制，如VIP會(huì)員雖然能訪問修改用戶頭像的接口，但每個(gè)用戶只能修改自己的頭像，如果VIP會(huì)員在請(qǐng)求中傳入的是其他用戶的ID，這顯然不允許。我們判斷當(dāng)前修改的數(shù)據(jù)是否符合業(yè)務(wù)規(guī)則，只能修改自己的頭像就是當(dāng)前的業(yè)務(wù)規(guī)則，這就是資源授權(quán)，即數(shù)據(jù)授權(quán)。

從架構(gòu)層面來看，API網(wǎng)關(guān)是所有接口的統(tǒng)一入口，適合做一些全局限制，所以有一些項(xiàng)目會(huì)把授權(quán)放在API網(wǎng)關(guān)來實(shí)現(xiàn)，事實(shí)證明，它確實(shí)可以做到訪問的權(quán)限控制。在架構(gòu)設(shè)計(jì)中，并不是一味地封裝或分離就是好的，要具體場(chǎng)景具體分析，比較通用的判斷方法就是如果設(shè)計(jì)導(dǎo)致代碼邏輯需要重復(fù)維護(hù)多個(gè)地方，就不是很好的設(shè)計(jì)。例如，之前我們分析的授權(quán)主要與業(yè)務(wù)規(guī)則相關(guān)，與是否為移動(dòng)端或PC端沒有關(guān)系，系統(tǒng)不會(huì)因?yàn)槭鞘謾C(jī)用戶就允許修改其他人的頭像。如果把授權(quán)放在API網(wǎng)關(guān)層實(shí)現(xiàn)，那么實(shí)現(xiàn)授權(quán)如圖5.14所示。

由于授權(quán)是針對(duì)業(yè)務(wù)規(guī)則進(jìn)行控制的，無論是接口級(jí)的資源路徑授權(quán)還是數(shù)據(jù)級(jí)的資源授權(quán)都需要對(duì)代碼有一定的侵入性，因此一般授權(quán)沒有很好的方式分離成單獨(dú)服務(wù)。首先，即使是相同的授權(quán)規(guī)則，也需要在不同的API網(wǎng)關(guān)中集成相同的授權(quán)實(shí)現(xiàn)；其次，授權(quán)與業(yè)務(wù)規(guī)則強(qiáng)相關(guān)，各個(gè)微服務(wù)更加了解自己的業(yè)務(wù)規(guī)則及數(shù)據(jù)規(guī)則，如果API網(wǎng)關(guān)由不同的團(tuán)隊(duì)開發(fā)，要做好授權(quán)顯然比較困難，綜合這些原因，授權(quán)其實(shí)更適合放到業(yè)務(wù)層，即微服務(wù)各自去控制和管理，如圖5.15所示。

圖5.15 服務(wù)的業(yè)務(wù)邏輯層負(fù)責(zé)授權(quán)示意圖

這樣做的好處是首先授權(quán)邏輯可以更加通用，調(diào)用者不需要重復(fù)實(shí)現(xiàn)和維護(hù)授權(quán)的規(guī)則，其次服務(wù)端實(shí)現(xiàn)授權(quán)更加方便，而且業(yè)務(wù)邏輯層也更了解數(shù)據(jù)規(guī)則。

本文給大家講解的內(nèi)容是API網(wǎng)關(guān)

1. 下篇文章給大家講解的是傳統(tǒng)的Cookie和Session認(rèn)證；
2. 覺得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編，有需要的可以私信小編獲取；
3. 感謝大家的支持！

,