您現在的位置是：首頁 > 垂釣

Java架構師分享：微服務架構之API閘道器

由少鷹發表于垂釣
2022-01-06

簡介現在我們採用微服務架構了，在一個專案中微服務節點很多，如果讓每一個節點都去處理上面這些 “鑑權認證功能、Session處理、安全檢查、日誌處理等” 會多出很多冗餘的程式碼，也會給增加業務程式碼的複雜度，因此我們就需要有一個「 API閘道器

萬能閘道器如何解除安裝

API閘道器」是任何微服務架構的重要組成部分。有了它我們可以在一個獨立的模組上方便的處理一些非業務邏輯，可以讓微服務本身專注在自身特定的功能上，使得每個微服務的開發更容易和更快速。

後面還會有文章繼續介紹配置中心、服務框架、服務監控、服務追蹤、服務治理等。還是那句話，只有將這些基礎設施弄清楚了，微服務實踐的道路才能走的穩、走的遠。

一、為什麼需要「 API閘道器」？

為什麼做微服務的需要「 API閘道器」呢？「 API閘道器」到底有些啥功能呢？我們以前專案結構比較簡單的時候有用到過「 API閘道器」概念的模組嗎？

其實在我們的專案曾經還是單體應用的時候，雖然沒有「 API閘道器」的概念，但是一般在專案中都會用到filter/過濾器之類的東西，filter的作用就是把專案中的一些非業務邏輯的功能抽離出來獨立處理，避免與業務邏輯混在一起增加程式碼複雜度。比如鑑權認證功能、Session處理、安全檢查、日誌處理等等。

現在我們採用微服務架構了，在一個專案中微服務節點很多，如果讓每一個節點都去處理上面這些 “鑑權認證功能、Session處理、安全檢查、日誌處理等” 會多出很多冗餘的程式碼，也會給增加業務程式碼的複雜度，因此我們就需要有一個「 API閘道器」把這些公共的功能獨立出來成為一個服務來統一的處理這些事情。

我們看一下下面這個微服務架構示意圖：

「 API閘道器」就像是微服務的大門守衛一樣，是連通外部客戶端與內部微服務之間的一個橋樑。

其主要功能有：

路由轉發

之前說了「API閘道器」是內部微服務的對外唯一入口，所以外面全部的請求都會先發到這個「API閘道器」上，然後由「API閘道器」來根據不同的請求去路由到不同的微服務節點上。例如可以根據路徑來轉發、也可以根據引數來轉發。

並且由於內部微服務例項也會隨著業務調整不停的變更，增加或者刪除節點，「API閘道器」可以與「服務註冊」模組進行協同工作，保證將外部請求轉發到最合適的微服務例項上面去。

負載均衡

既然「API閘道器」是內部微服務的單一入口，所以「API閘道器」在收到外部請求之後，還可以根據內部微服務每個例項的負荷情況進行動態的負載均衡調節。一旦內部的某個微服務例項負載很高，甚至是不能及時響應，則「API閘道器」就透過負載均衡策略減少或停止向這個例項轉發請求。當所有的內部微服務例項都處理不過來的時候，「API閘道器」還可以採用限流或熔斷的形式阻止外部請求，以保障整個系統的可用性。

安全認證

「API閘道器」就像是微服務的大門守衛，每一個請求進來之後，都必須先在「API閘道器」上進行身份驗證，身份驗證通過後才轉發給後面的服務，轉發的時候一般也會帶上身份資訊。

同時「API閘道器」也需要對每一個請求進行安全性檢查，例如引數的安全性、傳輸的安全性等等。

日誌記錄

既然所有的請求都需要走「API閘道器」，那麼我們就可以在「API閘道器」上統一集中的記錄下這些行為日誌。這些日誌既可以作為我們後續事件查詢使用，也可以作為系統的效能監控使用。

資料轉換

因為「API閘道器」對外是面向多種不同的客戶端，不同的客戶端所傳輸的資料型別可能是不一樣的。因此「API閘道器」還需要具備資料轉換的功能，將不同客戶端傳輸進來的資料轉換成同一種類型再轉發給內部微服務上，這樣，相容了這些請求的多樣性，保證了微服務的靈活性。