Spring Cloud Gateway應用篇（十三）

1、概述

在微服務架構中，每一個服務都是一個能夠獨立開發和運行的組件，而一個完整的微服務架構由一系列獨立運行的微服務組成。其中每一個服務都只會完成特定領域的功能，好比訂單服務提供與訂單業務場景有關的功能、商品服務提供商品展現功能等。各個微服務之間經過輕量級通訊機制 REST API 或者 RPC 完成通訊。 微服務以後在某些層面會帶來必定的影響，好比，一個用戶查看一個商品的詳情，對於客戶端來講，可能須要調用商品服務、評論服務、庫存服務、營銷服務等多個服務來完成數據的渲染在這個場景中，客戶端雖然能經過調用多個服務實現數據的獲取，可是會存在一 些問題，好比：

• 客戶端須要發起屢次請求，增長了網絡通訊的成本及客戶端處理的複雜性。
• 服務的鑑權會分佈在每一個微服務中處理，客戶端對於每一個服務的調用都須要重複鑑權。
• 在後端的微服務架構中，可能不一樣的服務採用的協議不一樣，好比有 HTTP、RPC 等。客戶端若是須要調用多個服務，須要對不一樣協議進行適配

2、微服務網關的做用

因此，咱們能夠在微服務以前增長一個前置節點，這個節點就是網關，網關就是一個網絡鏈接到另外一個網絡的「關口」。也就是網絡。而在微服務架構中，它不只僅只是一個網絡互連的一個關口，還有更多的做用，之前面分析的這個場景爲例，增長網關以後全部請求的下發都由網關下發；對於商品詳情展現的場景來講，增長了 API 網關以後，在 API 網關層能夠把後端的多個服務進行整合，而後提供一個惟一的業務接口，客戶端只須要調用這個接口便可完成數據的獲取及展現。在網關中會再去消費後端的多個微服務進行統一的整合，給客戶端返回一個惟一的響應。去消費後端的多個微服務進行統一的整合，給客戶端返回一個惟一的響應。

• 針對全部請求進行統一鑑權、限流、熔斷、日誌。
• 協議轉化。針對後端多種不一樣的協議，在網關層統一處理後以 HTTP 協議對外提供服務。
• 用過 Dubbo 框架的應該知道，針對 Dubbo 服務還須要提供一個 Web 應用來進行協議轉化。
• 統一錯誤碼處理。
• 請求轉發，而且能夠基於網關實現內外網隔離

 2.一、網關的做用

• 性能：API高可用，負載均衡，容錯機制。
• 安全：權限身份認證、脫敏，流量清洗，後端簽名（保證全鏈路可信調用）,黑名單（非法調用的限制）。
• 日誌：日誌記錄（spainid,traceid）一旦涉及分佈式，全鏈路跟蹤必不可少。
• 緩存：數據緩存。
• 監控：記錄請求響應數據，api耗時分析，性能監控。
• 限流：流量控制，錯峯流控，能夠定義多種限流規則。
• 灰度：線上灰度部署，能夠減少風險。
• 路由：動態路由規則。

3、服務網關的要求

從上面的案例來看，網關成了全部流量的入口，那麼對於這樣一個角色來講，它須要在某些方面有很高的要求

• 穩定性，
• 安全性，防止惡意請求，以及保障數據傳輸的安全性
• 高性能、可用性，
  • 網關做爲全部流量的入口，那麼對於性能這塊的要求就很是高了，由於一旦網關的性能出現瓶頸，就算後端的服務性能再高，意義也不大
  • 網關必需要支持集羣部署，這個是分佈式架構的基本要求。不然網關服務掛掉就會致使整個系統不可用
• 擴展性，可維護性，對於定製化需求方面，如何實現可擴展；

常見的網關方案

• OpenResty（Nginx+lua）
• Kong，是基於openresty之上的一個封裝，提供了更簡單的配置方式。 它還提供了付費的商業插件
• Tyk（開源、輕量級），Tyk 是一個開源的、輕量級的、快速可伸縮的 API 網關，支持配額和速度限制，支持認證和數據分析，支持多用戶多組織，提供全 RESTful API。它是基於go語言開發的組件。
• Zuul，是spring cloud生態下提供的一個網關服務，性能相對來講不是很高
• Spring Cloud Gateway，是Spring團隊開發的高性能網關

網關選型

• 部署和維護成本
• 開源仍是閉源
• 是否私有化部署
• 功能是否知足當前需求
• 社區資料的完善以及版本迭代和功能維護

4、Spring Cloud Gateway的核心概念

• Route 路由，它是網關的基礎元素，包含ID、目標URI、斷言、過濾器組成，當前請求到達網關時，會經過Gateway Handler Mapping，基於斷言進行路由匹配，當斷言爲true時，匹配到路由進行轉發
• Predicate，斷言，學過java8的應該知道這個函數，它能夠容許開發人員去匹配HTTP請求中的元素，一旦匹配爲true，則表示匹配到合適的路由進行轉發
• Filter，過濾器，能夠在請求發出的先後進行一些業務上的處理，好比受權、埋點、限流等。

它的總體工做原理以下。

其中，predicate就是咱們的匹配條件；而filter，就能夠理解爲一個無所不能的攔截器。有了這兩個元素，再加上目標uri，就能夠實現一個具體的路由了。客戶端向 Spring Cloud Gateway 發出請求，若是請求與網關程序定義的路由匹配，則該請求就會被髮送到網關 Web 處理程序，此時處理程序運行特定的請求過濾器鏈。過濾器之間用虛線分開的緣由是過濾器可能會在發送代理請求的先後執行邏輯。全部 pre 過濾器邏輯先執行，而後執行代理請求；代理請求完成後，執行 post 過濾器邏輯

5、應用實戰

新建一個spring-cloud-gateway服務

在spring-cloud-gateway服務中導入如下包

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

而後在配置文件中配置以下

server:
  port: 9100
spring:
  application:
    name: spring-cloud-gateway
  cloud:
    gateway:
      routes:
         - predicates:
            - Path=/service/**
           filters:   #過濾
            - StripPrefix=1
           uri: http://localhost:8080/


eureka:
  instance:
    hostname: localhost
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/  #指向服務註冊中心的地址

啓動項目經過網關訪問業務服務，發現能夠直接經過網關的端口發起訪問

 

 5.一、斷言

https://docs.spring.io/spring-cloud-gateway/docs/2.2.5.RELEASE/reference/html/#the-after-route-predicate-factory

這是官方提供的11種斷言方法，有興趣能夠按官網的去配置玩下，cloud整個體系配置相對來講很簡單的

 

 下面就寫一個關於經常使用的Cookie配置下；

 

 

 

 

 

 

 

 5.二、自定義斷言

若是官網提供的斷言不知足本身的要求，官網也支持自定義斷言；自定義斷言要繼承AbstractRoutePredicateFactory這個抽象工廠，咱們自定義的斷言類名後綴必須是RoutePredicateFactory；自定義也很簡單也就是看別人怎麼寫的而後抄就完了

 

 

 

 

 

 而後把以前測試工具的Cookies刪除，調用成功