隨著自己的電商網(wǎng)站知名度越來(lái)越高，系統(tǒng)迎來(lái)了一些“不速之客”，在凌晨的時(shí)候，系統(tǒng)中的搜索商品和用戶(hù)接口的調(diào)用量會(huì)急劇上升，持續(xù)一段時(shí)間之后又回歸正常。

這種搜索請(qǐng)求的特點(diǎn)是它們來(lái)自一組特定的設(shè)備。當(dāng)我在搜索服務(wù)上引入了設(shè)備ID的限流策略后，凌晨的高峰搜索請(qǐng)求得到了控制。然而，不久之后，用戶(hù)服務(wù)開(kāi)始受到大量爬蟲(chóng)請(qǐng)求，請(qǐng)求用戶(hù)信息，商品服務(wù)也開(kāi)始受到爬蟲(chóng)請(qǐng)求，請(qǐng)求商品信息。因此，我被迫在這兩個(gè)服務(wù)上添加了相同的限流策略。但這會(huì)引發(fā)一個(gè)問(wèn)題：相同的策略需要在多個(gè)服務(wù)中重復(fù)實(shí)現(xiàn)，無(wú)法實(shí)現(xiàn)代碼的重用。如果其他服務(wù)也面臨類(lèi)似問(wèn)題，那么就需要復(fù)制代碼，這顯然不是一個(gè)好的做法。

作為一名Java程序員，我的第一反應(yīng)是將限流功能獨(dú)立成一個(gè)可重用的JAR包供這三個(gè)服務(wù)引用。但問(wèn)題是，我們的電商團(tuán)隊(duì)不僅使用Java，還使用PHP、Go等多種編程語(yǔ)言開(kāi)發(fā)服務(wù)。對(duì)于不同編程語(yǔ)言的服務(wù)，無(wú)法直接使用Java的JAR包。這就是引入API網(wǎng)關(guān)的原因。API網(wǎng)關(guān)可以提供一種跨語(yǔ)言的解決方案，讓不同編程語(yǔ)言的服務(wù)都能夠輕松地使用相同的限流策略。

API 網(wǎng)關(guān)起到的作用

API網(wǎng)關(guān)（API Gateway）并非單一的開(kāi)源組件，而是一種架構(gòu)模式。它將一些服務(wù)共享的功能整合在一起，獨(dú)立部署為一個(gè)獨(dú)立的層級(jí)，用于解決服務(wù)治理問(wèn)題。你可以將其視為系統(tǒng)的前門(mén)，負(fù)責(zé)對(duì)系統(tǒng)的流量進(jìn)行統(tǒng)一管理。從我的角度來(lái)看，API網(wǎng)關(guān)可以分為兩種主要類(lèi)型：入口網(wǎng)關(guān)和出口網(wǎng)關(guān)。

• 入口網(wǎng)關(guān)：入口網(wǎng)關(guān)位于系統(tǒng)內(nèi)部，用于處理外部請(qǐng)求進(jìn)入系統(tǒng)的流量。它可以執(zhí)行一些重要的任務(wù)，如路由請(qǐng)求到正確的服務(wù)、身份驗(yàn)證、鑒權(quán)、限流、請(qǐng)求轉(zhuǎn)換和響應(yīng)轉(zhuǎn)換等。入口網(wǎng)關(guān)有助于管理系統(tǒng)對(duì)外部的可見(jiàn)性，并提供一致的接口。
• 出口網(wǎng)關(guān)：出口網(wǎng)關(guān)則位于系統(tǒng)內(nèi)部，用于處理系統(tǒng)內(nèi)部服務(wù)調(diào)用對(duì)外部系統(tǒng)的流量。它可以執(zhí)行任務(wù)如負(fù)載均衡、緩存、重試、錯(cuò)誤處理等，以確保內(nèi)部服務(wù)之間的通信可靠性和性能。出口網(wǎng)關(guān)通常用于隔離內(nèi)部服務(wù)和外部系統(tǒng)，同時(shí)提供一致的接口。

這兩種類(lèi)型的API網(wǎng)關(guān)可以幫助管理系統(tǒng)的邊界，提供了流量控制、安全性、性能優(yōu)化等方面的解決方案，以確保系統(tǒng)的穩(wěn)定性和可擴(kuò)展性。

