SpringCloud Alibaba實戰（11：引入服務網關Gateway）

源碼位址： https://gitee.com/fighter3/eshop-project.git 持續更新中……

大家好，我是三分惡。

在前面的章節中，我們已經完成了服務間的調用、統一配置等等，在這一章節裡，我們會引入微服務體系的一個重要元件——網關。

網關概述

為什麼要引入網關

大家都知道，我們服務端的各個服務調用是從服務注冊中心拉取服務清單，再由負載均衡政策去調用對應的服務提供方。

那麼，在什麼都不做的情況下，看看我們的用戶端，包括PC、移動端等等是怎麼通路我們的服務端的呢？

這麼辦有什麼問題呢？

• 用戶端需要維護後端服務的位址，如果我們叢集部署，一個服務有數十上百個節點呢？
• 日志、鑒權等等邏輯，我們每個服務都得搞一套。

• 服務端的服務都得能被用戶端通路，是以需要外網ip，但是ip資源實在太寶貴了。

  ……

這時候就需要在用戶端和服務端之間加一個統一的入口，而在微服務的體系中，承擔這個角色的就是網關。

我們加入一個網關，來作為請求的統一接入。我們隻需要将網關的機器ip配置到DNS，或者接入層負載，那麼用戶端的服務最終通過我們的網關，再轉發給對應的服務端服務。

常見微服務網關

目前市面上根據技術棧實作的不同大概有如下一些網關:

簡單介紹一下這些網關：

• Nginx： Nginx由核心和子產品組成，核心的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置檔案與用戶端請求進行 URL 比對，用于啟動不同的子產品去完成相應的工作。
• Kong: Kong是一款基于OpenResty（Nginx + Lua子產品）編寫的高可用、易擴充的，由Mashape公司開源的API Gateway項目。Kong是基于NGINX和Apache Cassandra或PostgreSQL建構的，能提供易于使用的RESTful API來操作和配置API管理系統，是以它可以水準擴充多個Kong伺服器，通過前置的負載均衡配置把請求均勻地分發到各個Server，來應對大批量的網絡請求。
• **Netfilx Zuul：**Zuul 是 Netflix 開源的微服務網關元件，它可以和 Eureka、Ribbon、Hystrix 等元件配合使用。社群活躍，融合于 SpringCloud 完整生态，是建構微服務體系前置網關服務的最佳選型之一。
• **Spring Cloud GetWay：**Spring Cloud Gateway 是Spring Cloud的一個全新的API網關項目，目的是為了替換掉Zuul1。Gateway可以與Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等元件配合使用，實作路由轉發、負載均衡、熔斷等功能，并且Gateway還内置了限流過濾器，實作了限流的功能。

Spring Cloud GetWay實踐

在上面我們已經簡單介紹了各種常見的微服務網關，接下來引入我們今天的主角——SpringCloud Gateway。

建立網關服務

• 建立網關子module

  esop-gateway

• 引入相關依賴，注意啊，因為網關服務作為一個服務，同樣需要配置中心和注冊中心，是以，我們也引入了相關依賴

<!--Spring Cloud Alibaba-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <version>0.2.2.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
        </dependency>
        <!-- spring cloud alibaba nacos config 依賴 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>
        <!--gateway網關-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>      

• bootstap.yml：在配置檔案裡除了應用名稱，我們還配置了Nacos的相關配置，不太清楚的同學可以檢視上一節。

spring:
  application:
    name: gateway-service # 應用名稱
  profiles:
    active: dev      # 目前環境對應的 profile
  cloud:
    nacos:
      config:
        enabled: true     # 如果不想使用 Nacos 進行配置管理，設定為 false 即可
        server-addr: 127.0.0.1:8848   # Nacos Server 位址
        group: DEFAULT_GROUP     # 組，預設為 DEFAULT_GROUP
        file-extension: yaml    # 配置内容的資料格式，預設為 properties
        namespace: dev_space    # 指定命名空間，預設為public      

路由配置

我們在nacos中來完成gateway的相關路由的配置。

server:
  port: 9000
spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
    gateway:
      discovery:
        locator:
          enabled: true
      routes:
      - id: user-service
        uri: lb://user-service
        predicates:
          - Path=/user/**
        filters:
          - StripPrefix=1        

我們在裡面進行了路由轉發的配置，也就是

routes

,我們來看一看這些配置項都是什麼意思：

• id： 路由的

  唯一

  辨別，用以和其它Route區分
• uri： 請求要轉發到的位址，lb 指的是從nacos中按照名稱擷取微服務，并遵循負載均衡政策
• predicates： 路由需要滿足的條件，也是個數組（這裡是

  或

  的關系）
• filters： 過濾器，請求在傳遞過程中可以通過過濾器對其進行一定的修改

在這個配置項裡，我們定義了

user

開頭的請求，分發到

user-service

這個服務。

接下來我們看看效果吧！

路由轉發效果

回憶一下，在使用者服務裡有一個get請求的根據 id 擷取使用者的接口，通路一下：

OK，我們現在不直接通路使用者服務的接口，而是改成通路網關服務，我們來看看效果：

我們通路的位址是：http://localhost:9000/user/shop-user/user/get-by-id?id=1 ，簡單解析一下：

到此，我們已經引入了Spring Cloud Gateway作為微服務網關，并完成了基本的路由轉發的功能。

除了基本的路由轉發，服務網關還可以完成權限校驗、限流、API校驗等功能，後續我們會繼續深入，敬請期待！

“簡單的事情重複做，重複的事情認真做，認真的事情有創造性地做！”——

我是三分惡，可以叫我老三/三分/三哥/三子，一個能文能武的全棧開發，咱們下期見！