EDAS 让 Spring Cloud Gateway 生产可用的二三策

2023-12-23
浙江
本文字数：4753 字
阅读完需：约 16 分钟

作者：kirito

Spring Cloud Gateway 是 Spring Cloud 微服务生态下的网关组件，一直以来备受 Java 社区的用户关注，很多企业选择使用其作为微服务网关或者业务网关。在阿里云上，也不乏有很多网关类型的产品供用户使用，例如 API Gateway 和 MSE Higress，使用 PaaS 化的方式提供网关能力，用户不再需要关注网关的实现，直接获得开箱即用的能力。在从前，用户只能选择自建 Spring Cloud Gateway，或者购买云产品，而今天介绍的 EDAS 增强 Spring Cloud Gateway 的新姿势，给用户提供了一个新的选择。

让 Spring Cloud Gateway 生产可用

开源 Spring Cloud Gateway 存在一些让企业级用户担忧的因素，包括内存泄漏问题，以及路由设计问题，EDAS 根据云服务总线 CSB 多年沉淀下来的 Spring Cloud Gateway 使用经验，对诸多已经存在的问题进行了治理，对诸多的风险因素也进行了规避，彻底打消用户使用 Spring Cloud Gateway 技术侧的顾虑。

内存泄漏问题，该问题来自于 CSB 的生产实践，Spring Cloud Gateway 底层依赖 netty 进行 IO 通信，熟悉 netty 的人应当知道其有一个读写缓冲的设计，如果通信内容较小，一般会命中 chunked buffer，而通信内容较大时，例如文件上传，则会触发内存的新分配，而 Spring Cloud Gateway 在对接 netty 时存在逻辑缺陷，会导致新分配的池化内存无法完全回收，导致堆外内存泄漏。并且这块堆外内存时 netty 使用 unsafe 自行分配的，通过常规的 JVM 工具还无法观测，非常隐蔽。

EDAS 建议为 Spring Cloud Gateway 应用增加启动参数 -Dio.netty.allocator.type=unpooled，使得请求未命中 chunked buffer 时，分配的临时内存不进行池化，规避内存泄漏问题。

-Dio.netty.allocator.type=unpooled 不会导致性能下降，只有大报文才会触发该内存的分配，而网关的最佳实践应该是不允许文件上传这类需求，加上该参数是为了应对非主流场景的一个兜底行为。

开源 Spring Cloud Gateway 并未提供路由配置校验能力，当路由配置出错时，可能会带来灾难性的后果，例如在配置路由时，误将 POST 写成了 PEST：predicates: Method=PEST，可能会导致网关中所有路由失效，爆炸半径极大。

EDAS 建议为 Spring Cloud Gateway 应用配置 spring.cloud.gateway.fail-on-route-definition-error: false ，降低爆炸半径。通过 EDAS 创建的路由，将会经过校验，确保路由的格式正确，提前规避问题。

以上只是 EDAS 增强 Spring Cloud Gateway 方案的部分案例，EDAS 围绕性能、安全、稳定性等方面，全面为用户的网关保驾护航，让用户彻底回归到业务本身。

围绕让 Spring Cloud Gateway 生产可用这个基本话题，让用户在云上放心的使用 Spring Cloud Gateway，EDAS 推出了一个新的功能，使用无侵入式的方式增强 Spring Cloud Gateway。

功能介绍

众所周知，在 EDAS 中部署的 Java 应用都会挂载一个 Java Agent，通过 Java Agent 技术，EDAS 提供了丰富的微服务治理以及可观测性的能力，此次介绍的 Spring Cloud Gateway 增强能力，同样通过该 Java Agent 实现。

EDAS 增强 Spring Cloud Gateway 带来的最直观的变化便是提供了一个白屏控制台，方便用户进行操作，同时提供了诸多的增强能力：

动态配置
自定义插件
路由调试
限流降级
可观测性增强

为了方便用户有一个直观的了解，本文以一个快速入门开始进行介绍。

部署 Spring Cloud Gateway

用户可以将已有的 Spring Cloud Gateway 打包成 jar 包或者镜像，在 EDAS 中进行部署，或者也可以使用 EDAS 提供 Demo 部署包进行部署。如上图所示，EDAS 新增支持了 Spring Cloud Gateway 应用的 Demo 部署包，在该部署包中，事先配置好了一个 Nacos 注册中心，会自动连接到当前部署的微服务空间，并未配置任何路由，因为接下来将会进行动态路由配置的演示，所以无需事先在配置文件中配置。整个部署过程和部署一个普通的微服务应用没有任何差异。

创建路由并测试

EDAS 会识别到 Spring Cloud Gateway 应用的特征，并在菜单栏中动态增加应用网关的菜单。在快速入门中，示例创建了两条路由，分别是 http:// 格式的直接请求场景和 lb:// 格式的服务发现场景。为方便测试，可以在应用总览中为该网关应用配置一个公网的 SLB，通过 curl 请求测试：

