分布式網(wǎng)關(guān)介紹及動(dòng)態(tài)路由實(shí)現(xiàn)

服務(wù)網(wǎng)關(guān)作為分布式系統(tǒng)對(duì)外服務(wù)的統(tǒng)一入口，設(shè)計(jì)功能上具有路由轉(zhuǎn)發(fā)、熔斷限流、安全認(rèn)證以及監(jiān)控等功能。本文簡(jiǎn)要介紹服務(wù)網(wǎng)關(guān)的基本概念，以及動(dòng)態(tài)路由的實(shí)現(xiàn)方式，以加深了解。

1、什么是分布式服務(wù)網(wǎng)關(guān)

1.1 服務(wù)網(wǎng)關(guān)的基本概念

網(wǎng)關(guān)是客戶端訪問系統(tǒng)請(qǐng)求及系統(tǒng)響應(yīng)所要經(jīng)過的網(wǎng)絡(luò)關(guān)口，網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部功能架構(gòu)，為每個(gè)客戶端訪問提供不同的接口。網(wǎng)關(guān)在功能上主要是進(jìn)行請(qǐng)求過濾，具體包括請(qǐng)求路由轉(zhuǎn)發(fā)、安全認(rèn)證、流量控制、負(fù)載均衡、日志、監(jiān)控等功能。

在分布式系統(tǒng)尤其是微服務(wù)架構(gòu)中，一個(gè)應(yīng)用系統(tǒng)被拆分為多個(gè)服務(wù)，但是像路由請(qǐng)求、安全認(rèn)證、流量控制、日志和監(jiān)控等功能對(duì)每個(gè)服務(wù)來說都是標(biāo)準(zhǔn)的功能模塊。如果沒有服務(wù)網(wǎng)關(guān)，那么每個(gè)服務(wù)就需要單獨(dú)實(shí)現(xiàn)一套這樣的模塊，功能重復(fù)并且不利于統(tǒng)一管理。另外，多個(gè)微服務(wù)可能部署在不同的服務(wù)器上，傳統(tǒng)的直接訪問應(yīng)用服務(wù)的方式增加了客戶端的復(fù)雜度，因此需要一個(gè)統(tǒng)一的客戶端訪問入口進(jìn)行標(biāo)準(zhǔn)化管理。

1.2 服務(wù)網(wǎng)關(guān)的作用及功能

服務(wù)網(wǎng)關(guān)作為客戶端請(qǐng)求的統(tǒng)一入口，具備以下功能：

1. 動(dòng)態(tài)路由 ：根據(jù)請(qǐng)求路由到對(duì)應(yīng)的服務(wù)上去，如果服務(wù)不可用還會(huì)有重試機(jī)制
2. 負(fù)載均衡 ：多服務(wù)器提供同一種服務(wù)，網(wǎng)關(guān)會(huì)從配置中心拉取各服務(wù)注冊(cè)信息，然后將請(qǐng)求負(fù)載到這些服務(wù)器進(jìn)行處理
3. 流量控制 ：限制并發(fā)請(qǐng)求的流量，避免內(nèi)部系統(tǒng)受到?jīng)_擊
4. 安全認(rèn)證 ：網(wǎng)關(guān)對(duì)相關(guān)權(quán)限驗(yàn)證、脫敏和流量清洗、簽名和黑名單功能
5. 熔斷降級(jí) ：當(dāng)服務(wù)不可用或者訪問量過大，網(wǎng)關(guān)可以將請(qǐng)求做降級(jí)，將流量打到其他服務(wù)器或者做其他處理，提示用戶暫時(shí)不可用
6. 灰度發(fā)布 ：先進(jìn)行小部分服務(wù)器升級(jí)，通過網(wǎng)關(guān)將少量的服務(wù)路由到已升級(jí)的服務(wù)器用來測(cè)試服務(wù)是否正常，大部分請(qǐng)求依舊在老版本服務(wù)器上處理
7. 日志服務(wù) ：服務(wù)訪問情況監(jiān)控和統(tǒng)計(jì)報(bào)表，請(qǐng)求的吞吐量、并發(fā)數(shù)、流量監(jiān)控、性能監(jiān)控和日常告警等

1.3 常見的分布式服務(wù)網(wǎng)關(guān)

常見的分布式服務(wù)網(wǎng)關(guān)有以下幾種：

