背景

• 旧网关服务使用的是zuul网关，而spring cloud2.x之后已经放弃集成zuul网关了，而是不断完善spring cloud gateway。
• spring-cloud-starter-netflix-zuul集成的zuul是1.x版本的，而1.x版本的zuul网关底层是基于servlet实现的，是阻塞api。而spring cloud gateway2.x的底层使用的是netty，是异步非阻塞api。由于底层实现差异，性能表现上不言而喻，两者没有可比性。

重构过程遇到的几个问题处理

其实从zuul改为spring cloud gateway并不麻烦，很多spring cloud gateway的配置都默认的，不需要更改。相对麻烦的是以下几点。

1）路由配置问题

已有的路由配置已经有五六十个，如果手动修改几乎是不太可能的。一来容易出错，二来重复工作量太大，所以针对这个问题写了一个zuul网关配置转spring cloud gateway配置的程序来转换，从而解决了配置问题。

2）zuul自定义过滤器问题

zuul网关有一些自定义的过滤器，这些只能一个个用spring cloud gateway的filter依次重写一遍，没有其他更好的办法。还好自定义的不多，就几个。

3）跨域问题

由于之前zuul网关并没有支持跨域，而重构之后希望把跨域的支持上移到网关，但是很多旧服务本来就有支持跨域的配置。导致响应的跨域头出现了两个，在某些浏览器就不支持了。
而我们刚切换spring cloud gateway的时候，网关还很不完善，很多bug，官网也没有这方面的配置说明，都是通过定义全局过滤器的方式支持跨域，并且专门定义一个过滤器处理响应头跨域重复问题。
但是后来spring cloud gateway网关2.2.x发布之后，通过查看官网，和亲自验证，已经可以完全通过配置处理跨域和跨域重复问题，具体参考我的另一篇博文。SpringCloudGateway多钟方式跨域配置

4）其他不可预知的问题

我们其中一个网关使用了basic auth验证，当直接使用Spring Cloud Security的basic auth验证响应会慢100毫秒，这是因为spring cloud gateway对这块的集成不完造成的，具体参考另一篇博文 SpringCloudGateway使用SecurityBasicAuth验证响应慢的问题

关于线上切换

我们线上切换之前，在测试环境先运行了一段时间，尽可能把一些未知的问题在测试环境暴露出来，避免造成一些低级线上故障。
另外，我们线上切换分了以下几步进行：

• 先全新部署，当新应用部署，然后线上先验证关键接口，确保正常。
• 然后等到深夜，再切换网关。由于我们使用的k8s，线上我们直接把k8s的service和ingress直接换成旧的，把旧的直接下掉即可。如果是其他nginx之类的，则更加简单，直接修改nginx配置reload一下即可。