基于Redis实现Spring Cloud Gateway的动态管理 _Redis

文章插图

转载本文需注明出处：微信公众号EAWorld，违者必究。
引言：Spring Cloud Gateway是当前使用非常广泛的一种API网关。它本身能力并不能完全满足企业对网关的期望，人们希望它可以提供更多的服务治理能力。但Spring Cloud Gateway并不提供数据的动态管理，甚至修改个路由都需要重启。我们如何解决它这个短板，同时实现治理配置数据的高效动态管理呢？本文将带来我们网关与redis组合的实践。
目录：1.Spring Cloud Gateway 简介
2.网关数据管理
3.实现细节
1.Spring Cloud Gateway 简介API 网关
API 网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：

客户端会多次请求不同的微服务，增加了客户端的复杂性。
存在跨域请求，在一定场景下处理相对复杂。
认证复杂，每个服务都需要独立认证。
难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。

以上这些问题可以借助 API 网关解决。API 网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑。

文章插图

使用 API 网关后的优点如下：

易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。
易于认证。可以在网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
减少了客户端与各个微服务之间的交互次数。

Spring Cloud Gateway
Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。
Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

文章插图
SCG架构
如图所示，SCG的架构看起来很简单。
首先，它内部包含了一个高性能的Netty Server，用来接收各类网络请求。请求进来之后，会根据配置的各个路由进行匹配并处理请求。每个路由都可以定义多个断言(Predicate)，用于路由匹配。
SCG默认提供了10多个内建的断言，可以基于请求的各个方面（请求头，路径，路径，时间，Cookie，http方法等）进行路由匹配。如果还不够，用户还可以自已扩展。
请求匹配到了合适的路由之后，就会按照路由中配置的各过滤器(filter)，按顺序对请求进行处理。Filter也基本上可以对请求的所有属性做处理，修改，添加或者除请求头，修改请求数据，修改返回的数据等，几乎无所不能。当然，修改请求也只是一方面的用途，认证，鉴权，记录日志等也都可以在网关中统一来做。
所有filter形成处理链，直到所有的filter处理完，才会交给最后面的 Netty Client，由它将处理过的请求发送至对应的微服务。
在请求发送至微服务之前，还可以定义它的负载均衡策略(LoadBalancerRule)，以决定请求至底发往微服务的哪个实例。
Filter 与 LoadBalancerRule 都支持自行扩展。
2.网关数据管理实现一个适合自已的网关，对数据管理需要考虑哪些方面的东西呢？
1.首先，我们要考虑一下，我们需要管理些什么数据。
SCG本身对数据管理的管理是很弱的。它没有提供数据的持久化方案，它所有的数据都来自初始化，来自它的配置文件(Application.yml) 。它本身虽然也对外提供了一些管理接口(Actuator API)能力不够，但能力不够，且这些修改都是暂时的，网关一停，数据就消失了。这就要求我们要用一套更完善的方案，把网关的这些数据管理起来，不能让它只能写在配置文件中，而要支持持久化，支持动态变更。再有就是我们对各微服务的治理数据。网关只用来做路由转发，那就太浪费了，统一认证，统一鉴权，访问日志记录，应用访问统计，黑白名单过滤，API订阅管理，流量限制，甚至数据格式转换，网络协议转换，都可以在网关中来做。而所有的这些能力，无不需要数据的支持。因此，这些服务的治理配置，也是网关需要管理的数据。