詳解Spring Cloud Zuul 服務網(wǎng)關

更新時間：2017年12月15日 16:21:08 作者：鐘艾伶

本篇文章主要介紹了詳解Spring Cloud Zuul 服務網(wǎng)關，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

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

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

Zuul介紹

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

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

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

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

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

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

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

一、Zuul 實例

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

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

@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服務注冊中心地址，api-a.serviceId,b-serviceId 指向服務提供者名稱

3、訪問效果

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

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

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

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

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

您可能感興趣的文章: