Spring Cloud : Gateway 服务网关认识（一）

目录

一、简介

二、Spring Cloud Gateway 词汇

三、Spring Cloud Gateway 与 Zuul的区别

四、什么是微服务网关

五、为什么要使用网关

六、网关解决了什么问题

七、常用的网关解决方案

1. Nginx + Lua

2. Kong

3. Traefik

4. Spring Cloud Netflix  Zuul

Spring Cloud Gateway 学习专栏

1. Spring Cloud : Gateway 服务网关认识（一）

2. Spring Cloud ：整合Gateway 学习 (二)

3. Spring Cloud：Gateway 路由定义定位器 RouteDefinitionLocator （三）

4. Spring Cloud : Gateway 网关过滤器 GatewayFilter（四）

5. Spring Cloud : Gateway 网关限流（五）

6. Spring Cloud：Gateway 集成 Sentinel （六）

7. Spring Cloud : Gateway Redis动态路由 (七)

8. Spring Cloud : Gateway 整合Swagger (八)

如果发现本文有错误的地方，请大家毫不吝啬，多多指教，欢迎大家评论，谢谢！

---

一、简介

Spring Cloud Gateway是Spring Cloud推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。相对Zuul有哪些优势？Zuul（1.x） 基于 Servlet，使用阻塞 API，它不支持任何长连接，如 WebSockets，Spring Cloud Gateway 使用非阻塞 API，支持 WebSockets，支持限流等新特性。

  Spring Cloud Gateway 特性

• 基于 Java 8 编码；
• 基于Spring Framework 5，Project Reactor和Spring Boot 2.0构建
• 支持动态路由，能够匹配任何请求属性上的路由。
• 支持内置 到 Spring Handler 映射 中的 路 由 匹配；
• 支持基于 HTTP 请求的路由匹配（ Path、 Method、 Header、 Host 等）；
• 集成了Hystrix断路器
• 过滤器 作用于 匹配 的 路 由；
• 过滤器可以修改 HTTP 请求和HTTP 响应（ 增加/ 修改 头部、 增加/ 修改 请求 参数、 改写 请求 路径 等）；
• 支持 Spring Cloud DiscoveryClient 配置路由，与服务发现与注册配合使用。
• 支持限流
• 支持地址重写

二、Spring Cloud Gateway 词汇

Route（路由）: 路由网关的基本构建块。 它由ID，目标URI，谓词集合和过滤器集合定义。 如果聚合谓词为真，则匹配路由。

Predicate: 这是一个Java 8函数谓词。 输入类型是Spring Framework ServerWebExchange。 这允许开发人员匹配HTTP请求中的任何内容，例如标头或参数。

Filter: 这些是使用特定工厂构建的Spring Framework GatewayFilter实例。 这里，可以在发送下游请求之前或之后修改请求和响应。

三、Spring Cloud Gateway 与 Zuul的区别

在 Finchley 正式版之前，Spring Cloud 推荐的网关是 Netflix 提供的Zuul：

1、Zuul 1.x，是一个基于阻塞 I/ O 的 API Gateway

2、Zuul 1.x 基于Servlet 2. 5，使用阻塞架构，它不支持任何长连接，如 WebSocket。 Zuul 的设计模式和Nginx较像，每次 I/ O 操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx 用C++ 实现，Zuul 用 Java 实现，而 JVM 本身会有第一次加载较慢的情况，使得Zuul 的性能相对较差。

3、Zuul 2.x，基于 Netty 非阻塞、支持长连接，但 Spring Cloud 目前还没有整合。 Zuul 2.x的性能较 Zuul 1.x 有较大提升。在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1. 6 倍。

4、Spring Cloud Gateway 建立在 Spring Framework 5、 Project Reactor 和 Spring Boot 2 之上， 使用 非 阻塞 API。

5、Spring Cloud Gateway 还 支持 WebSocket， 并且 与 Spring 紧密 集成， 拥有更好的开发体验Spring Cloud Gateway需要Spring Boot和Spring Webflux提供的Netty运行时。它不能在传统的Servlet容器中工作或构建为WAR。

四、什么是微服务网关

        API Gateway（APIGW / API 网关），顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。在微服务概念的流行之前，API 网关就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

　　API 网关的流行，源于近几年来移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的一个标配组件。

　　API 网关是一个服务器，是系统对外的唯一入口。API 网关封装了系统内部架构，为每个客户端提供定制的 API。所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有非业务功能。API 网关并不是微服务场景中必须的组件，如下图，不管有没有 API 网关，后端微服务都可以通过 API 很好地支持客户端的访问。

五、为什么要使用网关