入口網(wǎng)關(guān)是我們經(jīng)常使用的網(wǎng)關(guān)種類(lèi)，它部署在負(fù)載均衡服務(wù)器和應(yīng)用服務(wù)器之間，主要有幾方面的作用。

• API網(wǎng)關(guān)為客戶(hù)端提供了一個(gè)單一的入口地址，它可以根據(jù)客戶(hù)端的請(qǐng)求，動(dòng)態(tài)將請(qǐng)求路由到不同的業(yè)務(wù)服務(wù)，并執(zhí)行必要的協(xié)議轉(zhuǎn)換。在您的系統(tǒng)中，不同微服務(wù)可能以不同的協(xié)議對(duì)外提供服務(wù)：一些是HTTP服務(wù)，一些已經(jīng)改造為RPC服務(wù)，而一些可能仍然是Web服務(wù)。API網(wǎng)關(guān)的作用是將這些服務(wù)的部署地址和協(xié)議的細(xì)節(jié)對(duì)客戶(hù)端屏蔽，從而為客戶(hù)端調(diào)用帶來(lái)便利?？蛻?hù)端只需與API網(wǎng)關(guān)交互，而無(wú)需直接與各種不同協(xié)議的服務(wù)通信，使整體調(diào)用過(guò)程更加簡(jiǎn)便。

• 另一方面，在 API 網(wǎng)關(guān)中，我們可以植入一些服務(wù)治理的策略，比如服務(wù)的熔斷、降級(jí)、流量控制和分流等等。
• 再有，客戶(hù)端的認(rèn)證和授權(quán)的實(shí)現(xiàn)，也可以放在 API 網(wǎng)關(guān)中。
• 另外，API 網(wǎng)關(guān)還可以做一些與黑白名單相關(guān)的事情，比如針對(duì)設(shè)備 ID、用戶(hù) IP、用戶(hù) ID 等維度的黑白名單。
• 最后，在 API 網(wǎng)關(guān)中也可以做一些日志記錄的事情，比如記錄 HTTP 請(qǐng)求的訪(fǎng)問(wèn)日志，分布式追蹤系統(tǒng)時(shí)，提到的標(biāo)記一次請(qǐng)求的 requestId 也可以在網(wǎng)關(guān)中來(lái)生成。

圖片

出口網(wǎng)關(guān)的功能相對(duì)較簡(jiǎn)，但在系統(tǒng)開(kāi)發(fā)中也發(fā)揮著重要的作用。我們的應(yīng)用經(jīng)常需要依賴(lài)外部的第三方系統(tǒng)，比如第三方賬戶(hù)登錄或支付服務(wù)。在這種情況下，我們可以在應(yīng)用服務(wù)器和外部系統(tǒng)之間部署出口網(wǎng)關(guān)，用于統(tǒng)一處理對(duì)外部API的認(rèn)證、授權(quán)、審計(jì)和訪(fǎng)問(wèn)控制等任務(wù)。這樣可以幫助我們更好地管理和保護(hù)與外部系統(tǒng)的通信，確保系統(tǒng)的安全性和合規(guī)性。

圖片

API 網(wǎng)關(guān)要如何實(shí)現(xiàn)

了解了API網(wǎng)關(guān)的作用后，下一步是關(guān)注在實(shí)施API網(wǎng)關(guān)時(shí)需要注意的關(guān)鍵方面，以及了解一些常見(jiàn)的開(kāi)源API網(wǎng)關(guān)解決方案。這將使您在實(shí)際工作中，不論是考慮自主開(kāi)發(fā)API網(wǎng)關(guān)還是使用現(xiàn)有的開(kāi)源實(shí)現(xiàn)，都能更自如地做出決策。

在開(kāi)發(fā)API網(wǎng)關(guān)時(shí)，首要考慮的是其性能。這非常重要，因?yàn)锳PI入口網(wǎng)關(guān)需要處理所有來(lái)自客戶(hù)端的流量。舉個(gè)例子來(lái)說(shuō)，假設(shè)業(yè)務(wù)服務(wù)的處理時(shí)間是10毫秒，而API網(wǎng)關(guān)的處理時(shí)間是1毫秒，那么相當(dāng)于每個(gè)接口的響應(yīng)時(shí)間都要增加10%，這將對(duì)性能產(chǎn)生巨大的影響。性能的關(guān)鍵通常在于I/O模型的選擇，這里只是舉一個(gè)例子來(lái)說(shuō)明I/O模型對(duì)性能的影響

