API網關在微服務中的應用

做者：老顧

轉載請聲明出處！

前言

如今的互聯網產品技術架構，若是沒有上微服務架構，都感受被同行鄙視，太low了。在微服務架構中，不一樣的微服務有不一樣的請求地址，各個微服務之間經過互相調用完成用戶請求。客戶端要完成用戶請求，須要調用不少微服務接口。

好比：

用戶查看一個商品詳情頁，詳情頁包含了商品基本信息，商品價格，庫存信息，評論信息，促銷活動信息等，而這些信息是不一樣的微服務提供的；如：庫存服務，促銷服務，評論系統等。

用戶要查看商品詳情頁，須要讓客戶端調用多個微服務，且客戶端直接與各個微服務通訊，會有如下的問題：

一、客戶端屢次請求不一樣的微服務，增長了客戶端的複雜度。

二、屢次網絡請求，耗時增長。

三、微服務的請求地址不一樣，很容易引發跨域問題。

四、客戶端請求微服務須要保證安全認證，但每一個服務都要進行認證。

五、未來的項目重構，微服務的變化，如：把多個服務合併一個服務，或一個服務拆分多個服務；這樣會致使客戶端請求須要重構。

六、限流、降級、監控等需求，會致使實現複雜，每一個服務都要實現，重複代碼。

遇到這些問題，咱們怎麼去解決呢？咱們只要增長一個API網關。

什麼是API網關？

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

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

簡潔圖：

生產圖：

網關優勢

經過上圖中API網關作爲系通通一入口，實現了對各個微服務間的整合，同時又作到了對客戶端友好，屏蔽系統的複雜性和差別性。對比以前無API網關模式，API網關具備幾個比較重要的優勢：

一、網關能夠和微服務註冊中心鏈接，動態增長微服務應用，進行服務擴容

二、網關對於沒法訪問的服務，作到自動熔斷

三、網關能夠方便實現藍綠部署、金絲雀發佈

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

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

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

接口優化

咱們發現各個微服務的接口返回體是不同的，在以前沒有網關的時候，客戶端獲取商品id爲1的商品信息時，須要分別請求商品信息服務、價格服務、庫存服務等，才能得到完整的商品信息。客戶端自行進行數據組裝處理。有了網關這個屢次接口請求就徹底的交給網關進行處理，客戶端只要請求/good/1一個接口就好了，網關會請求多個微服務，把多個微服務返回的值進行合併，一次性返回完整的信息。簡化了客戶端請求接口的複雜性。

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

中心化

一、在實際業務中，不少提供的微服務接口，是須要身份認證的；

二、還有就是對外部的流量控制，防止流量過大，把總體系統搞崩潰；須要預估系統可以支撐的流量。

三、訪問日誌，監控分析

以上的需求，每一個微服務都須要，且跟具體業務無關；這種相似的需求，交給網關處理，再適合不過了。由網關統一處理，由於網關是入口，統一處理更加可控，簡潔。讓微服務接口作業務相關的事情上面。這就是中心化的思想，集中處理。

負載均衡

在實際的部署應用中，當應用系統面臨大量訪問，負載太高時，一般咱們會增長服務數量來進行橫向擴展，使用集羣來提升系統的處理能力。此時多個服務經過某種負載算法分攤了系統的壓力，咱們將這種多節點分攤壓力的行爲稱爲負載均衡。

網關爲入口，由網關與微服務進行交互，因此網關必需要實現負載均衡的功能；網關會獲取微服務註冊中內心面的服務鏈接地址，再配合一些算法選擇其中一個服務地址，進行處理業務。這個屬於客戶端側的負載均衡，由調用方去實現負載均衡邏輯。

主流注冊中心Eureka、Zookeeper等； 負載均衡的算法通常有隨機，輪詢，權重，負載等。

服務熔斷

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

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

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

灰度發佈

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

看看灰度發佈邏輯

在灰度發佈開始後，先啓動一個新版本應用，可是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啓動的這個新版本應用，就是咱們的金絲雀。若是沒有問題，那麼能夠將少許的用戶流量導入到新版本上，而後再對新版本作運行狀態觀察，收集各類運行時數據，若是此時對新舊版本作各類數據對比，就是所謂的 A/B測試。

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

這種發佈，經過網關就能夠很好的實現，網關經過流控模塊，進行控制分流。

現有網關框架

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

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

三、Orange：和Kong相似也是基於OpenResty的一個API網關程序，是由國人開發的。

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

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

六、apiaxle：Nodejs 實現的一個 API 網關。

七、api-umbrella：Ruby 實現的一個 API 網關。

總結

今天老顧有關網關的功能，就介紹到這裏；網關是個很是核心組件，小夥伴們要多多瞭解，實戰哦。

你的贊和關注是我繼續創做的動力~