~ curl 121.xx.xx.xx/httpbin/get{  "args": {},  "headers": {    "Aaa": "ccc",    "Accept": "*/*",    "Content-Length": "0",    "Eagleeye-Ip": "192.168.2.1",    "Eagleeye-Pappname": "5ae05114-bc80-4a32-9048-209b3a93d723",    "Eagleeye-Prpc": "/httpbin/get",    "Eagleeye-Pspanid": "-7254661991881594415",    "Eagleeye-Root-App": "5ae05114-bc80-4a32-9048-209b3a93d723",    "Eagleeye-Rpcid": "0.2.1",    "Eagleeye-Sampled": "s0",    "Eagleeye-Spanid": "-1207596966212570593",    "Eagleeye-Traceid": "eac0a8020116974429411421021d0001",    "Eagleeye-Userdata": "__microservice_match_result__=[]",    "Forwarded": "proto=http;host=121.xx.xx.xx;for=\"140.xx.xx.xx\"",    "Gfs.Scg.Ip": "192.168.2.1",    "Host": "httpbin.org",    "Name": "kirito,kirito",    "User-Agent": "curl/7.64.1",    "X-Amzn-Trace-Id": "Root=1-652cec7d-50f852f622c546f20f8997fe",    "X-Forwarded-Host": "121.xx.xx.xx",    "X-Forwarded-Prefix": "/httpbin"  },  "origin": "121.xx.xx.xx, 47.xx.xx.xx",  "url": "http://121.xx.xx.xx/get"}

复制代码

网关成功转发了请求，至此路由测试完毕。

方案优势

以下情况，均可以考虑使用 EDAS Spring Cloud Gateway 增强方案：

已经在使用 Spring Cloud Gateway
网关存在较强的业务定制需求，例如企业级用户/权限体系对接
Java 技术栈主导，希望对网关组件有自主掌控力
网关后端服务使用 Spring Cloud 技术栈

EDAS 提供的 Spring Cloud Gateway 增强方案解耦了网关的业务属性和中间件属性，用户可以专注于在 Spring Cloud Gateway 开源的基础上进行二次开发，注入复杂的业务逻辑，而将网关的功能（动态配置、限流降级等）、安全、性能等中间件属性交给 EDAS。

对于已经在使用 Spring Cloud Gateway 的用户，当 Spring Cloud Gateway 应用被 EDAS 托管后，无需改动任何代码，即可以在保留原本扩展点的同时，获得诸多的增强能力。 今后依旧可以在应用基础上继续进行二次开发，使网关应用获得和业务应用一样的开发体验。传统的 PaaS 化网关在自定义扩展的支持上，一般要求用户去适配网关自身的规范，使用不熟悉的语言或者插件机制，存在一定的学习成本和风险。

如果用户目前没有网关，考虑新增一个网关，正在进行网关方案的调研，则需要针对自身的业务场景进行充分的考虑。如果符合 Java 技术栈、Spring Cloud 微服务体系等关键词，那么同样可以优先考虑该方案。

相比较阿里云上同类型的 PaaS 网关产品，他们同样有各自的使用场景，例如 API Gateway 可以实现精细化的 API 管理，MSE Higress 可以作为三合一的网关，也可以作为 K8s Ingress 的实现。可以根据自身需求来决定网关方案，EDAS 增强 Spring Cloud Gateway 的方案为用户新添了一个选型。

相比开源 Spring Cloud Gateway，EDAS Agent 增强方案在 100% 兼容开源功能的基础上，进行了以下能力的增强。

能力增强

动态配置能力

EDAS 为 Spring Cloud Gateway 的路由（Route）和插件（Gateway Filter）提供了动态配置能力，以白屏化的形式呈现，方便用户进行配置。

如果 Spring Cloud Gateway 项目中已经配置了路由，例如配置在 application.yml 中，同时又在 EDAS 控制台中进行了配置，这些路由最终会合并成一份路由集合。需要注意的是 EDAS 控制台中只会展示由 EDAS 发布的路由配置，不会展示 application.yml 中的配置，但实际上这两份路由都会生效。使用该方案时，建议用户通过配置导入 &导出的方式将配置迁移至 EDAS 控制台，方便统一管理。

配置导入 &导出

路由和全局插件均支持通过 Yaml 创建，Yaml 的格式遵循开源 Spring Cloud Gateway 的 schema 规范，以下是两个配置示例：

spring:  cloud:    gateway:      routes:      # 1. 利用域名进行路由匹配，且后端是固定 HTTP URL 的场景      - id: r-demo        predicates:        # 只有域名为 demo.com 的请求才会匹配上该路由        - Host=demo.com        filters:        # 该插件在转发请求时，在请求头中添加 Header 键值对        - AddRequestHeader=a,b        # uri 里填写后端 HTTP URL        uri: http://demo.com        # order 代表路由的优先级，值越小，优先级越高        order: 1000      # 2. 利用路径前缀进行路由匹配，且后端是微服务的场景      - id: r-demo-2        predicates:        # 请求路径以 /demo-2 开头，才会匹配上该路由        - Path=/demo-2/**        filters:        # 该插件确保请求在转发至后端服务时，会移除掉 /demo-2 的前缀        - StripPrefix=1        # 后端为微服务时，uri应该以 lb:// 开头，并填写服务名        uri: lb://service-provider        # 可以为路由添加元数据，以在插件中使用        metadata:          ccc: ddd          eee: 10        order: 1000