• 单体应用：浏览器发起请求到单体应用所在的机器，应用从数据库查询数据原路返回给浏览器，对于单体应用来说是不需要网关的。
• 微服务：微服务的应用可能部署在不同机房，不同地区，不同域名下。此时客户端（浏览器/手机/软件工具）想要请求对应的服务，都需要知道机器的具体 IP 或者域名 URL，当微服务实例众多时，这是非常难以记忆的，对于客户端来说也太复杂难以维护。此时就有了网关，客户端相关的请求直接发送到网关，由网关根据请求标识解析判断出具体的微服务地址，再把请求转发到微服务实例。这其中的记忆功能就全部交由网关来操作了。

总结

如果让客户端直接与各个微服务交互：

• 客户端会多次请求不同的微服务，增加了客户端的复杂性
• 存在跨域请求，在一定场景下处理相对复杂
• 身份认证问题，每个微服务需要独立身份认证
• 难以重构，随着项目的迭代，可能需要重新划分微服务
• 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难

　　

因此，我们需要网关介于客户端与服务器之间的中间层，所有外部请求率先经过微服务网关，客户端只需要与网关交互，只需要知道网关地址即可。这样便简化了开发且有以下优点：

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

六、网关解决了什么问题

网关具有身份认证与安全、审查与监控、动态路由、负载均衡、缓存、请求分片与管理、静态响应处理等功能。当然最主要的职责还是与“外界联系”。

　　总结一下，网关应当具备以下功能：

• 性能：API 高可用，负载均衡，容错机制。
• 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用），黑名单（非法调用的限制）。
• 日志：日志记录，一旦涉及分布式，全链路跟踪必不可少。
• 缓存：数据缓存。
• 监控：记录请求响应数据，API 耗时分析，性能监控。
• 限流：流量控制，错峰流控，可以定义多种限流规则。
• 灰度：线上灰度部署，可以减小风险。
• 路由：动态路由规则。

　　

七、常用的网关解决方案

1. Nginx + Lua

　　Nginx 是由 IgorSysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，一个高性能的 HTTP 和反向代理服务器。Ngnix 一方面可以做反向代理，另外一方面做可以做静态资源服务器。

• Nginx 适合做门户网关，是作为整个全局的网关，对外的处于最外层的那种；而 Gateway 属于业务网关，主要用来对应不同的客户端提供服务，用于聚合业务。各个微服务独立部署，职责单一，对外提供服务的时候需要有一个东西把业务聚合起来。

• Gateway 可以实现熔断、重试等功能，这是 Nginx 不具备的。

2. Kong

　　Kong 是 Mashape 提供的一款 API 管理软件，它本身是基于 Ngnix + Lua 的，但比 Nginx 提供了更简单的配置方式，数据采用了 ApacheCassandra/PostgreSQL 存储，并且提供了一些优秀的插件，比如验证，日志，调用频次限制等。Kong 非常诱人的地方就是提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。

优点：基于 Nginx 所以在性能和稳定性上都没有问题。Kong 作为一款商业软件，在 Nginx 上做了很扩展工作，而且还有很多付费的商业插件。Kong 本身也有付费的企业版，其中包括技术支持、使用培训服务以及 API 分析插件。

缺点：如果你使用 Spring Cloud，Kong 如何结合目前已有的服务治理体系？

3. Traefik

　　Traefik 是一个开源的 GO 语言开发的为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。Traefik 拥有一个基于 AngularJS 编写的简单网站界面，支持 Rest API，配置文件热更新，无需重启进程。高可用集群模式等。

相对 Spring Cloud 和 Kubernetes 而言，目前比较适合 Kubernetes。

　　

4. Spring Cloud Netflix  Zuul

　　Zuul 是 Netflix 公司开源的一个 API 网关组件，Spring Cloud 对其进行二次基于 Spring Boot 的注解式封装做到开箱即用。目前来说，结合 Sring Cloud 提供的服务治理体系，可以做到请求转发，根据配置或者默认的路由规则进行路由和 Load Balance，无缝集成 Hystrix。

虽然可以通过自定义 Filter 实现我们想要的功能，但是由于 Zuul 本身的设计是基于单线程的接收请求和转发处理，是阻塞 IO，不支持长连接。目前来看 Zuul 就显得很鸡肋，随着 Zuul 2.x 一直跳票（2019 年 5 月发布了 Zuul 2.0 版本），Spring Cloud 推出自己的 Spring Cloud Gateway。

大意就是：Zuul 已死，Spring Cloud Gateway 永生（手动狗头）。

　　

 Zuul 1.0

　　

　　

Zuul 2.0

　　

　　

原文链接

1. Spring Cloud 系列之 Gateway 服务网关（一）