1. 网关

网关大致分为流量网关（Traffic Gateway）和服务网关（Service Gateway），在微服务架构中扮演着不同的角色，尽管它们的功能有一定的重叠，但两者有着明显的区别

先说一点，SpringCloud Gateway属于服务网关，抛开这一章的介绍，先阐述下两者的差异

1.1 流量 | 服务

概念	作用	功能	例子
服务网关（Service Gateway）	位于微服务架构内部的组件，主要负责处理微服务之间的通信 位于微服务架构的边缘，用于接收外部请求，并根据路由规则将请求转发到相应的微服务实例	实现了路由、负载均衡、安全认证、监控等功能，帮助微服务之间进行解耦和统一管理，提高系统的可用性和可扩展性	Spring Cloud Gateway、Netflix Zuul 等
流量网关（Traffic Gateway）	位于系统边缘的组件，主要负责处理系统的入口流量，并将流量路由到不同的后端服务或者目标 位于系统的最前端，作为整个系统的入口点	实现了流量控制、协议转换、安全认证、监控等功能，帮助管理和控制系统的入口流量，并保护系统免受恶意攻击和不良流量的影响	NGINX、Kong、Envoy

对于流量网关推荐阅读：Nginx从入门到精通（全）
补充阅读：java框架 零基础从入门到精通的学习路线 附开源项目面经等（超全）

总的来说，两者的有一定的区别，但又有些差异

概念	位置	职责	关注点
服务网关（Service Gateway）	位于微服务架构内部，处理微服务之间的通信	负责微服务之间的路由、负载均衡等	更关注微服务架构内部的通信和管理
流量网关（Traffic Gateway）	位于系统边缘，处理系统的入口流量	负责流量控制、协议转换、安全认证等	更关注系统的入口流量和流量管理

1.2 服务

由于这篇文章的侧重点在于服务网关，此处在了解SpringCloud Gateway的基本知识前，先了解它的缘由

引入的缘由：

• 解耦和服务发现：微服务架构中存在大量的微服务实例，需要解耦客户端和具体的服务实例，引入服务网关可以隐藏底层服务的具体实现，提供统一的服务访问接口
• 复杂路由需求：随着系统的增长，服务之间的通信模式变得复杂，需要灵活的路由机制来处理不同的请求
• 安全性和监控需求：微服务架构中的每个服务都需要独立的安全性和监控机制，通过服务网关可以集中管理安全认证和监控功能，简化系统的管理和维护
• 统一管理和控制：通过服务网关可以统一管理和控制所有的服务请求，实现统一的访问控制、流量控制和日志记录，提高系统的可维护性和可管理性

总的来说：服务网关的引入是为了解决微服务架构中的一些共性问题，并提供统一的解决方案

详细说说服务网关的概念：

• 位于服务端点之前的服务器，系统的入口点，用于处理所有传入和传出的请求
• 充当前端服务与后端微服务之间的中介
• 接收外部请求，执行路由、负载均衡、安全认证、监控等操作，然后将请求转发到相应的微服务实例

对此引入服务网关带来的作用有很多：

• 路由(Routing)：将传入的请求路由到相应的微服务实例，根据请求的路径、主机、请求方法等进行匹配
• 负载均衡(Load Balancing)：分发请求到多个微服务实例，以实现负载均衡，提高系统的可用性和性能
• 安全认证(Security)：处理身份验证和授权，保护微服务免受未经授权的访问
• 监控与日志(Monitoring and Logging)：收集请求的指标和日志，用于监控系统的运行状态、追踪问题和进行分析
• 缓存(Caching)：缓存静态内容或频繁请求的数据，减少对后端服务的压力，提高响应速度
• 协议转换(Protocol Conversion)：将传入的请求从一种协议转换为另一种协议，如 HTTP 到 WebSocket 的转换
• 限流(Rate Limiting)：限制请求的速率，防止因流量过大而导致的系统崩溃或性能下降
• 降级(Degradation)：在系统资源不足或故障时，临时关闭某些功能或服务，以保证核心功能的可用性
• 统一接入(Unified Access)：提供统一的入口点，简化客户端与微服务之间的通信，降低耦合度

2. 基本知识

Spring Cloud Gateway 是一个构建在 Spring Framework 之上的 API 网关服务，它提供了一种简单而有效的方式来路由请求、执行过滤操作以及提供一些基本的流量管理功能

• 路由(Routing)：
  灵活的方式来定义路由规则，将传入的请求映射到相应的目标服务
  路由规则可以基于请求的路径、主机、请求方法、请求头等进行匹配

• 过滤(Filtering)：
  对传入的请求或传出的响应进行修改或添加功能
  过滤器可以用于鉴权、日志记录、请求/响应修改等场景

• 断路器(Circuit Breaker)：
  集成 Hystrix 或者 Resilience4j 来实现断路器模式，以防止服务故障对整体系统的影响

• 负载均衡(Load Balancing)：
  支持集成多种负载均衡策略
  例如使用 Ribbon 或者自定义的负载均衡器，以在多个实例之间分发请求

• 动态路由(Dynamic Routing)：
  通过使用 Spring Cloud DiscoveryClient，Spring Cloud Gateway 可以实现动态路由，从而实现服务的自动发现和注册

• 可插拔性(Pluggability)：
  轻松地添加自定义的路由和过滤器，以满足特定的需求

• 集成(Spring Cloud Integration)：
  提供了与其他 Spring Cloud 组件（如 Eureka、Config Server 等）的无缝集成

• 配置中心(Configurability)：
  通过配置中心（例如 Spring Cloud Config Server）动态管理路由规则和过滤器的配置，从而实现更灵活的配置管理

