喜马拉雅自研网关架构演进过程

最新推荐文章于 2024-10-12 10:41:56 发布

2401_84049061

最新推荐文章于 2024-10-12 10:41:56 发布

阅读量1k

点赞数 9

分类专栏：程序员文章标签：架构 safari 前端

本文链接：https://blog.csdn.net/2401_84049061/article/details/138000319

版权

程序员专栏收录该内容

433 篇文章 1 订阅

订阅专栏

缓存太多，Tomcat用了很多对象池技术，内存有限的情况下，流量一高很容易触发gc。

内存copy，Tomcat的默认是用堆内存，所以数据需要读到堆内，而我们后端服务是Netty，有堆外内存，需要通过数次copy。

Tomcat还有个问题是读body是阻塞的，Tomcat的NIO模型和Reactor模型不一样，读body是Block的。

HttpNioClient的问题

获取和释放链接都需要加锁，对应网关这样的代理服务场景，会频繁的建链和关闭链接，势必会影响性能。

基于Tomcat的存在的这些问题，我们后面对接入端做改造，用Netty做接入层和服务调用层，也就是我们的第二版，能彻底解决上面的问题，达到理想的性能。

第二版：Netty + 全异步

基于Netty的优势，我们实现了全异步、无锁、分层的架构。

先看下我们基于Netty做接入端的架构图：

接入层

Netty的io线程，负责http协议的编解码工作，同时对协议层面的异常做监控报警。

对http协议的编解码做了优化，对异常，攻击性请求监控可视化，比如我们对http的请求行和请求头大小是有限制的，Tomcat是请求行和请求加在一起，不超过8K，Netty是分别有大小限制，假如客户端发送了超过阀值的请求，带cookie的请求很容易超过，正常情况下，netty就直接响应400给客户端，经过改造后，我们只取正常大小的部分，同时标记协议解析失败，到业务层后，就可以判断出是那个服务出现这类问题，其他的一些攻击性的请求，比如只发请求头，不发body/或者发部分这些都需要监控和报警。

业务逻辑层

负责对API路由，流量调度等一序列的支持业务的公有逻辑，都在这层实现，采样责任链模式，这层不会有io操作。

在业界和一些大厂的网关设计中，业务逻辑层基本都是设计成责任链模式，公有的业务逻辑也在这层实现，我们在这层也是相同的套路，支持了：

用户鉴权和登陆校验，支持接口级别配置
黑白明单，分全局和应用，以及IP维度，参数级别
流量控制，支持自动和手动，自动是对超大流量自动拦截，通过令牌桶算法实现
智能熔断，在histrix的基础上做了改进，支持自动升降级，我们是全部自动的，也支持手动配置立即熔断，就是发现服务异常比例达到阀值，就自动触发熔断
灰度发布，我对新启动的机器的流量支持类似tcp的慢启动机制，给机器一个预热的时间窗口
统一降级，我们对所有转发失败的请求都会找统一降级的逻辑，只要业务方配了降级规则，都会降级，我们对降级规则是支持到参数级别的，包含请求头里的值，是非常细粒度的，另外我们还会和varnish打通，支持varish的优雅降级
流量调度，支持业务根据筛选规则，对流量筛选到对应的机器，也支持只让筛选的流量访问这台机器，这在查问题/新功能发布验证时非常用，可以先通过小部分流量验证再大面积发布上线
流量copy，我们支持对线上的原始请求根据规则copy一份，写入到mq或者其他的upstream，来做线上跨机房验证和压力测试
请求日志采样，我们对所有的失败的请求都会采样落盘，提供业务方排查问题支持，也支持业务方根据规则进行个性化采样，我们采样了整个生命周期的数据，包含请求和响应相关的所有数据

上面提到的这么多都是对流量的治理，我们每个功能都是一个filter，处理失败都不影响转发流程，而且所有的这些规则的元数据在网关启动时就会全部初始化好，在执行的过程中，不会有IO操作，目前有些设计会对多个filter做并发执行，由于我们的都是内存操作，开销并不大，所以我们目前并没有支持并发执行，还有个就是规则会修改，我们修改规则时，会通知网关服务，做实时刷新，我们对内部自己的这种元数据更新的请求，通过独立的线程处理，防止IO在操作时影响业务线程。

服务调用层

服务调用对于代理网关服务是关键的地方，一定需要异步，我们通过Netty实现，同时也很好的利用了Netty提供的链接池，做到了获取和释放都是无锁操作。

异步Push

网关在发起服务调用后，让工作线程继续处理其他的请求，而不需要等待服务端返回，这里的设计是我们为每个请求都会创建一个上下文，我们在发完请求后，把该请求的context绑定到对应的链接上，等Netty收到服务端响应时，就会在给链接上执行read操作，解码完后，再从给链接上获取对应的context，通过context可以获取到接入端的session，这样push就通过session把响应写回客户端了，这样设计也是基于http的链接是独占的，即链接可以和请求上下文绑定。

链接池

链接池的原理如下图：

服务调用层除了异步发起远程调用外，还需要对后端服务的链接进行管理，http不同于RPC，http的链接是独占的，所以在释放的时候要特别小心，一定要等服务端响应完了才能释放，还有就是链接关闭的处理也要小心，总结如下几点：

Connection:close
空闲超时，关闭链接
读超时关闭链接
写超时，关闭链接
Fin，Reset

上面几种需要关闭链接的场景，下面主要说下Connection:close和空闲写超时两种，其他的应该是比较常见的比如读超时，链接空闲超时，收到fin，reset码这几个。

Connection:close

后端服务是Tomcat，Tomcat对链接重用的次数是有限制的，默认是100次，当达到100次后，Tomcat会通过在响应头里添加Connection:close，让客户端关闭该链接，否则如果再用该链接发送的话，会出现400。

还有就是如果端上的请求带了connection:close，那Tomcat就不等这个链接重用到100次，即一次就关闭，通过在响应头里添加Connection:close，即成了短链接，这个在和Tomcat保持长链接时，需要注意的，如果要利用，就要主动remove掉这个close头。

写超时

首先网关什么时候开始计算服务的超时时间，如果从调用writeAndFlush开始就计算，这其实是包含了Netty对http的encode时间和从队列里把请求发出去即flush的时间，这样是对后端服务不公平的，所以需要在真正flush成功后开始计时，这样是和服务端最接近的，当然还包含了网络往返时间和内核协议栈处理的时间，这个不可避免，但基本不变。

所以我们是flush成功回调后开始启动超时任务，这里就有个注意的地方，如果flush不能快速回调，比如来了一个大的post请求，body部分比较大，而netty发送的时候第一次默认是发1k的大小，如果还没有发完，则增大发送的大小继续发，如果在Netty在16次后还没有发送完成，则不会再继续发送，而是提交一个flushTask到任务队列，待下次执行到后再发送，这时flush回调的时间就比较大，导致这样的请求不能及时关闭，而且后端服务Tomcat会一直阻塞在读body的地方，基于上面的分析，所以我们需要一个写超时，对大的body请求，通过写超时来及时关闭。