在Netflix開(kāi)源的API網(wǎng)關(guān)Zuul的1.0版本中，采用的是同步阻塞I/O模型。整體系統(tǒng)可以看作是一個(gè)Servlet，它接收用戶(hù)的請(qǐng)求，然后在網(wǎng)關(guān)中執(zhí)行配置的認(rèn)證、協(xié)議轉(zhuǎn)換等邏輯，最后調(diào)用后端服務(wù)獲取數(shù)據(jù)并返回給用戶(hù)。

在Zuul 2.0中，Netflix團(tuán)隊(duì)進(jìn)行了重大改進(jìn)。他們將原本的Servlet轉(zhuǎn)變?yōu)榱艘粋€(gè)Netty服務(wù)器，采用了I/O多路復(fù)用模型來(lái)處理傳入的I/O請(qǐng)求。同時(shí)，他們還對(duì)之前的同步阻塞方式調(diào)用后端服務(wù)進(jìn)行了改進(jìn)，采用了非阻塞方式的Netty客戶(hù)端調(diào)用。經(jīng)過(guò)這些改進(jìn)，Netflix團(tuán)隊(duì)測(cè)試發(fā)現(xiàn)性能提升了約20%。

API網(wǎng)關(guān)的功能可以分為兩種類(lèi)型：一種是可以預(yù)先定義和配置的，如黑白名單設(shè)置、接口動(dòng)態(tài)路由等；另一種需要根據(jù)具體業(yè)務(wù)來(lái)定義和實(shí)現(xiàn)。因此，在API網(wǎng)關(guān)的設(shè)計(jì)中，關(guān)注擴(kuò)展性是非常重要的。這意味著您可以隨時(shí)在執(zhí)行鏈路上添加自定義邏輯，也可以隨時(shí)移除不需要的邏輯，實(shí)現(xiàn)所謂的熱插拔功能。這種靈活性允許根據(jù)不同的業(yè)務(wù)需求自定義API網(wǎng)關(guān)的行為，使其更具通用性和適應(yīng)性。

通常情況下，我們可以將每個(gè)操作定義為一個(gè)過(guò)濾器（filter），然后使用責(zé)任鏈模式將這些過(guò)濾器串起來(lái)。責(zé)任鏈模式允許我們動(dòng)態(tài)地組織這些過(guò)濾器，使它們之間解耦。這意味著我們可以隨時(shí)添加或移除過(guò)濾器，而不會(huì)對(duì)其他過(guò)濾器產(chǎn)生影響。這種模式使得我們可以靈活地定制API網(wǎng)關(guān)的行為，根據(jù)具體需求來(lái)構(gòu)建過(guò)濾器鏈，無(wú)需擔(dān)心過(guò)濾器之間的相互影響。

Zuul采用責(zé)任鏈模式來(lái)處理請(qǐng)求。在Zuul 1中，它將過(guò)濾器定義為三種類(lèi)型：預(yù)處理過(guò)濾器（pre routing filter）、路由過(guò)濾器（routing filter）和后處理過(guò)濾器（after routing filter）。每個(gè)過(guò)濾器都定義了執(zhí)行的順序，在注冊(cè)過(guò)濾器時(shí)，它們會(huì)按照順序插入到過(guò)濾器鏈中。這意味著當(dāng)Zuul接收到請(qǐng)求時(shí)，它會(huì)按照順序依次執(zhí)行過(guò)濾器鏈中插入的過(guò)濾器。這種方式使得可以在請(qǐng)求處理過(guò)程中輕松應(yīng)用各種過(guò)濾器，以實(shí)現(xiàn)不同類(lèi)型的操作。

圖片

