API網關在微服務架構中的應用,這一篇就夠了


目錄

  1. 前言
  2. 什麼是API網關
  3. 網關優點
  4. 接口優化
  5. 中心化
  6. 負載均衡
  7. 服務熔斷
  8. 灰度發佈
  9. 現有網關框架
  10. 總結

前言

現在的互聯網產品技術架構,如果沒有上微服務架構,都感覺被同行鄙視,太low了。在微服務架構中,不同的微服務有不同的請求地址,各個微服務之間通過互相調用完成用戶請求。客戶端要完成用戶請求,需要調用很多微服務接口。比如:

用戶查看一個商品詳情頁,詳情頁包含了商品基本信息,商品價格,庫存信息,評論信息,促銷活動信息等,

而這些信息是不同的微服務提供的;如:庫存服務,促銷服務,評論系統等。

API網關在微服務架構中的應用,這一篇就夠了

用戶要查看商品詳情頁,需要讓客戶端調用多個微服務,且客戶端直接與各個微服務通信,會有以下的問題:

1、客戶端多次請求不同的微服務,增加了客戶端的複雜度。

2、多次網絡請求,耗時增加

3、微服務的請求地址不同,很容易引起跨域問題

4、客戶端請求微服務需要保證安全認證,但每個服務都要進行認證

5、將來的項目重構,微服務的變化,如:把多個服務合併一個服務,或一個服務拆分多個服務;這樣會導致客戶端請求需要重構

6、限流、降級、監控等需求

,會導致實現複雜,每個服務都要實現,重複代碼。

遇到這些問題,我們怎麼去解決呢?我們只要增加一個API網關。

什麼是API網關?

API網關是一個服務器,是系統的唯一入口。從面向對象設計的角度看,它與外觀模式類似。API網關封裝了系統內部架構,為每個客戶端提供一個API入口

API擁有一些職責,如身份驗證、監控、負載均衡、緩存、流控。API網關方式的核心要點是,所有客戶端和消費端都通過統一的網關接入微服務,在網關層處理所有的非業務功能。

簡潔圖:

API網關在微服務架構中的應用,這一篇就夠了

生產圖:

API網關在微服務架構中的應用,這一篇就夠了

網關優點

通過上圖中API網關做為系統統一入口,實現了對各個微服務間的整合,同時又做到了對客戶端友好,屏蔽系統的複雜性和差異性

。對比之前無API網關模式,API網關具有幾個比較重要的優點:

1、網關可以和微服務註冊中心連接,動態增加微服務應用,進行服務擴容

2、網關對於無法訪問的服務,做到自動熔斷

3、網關可以方便實現藍綠部署、金絲雀發佈

4、網關可處理微服務公共需求,簡化微服務職責

5、網關可幫助客戶端實現負載均衡

下面老顧就用圖解的方式進行說明

接口優化

API網關在微服務架構中的應用,這一篇就夠了

我們發現各個微服務的接口返回體是不一樣的,在之前沒有網關的時候,客戶端獲取商品id為1的商品信息時,需要分別請求商品信息服務、價格服務、庫存服務等,才能獲得完整的商品信息。客戶端自行進行數據組裝處理。

有了網關這個多次接口請求就完全的交給網關進行處理,客戶端只要請求/good/1一個接口就行了,網關會請求多個微服務,把多個微服務返回的值進行合併,一次性返回完整的信息。簡化了客戶端請求接口的複雜性。

注意:有些業務數據,不一定要同步返回給客戶端,也許異步會更好,根據用戶體驗,業務需求而定。如:促銷價格的話,也許就需要客戶端單獨去請求了,而不是跟商品基礎信息一起同步返回。具體要看業務哦

中心化

API網關在微服務架構中的應用,這一篇就夠了

1、在實際業務中,很多提供的微服務接口,是需要身份認證的;

2、還有就是對外部的流量控制,防止流量過大,把整體系統搞崩潰;需要預估系統能夠支撐的流量。

3、訪問日誌,監控分析

以上的需求,每個微服務都需要,且跟具體業務無關;這種類似的需求,交給網關處理,再適合不過了。由

