最后
给大家送一个小福利
附高清脑图,高清知识点讲解教程,以及一些面试真题及答案解析。送给需要的提升技术、准备面试跳槽、自身职业规划迷茫的朋友们。
架构图如下:
这版我们实现单独的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核心面试题库
正逢面试跳槽季,给大家整理了大厂问到的一些面试真题,由于文章长度限制,只给大家展示了部分题目,更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传,感兴趣的朋友可以看看支持一波!
Q、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传,感兴趣的朋友可以看看支持一波!