前言
架构1.0版本上线后，用户量及访问量都是呈现爆发式增长。尤其在每周五推文之后，都会出现一波用户访问高峰。用户访问量的瞬间暴增，对我们的网关组件的挑战也是最大的。
网关故障
概述
18年11月2号和11月9号这两天，都出现用户访问量突然暴增的情况，在这种情况下，我们的网关组件都出现的故障。导致部分用户无法访问我们的接口服务。
现象及原因分析
当gateway不可用时，会打印大量如下的日志信息⬇️⬇️⬇️
2018-11-09 18:27:09 [reactor-http-nio-1] ERROR org.springframework.boot.autoconfigure.web.reactive.error.DefaultErrorWebExceptionHandler- Failed to handle request [POST http://api.
com/account/login]
io.netty.handler.codec.EncoderException: java.lang.IllegalStateException: unexpected message type: DefaultHttpRequest
at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:106) ~[netty-codec-4.1.23.Final.jar!/:4.1.23.Final]
at io.netty.channel.CombinedChannelDuplexHandler.write(CombinedChannelDuplexHandler.java:348) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:738) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:730) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:816) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final]
网上的解释
According to our tests the highest probability when onCompete() for client requests is not called happens in the following conditions:
1.HttpClient receives HTTP error response, 404 in our case. Most likely the error code value might be any. However, with 200 code everything seem to work fine.
2.HttpClient uses HTTPS to connect a server. With HTTP it seems to work well, or at least the probability to fail is much lower. The only explanation coming to our minds is that HTTPS uses chuncked encoding, while HTTP sets content length and thus someone tracking end of package upload operation properly calls onComplete.
3.One more thing, the uploaded content in HTTP request should be greater than some value. E.g. uploading 200 bytes file works fine, while 2MBs file reproduces the case almost immediately.
https://github.com/reactor/reactor-netty/issues/177
https://github.com/spring-cloud/spring-cloud-gateway/issues/228
我们发现这个问题是SpringCloud Gateway的bug造成的,大致的原因应该是在一些异常场景下，connection已经broken了，但是没有立即回收掉，导致broken的connectioin还被继续使用。
我们当前使用的Springboot版本是2.0.1.RELEASE。经过在测试环境反复的压测后，我们将版本升级到2.0.4.RELEASE，这个问题暂时得到的解决。
思考
前期的架构选型中，对组件的稳定性考虑不够。SpringCloud Gateway作为一个全新的组件出来，在还没有经过大量实践的考验下，直接使用，其实风险是很大的。我们要承担新组件内部版本快速升级过程中，和其他组件的版本兼容性问题，还有就是新版本会不会引发新的bug的问题呢？基于对SpringCloud Gateway版本稳定性的担忧，我们决定将网关组件进行重新的选型和改造。
网关功能介绍
在介绍网关改造方案之前，先大概说明一下现有网关都包含了哪些功能。这个可以帮忙我们在后续网关选型上提供一些参考的方向。
网关功能组成
- JWT 校验
- 访问权限控制
- 请求动态路由转发
JWT 简介
JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。
JWT 适用场景
- 身份认证
当用户成功登录后，后端会颁发一个JWT，在接下来的每个请求中包含JWT，网关就可以根据请求中JWT来判断用户的合法性。由于它的开销非常小，可以轻松的在不同域名的系统中传递。
JWT 组成
image.png
由上图可以看到，JWT由三个部分组成
- header(头部信息)
头部信息中包含了token的类型和所使用到加密算法。经过base64编码后，作为JWT的一部分。 - payload(内容信息)
这里包含了实际需要使用的用户信息。 一般包括用户名、用户id、过期时间等信息。 - signature(签名信息)
signature=header(base64) + payload(base64) + secret
JWT 使用技巧
JWT生成策略
-
方案一：Token过期后，再重新触发登录逻辑，登录成功重新颁发新的Token给前端。
这种方案每次token都需要让用户重新走一次登录流程，安全性有保证。但是频繁的用户重登录会降低用户的体验，所以token的过期时间不能设置太短。一般建议设置3～7天比较合适。 -
方案二：Token过期后，重新生成新的Token并直接颁发给前端。
这种方案对用户来说完全是无感的，token可以设置成5分钟就失效。失效后，等待下一次访问了又在重新颁发一个token。这种方案的有点就是用户体验更好，但是无法确定用户的合法性，当非法用户拿到token后，可以随意使用，而不需要在进行任何登录判断。
访问控制
在网关层面针对API设置了不同的访问权限控制
动态路由转发
网关路由请求简图.png
网关改造
选型考虑
网关作为所有流量的入口，要求必须是高并发的、稳定的、并且是经过大量验证的。经过住性能和稳定性考验的，首选肯定就是nginx，或者是基于nginx搭建的产品。
nginx
nginx基于C语言实现，采用的非阻塞模型能轻松支持大量并发连接数。但作为网关来使用，除了性能高，同时还需要具备良好的可扩展性，包括上文提到的限流、鉴权、监控、路由等等。
Openresty
基于nginx+lua实现的高性能web平台。其内部集成了大量优秀的lua库，开发者也可以基于自身的需求来实现自己的lua脚本，非常适合用来做一些高性能的web应用、网关。
最终选择了Openresty，这个主要还是根据我们目前的业务量和开发成本综合考虑的结果。其实，业界还有像Kong、Orange这些基于Openresty搭建的网关产品，他们提供的组件更加丰富，能力更强大。 但最终我们没选择，其实也没什么原因，就是觉得Openresty已经足够能满足我们，所以就选择了Openresty。
解决方案
- JWT 校验 —> 集成jwt nginx模块
- 访问权限控制 —> 自编lua脚本
- 路由转发 —> consul-template
简单说明
Openresty提供了jwt的模块，我们只需要基于jwt来简单实现我们对token合法性校验和异常处理逻辑即可；路由转发Nginx提供了upstream的模块来实现，但是我们需要基于consul来实现一套动态生成upstream的机制，这里我们选择了Consul-template.
Consul-template
是Consul官网提供的模块，可以基于Consul实现自动替换配置文件的应用。
处理流程
Consul-Template流程
完整教程入口：https://www.jianshu.com/p/6534ac03ab28
结束语
网关改造耗时1个月时间完成。部署上线后到现在已经快1年了，再没出现过因为网关故障而导致服务不可用的情况了。
参考资料
openresty：http://openresty.org/cn/
jwt：https://www.jianshu.com/p/576dbf44b2ae
consul-template：https://www.hi-linux.com/posts/36431.html
网友评论