淺談微服務之API網關

在微服務架構中，API Gateway作為整體架構的重要組件，它抽象了微服務中都需要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度發布，統一認證，限流流控，日誌統計等豐富的功能，幫助我們解決很多API管理難題。

淺談API網關

一

作者說

隨著微服務的大紅大紫，大家紛紛使用微服務架構來實現新系統或進行老系統的改造。當然，微服務帶給我們太多的好處，同時也帶給我們許多的問題需要解決。採用微服務後，所有的服務都變成了一個個細小的API，那麼這些服務API該怎麼正確的管理？API認證授權如何實現？如何實現服務的負載均衡，熔斷，灰度發布，限流流控？如何合理的治理這些API服務尤其重要。

什麼是API網關

API網關是一個伺服器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、流控。API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

為什麼需要API網關

從部署結構上說，下圖是不採用API Gateway的微服務部署模式，我們可以清晰看到，這種部署模式下，客戶端與負載均衡器直接交互，完成服務的調用。但這是這種模式下，也有它的不足。

第一、不支持動態擴展，如果發生服務實例新增、下線、IP或者埠變動等，需要修改負載均衡器的配置。

第二、無法做到動態的開關服務，若要下線某個服務，需要運維人員將服務地址從負載均衡器中移除。

第三、對於API的限流，安全等控制，需要每個微服務去自己實現，增加了微服務的複雜性，同時也違反了微服務設計的單一職責原則。

上圖為採用API Gateway模式，通過圖中可以看到，API Gateway做為系統統一入口，實現了對各個微服務間的整合，同時又做到了對客戶端友好，屏蔽系統的複雜性和差異性。對比之前無API Gateway模式，API Gateway具有幾個比較重要的優點：

第一、採用API Gateway可以與微服務註冊中心連接，實現微服務無感知動態擴容。

第二、API Gateway對於無法訪問的服務，可以做到自動熔斷，無需人工參與。

第三、API Gateway可以方便的實現藍綠部署，金絲雀發布或A/B發布。

第四、API Gateway做為系統統一入口，我們可以將各個微服務公共功能放在API Gateway中實現，以儘可能減少各服務的職責。

第五、幫助我們實現客戶端的負載均衡策略。

API網關核心特性

01.負載策略

在實際的部署應用中，當應用系統面臨大量訪問，負載過高時，通常我們會增加服務數量來進行橫向擴展，使用集群來提高系統的處理能力。此時多個服務通過某種負載演算法分攤了系統的壓力，我們將這種多節點分攤壓力的行為稱為負載均衡。

負載均衡分為服務端負載和客戶端側負載。服務端側負載在訪問者和目標服務之間架設LB硬體或者軟體中間件，硬體流行的有F5，中間件主流的有Apache、Nginx、HAProxy、KeepAlived等。

請求首先發送到負載均衡伺服器，負載均衡伺服器根據一定演算法，將請求轉發給後端伺服器之中的一個。服務端側負載軟硬體技術成熟，效率也高。不過後端伺服器變動需要修改負載均衡伺服器的配置，略有不便，且需要對負載均衡伺服器本身實現高可用，增加了部署和維護成本。

客戶端側負載有所不同，後端伺服器的地址列表不再由負載均衡伺服器存儲和維護，而是每個客戶端都會存儲在本地。後端伺服器啟動時自動向註冊中心註冊服務，服務下線時服務註冊中心也能獲知。客戶端建立對服務註冊中心的長監聽，每當後端服務發生變化，註冊中心自動通知客戶端更新本地緩存的伺服器列表。

目前主流的服務註冊中心由Eureka、Zookeeper等。客戶端側負載的好處是方便，後端服務變化對客戶端是透明的。但是相比服務端負載，客戶端側負載對後端服務有要求，不是所有的後端服務都能做客戶端側負載。

目前流行的API Gateway有Spring Cloud Zuul，Zuul默認使用Ribbon實現客戶端側負載，利用服務註冊中心可知道所有後端服務的地址和狀態，通過負載均衡演算法，儘可能均衡的轉發請求到後台微服務。

Ribbon支持的負載均衡策略即是網關支持的，其默認提供的負載均衡策略包括主要包括以下內容。

02.服務熔斷

在實際生產中，一些服務很有可能因為某些原因發生故障而不可用，比如服務內部錯誤、網路延遲等，如果放任故障服務不管，可能會因為級聯故障導致雪崩效應，使得整個系統癱瘓。為此，我們需要對不可用服務的調用快速失敗。

Spring Cloud提供了Hystrix組件來實現這一點。當某服務在短時間內多次發生調用失敗，服務消費方的斷路器會被斷開。開路的斷路器就像電路跳閘一樣，阻止消費方向故障服務發送請求，直接返回失敗或者執行消費方的降級邏輯。斷路器通常在一定時間後關閉，在這期間可以為底層服務提供足夠的空間來恢復。

理解斷路器需要了解以下幾點：

第一、斷路器只是作用在服務調用這一端。

第二、服務的健康狀況 = 請求失敗數 / 請求總數。

第三、斷路器開關由關閉到打開的狀態轉換是通過當前服務健康狀況和設定閾值比較決定的。

第四、關閉時, 請求被允許通過斷路器. 如果當前健康狀況高於設定閾值, 開關繼續保持關閉. 如果當前健康狀況低於設定閾值, 開關則切換為打開狀態。

