2024年最全喜马拉雅自研网关架构演进过程,Java面试你必须要知道的那些知识

最后

给大家送一个小福利

附高清脑图,高清知识点讲解教程,以及一些面试真题及答案解析。送给需要的提升技术、准备面试跳槽、自身职业规划迷茫的朋友们。

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

架构图如下:

图片

这版我们实现单独的Push层,作为网关收到响应后,响应客户端时,通过这层实现,和后端服务的通信是HttpNioClient,对业务的支持黑白名单,流控,鉴权,API发布等功能,这版只是功能上达到网关的邀请,但是处理能力很快就成了瓶颈,单机QPS到5k的时候,就会不停的full gc,后面通过dump线上的堆分析,发现全是Tomcat缓存了很多http的请求,因为Tomcat默认会缓存200个RequestProcessor,每个prcessor都关联了一个request,还有就是Servlet 3.0 Tomcat的异步实现会出现内存泄漏,后面通过减少这个配置,效果明显。但性能肯定就下降了,总结了下,基于Tomcat做为接入端,有如下几个问题:

Tomcat自身的问题

缓存太多,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请求,通过写超时来及时关闭。

全链路超时机制

下面是我们在整个链路种一个超时处理的机制。

图片

  • 协议解析超时

  • 等待队列超时

  • 建链超时

  • 等待链接超时

  • 写前检查是否超时

  • 写超时

一线互联网大厂Java核心面试题库

image

正逢面试跳槽季,给大家整理了大厂问到的一些面试真题,由于文章长度限制,只给大家展示了部分题目,更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传,感兴趣的朋友可以看看支持一波!

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

Q、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传,感兴趣的朋友可以看看支持一波!

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值