一、概述

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

客戶端需要發起多次請求，增加了網路通訊的成本及客戶端處理的複雜性。
服務的鑒權會分布在每個微服務中處理，客戶端對於每個服務的調用都需要重複鑒權。
在後端的微服務架構中，可能不同的服務採用的協議不同，比如有 HTTP、RPC 等。客戶端如果需要調用多個服務，需要對不同協議進行適配

二、微服務網關的作用

所以，我們可以在微服務之前增加一個前置節點，這個節點就是網關，網關就是一個網路連接到另一個網路的「關口」。也就是網路。而在微服務架構中，它不僅僅只是一個網路互連的一個關口，還有更多的作用，以前面分析的這個場景為例，增加網關之後所有請求的下發都由網關下發；對於商品詳情展示的場景來說，增加了 API 網關之後，在 API 網關層可以把後端的多個服務進行整合，然後提供一個唯一的業務介面，客戶端只需要調用這個介面即可完成數據的獲取及展示。在網關中會再去消費後端的多個微服務進行統一的整合，給客戶端返回一個唯一的響應。去消費後端的多個微服務進行統一的整合，給客戶端返回一個唯一的響應。

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

2.1、網關的作用

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

三、服務網關的要求

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

穩定性，
安全性，防止惡意請求，以及保障數據傳輸的安全性
高性能、可用性，
- 網關作為所有流量的入口，那麼對於性能這塊的要求就非常高了，因為一旦網關的性能出現瓶頸，就算後端的服務性能再高，意義也不大
- 網關必須要支援集群部署，這個是分散式架構的基本要求。否則網關服務掛掉就會導致整個系統不可用
擴展性，可維護性，對於訂製化需求方面，如何實現可擴展；

常見的網關方案

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

網關選型

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

四、Spring Cloud Gateway的核心概念

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

它的整體工作原理如下。

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

五、應用實戰

新建一個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: //localhost:8080/


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

啟動項目通過網關訪問業務服務，發現可以直接通過網關的埠發起訪問