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。

前言

本文整理自云原生技术实践营广州站 Meetup 的分享，其中的经验来自于我们团队开发的阿里云 CSB 2.0 这款产品，这是一款基于开源 SpringCloud Gateway 为 code base 开发的产品，在完全兼容开源用法的前提下，做了非常多企业级的改造，涉及功能特性、稳定性、安全、性能等方面。

为什么需要微服务网关

从功能角度来看，微服务网关通常用来统一提供认证授权、限流、熔断、协议转换等功能。

从使用场景上来看

• 南北向流量，需要流量网关和微服务网关配合使用，主要是为了区分外部流量和微服务流量，将内部的微服务能力，以统一的 HTTP 接入点对外提供服务
• 东西向流量，在一些业务量比较大的系统中，可能会按照业务域隔离出一系列的微服务，在同一业务域内的微服务通信走的是服务发现机制，而跨业务域访问，则建议借助于微服务网关。

Spring Cloud 终于改了

最近 Spring Cloud 把版本号从 A 到 Z 的伦敦地铁站，改成用日期命名了。

• https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released

也就是从 Greenwich.SR6, Hoxton.SR9 这样的风格改成了 2020.0.0 的形式。广大人民终于不用为 Spring Cloud 的版本号烦恼了。

Spring Cloud 推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。

以日期为版本号，即所谓的 Calendar Versioning，可以参考这个网站：

• https://calver.org/overview_zhcn.html

在服务比较少的年代，一个系统的接口响应缓慢通常能够迅速被发现，但如今的微服务模块，大多具有规模大，依赖关系复杂等特性，错综复杂的网状结构使得我们不容易定位到某一个执行缓慢的接口。分布式的服务跟踪组件就是为了解决这一个问题。其次，它解决了另一个难题，在没有它之前，我们客户会一直询问：你们的系统有监控吗？你们的系统有监控吗？你们的系统有监控吗？现在，谢天谢地，他们终于不问了。是有点玩笑的成分，但可以肯定的一点是，实现全链路监控是保证系统健壮性的关键因子。

介绍 Spring Cloud Sleuth 和 Zipkin 的文章在网上其实并不少，所以我打算就我目前的系统来探讨一下，如何实现链路监控。全链路监控这个词意味着只要是不同系统模块之间的调用都应当被监控，这就包括了如下几种常用的交互方式：

1 Http 协议，如 RestTemplate，Feign，Okhttp3，HttpClient…

2 Rpc 远程调用，如 Motan，Dubbo，GRPC…

最近项目中大量使用了 Spring Cloud Feign 来对接 http 接口，踩了不少坑，也产生了一些对 RESTFUL 接口设计的想法，特此一篇记录下。

[TOC]

SpringMVC 的请求参数绑定机制

了解 Feign 历史的朋友会知道，Feign 本身是 Netflix 的产品，Spring Cloud Feign 是在原生 Feign 的基础上进行了封装，引入了大量的 SpringMVC 注解支持，这一方面使得其更容易被广大的 Spring 使用者开箱即用，但也产生了不小的混淆作用。所以在使用 Spring Cloud Feign 之前，笔者先介绍一下 SpringMVC 的一个入参机制。预设一个 RestController，在本地的 8080 端口启动一个应用，用于接收 http 请求。

Spring Cloud Feign

Spring Cloud Feign 是一套基于 Netflix Feign 实现的声明式服务调用客户端。它使得编写 Web 服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对 Web 服务接口的绑定。它具备可插拔的注解支持，包括 Feign 注解、JAX-RS 注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign 还扩展了对 Spring MVC 注解的支持，同时还整合了 Ribbon 和 Eureka 来提供均衡负载的 HTTP 客户端实现。

分布式应用早在十几年前就开始出现，各自的应用运行在各自的 tomcat，jboss 一类的容器中，他们之间的相互调用变成了一种远程调用，而实现远程调用的方式很多。按照协议划分，可以有 RPC，Webservice，http。不同的框架也对他们有了各自的实现，如 dubbo(x)，motan 就都是 RPC 框架，本文所要讲解的 Feign 便可以理解为一种 http 框架，用于分布式服务之间通过 Http 进行接口交互。说他是框架，有点过了，可以理解为一个 http 工具，只不过在 spring cloud 全家桶的体系中，它比 httpclient，okhttp，retrofit 这些 http 工具都要强大的多。

入门

先用一个简单的例子，看看如何在项目中使用 Feign。示例项目使用 maven 多 module 构建，采用 springcloud 的 Dalston.SR1 版本