微服務為什么要用到服務網關?
圖片
服務網關為客戶與服務系統之間的交互提供了統一的接口,也是管理請求和響應的中心點,選擇一個適合的服務網關,可以有效地簡化開發并提高系統的運維與管理效率。
服務網關 = 路由轉發 + 過濾器
1、路由轉發:接收一切外界請求,轉發到后端的微服務上去;
2、過濾器:在服務網關中可以完成一系列的橫切功能,例如權限校驗、限流以及監控等,這些都可以通過過濾器完成(其實路由轉發也是通過過濾器實現的)。
上述所說的橫切功能(以權限校驗為例)可以寫在三個位置:
每個服務自己實現一遍
寫到一個公共的服務中,然后其他所有服務都依賴這個服務
寫到服務網關的前置過濾器中,所有請求過來進行權限校驗
第一種,缺點太明顯,基本不用;第二種,相較于第一點好很多,代碼開發不會冗余,但是有兩個缺點:
- 由于每個服務引入了這個公共服務,那么相當于在每個服務中都引入了相同的權限校驗的代碼,使得每個服務的jar包大小無故增加了一些,尤其是對于使用docker鏡像進行部署的場景,jar越小越好;
- 由于每個服務都引入了這個公共服務,那么我們后續升級這個服務可能就比較困難,而且公共服務的功能越多,升級就越難,而且假設我們改變了公共服務中的權限校驗的方式,想讓所有的服務都去使用新的權限校驗方式,我們就需要將之前所有的服務都重新引包,編譯部署。
而服務網關恰好可以解決這樣的問題:
- 將權限校驗的邏輯寫在網關的過濾器中,后端服務不需要關注權限校驗的代碼,所以服務的jar包中也不會引入權限校驗的邏輯,不會增加jar包大小;
- 如果想修改權限校驗的邏輯,只需要修改網關中的權限校驗過濾器即可,而不需要升級所有已存在的微服務。
所以,需要服務網關!!!
三、服務網關技術選型
圖片
引入服務網關后的微服務架構如上,總體包含三部分:服務網關、open-service和service。
1、總體流程
- 服務網關、open-service和service啟動時注冊到注冊中心上去;
- 用戶請求時直接請求網關,網關做智能路由轉發(包括服務發現,負載均衡)到open-service,這其中包含權限校驗、監控、限流等操作
- open-service聚合內部service響應,返回給網關,網關再返回給用戶
2、引入網關的注意點
- 增加了網關,多了一層轉發(原本用戶請求直接訪問open-service即可),性能會下降一些(但是下降不大,通常,網關機器性能會很好,而且網關與open-service的訪問通常是內網訪問,速度很快);
- 網關的單點問題:在整個網絡調用過程中,一定會有一個單點,可能是網關、nginx、dns服務器等。防止網關單點,可以在網關層前邊再掛一臺nginx,nginx的性能極高,基本不會掛,這樣之后,網關服務就可以不斷的添加機器。但是這樣一個請求就轉發了兩次,所以最好的方式是網關單點服務部署在一臺牛逼的機器上(通過壓測來估算機器的配置),而且nginx與zuul的性能比較,根據國外的一個哥們兒做的實驗來看,其實相差不大,zuul是netflix開源的一個用來做網關的開源框架;
- 網關要盡量輕。
3、網關基本功能
服務網關作為客戶端和服務端的中間橋梁,為微服務系統提供統一的管理機制:除了基礎的請求分發、API 管理和條件路由等功能,還包括身份驗證、監控報警、調用鏈追蹤、負載均衡、限流隔離和熔斷降級。
- 身份認證:下圖表示的是微服務聯合 服務網關如何進行身份認證的,由圖可見所有請求都通過網關,從而有效地隱藏了微服務。
圖片
- 監控報警/調用鏈追蹤:API 作為客戶端和服務端的中間橋梁,是微服務監控的最好載體,服務網關監控功能的主要職責是及時發現網關以及后端服務器的連接異常,在 API 的監控平臺上面用戶可以隨時查看日志信息,監控信息,調用鏈等等,并且主機發生的任何異常都會自動報警到控制臺。有些網關甚至可以做到給客戶端和服務端雙向報警。
圖片
- 限流隔離/熔斷降級:隨著互聯網業務規模的增加,系統的并發度增高,多個服務之間相互調用鏈路,一條核心鏈路往往可能調用十個服務。如果在鏈路中,某個服務的 rt(響應時間)急劇上升,上游服務不斷請求,造成惡性循環,上游等待結果線程數越多,使得更上游服務阻塞最終整條鏈路無法使用,從而導致服務雪崩,所以對入口流量進行整治管理是很有必要的。
下圖表示微服務系統是如何結合 服務網關進行限流隔離和熔斷降級的。
圖片
4、主流網關對比
網關 | 痛點 | 優勢 |
NGINX | 1. 修改配置需要 Reload 才能生效,跟不上云原生的發展。 | 1. 老牌應用; |
Apache APISIX | 1. 文檔不夠豐富和清晰,需要待改進。 | 1. Apache 基金會頂級項目; |
Kong | 1. 默認使用 PostgreSQL 或 Cassandra 數據庫,使得整個架構非常臃腫,并且會帶來高可用的問題; | 1. 開源 API 網關的鼻祖,用戶數眾多; |
Envoy | 1. 使用 C++,二次開發難度大; | 1. CNCF 畢業項目 更適合服務網格場景多語言架構部署。 |
Spring Cloud Gateway | 1. 雖然 Spring 社區成熟,但是 Gateway 資源缺乏。 | 1. 內置了非常多的開箱即用功能,并且都可以通過 SpringBoot 配置或者手工編碼鏈式調用來使用; |
四、總結
隨著互聯網的發展,互聯網企業的業務也在不斷的飛速發展,進而導致系統的架構也在不斷的發生著變化,微服務架構已經在眾多公司得到廣泛應用。隨著微服務的數據越來越多,API 的數量也越來越多,對于大流量的治理,選擇一個優秀的服務網關是至關重要的。
本文列舉了常見網關,并進行對比,列出各自的優缺點,如果你正在做服務網關的技術選型,或者你的微服務系統出現了性能問題,再或者你想搭建一個高效穩定的微服務系統,希望本文可以帶給你一定的啟發。