第五、打開狀態, 經過一段時間後, 斷路器會自動進入半開狀態, 這時斷路器只允許一個請求通過. 當該請求調用成功時, 斷路器恢復到關閉狀態. 若該請求失敗, 斷路器繼續保持打開狀態, 接下來的請求被禁止通過。

第六、保證服務調用者在調用異常服務時, 快速返回結果, 避免大量的同步等待。

第七、在一段時間後繼續偵測請求執行結果, 提供恢復服務調用的可能。

API網關作為服務請求的統一入口，負責轉發請求到後端服務。對於所有後端服務來說，網關就是服務請求方。所以，在網關上配置斷路器是最佳實踐。Spring Cloud Zuul默認提供了對Hystrix的支持。

03.流控

流控的目的主要是防止短時間內大量請求轉發到後台壓垮伺服器，比如典型的DDos攻擊，惡意攻擊者操控大量殭屍機器，持續向目標伺服器發送大量請求，讓伺服器忙於應付而無暇處理正常用戶的請求，達到癱瘓伺服器的目的。為了防止這種情況出現，API網關應對請求做限流，即流量控制也叫流控。API網關統計一個時間窗口內針對某服務的請求數量，如果超過一定的閾值，則應拒絕繼續轉發請求到後端服務。時間窗口是滑動窗口，下一個時間窗口到來時，計數器清零。

計數器被並發請求訪問，如果設置為線程安全的，則並發性能大大降低，限流將成為服務的性能瓶頸，如果計數器不做線程並發控制，則可能導致計數錯誤。針對這個問題，可使用Redis解決。利用Redis的單線程模型和高性能的並發支持，可以在保證高並發下計數器計數準確。

流控的時間窗口設置不宜太大，因為請求數量有高峰和低谷，請求洪峰到來時可能短時間內將配額用盡，如果時間窗口過大，則窗口內其他時間裡會一直拒絕請求，即便後端服務此時壓力已經不大，這樣流控的效果很差。流控時間窗口也不宜過小，否則損耗在流控計算上的資源代價太大，得不償失。流控的閾值設置不能靠拍腦袋評估，需要在嚴謹的性能壓力測試基礎上得出。根據經驗，可以將流控時間窗口設置為1秒，請求數量設置為服務的壓測TPS數。

04.認證鑒權

從單體應用架構到分散式應用架構再到微服務架構，應用的安全訪問在不斷的經受考驗。單體應用體系下，應用是一個整體，一般針對所有的請求都會進行許可權校驗。請求一般會通過一個許可權攔截器進行許可權校驗，在登錄時將用戶信息緩存到會話Session中，後續訪問則從會話中獲取用戶信息。

而在微服務架構下，一個應用被拆分為若干個微應用，每個微應用都需要對訪問進行鑒權，每個微應用都需要明確當前訪問用戶及其許可權，單體應用架構下的鑒權方式就不適合了。為了適應架構的變化，身份認證與鑒權方案也在不斷的變革。面對數十個甚至上百個微服務之間的調用，如何保證高效安全的身份認證，如何提供細粒度的鑒權方案，是亟待解決的問題。

API網關作為服務訪問的統一入口，所有用戶請求都會過API網關，很適合用來做認證鑒權這類切面型服務。網關可以攔截用戶請求，獲取請求中附帶的用戶身份信息，調用認證授權中心的服務，對請求者做身份認證，即確認當前訪問者確實是其所聲稱的身份，檢查該用戶是否有訪問該後台服務的許可權。

目前主流的認證鑒權方案有2種。

第一種是引入Redis做分散式會話，即用戶登錄成功後，將用戶身份、許可權信息存入Redis，以一個唯一ID作為Key，並設置信息在Redis里的失效時間。這個唯一ID的Key將返回給客戶端，客戶端可以放入Cookie，sessionStorage等處做本地存儲。下次訪問的時候，將這個唯一ID放入請求參數中一起發送（一般放入Header）。服務端通過檢查Redis里有無這個ID來判斷用戶是否登錄，獲取用戶身份和許可權信息。客戶端如果長時間沒有操作，則存儲在Redis里會話信息過期自動刪除。客戶端每訪問一次服務端，需刷新一次會話信息的過期時間，避免固定過期時間帶來的低用戶體驗。

第二種是JWT，即Java Web Token。用戶登錄成功後，服務端向客戶端返回的唯一ID不再是無意義的字元串，而是包含了用戶身份、許可權、失效時間等信息的加密字元串。並且這個字元串包含數字簽名，服務端可對這個字元串做數字簽名驗簽，確保該字元串未經篡改和偽造。相比分散式會話方案，JWT雖省去了Redis存儲，但是每次訪問都要做數字簽名驗證，增加了CPU的資源損耗。

05.灰度發布

服務發布上線過程中，我們不可能將新版本全部部署在生產環節中，因為新版本並沒有接受真實用戶、真實數據、真實環境的考驗，此時我們需要進行灰度發布，灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，同時影響小。API Gateway可以幫助我們輕鬆的完成灰度發布，只需要在API Gateway中配置我們需要的規則，按版本，按IP段等，API Gateway會自動為我們完成實際的請求分流。

——//////////——

平台雲課堂

為郵儲科技人帶來有價值有溫度的閱讀

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！