前言

介紹完分散式配置中心，結合前面的文章。我們已經有了一個微服務的框架了，可以對外提供api介面服務了。但現在試想一下，在微服務框架中，每個對外服務都是獨立部署的，對外的api或者服務地址都不是不盡相同的。對於內部而言，很簡單，通過註冊中心自動感知即可。但我們大部分情況下，服務都是提供給外部系統進行呼叫的，不可能同享一個註冊中心。同時一般上內部的微服務都是在內網的，和外界是不連通的。而且，就算我們每個微服務對外開放，對於呼叫者而言，呼叫不同的服務的地址或者引數也是不盡相同的，這樣就會造成消費者客戶端的複雜性，同時想想，可能微服務可能是不同的技術棧實現的，有的是http、rpc或者websocket

等等，也會進一步加大客戶端的呼叫難度。所以，一般上都有會有個api閘道器，根據請求的url不同，路由到不同的服務上去，同時入口統一了，還能進行統一的身份鑑權、日誌記錄、分流等操作。接下來，我們就來了解今天要講解的路由服務：zuul。

一點知識

為什麼要使用微服務閘道器

簡單來說，微服務閘道器是微服務架構中一個不可或缺的部分。通過服務閘道器統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了許可權控制等功能。

在未加入閘道器時，一般上會在服務外網架設一個負載均衡，如nginx等。此時，微服務的組成為：

此時，對於Open Service而言可能需要提供許可權控制等和業務無關的能力，這樣本身就破壞了微服務服務單一的原則。所以，一般上在Open Service

API閘道器是什麼

API閘道器可以提供一個單獨且統一的API入口用於訪問內部一個或多個API。簡單來說嘛就是一個統一入口，比如現在的支付寶或者微信的相關api服務一樣，都有一個統一的api地址，統一的請求引數，統一的鑑權。

客戶端和服務端直連的弊端

• 客戶端會對此請求不同的微服務，增加客戶端複雜性
• 存在跨域請求時，需要進行額外處理
• 認證服務，每個服務需要獨立認證
• UI端和微服務耦合

閘道器的優缺點

優點：

• 減少api請求次數
• 限流
• 快取
• 統一認證
• 降低微服務的複雜度
• 支援混合通訊協議(前端只和api通訊，其他的由閘道器呼叫)
• ……

缺點：

• 閘道器需高可用，可能產生單點故障
• 管理複雜

閘道器的選擇

現在市場上有很多的閘道器可供選擇：

• Spring Cloud Zuul：本身基於Netflix開源的微服務閘道器,可以和Eureka,Ribbon,Hystrix等元件配合使用。
• Kong : 基於OpenResty的 API 閘道器服務和閘道器服務管理層。
• Spring Cloud Gateway：是由spring官方基於Spring5.0,Spring Boot2.0,Project Reactor等技術開發的閘道器，提供了一個構建在Spring Ecosystem之上的API閘道器，旨在提供一種簡單而有效的途徑來發送API，並向他們提供交叉關注點，例如：安全性，監控/指標和彈性。目的是為了替換Spring Cloud Netfilx Zuul的。

在Spring cloud體系中，一般上選擇zuul或者Gateway。當然，也可以綜合自己的業務複雜性，自研一套或者改在一套符合自身業務發展的api閘道器的，最簡單做法是做個聚合api服務，通過SpringBoot構建對外的api介面，實現統一鑑權、引數校驗、許可權控制等功能，說白了就是一個rest服務。

Zuul介紹和使用

何為Zuul

Zuul是Netflix開源的微服務閘道器，可以和Eureka、Ribbon、Hystrix等元件配合使用，Spring Cloud對Zuul進行了整合與增強，Zuul的主要功能是路由轉發和過濾器。

Zuul基於JVM的路由器和伺服器端負載均衡器。同時，Zuul的規則引擎允許規則和過濾器基本上用任何JVM語言編寫，內建支援Java和Groovy。這個功能，就可以實現動態路由的功能了。當需要新增某個新的對外服務時，一般上不停機更新是通過資料快取配置或者使用Groovy進行動態路由的新增的。

Zuul的核心一系列的過濾器：

• 身份認證與安全：識別每個資源的驗證要求，並拒絕那些與要求不符的請求。
• 審查與監控：在邊緣位置追蹤有意義的資料和統計結果，從而帶來精確的生產檢視。
• 動態路由：動態地將請求路由到不同的後端叢集。
• 壓力測試：逐漸增加指向叢集的流量，以瞭解效能。
• 負載分配：為每一種負載型別分配對應容量，並啟用超出限定值的請求。
• 靜態響應處理：在邊緣位置直接建立部分相應，從而避免其轉發到內部叢集。

加入Zuul閘道器後：

Zuul實踐

建立工程：spring-cloud-zuul。 這裡直接加入了註冊中心進行服務化模式。

0.加入pom依賴。

        <!-- zuul 依賴 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        </dependency>        
        <!-- eureka client 依賴 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

注意：這裡的Eureka不是必須的。在沒有註冊中心的情況下，也是可以進行zuul使用的。

1.配置檔案，配置註冊中心相關資訊、路由規則等。

spring.application.name=zuul-server
server.port=8888

