微服務架構之「 API網關 」

在微服務架構的系列文章中,前面已經經過文章《架構設計之「服務註冊 」》介紹過了服務註冊的原理和應用,今天這篇文章咱們來聊一聊「 API網關 」。後端

「 API網關 」是任何微服務架構的重要組成部分。有了它咱們能夠在一個獨立的模塊上方便的處理一些非業務邏輯,可讓微服務自己專一在自身特定的功能上,使得每一個微服務的開發更容易和更快速。安全

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

1、爲何須要「 API網關 」?

爲何作微服務的須要「 API網關 」呢?「 API網關 」到底有些啥功能呢?咱們之前項目結構比較簡單的時候有用到過「 API網關 」概念的模塊嗎?架構

其實在咱們的項目曾經仍是單體應用的時候,雖然沒有「 API網關 」的概念,可是通常在項目中都會用到filter/過濾器之類的東西,filter的做用就是把項目中的一些非業務邏輯的功能抽離出來獨立處理,避免與業務邏輯混在一塊兒增長代碼複雜度。好比 鑑權認證功能、Session處理、安全檢查、日誌處理等等。負載均衡

如今咱們採用微服務架構了,在一個項目中微服務節點不少,若是讓每個節點都去處理上面這些 「鑑權認證功能、Session處理、安全檢查、日誌處理等」 會多出不少冗餘的代碼,也會給增長業務代碼的複雜度,所以咱們就須要有一個「 API網關 」把這些公共的功能獨立出來成爲一個服務來統一的處理這些事情。框架

咱們看一下下面這個微服務架構示意圖:微服務

「 API網關 」就像是微服務的大門守衛同樣,是連通外部客戶端與內部微服務之間的一個橋樑。post

其主要功能有:性能

  • 路由轉發大數據

    以前說了「API網關」是內部微服務的對外惟一入口,因此外面所有的請求都會先發到這個「API網關」上,而後由「API網關」來根據不一樣的請求去路由到不一樣的微服務節點上。例如能夠 根據路徑 來轉發、也能夠 根據參數 來轉發。

    而且因爲內部微服務實例也會隨着業務調整不停的變動,增長或者刪除節點,「API網關」能夠與「服務註冊」模塊進行協同工做,保證將外部請求轉發到最合適的微服務實例上面去。

  • 負載均衡

    既然「API網關」是內部微服務的單一入口,因此「API網關」在收到外部請求以後,還能夠根據內部微服務每一個實例的負荷狀況進行動態的負載均衡調節。一旦內部的某個微服務實例負載很高,甚至是不能及時響應,則「API網關」就經過負載均衡策略減小或中止向這個實例轉發請求。當全部的內部微服務實例都處理不過來的時候,「API網關」還能夠採用限流或熔斷的形式阻止外部請求,以保障整個系統的可用性。

  • 安全認證

    「API網關」就像是微服務的大門守衛,每個請求進來以後,都必須先在「API網關」上進行身份驗證,身份驗證經過後才轉發給後面的服務,轉發的時候通常也會帶上身份信息。

    同時「API網關」也須要對每個請求進行安全性檢查,例如參數的安全性、傳輸的安全性等等。

  • 日誌記錄

    既然全部的請求都須要走「API網關」,那麼咱們就能夠在「API網關」上統一集中的記錄下這些行爲日誌。這些日誌既能夠做爲咱們後續事件查詢使用,也能夠做爲系統的性能監控使用。

  • 數據轉換

    由於「API網關」對外是面向多種不一樣的客戶端,不一樣的客戶端所傳輸的數據類型多是不同的。所以「API網關」還須要具有數據轉換的功能,將不一樣客戶端傳輸進來的數據轉換成同一種類型再轉發給內部微服務上,這樣,兼容了這些請求的多樣性,保證了微服務的靈活性。

2、「 API網關 」原理與應用?

上面聊完了「爲何須要API網關」,咱們再來看一下在實際項目中應該如何去應用。雖然咱們能夠本身去開發一套「API網關」,可是若是沒有特殊需求,仍是不建議重複造輪子了,市面上有不少成熟的方案能夠直接使用,下面簡單介紹一下 Zuul、Tyk、Kong三個比較熱門的開源組件。

  • Zuul

    Zuul 是由 Netflix 所開源的組件,基於JAVA技術棧開發的。

    Zuul網關的使用熱度很是高,而且也集成到了 Spring Cloud 全家桶中了,使用起來很是方便。

    上圖能夠看到Zuul的一個簡化結構,過濾器filter是整個Zuul的核心,分爲前置過濾器(pre filter)、路由過濾器(routing filter)、後置過濾器(post filter)以及 錯誤過濾器(error filter)。

    一個請求過來,會先執行全部的 pre filter,而後再經過 routing filter 將請求轉發給後端服務,後端服務進行結果響應以後,再執行 post filter,最後再響應給客戶端。在不一樣的filter裏面能夠執行不一樣的邏輯,好比安全檢查、日誌記錄等等。

  • Tyk

    Tyk是一個基於GO編寫的,輕量級、快速可伸縮的開源的API網關。

    能夠經過下圖簡單瞭解一下Tyk的流程原理。

  • Kong

    Kong是基於OpenResty技術棧的開源網關服務,所以其也是基於Nginx實現的。

    Kong能夠作到高性能、插件自定義、集羣以及易於使用的Restful API管理。

以上,就是對微服務架構中「 服務網關」的一些思考。

碼字不易啊,喜歡的話不妨轉發朋友吧。😊

本文原創發佈於微信公衆號「 不止思考 」,歡迎關注。涉及 思惟認知、我的成長、架構、大數據、Web技術 等。

 

相關文章
相關標籤/搜索