1. Nginx+Lua ：基于Nginx的服務(wù)端網(wǎng)關(guān)方案，實(shí)現(xiàn)web服務(wù)器、反向代理、負(fù)載均衡、動(dòng)靜分離等功能；
2. Kong ：基于OpenResty實(shí)現(xiàn)，是一款高性能、云原生、可擴(kuò)展的網(wǎng)關(guān)系統(tǒng)；
3. SpringCloud Zuul ：基于Netty實(shí)現(xiàn)了異步IO，可自定義過濾器來處理請(qǐng)求，同時(shí)提供了動(dòng)態(tài)路由、監(jiān)控、彈性負(fù)載和安全功能
4. SpringCloud Gateway ：基于Spring WebFlux，提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)的基本功能，如安全、限流、監(jiān)控等

1.3.1 Nginx+Lua實(shí)現(xiàn)

在《簡(jiǎn)單聊聊Nginx實(shí)現(xiàn)原理》中對(duì)Nginx的功能做了簡(jiǎn)單的介紹，可以實(shí)現(xiàn)反向代理、負(fù)載均衡、動(dòng)靜分離等功能。

1.3.2 Kong

Kong基于OpenResty實(shí)現(xiàn) ，OpenResty是基于Nginx的庫(kù)，它將Nginx進(jìn)行封裝，使用Lua腳本就可以對(duì)Nginx進(jìn)行插件化管理。

• 使用PostgreSQL或Cassandra來對(duì)其配置文件進(jìn)行持久化存儲(chǔ)，使得可以進(jìn)行集群管理
• 提供了插件模型，使用 Lua腳本來對(duì)Nginx整個(gè)生命周期進(jìn)行擴(kuò)展 。實(shí)現(xiàn)了一些常用插件（ 限流、熔斷、驗(yàn)權(quán)等 ）
• 提供了Http/Rest的接口來實(shí)現(xiàn)配置，使得其可以更簡(jiǎn)單的構(gòu)建圖形化界面進(jìn)行動(dòng)態(tài)配置

1.3.3 Spring Cloud Zuul

Zuul是來自Netflix的基于JVM的路由器和服務(wù)器端負(fù)載均衡器，為微服務(wù)架構(gòu)提供了前門保護(hù)的作用，同時(shí)將權(quán)限控制這些較重的非業(yè)務(wù)邏輯內(nèi)容遷移到服務(wù)路由層面，使得服務(wù)集群主體能夠具備更高的可復(fù)用性和可測(cè)試性。官方定義如下：

Zuul是在云平臺(tái)上提供動(dòng)態(tài)路由,監(jiān)控,彈性,安全等邊緣服務(wù)的框架。Zuul 相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請(qǐng)求的前門。即Zuul為微服務(wù)集群提供代理、過濾和路由等功能。

Zuul會(huì)把外部的請(qǐng)求過程分為不同階段，每個(gè)階段提供一系列的過濾器。這些過濾器實(shí)現(xiàn)了以下功能：

1. 身份驗(yàn)證和安全性 ：對(duì)需要身份驗(yàn)證的資源進(jìn)行過濾，拒絕處理不符合身份認(rèn)證的請(qǐng)求。
2. 觀察和監(jiān)控 ：跟蹤重要的數(shù)據(jù)，為我們展示準(zhǔn)確的請(qǐng)求狀況
3. 動(dòng)態(tài)路由 ：將請(qǐng)求動(dòng)態(tài)路由到不同的服務(wù)集群
4. 負(fù)載均衡 ：設(shè)置每種請(qǐng)求的處理能力，刪除那些超出限制的請(qǐng)求
5. 靜態(tài)響應(yīng)處理 ：提供靜態(tài)的過濾器，直接響應(yīng)一些請(qǐng)求，而不將它們轉(zhuǎn)發(fā)到集群內(nèi)部
6. 路由多樣化 ：除了將請(qǐng)求路由到Spring Cloud集群內(nèi)部，還可以將請(qǐng)求路由到其他服務(wù)

Zuul的 核心原理是一系列filters ，在請(qǐng)求路由合并到用戶處理邏輯的過程中，這些過濾器參與驗(yàn)證、加載等過濾處理。zul定義了四種標(biāo)準(zhǔn)過濾器類型，用于請(qǐng)求的典型生命周期。

