Spring Cloud Zuul服務網關的示例分析

這篇文章將為大家詳細講解有關Spring Cloud Zuul服務網關的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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

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

Zuul介紹

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

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

1) Pre: 過濾規則在路由之前起作用。可以利用“Pre”過濾器實現用戶鑒權，記錄請求日志等；

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

3) Post：過濾規則在路由之后發生作用。可以利用"Post"過濾器收集統計信息和指標，將微服務的相應寫入Http響應并返回給服務消費者；

4) Error：過濾規則路由過程中發生錯誤時發生作用。可以利用Error過濾器記錄錯誤日志，并對錯誤進行二次處理等。

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

一、Zuul 實例

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

1、創建網關類 

@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服務實例，現在則可直接localhost：5555/api-a/add?a=1&b=2網關地址訪問compute-service服務。同樣zuul網關也提供服務負載均衡功能，將請求均發到service服務實例。

二、什么是網關？為何需要使用網關？

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

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

關于“Spring Cloud Zuul服務網關的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。