# 註冊中心地址 -此為單機模式
eureka.client.service-url.defaultZone=http://127.0.0.1:1000/eureka
# 啟用ip配置 這樣在註冊中心列表中看見的是以ip+埠呈現的
eureka.instance.prefer-ip-address=true
# 例項名稱  最後呈現地址：ip:15678
eureka.instance.instance-id=${spring.cloud.client.ip-address}:${server.port}

## 路由規則
## 傳統路由配置：不依賴服務發現。
## 所有以myapi開頭的url路由至http://127.0.0.1:2000/下
## 如http://127.0.0.1:8888/myapi/hello --> http://127.0.0.1:2000/hello
zuul.routes.myApi.path=/myapi/**
zuul.routes.myApi.url=http://127.0.0.1:2000

#forward模式 直接轉發至zuul提供的rest服務
zuul.routes.myDemo.path=/myDemo/**
zuul.routes.myDemo.url=forward:/demo

## 服務發現模式
# 路由地址
zuul.routes.myEureka.path=/eureka/**
#為具體服務的名稱
zuul.routes.myEureka.service-id=eureka-client

友情提示： 預設情況下：Zuul代理所有註冊到EurekaServer的微服務，路由規則： http://ZUUL_HOST:ZUUL_PORT/微服務例項名(serverId)/** 轉發至serviceId對應的微服務。

如：http://127.0.0.1:8888/eureka-client/hello?name=oKong 最後就是轉發至：http://127.0.0.1:2000//hello?name=oKong

2.啟動類加入@EnableZuulProxy註解，宣告一個Zuul代理。

/**
 * zuul 示例
 * 
 * @author oKong
 *
 */
@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
@Slf4j
public class SpringCloudZuulApplication {
    public static void main(String[] args) throws Exception {
        SpringApplication.run(SpringCloudZuulApplication.class, args);
        log.info("spring-cloud-zuul啟動!");
    }

}

3.編寫一個控制類，測試forward功能。

/**
 * zuul 內部提供對外服務示例
 * @author oKong
 *
 */
@RestController
@RequestMapping("/demo")
public class DemoController {

    @GetMapping("/hello")
    public String hello(String name) {
        return "hi," + name + ",this is zuul api! ";
    }
}

4.啟動spring-cloud-eureka-server和spring-cloud-eureka-client服務，之後再啟動spring-cloud-zuul服務。

此時，我們來訪問zuul內部服務：http://127.0.0.1:8888/demo/hello?name=oKong

然後訪問：http://127.0.0.1:8888/myDemo/hello?name=oKong 效果和上面直接方式是一樣的，最後都是訪問/demo/**api地址的。

訪問：http://127.0.0.1:8888/myapi/hello?name=oKong 和 http://127.0.0.1:8888/eureka/hello?name=oKong 最後效果都是一樣的，都是訪問http://127.0.0.1:2000/hello?name=oKong 。

直接以預設形式訪問:http://127.0.0.1:8888/eureka-client/hello?name=oKong 最後效果也是一樣的。

其實，從控制檯輸出日誌也是可以一窺究竟的：

路由規則說明

簡單說明下關於路由規則的一些說明：

傳統路由配置：不依賴服務發現，如nginx

• 單例例項配置：通過zuul.routes.<route>.path和zuul.routes.<route>.url引數對的方式來配置

# 傳統路由配置
zuul.routes.server-provide.path=/server-provide/**
zuul.routes.server-provide.url=http://127.0.0.1:1001/

• 多例項配置：通過一組zuul.routes.<route>.path與zuul.routes.<route>.serviceId引數對的方式配置

# 多例項
zuul.routes.server-provide.path=/user-service/**
zuul.routes.server-provide.serviceId=user-service
ribbon.eureka.enabled=false
server-provide.ribbon.listOfServers=http://127.0.0.1:1001/,http://127.0.0.1:1001/

服務路由配置：依賴服務發現，結合Eureka

• 預設規則：http://ZUUL_HOST:ZUUL_PORT/微服務例項名(serverId)/** ，轉發至serviceId對應的微服務。

• 自定義路由規則：通過一組zuul.routes.<route>.path與zuul.routes.<route>.serviceId引數對的方式配置

# 自定義路由
zuul.routes.server-provide.path=/server-api/**
zuul.routes.server-provide.serviceId=server-provide

比如:

而且，要注意，這些過濾器是path進行最佳路徑匹配的，所以，一般上在一些歷史系統上，我們會在最後後面加上一個路徑/**的匹配規則，以保證歷史api可以使用，做到最大相容性,避免類似404的異常。

zuul.routes.legacy.path=/**

參考資料

總結

本章節主要簡單介紹了關於Zuul的一些簡單使用以及一些路由規則的簡單說明。開頭也說過了，Zuul的核心是一系列的過濾器。介於篇幅問題，關於過濾器的介紹、自定義過濾器、異常處理、熔斷降級等放在下一章節來講解。而相關的其他配置，大家可以去官網進行檢視，或者自行搜尋下，也可以檢視下：org.springframework.cloud.netflix.zuul.filters.ZuulProperties類，相關配置資訊都在裡面了。

最後

目前網際網路上大佬都有分享SpringCloud系列教程，內容可能會類似，望多多包涵了。原創不易，碼字不易，還希望大家多多支援。若文中有錯誤之處，還望提出，謝謝。

老生常談

• 個人QQ：499452441
• 微信公眾號：lqdevOps