服務閘道器是微服務架構中一個不可或缺的部分。通過服務閘道器統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了許可權控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將許可權控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務叢集主體能夠具備更高的可複用性和可測試性。

路由在微服務體系結構的一個組成部分。例如，/可以對映到您的Web應用程式，/api/users對映到使用者服務，並將/api/shop對映到商店服務。Zuul是Netflix的基於JVM的路由器和伺服器端負載均衡器。

Netflix使用Zuul進行以下操作：

• 認證
• 洞察
• 壓力測試
• 金絲雀測試
• 動態路由
• 服務遷移
• 負載脫落
• 安全
• 靜態響應處理
• 主動/主動流量管理

Zuul的規則引擎允許基本上寫任何JVM語言編寫規則和過濾器，內建Java和Groovy。

什麼是服務閘道器

服務閘道器 = 路由轉發 + 過濾器

1、路由轉發：接收一切外界請求，轉發到後端的微服務上去；

2、過濾器：在服務閘道器中可以完成一系列的橫切功能，例如許可權校驗、限流以及監控等，這些都可以通過過濾器完成（其實路由轉發也是通過過濾器實現的）。

為什麼需要服務閘道器

上述所說的橫切功能（以許可權校驗為例）可以寫在三個位置：

• 每個服務自己實現一遍
• 寫到一個公共的服務中，然後其他所有服務都依賴這個服務
• 寫到服務閘道器的前置過濾器中，所有請求過來進行許可權校驗

第一種，缺點太明顯，基本不用；
第二種，相較於第一點好很多，程式碼開發不會冗餘，但是有兩個缺點：

• 由於每個服務引入了這個公共服務，那麼相當於在每個服務中都引入了相同的許可權校驗的程式碼，使得每個服務的jar包大小無故增加了一些，尤其是對於使用docker映象進行部署的場景，jar越小越好；
• 由於每個服務都引入了這個公共服務，那麼我們後續升級這個服務可能就比較困難，而且公共服務的功能越多，升級就越難，而且假設我們改變了公共服務中的許可權校驗的方式，想讓所有的服務都去使用新的許可權校驗方式，我們就需要將之前所有的服務都重新引包，編譯部署。

而服務閘道器恰好可以解決這樣的問題：

• 將許可權校驗的邏輯寫在閘道器的過濾器中，後端服務不需要關注許可權校驗的程式碼，所以服務的jar包中也不會引入許可權校驗的邏輯，不會增加jar包大小；
• 如果想修改許可權校驗的邏輯，只需要修改閘道器中的許可權校驗過濾器即可，而不需要升級所有已存在的微服務。

所以，需要服務閘道器！！！

服務閘道器技術選型

引入服務閘道器後的微服務架構如上，總體包含三部分：服務閘道器、open-service和service。

1、總體流程：

• 服務閘道器、open-service和service啟動時註冊到註冊中心上去；
• 使用者請求時直接請求閘道器，閘道器做智慧路由轉發（包括服務發現，負載均衡）到open-service，這其中包含許可權校驗、監控、限流等操作
• open-service聚合內部service響應，返回給閘道器，閘道器再返回給使用者

2、引入閘道器的注意點

• 增加了閘道器，多了一層轉發（原本使用者請求直接訪問open-service即可），效能會下降一些（但是下降不大，通常，閘道器機器效能會很好，而且閘道器與open-service的訪問通常是內網訪問，速度很快）；
• 閘道器的單點問題：在整個網路呼叫過程中，一定會有一個單點，可能是閘道器、nginx、dns伺服器等。防止閘道器單點，可以在閘道器層前邊再掛一臺nginx，nginx的效能極高，基本不會掛，這樣之後，閘道器服務就可以不斷的新增機器。但是這樣一個請求就轉發了兩次，所以最好的方式是閘道器單點服務部署在一臺牛逼的機器上（通過壓測來估算機器的配置），而且nginx與zuul的效能比較，根據國外的一個哥們兒做的實驗來看，其實相差不大，zuul是netflix開源的一個用來做閘道器的開源框架；
• 閘道器要儘量輕。

3、服務閘道器基本功能

