有了Eureka服務(wù)注冊(cè)發(fā)現(xiàn)、Hystrix斷路器、Ribbon服務(wù)調(diào)用負(fù)載均衡，以及spring cloud config 集群配置中心，似乎一個(gè)微服務(wù)框架已五臟俱全，last but not least，一個(gè)服務(wù)網(wǎng)關(guān)卻不可或缺。

Spring Cloud Zuul路由是微服務(wù)架構(gòu)的不可或缺的一部分，提供動(dòng)態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。Zuul是Netflix出品的一個(gè)基于JVM路由和服務(wù)端的負(fù)載均衡器。

Zuul介紹

在整個(gè)Spring Cloud微服務(wù)框架里，Zuul扮演著”智能網(wǎng)關(guān)“的角色。一方面，Zuul是接入網(wǎng)關(guān)，起到反向代理的作用，是外部消費(fèi)者請(qǐng)求內(nèi)部服務(wù)的唯一入口。另一方面，Zuul也具備過濾功能，通過在運(yùn)行時(shí)注入過濾規(guī)則可實(shí)現(xiàn)用戶鑒權(quán)、動(dòng)態(tài)路由、灰度發(fā)布、A/B測(cè)試、負(fù)載限流等功能。

Zuul的大部分功能都是通過過濾功能來完成的，Zuul可以提供四種標(biāo)準(zhǔn)類型的過濾，如下圖所示：

1) Pre: 過濾規(guī)則在路由之前起作用。可以利用“Pre”過濾器實(shí)現(xiàn)用戶鑒權(quán)，記錄請(qǐng)求日志等；

2) Routing：過濾規(guī)則在路由時(shí)發(fā)生作用?？梢岳谩癛outing”過濾器實(shí)現(xiàn)動(dòng)態(tài)路由、灰度發(fā)布、A/B測(cè)試、負(fù)載限流等。

3) Post：過濾規(guī)則在路由之后發(fā)生作用?？梢岳?Post"過濾器收集統(tǒng)計(jì)信息和指標(biāo)，將微服務(wù)的相應(yīng)寫入Http響應(yīng)并返回給服務(wù)消費(fèi)者；

4) Error：過濾規(guī)則路由過程中發(fā)生錯(cuò)誤時(shí)發(fā)生作用?？梢岳肊rror過濾器記錄錯(cuò)誤日志，并對(duì)錯(cuò)誤進(jìn)行二次處理等。

在過濾器之間用RequestContext傳遞消息。RequestContext存儲(chǔ)的內(nèi)容包括路由目標(biāo)地址、錯(cuò)誤信息、請(qǐng)求信息、響應(yīng)信息等。Zuul的過濾規(guī)則也可以用基于JVM的語言編寫，包括Java、Python、Groovy等。

一、Zuul 實(shí)例

在上篇demo創(chuàng)建好注冊(cè)中心、服務(wù)提供方的基礎(chǔ)之上，再來演示一下zuul網(wǎng)關(guān)服務(wù)

1、創(chuàng)建網(wǎng)關(guān)類 

@EnableZuulProxy 
@SpringCloudApplication  
//整合@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker 
public class ZuulApplication { 
 
  public static void main(String[] args) { 
    new SpringApplicationBuilder(ZuulApplication.class).web(true).run(args); 
  } 
} 

2、添加properties配置文件

spring.application.name=api-gateway 
server.port=5555 
 
zuul.routes.api-a.path=/api-a/** 
zuul.routes.api-a.serviceId=compute-service 
 
zuul.routes.api-b.path=/api-b/** 
zuul.routes.api-b.serviceId=compute-service 
 
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/ 

同樣也指向eureka服務(wù)注冊(cè)中心地址，api-a.serviceId,b-serviceId 指向服務(wù)提供者名稱

3、訪問效果

原來直接通過http://COMPUTE-SERVICE/add?a=10&b=20鏈接直接訪問compute-service服務(wù)實(shí)例，現(xiàn)在則可直接localhost：5555/api-a/add?a=1&b=2網(wǎng)關(guān)地址訪問compute-service服務(wù)。同樣zuul網(wǎng)關(guān)也提供服務(wù)負(fù)載均衡功能，將請(qǐng)求均發(fā)到service服務(wù)實(shí)例。

二、什么是網(wǎng)關(guān)？為何需要使用網(wǎng)關(guān)？

通過上圖，對(duì)外提供的服務(wù)，在無網(wǎng)關(guān)的情況下，API接口直接暴露給服務(wù)調(diào)用方，當(dāng)調(diào)用方增多，不同業(yè)務(wù)調(diào)用方各不相同，勢(shì)必需要添加定制化訪問權(quán)限、校驗(yàn)等邏輯。當(dāng)添加API網(wǎng)關(guān)后，再第三方調(diào)用端和服務(wù)提供方之間就創(chuàng)建了一面墻，這面墻直接與調(diào)用方通信進(jìn)行權(quán)限控制，后將請(qǐng)求均衡分發(fā)給后臺(tái)服務(wù)端，正如無需直接訪問compute-service的add方法，而是通過api-a/add鏈接將請(qǐng)求傳遞給service實(shí)例。Zuul就是提供負(fù)載均衡-反向代理-權(quán)限認(rèn)證的這么一個(gè)API gateway。

類似于Nginx在應(yīng)用服務(wù)最前端添加一堵保護(hù)墻，zuul的負(fù)載均衡是針對(duì)將請(qǐng)求分發(fā)給集群中某臺(tái)服務(wù)或者某個(gè)服務(wù)實(shí)例。而前面介紹過的ribbon也是主打服務(wù)負(fù)載功能，它所針對(duì)的是服務(wù)消費(fèi)者將調(diào)用請(qǐng)求分發(fā)到某具體服務(wù)提供實(shí)例。兩者均做負(fù)載均衡，實(shí)際是在系統(tǒng)不同的層級(jí)上進(jìn)行。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論