此外，還需要特別注意，為了提高網(wǎng)關(guān)對(duì)請(qǐng)求的并行處理能力，通常會(huì)使用線(xiàn)程池來(lái)同時(shí)處理多個(gè)請(qǐng)求。然而，這也帶來(lái)了一個(gè)問(wèn)題：如果商品服務(wù)響應(yīng)緩慢，導(dǎo)致調(diào)用商品服務(wù)的線(xiàn)程被阻塞，無(wú)法釋放，隨著時(shí)間的推移，線(xiàn)程池中的線(xiàn)程可能會(huì)被商品服務(wù)所占用，從而影響其他服務(wù)。因此，我們需要考慮針對(duì)不同的服務(wù)采取線(xiàn)程隔離或保護(hù)的策略。從我看來(lái)，有兩種主要思路來(lái)應(yīng)對(duì)這個(gè)問(wèn)題：

如果你后端的服務(wù)拆分得不多，可以針對(duì)不同的服務(wù)，采用不同的線(xiàn)程池，這樣商品服務(wù)的故障就不會(huì)影響到支付服務(wù)和用戶(hù)服務(wù)了；

在線(xiàn)程池內(nèi)部可以針對(duì)不同的服務(wù)甚至不同的接口做線(xiàn)程的保護(hù)。比如說(shuō)，線(xiàn)程池的最大線(xiàn)程數(shù)是 1000，那么可以給每個(gè)服務(wù)設(shè)置一個(gè)最多可以使用的配額。

通常情況下，服務(wù)的執(zhí)行時(shí)間應(yīng)該非常快，通常在毫秒級(jí)別。使用線(xiàn)程后，線(xiàn)程應(yīng)迅速釋放回線(xiàn)程池，以供后續(xù)請(qǐng)求使用。同時(shí)，系統(tǒng)中運(yùn)行的執(zhí)行中線(xiàn)程數(shù)量應(yīng)該保持較低水平，不會(huì)大量增加，這樣可以確保服務(wù)或接口的線(xiàn)程配額不會(huì)對(duì)正常執(zhí)行產(chǎn)生影響。

然而，一旦發(fā)生故障，某個(gè)接口或服務(wù)的響應(yīng)時(shí)間變慢，可能會(huì)導(dǎo)致線(xiàn)程數(shù)大幅增加。但由于有線(xiàn)程配額的限制，這不會(huì)對(duì)其他接口或服務(wù)產(chǎn)生負(fù)面影響。這種方式有助于隔離故障，確保故障不會(huì)蔓延到整個(gè)系統(tǒng)。

你在實(shí)際應(yīng)用中也可以將這兩種方式結(jié)合，比如說(shuō)針對(duì)不同的服務(wù)使用不同的線(xiàn)程池，在線(xiàn)程池內(nèi)部針對(duì)不同的接口設(shè)置配額。

如何在你的系統(tǒng)中引入 API 網(wǎng)關(guān)

目前，我們的電商系統(tǒng)已經(jīng)經(jīng)歷了服務(wù)化改造，其中在服務(wù)層和客戶(hù)端之間引入了一個(gè)薄薄的Web層。這個(gè)Web層承擔(dān)兩項(xiàng)主要任務(wù)：首先，它負(fù)責(zé)對(duì)服務(wù)層接口數(shù)據(jù)進(jìn)行聚合。舉例來(lái)說(shuō)，商品詳情頁(yè)面的接口可能會(huì)聚合多個(gè)服務(wù)接口的數(shù)據(jù)，包括商品信息、用戶(hù)信息、店鋪信息以及用戶(hù)評(píng)論等。其次，Web層需要將HTTP請(qǐng)求轉(zhuǎn)換為RPC請(qǐng)求，并對(duì)前端的流量進(jìn)行一些限制，例如為某些請(qǐng)求添加設(shè)備ID的黑名單等。

因此，在進(jìn)行改造時(shí)，我們可以首先將API網(wǎng)關(guān)從Web層中獨(dú)立出來(lái)，將協(xié)議轉(zhuǎn)換、限流、黑白名單等功能移到API網(wǎng)關(guān)中進(jìn)行處理，形成一個(gè)獨(dú)立的入口網(wǎng)關(guān)層。而對(duì)于服務(wù)接口數(shù)據(jù)聚合的操作，

通常有兩種解決思路：一種是獨(dú)立出一組網(wǎng)關(guān)，專(zhuān)門(mén)負(fù)責(zé)流量聚合和超時(shí)控制，我們通常稱(chēng)其為流量網(wǎng)關(guān)；