網關統一處理,因為網關是入口,統一處理更加可控,簡潔。讓微服務接口做業務相關的事情上面。這就是中心化的思想,集中處理

負載均衡

API網關在微服務架構中的應用,這一篇就夠了

在實際的部署應用中,當應用系統面臨大量訪問,負載過高時,通常我們會增加服務數量來進行

橫向擴展,使用集群來提高系統的處理能力。此時多個服務通過某種負載算法分攤了系統的壓力,我們將這種多節點分攤壓力的行為稱為負載均衡

網關為入口,由網關與微服務進行交互,所以網關必須要實現負載均衡的功能;網關會獲取微服務註冊中心裡面的服務連接地址,再配合一些算法選擇其中一個服務地址,進行處理業務。這個屬於客戶端側的負載均衡,由調用方去實現負載均衡邏輯。

主流注冊中心Eureka、Zookeeper等;負載均衡的算法一般有隨機,輪詢,權重,負載等。

服務熔斷

API網關在微服務架構中的應用,這一篇就夠了

在現實生產環境中,會經常遇到某個服務突然停止了工作,然後返回了大量的錯誤。這個時間API網關可以實現斷路器(circuit breakers)的能力,也就是說超過了指定的閾值,API網關就會停止發送請求到那些失敗的服務。

這樣就給了我們時間來分析日誌,實現修復以及發包更新。通常當你發現一個模塊下的某個實例失敗後,這時候這個模塊依然還會接收流量,然後這個有問題的模塊還調用了其他的模塊,這樣就會發生級聯故障,或者叫雪崩

斷路器通過簡單的斷開流量的方式,這樣就不會有新的請求到達那些有問題的實例,這時候我們就有相對充分的時間來修復和解決問題

灰度發佈

又稱金絲雀發佈,起源是,礦井工人發現,金絲雀對瓦斯氣體很敏感,礦工會在下井之前,先放一隻金絲雀到井中,如果金絲雀不叫了,就代表瓦斯濃度高。

API網關在微服務架構中的應用,這一篇就夠了

看看灰度發佈邏輯

在灰度發佈開始後,先啟動一個新版本應用,但是並不直接將流量切過來,而是測試人員對新版本進行線上測試,啟動的這個新版本應用,就是我們的金絲雀。如果沒有問題,那麼可以將少量的用戶流量導入到新版本上,然後再對新版本做運行狀態觀察,收集各種運行時數據,如果此時對

新舊版本做各種數據對比,就是所謂的A/B測試。

新版本沒什麼問題,那麼逐步擴大範圍、流量,把所有用戶都遷移到新版本上面來

這種發佈,通過網關就可以很好的實現,網關通過流控模塊,進行控制分流。

現有網關框架

1、Tyk:Tyk是一個開放源碼的API網關,它是快速、可擴展和現代的。Tyk提供了一個API管理平臺,其中包括API網關、API分析、開發人員門戶和API管理面板。Trk 是一個基於Go實現的網關服務。

2、Kong:Kong是一個可擴展的開放源碼API Layer(也稱為API網關或API中間件)。Kong 在任何RESTful API的前面運行,通過插件擴展,它提供了超越核心平臺的額外功能和服務。

3、Orange:和Kong類似也是基於OpenResty的一個API網關程序,是由國人開發的。

4、Netflix zuul:

Zuul是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。

5、Spring Cloud Gateway:Spring Cloud Gateway是基於Spring 框架5.0版本和Spring Boot 2.0的版本構建,提供路由等功能。

6、apiaxle:Nodejs 實現的一個 API 網關。

7、api-umbrella: Ruby 實現的一個 API 網關。

總結

今天老顧有關網關的功能,就介紹到這裡;網關是個非常核心組件,小夥伴們要多多瞭解,實戰哦。


---End---

最近老顧上傳了微服務網關的分享課程,請大家多多支持

1、

2、

3、

4、

5、

6、

7、

8、

9、

10、

11、

12、

13、

14、

15、

16、

17、

18、

19、

20、

21、

22、

23、

24、

25、

26、

27、

28、

29、

30、

31、

32、

33、

34、


分享到:


相關文章: