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