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

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

Zuul介紹

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

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

1) Pre: 過濾規(guī)則在路由之前起作用?？梢岳谩癙re”過濾器實現(xiàn)用戶鑒權(quán)，記錄請求日志等；

2) Routing：過濾規(guī)則在路由時發(fā)生作用。可以利用“Routing”過濾器實現(xiàn)動態(tài)路由、灰度發(fā)布、A/B測試、負載限流等。

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

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

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

一、Zuul 實例

在上篇demo創(chuàng)建好注冊中心、服務(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ù)注冊中心地址，api-a.serviceId,b-serviceId 指向服務(wù)提供者名稱

3、訪問效果

原來直接通過http://COMPUTE-SERVICE/add?a=10&b=20鏈接直接訪問compute-service服務(wù)實例，現(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ā)到service服務(wù)實例。

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

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

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

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