• 监控与度量(Monitoring and Metrics)：
  集成了 Actuator，可以方便地监控和收集关于网关的运行时数据，如请求处理时间、流量等指标

• 安全性(Security)：
  提供了对安全机制的支持，可以通过 Spring Security 或者其他安全框架来保护网关和后端服务

• 性能优化(Performance Optimization)：
  通过合理的配置和优化，Spring Cloud Gateway 可以实现高性能的请求转发和处理，满足高并发、低延迟的需求

3. 实战讲解

3.1 Demo1

配置 Spring Cloud Gateway 时，通常会涉及路由配置、过滤器配置、负载均衡配置等

下面展示一个简单的 Spring Cloud Gateway 的配置示例
（有两个微服务：service1 和 service2，它们的实例分别运行在 http://localhost:8081 和 http://localhost:8082 上）

在 Spring Boot 项目中引入相关的依赖，以使用 Spring Cloud Gateway

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

在 application.yml 中配置 Spring Cloud Gateway：

spring:
  cloud:
    gateway:
      routes:
        - id: service1_route  # id：路由的唯一标识符，通常以微服务命名，指明这个服务做啥
          uri: http://localhost:8081  # uri：目标服务的地址
          predicates:
            - Path=/service1/**  # predicates：路由匹配规则，这里使用 Path 谓词，表示匹配请求的路径
          filters:
            - StripPrefix=1  # filters：过滤器配置，这里使用 StripPrefix 过滤器，表示去除请求路径中的前缀

        - id: service2_route
          uri: http://localhost:8082
          predicates:
            - Path=/service2/**
          filters:
            - StripPrefix=1

以上配置实现了以下功能：

• 将 /service1/** 的请求转发到 http://localhost:8081，并去掉请求路径中的 /service1 前缀
• 将 /service2/** 的请求转发到 http://localhost:8082，并去掉请求路径中的 /service2 前缀

对应的配置项详细说明：

• id：路由的唯一标识符，用于在配置文件中区分不同的路由规则
  每个路由都需要一个唯一的id，以确保路由的唯一性
  通常采用自定义的名称，以便在配置文件中更好地理解和管理

• uri：请求最终被转发到的目标地址
  这个地址可以是一个具体的URL，也可以是一个服务的逻辑名称，Spring Cloud Gateway 会根据配置进行服务的发现和路由

• order：路由的优先级，用于确定路由的匹配顺序
  数字越小，优先级越高，即在多个路由规则匹配的情况下，优先选择优先级高的路由
  默认情况下，路由的优先级是根据它们在配置文件中的顺序来确定的

• predicates：断言数组，用于定义匹配条件，确定哪些请求会被路由到指定的目标地址
  断言函数根据请求的不同属性进行判断，例如路径、方法、主机等
  如果断言函数返回true，则路由规则匹配成功

• filters：过滤器数组，用于在请求传递过程中对请求进行一些修改或者添加功能
  过滤器可以用于修改请求头、请求体，添加请求参数，实现安全认证，记录日志等功能，增强了网关的灵活性和扩展性

3.2 Demo2

根据上面的Demo1讲解，相信了解了不少，现在看如下的配置：（application.yaml）

# 配置网关
spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/user/**  # 访问user路径转发用户服务
        - id: product-service # 此名称随意定义
          uri: lb://product-service #使用负载均衡,调用服务名,这是服务名
          predicates:
            - Path=/product/** # 访问product相关,转发到product服务
        # 静态资源对应的服务
        - id: static-service
          uri: lb://static-service #静态资源处理以及oss上传服务!
          predicates:
            - Path=/public/**
        - id: carousel-service  # 轮播图服务
          uri: lb://carousel-service #静态资源处理以及oss上传服务!
          predicates:
            - Path=/carousel/**
        - id: category-service  # 类别服务
          uri: lb://category-service
          predicates:
            - Path=/category/**
        - id: search-service  # 类别服务
          uri: lb://search-service
          predicates:
            - Path=/search/**
        - id: collect-service  # 收藏服务
          uri: lb://collect-service
          predicates:
            - Path=/collect/**
        - id: cart-service  # 购物车服务
          uri: lb://cart-service
          predicates:
            - Path=/cart/**
        - id: order-service  # 订单服务
          uri: lb://order-service
          predicates:
            - Path=/order/**
        - id: admin-service  # 订单服务
          uri: lb://admin-service
          predicates:
            - Path=/admin/**

在这个配置中，uri 值看起来比较奇怪，例如 lb://user-service、lb://product-service 等。这里的 lb 是 LoadBalancer 的简写，表示这是一个负载均衡的目标地址

在 Spring Cloud 中，服务发现和负载均衡是通过服务名称来进行的，而不是直接指定服务的实际地址
这样做的好处是，可以让微服务的实例动态地注册和注销，而网关不需要关心服务的具体地址，而是通过服务名称来进行查找和负载均衡

因此，lb://user-service 表示通过服务发现（通常是使用注册中心，如Eureka、Consul等）来查找名为 user-service 的微服务实例，并且负载均衡地将请求分发到这些实例之一
这样，无论 user-service 的实例在哪个地址，网关都可以找到它并转发请求

对应的bootstrap.yaml配置 （结合Nacos），推荐阅读：Nacos基础版 从入门到精通

server:
  port: 3000 # 前端默认访问端口号为3000
  servlet:
    context-path: / # 前端默认访问的根路径
spring:
  application:
    name: gateway-service  # 程序名就是服务名
  cloud:
    nacos:
      # 如果注册中心不在本机,需要移到本位置,否则一致查找本地:8848端口!
      server-addr: 127.0.0.1:8848 #注册中心

这种方式使得微服务架构更加灵活，可以根据实际情况动态地调整和管理服务的实例，而不需要手动维护地址信息