• 智慧路由：接收外部一切請求，並轉發到後端的對外服務open-service上去；
• 注意：我們只轉發外部請求，服務之間的請求不走閘道器，這就表示全鏈路追蹤、內部服務API監控、內部服務之間呼叫的容錯、智慧路由不能在閘道器完成；當然，也可以將所有的服務呼叫都走閘道器，那麼幾乎所有的功能都可以整合到閘道器中，但是這樣的話，閘道器的壓力會很大，不堪重負。
• 許可權校驗：只校驗使用者向open-service服務的請求，不校驗服務內部的請求。服務內部的請求有必要校驗嗎？
• API監控：只監控經過閘道器的請求，以及閘道器本身的一些效能指標（例如，gc等）；
• 限流：與監控配合，進行限流操作；
• API日誌統一收集：類似於一個aspect切面，記錄介面的進入和出去時的相關日誌
• 。。。後續補充

4、技術選型

筆者準備自建一個輕量級的服務閘道器，技術選型如下：

• 開發語言：java + groovy，groovy的好處是閘道器服務不需要重啟就可以動態的新增filter來實現一些功能；
• 微服務基礎框架：springboot；
• 閘道器基礎元件：netflix zuul；
• 服務註冊中心：consul；
• 許可權校驗：jwt；
• API監控：prometheus + grafana；
• API統一日誌收集：logback + ELK；
• 壓力測試：Jmeter；
• 。。。後續補充
• 在後續的介紹中，會逐漸介紹各個知識點，並完成一個輕量級的服務閘道器！！！

Spring Cloud Zuul

簡單使用

新建專案 spring-cloud-zuul-service

新增依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>

開啟服務註冊

在程式的啟動類 ZuulApplication 通過 @EnableZuulProxy 開啟 Zuul 服務閘道器

package io.ymq.example.zuul;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;

@EnableZuulProxy
@SpringBootApplication
public class ZuulApplication {

    public static void main(String[] args) {
        SpringApplication.run(ZuulApplication.class, args);
    }
}

新增配置

配置檔案 application.yml

spring:
  application:
    name: zuul-service

server:
  port: 9000


zuul:
  routes:
    blog:
        path: /ymq/**
        url: http://www.ymq.io/about

測試訪問

配置說明：

服務轉發

準備工作

我們先拿之前兩篇文章，構建的兩個微服務程式碼為基礎，進行下面的操作

建議先閱讀以下兩篇文章

Eureka Service

匯入第三篇文章中的專案：作為服務註冊中心

spring-cloud-eureka-service

Eureka Provider

匯入第三篇文章中的專案：作為服務的提供者

spring-cloud-eureka-provider-1
spring-cloud-eureka-provider-2
spring-cloud-eureka-provider-3

新增依賴

專案繼續改造，新增依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

修改配置

配置檔案 application.yml

spring:
  application:
    name: zuul-service

server:
  port: 9000

#zuul:
#  routes:
#    blog:
#        path: /ymq/**
#        url: http://www.ymq.io/about

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/

zuul:
  routes:
    api:
        path: /**
        serviceId: eureka-provider

配置說明：

瀏覽器訪問:http://127.0.0.1:9000/ ,Zuul 會去 Eureka 服務註冊中心，找到eureka-provider服務以均衡負載的方式訪問

測試服務

依次啟動專案：

spring-cloud-eureka-service
spring-cloud-eureka-provider-1
spring-cloud-eureka-provider-2
spring-cloud-eureka-provider-3
spring-cloud-zuul-service

瀏覽器訪問

訪問:http://127.0.0.1:9000/ ,Zuul 會去 Eureka 服務註冊中心，找到eureka-provider服務以均衡負載的方式訪問

在命令視窗curl http://localhost:9000/，發現一切正常

或者瀏覽器get 請求http://localhost:9000/ F5 重新整理

路由規則

閘道器的預設路由規則

Spring cloud zuul 預設情況下，Zuul會代理所有註冊到Eureka Server的微服務，並且Zuul的路由規則如下：[http://ZUUL_HOST:ZUUL_PORT/]() 微服務在Eureka上的serviceId/**會被轉發到serviceId對應的微服務。

我們註釋 spring-cloud-zuul-service專案中關於路由的配置：

#zuul:
#  routes:
#    api:
#        path: /**
#        serviceId: eureka-provider

瀏覽器訪問

在命令視窗curl http://127.0.0.1:9000/eureka-provider/，發現一切正常

或者瀏覽器get 請求http://127.0.0.1:9000/eureka-provider/ F5 重新整理

ZuulFilter

在下一章，會深入介紹 Zuul 高階功能使用，ZuulFilter ,支援下鵬磊，關注下螢幕下方的微信公眾號

原始碼下載

Contact

• 作者：鵬磊
• 版權歸作者所有，轉載請註明出處
• Wechat：關注公眾號，搜雲庫，專注於開發技術的研究與知識分享