1. PRE：這樣的過濾器在請(qǐng)求被路由之前被調(diào)用 ?？梢岳眠@樣的過濾器實(shí)現(xiàn)認(rèn)證，選擇集群內(nèi)要求的微服務(wù)器，記錄調(diào)試信息。
2. ROUTING：該過濾器將請(qǐng)求路由到微服務(wù) 。此過濾器用于生成發(fā)送到微服務(wù)的請(qǐng)求，并使用Apachehttp客戶端或Netfilx Ribbon請(qǐng)求微服務(wù)。
3. POST：在路由到微服務(wù)之后執(zhí)行該過濾器 。使用此過濾器可以將標(biāo)準(zhǔn)HTTP Header添加到響應(yīng)中，收集統(tǒng)計(jì)信息和指標(biāo)，以及將響應(yīng)從微服務(wù)器發(fā)送到客戶端。
4. ERROR：如果在其他階段發(fā)生錯(cuò)誤 ，則執(zhí)行該過濾器。

1.3.4 Spring Cloud Gateway

Spring Cloud Gateway是Spring官方基于Spring5.0，Spring Boot2.0和Project Reactor等技術(shù)開發(fā)的網(wǎng)關(guān)，Spring Cloud Gateway旨在為微服務(wù)架構(gòu)提供簡(jiǎn)單，有效且統(tǒng)一的API路由管理方式。 Spring Cloud Gateway作為Spring Cloud 生態(tài)系統(tǒng)中的網(wǎng)關(guān) ，目標(biāo)是替代Netflix Zuul，其不僅提供統(tǒng)一的路由方式，并且還基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控、埋點(diǎn)，限流等。

1）Spring Cloud Gateway特性

• 基于Spring Framework 5、Reactor和Spring Boot 2.0框架。
• 根據(jù)請(qǐng)求的屬性可以匹配對(duì)應(yīng)的路由。
• 集成Hystrix。
• 集成Spring Cloud DiscoveryClient。
• 把易于編寫的Predicates和Filters作用于特定路由。
• 具備一些網(wǎng)關(guān)的高級(jí)功能，如動(dòng)態(tài)路由、限流、路徑重寫。

2）Spring Cloud Gateway核心概念

• Filter（過濾器） ：和Zuul的過濾器在概念上類似，可以使用Filter攔截和修改請(qǐng)求，實(shí)現(xiàn)對(duì)上游的響應(yīng)，進(jìn)行二次處理，實(shí)現(xiàn)橫切與應(yīng)用無關(guān)的功能，如安全、訪問超時(shí)設(shè)置、限流等功能。
• Route（路由） ：網(wǎng)關(guān)配置的基本組成模塊，和Zuul的路由配置模塊類似。一個(gè)Route模塊由一個(gè)ID、一個(gè)目標(biāo)URI、一組斷言和一組過濾器組成。如果斷言為真，則路由匹配，目標(biāo)URI會(huì)被訪問。
• Predicate（斷言） ：Predicate來自Java 8的接口，它可以用來匹配來自HTTP請(qǐng)求的任何內(nèi)容，例如headers或參數(shù)。接口包含多種默認(rèn)方法，并將Predicate組合成復(fù)雜的邏輯（與、或、非），可以用于接口參數(shù)校驗(yàn)、路由轉(zhuǎn)發(fā)判斷等。

3）Spring Cloud Gateway核心處理流程