另一種是將接口聚合操作提取到一個(gè)獨(dú)立的服務(wù)層中。這樣，服務(wù)層可以大致分為原子服務(wù)層和聚合服務(wù)層。

在我看來(lái)，接口數(shù)據(jù)聚合屬于業(yè)務(wù)操作，與其將其置于通用的網(wǎng)關(guān)層實(shí)現(xiàn)，不如將其放在更貼近業(yè)務(wù)的服務(wù)層中實(shí)現(xiàn)。因此，我更傾向于第二種方案。這種方式有助于更好地劃分職責(zé)，使系統(tǒng)更模塊化和可維護(hù)。

圖片

同時(shí)，我們可以在系統(tǒng)和第三方支付服務(wù)，以及登陸服務(wù)之間部署出口網(wǎng)關(guān)服務(wù)。原先，你會(huì)在拆分出來(lái)的支付服務(wù)中完成對(duì)于第三方支付接口所需要數(shù)據(jù)的加密、簽名等操作，再調(diào)用第三方支付接口完成支付請(qǐng)求。現(xiàn)在，你把對(duì)數(shù)據(jù)的加密、簽名的操作放在出口網(wǎng)關(guān)中，這樣一來(lái)，支付服務(wù)只需要調(diào)用出口網(wǎng)關(guān)的統(tǒng)一支付接口就可以了。

在引入了 API 網(wǎng)關(guān)之后，我們的系統(tǒng)架構(gòu)就變成了下面這樣：

圖片

強(qiáng)調(diào)的重點(diǎn)：

API網(wǎng)關(guān)可以劃分為兩類(lèi)：入口網(wǎng)關(guān)和出口網(wǎng)關(guān)。入口網(wǎng)關(guān)具有多種功能，包括隔離客戶(hù)端和微服務(wù)、提供協(xié)議轉(zhuǎn)換、實(shí)施安全策略、進(jìn)行認(rèn)證、限流以及實(shí)現(xiàn)熔斷等功能。出口網(wǎng)關(guān)的主要作用是為調(diào)用第三方服務(wù)提供統(tǒng)一的出口，它可以執(zhí)行統(tǒng)一的認(rèn)證、授權(quán)、審計(jì)和訪(fǎng)問(wèn)控制等任務(wù)，以確保與外部系統(tǒng)的通信安全和合規(guī)。

API網(wǎng)關(guān)的關(guān)鍵在于性能和可擴(kuò)展性的實(shí)現(xiàn)。為了提高網(wǎng)關(guān)的性能，可以采用多路I/O復(fù)用模型和線(xiàn)程池并發(fā)處理請(qǐng)求。而為了提升網(wǎng)關(guān)的可擴(kuò)展性，可以使用責(zé)任鏈模式來(lái)組織和管理過(guò)濾器，以便輕松添加、移除或修改過(guò)濾器，以滿(mǎn)足不同的需求。

API 網(wǎng)關(guān)中的線(xiàn)程池可以針對(duì)不同的接口或者服務(wù)做隔離和保護(hù)，這樣可以提升網(wǎng)關(guān)的可用性；

API 網(wǎng)關(guān)可以替代原本系統(tǒng)中的 Web 層，將 Web 層中的協(xié)議轉(zhuǎn)換、認(rèn)證、限流等功能挪入到 API 網(wǎng)關(guān)中，將服務(wù)聚合的邏輯下沉到服務(wù)層。

API網(wǎng)關(guān)不僅提供了方便的API調(diào)用方式，還能將一些服務(wù)治理功能獨(dú)立出來(lái)，以實(shí)現(xiàn)更好的復(fù)用性。盡管在性能方面可能會(huì)有一些犧牲，但通常情況下，使用成熟的開(kāi)源API網(wǎng)關(guān)組件，這些性能損失是可以接受的。因此，當(dāng)您的微服務(wù)系統(tǒng)變得越來(lái)越復(fù)雜時(shí)，可以考慮將API網(wǎng)關(guān)作為整個(gè)系統(tǒng)的門(mén)面，以簡(jiǎn)化系統(tǒng)架構(gòu)并提供更好的可維護(hù)性。