1. Gateway的客戶端回向Spring Cloud Gateway發(fā)起請(qǐng)求
2. 請(qǐng)求首先會(huì)被HttpWebHandlerAdapter進(jìn)行 提取組裝成網(wǎng)關(guān)的上下文 ，然后網(wǎng)關(guān)的上下文會(huì)傳遞到DispatcherHandler。
3. DispatcherHandler是所有請(qǐng)求的分發(fā)處理器，DispatcherHandler主要 負(fù)責(zé)分發(fā)請(qǐng)求對(duì)應(yīng)的處理器 ，比如將請(qǐng)求分發(fā)到對(duì)應(yīng)RoutePredicateHandlerMapping(路由斷言處理器映射器）。
4. 路由斷言處理映射器 主要用于路由的查找 ，以及找到路由后返回對(duì)應(yīng)的FilteringWebHandler。
5. FilteringWebHandler主要 負(fù)責(zé)組裝Filter鏈表并調(diào)用Filter執(zhí)行一系列Filter處理 ，然后把請(qǐng)求轉(zhuǎn)到后端對(duì)應(yīng)的代理服務(wù)處理，
6. 處理完畢后，將Response 返回到Gateway客戶端 。

1.3.5 Zuul和Gateway對(duì)比

Spring cloud Zuul和Spring Cloud Gateway處理的都是http請(qǐng)求，底層是serverlet服務(wù)。不同之處有以下幾點(diǎn)：

• 內(nèi)部實(shí)現(xiàn)
  • gateway對(duì)比zuul多依賴了spring-webflux，在spring的支持下，功能更強(qiáng)大，內(nèi)部實(shí)現(xiàn)了限流、負(fù)載均衡等，擴(kuò)展性也更強(qiáng)，但同時(shí)也限制了僅適合于Spring Cloud套件
  • zuul則可以擴(kuò)展至其他微服務(wù)框架中，其內(nèi)部沒有實(shí)現(xiàn)限流、負(fù)載均衡等
• 是否支持異步
  • Zuul 1.x只支持同步。Zuul 2.x基于Netty實(shí)現(xiàn)了異步IO
  • Gateway支持異步。 理論上gateway則更適合于提高系統(tǒng)吞吐量（但不一定能有更好的性能），最終性能還需要通過嚴(yán)密的壓測(cè)來決定
• 擴(kuò)展性
  • Gateway具有更好的擴(kuò)展性，穩(wěn)定性也是非常好的
• 性能
  • Spring webflux 有一個(gè)全新的非堵塞的函數(shù)式 Reactive Web 框架，可以用來構(gòu)建異步的、非堵塞的、事件驅(qū)動(dòng)的服務(wù)，在伸縮性方面表現(xiàn)非常好
  • Zuul 1.x，是一個(gè)基于阻塞io的API Gateway。Zuul已經(jīng)發(fā)布了Zuul 2.x，基于Netty，也是非阻塞的，支持長(zhǎng)連接，但Spring Cloud暫時(shí)還沒有整合計(jì)劃

在實(shí)際生產(chǎn)使用中，Zuul 1.x雖然使用的是同步io，但是可以通過參數(shù)優(yōu)化提高性能理論上可以達(dá)到極限性能，而springcloud gateway使用的是異步io，不需優(yōu)化既可以達(dá)到接近極限的性能。

2、分布式網(wǎng)關(guān)動(dòng)態(tài)路由實(shí)現(xiàn)

相比較靜態(tài)路由，動(dòng)態(tài)路由的好處是對(duì)路由配置的修改、新增或者刪除，可以動(dòng)態(tài)生效，不需要重啟網(wǎng)關(guān)服務(wù)。這里主要介紹 基于Spring Cloud Gateway的動(dòng)態(tài)路由幾種實(shí)現(xiàn)方式 ，包括：

• 基于Nacos
• 基于數(shù)據(jù)庫(kù)
• 基于內(nèi)存

2.1 基于Nacos的動(dòng)態(tài)路由

Nacos集成在Spring Cloud中，提供了快速實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理等功能。基于Nacos動(dòng)態(tài)路由是通過Nacos更新修改路由配置，通過接口調(diào)用動(dòng)態(tài)更新到本地緩存中。

1）加載配置和監(jiān)聽路由

configInfo = configService.getConfig(NACOS_ROUTE_DATA_ID, NACOS_ROUTE_GROUP, DEFAULT_TIMEOUT);
configService.addListener(dataId, group, new Listener()

2）路由的動(dòng)態(tài)添加和刪除

routeDefinitionWriter.delete(Mono.just(id)).subscribe()
routeDefinitionWriter.save(Mono.just(definition)).subscribe();

3）路由信息刷新到本地緩存

publisher.publishEvent(new RefreshRoutesEvent(this));

2.2 基于數(shù)據(jù)庫(kù)的動(dòng)態(tài)路由

基于數(shù)據(jù)庫(kù)的動(dòng)態(tài)路由實(shí)現(xiàn)，是 將路由信息寫入數(shù)據(jù)庫(kù)中 ，再通過接口讀取路由配置信息以及更新路由信息，最后刷新到本地緩存中。

2.3 基于內(nèi)存的動(dòng)態(tài)路由

基于本地內(nèi)存的方式比較簡(jiǎn)單，Spring Boot已經(jīng)提供了兩個(gè)組件Spring Boot Admin和Spring Boot Actuator。 通過調(diào)用接口更新路由信息，再刷新即可完成路由更新 。

o.s.c.g.a.GatewayControllerEndpoint:
{GET /routes/{id}}: route(String)
{GET /routes}: routes()
{GET /routedefinitions}: routesdef()
{GET /globalfilters}: globalfilters()
{GET /routefilters}: routefilers()
{GET /routepredicates}: routepredicates()
{GET /routes/{id}/combinedfilters}: combinedfilters(String)
{DELETE /routes/{id}}: delete(String)
{POST /routes/{id}}: save(String,RouteDefinition)
{POST /refresh}: refresh()