头图

长连接网关技术专题(五):喜马拉雅自研亿级API网关技术实践

JackJiang
English

本文由喜马拉雅技术团队原创分享,原题《喜马拉雅自研网关架构实践》,有改动。

1、引言

网关是一个比较成熟的产品,基本上各大互联网公司都会有网关这个中间件,来解决一些公有业务的上浮,而且能快速的更新迭代。如果没有网关,要更新一个公有特性,就要推动所有业务方都更新和发布,那是效率极低的事,有网关后,这一切都变得不是问题。

喜马拉雅也是一样,用户数增长达到 6 亿多的级别,Web 服务个数达到500+,目前我们网关日处理 200 亿+次调用,单机 QPS 高峰达到 4w+。

网关除了要实现最基本的功能反向代理外,还有公有特性,比如黑白名单,流控,鉴权,熔断,API 发布,监控和报警等。我们还根据业务方的需求实现了流量调度,流量 Copy,预发布,智能化升降级,流量预热等相关功能。

从技术上来说,喜马拉雅API网关的技术演进路线图大致如下:

本文将分享在喜马拉雅API网关在亿级流量前提下,进行的技术演进发展历程和实践经验总结。

学习交流:

  • 即时通讯/推送技术开发交流5群:215477170 [推荐]
  • 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》
  • 开源IM框架源码:https://github.com/JackJiang2...

(本文同步发布于:http://www.52im.net/thread-35...

2、专题目录

本文是系列文章的第5篇,总目录如下:

  • 《长连接网关技术专题(一):京东京麦的生产级TCP网关技术实践总结》
  • 《长连接网关技术专题(二):知乎千万级并发的高性能长连接网关技术实践》
  • 《长连接网关技术专题(三):手淘亿级移动端接入层网关的技术演进之路》
  • 《长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践》
  • 《长连接网关技术专题(五):喜马拉雅自研亿级API网关技术实践》(* 本文)

3、第1版:Tomcat NIO+Async Servlet

网关在架构设计时最为关键点,就是网关在接收到请求,调用后端服务时不能阻塞 Block,否则网关的吞吐量很难上去,因为最耗时的就是调用后端服务这个远程调用过程。

如果这里是阻塞的,Tomcat 的工作线程都 block 住了,在等待后端服务响应的过程中,不能去处理其他的请求,这个地方一定要异步。

架构图如下:

这版我们实现单独的 Push 层,作为网关收到响应后,响应客户端时,通过这层实现,和后端服务的通信是 HttpNioClient,对业务的支持黑白名单,流控,鉴权,API 发布等功能。

但是这版只是功能上达到网关的要求,处理能力很快就成了瓶颈,单机 QPS 到 5K 的时候,就会不停的 Full GC。

后面通过 Dump 线上的堆分析,发现全是 Tomcat 缓存了很多 HTTP 的请求,因为 Tomcat 默认会缓存 200 个 requestProcessor,每个 prcessor 都关联了一个 request。

还有就是 Servlet 3.0 Tomcat 的异步实现会出现内存泄漏,后面通过减少这个配置,效果明显。

但性能肯定就下降了,总结了下,基于 Tomcat 做为接入端,有如下几个问题。

Tomcat 自身的问题:

  • 1)缓存太多,Tomcat 用了很多对象池技术,内存有限的情况下,流量一高很容易触发 GC;
  • 2)内存 Copy,Tomcat 的默认是用堆内存,所以数据需要读到堆内,而我们后端服务是 Netty,有堆外内存,需要通过数次 Copy;
  • 3)Tomcat 还有个问题是读 body 是阻塞的, Tomcat 的 NIO 模型和 reactor 模型不一样,读 body 是 block 的。

这里再分享一张 Tomcat buffer 的关系图:

通过上面的图,我们可以看出,Tomcat 对外封装的很好,内部默认的情况下会有三次 copy。

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

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

4、第2版:Netty+全异步

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

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

PS:如果你对Netty和Java NIO了解太少,下面几篇资料请务必阅读:

  1. 《少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别》
  2. 《Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!》
  3. 《史上最强Java NIO入门:担心从入门到放弃的,请读这篇!》
  4. 《写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略》
  5. 《新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析》
  6. 《史上最通俗Netty框架入门长文:基本介绍、环境搭建、动手实战》

4.1 接入层
Netty 的 IO 线程,负责 HTTP 协议的编解码工作,同时对协议层面的异常做监控报警。

对 HTTP 协议的编解码做了优化,对异常,攻击性请求监控可视化。比如我们对 HTTP 的请求行和请求头大小是有限制的,Tomcat 是请求行和请求加在一起,不超过 8K,Netty 是分别有大小限制。

假如客户端发送了超过阀值的请求,带 cookie 的请求很容易超过,正常情况下,Netty 就直接响应 400 给客户端。

经过改造后,我们只取正常大小的部分,同时标记协议解析失败,到业务层后,就可以判断出是那个服务出现这类问题,其他的一些攻击性的请求,比如只发请求头,不发 body 或者发部分这些都需要监控和报警。

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

在业界和一些大厂的网关设计中,业务逻辑层基本都是设计成责任链模式,公有的业务逻辑也在这层实现。

我们在这层也是相同的套路,支持了:

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

在执行的过程中,不会有 IO 操作,目前有些设计会对多个 filter 做并发执行,由于我们的都是内存操作,开销并不大,所以我们目前并没有支持并发执行。

还有个就是规则会修改,我们修改规则时,会通知网关服务,做实时刷新,我们对内部自己的这种元数据更新的请求,通过独立的线程处理,防止 IO 在操作时影响业务线程。

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

4.3.1)异步 Push:

网关在发起服务调用后,让工作线程继续处理其他的请求,而不需要等待服务端返回。

这里的设计是我们为每个请求都会创建一个上下文,我们在发完请求后,把该请求的 context 绑定到对应的连接上,等 Netty 收到服务端响应时,就会在给连接上执行 read 操作。

解码完后,再从给连接上获取对应的 context,通过 context 可以获取到接入端的 session。

这样 push 就通过 session 把响应写回客户端了,这样设计也是基于 HTTP 的连接是独占的,即连接和请求上下文绑定。

4.3.2)连接池:

连接池的原理如下图:

服务调用层除了异步发起远程调用外,还需要对后端服务的连接进行管理。

HTTP 不同于 RPC,HTTP 的连接是独占的,所以在释放的时候要特别小心,一定要等服务端响应完了才能释放,还有就是连接关闭的处理也要小心。

总结如下几点:

  • 1)Connection:close;
  • 2)空闲超时,关闭连接;
  • 3)读超时关闭连接;
  • 4)写超时,关闭连接;
  • 5)Fin、Reset。
    上面几种需要关闭连接的场景,下面主要说下 Connection:close 和空闲写超时两种,其他的应该是比较常见的比如读超时,连接空闲超时,收到 fin,reset 码这几个。

4.3.3)Connection:close:

后端服务是 Tomcat,Tomcat 对连接重用的次数是有限制的,默认是 100 次。

当达到 100 次后,Tomcat 会通过在响应头里添加 Connection:close,让客户端关闭该连接,否则如果再用该连接发送的话,会出现 400。

还有就是如果端上的请求带了 connection:close,那 Tomcat 就不等这个连接重用到 100 次,即一次就关闭。

通过在响应头里添加 Connection:close,即成了短连接,这个在和 Tomcat 保持长连接时,需要注意的,如果要利用,就要主动 remove 掉这个 close 头。

4.3.4)写超时:

首先网关什么时候开始计算服务的超时时间,如果从调用 writeAndFlush 开始就计算,这其实是包含了 Netty 对 HTTP 的 encode 时间和从队列里把请求发出去即 flush 的时间,这样是对后端服务不公平的。

所以需要在真正 flush 成功后开始计时,这样是和服务端最接近的,当然还包含了网络往返时间和内核协议栈处理的时间,这个不可避免,但基本不变。

所以我们是 flush 成功回调后开始启动超时任务。

这里就有个注意的地方:如果 flush 不能快速回调,比如来了一个大的 post 请求,body 部分比较大,而 Netty 发送的时候第一次默认是发 1k 的大小。

如果还没有发完,则增大发送的大小继续发,如果在 Netty 在 16 次后还没有发送完成,则不会再继续发送,而是提交一个 flushTask 到任务队列,待下次执行到后再发送。

这时 flush 回调的时间就比较大,导致这样的请求不能及时关闭,而且后端服务 Tomcat 会一直阻塞在读 body 的地方,基于上面的分析,所以我们需要一个写超时,对大的 body 请求,通过写超时来及时关闭。

5、全链路超时机制

上图是我们在整个链路超时处理的机制:

  • 1)协议解析超时;
  • 2)等待队列超时;
  • 3)建连超时;
  • 4)等待连接超时;
  • 5)写前检查是否超时;
  • 6)写超时;
  • 7)响应超时。
  • 6、监控报警
    网关业务方能看到的是监控和报警,我们是实现秒级别报警和秒级别的监控,监控数据定时上报给我们的管理系统,由管理系统负责聚合统计,落盘到 influxdb。

我们对 HTTP 协议做了全面的监控和报警,无论是协议层的还是服务层的。

协议层:

  • 1)攻击性请求,只发头,不发/发部分 body,采样落盘,还原现场,并报警;
  • 2)Line or Head or Body 过大的请求,采样落盘,还原现场,并报警。

应用层:

  • 1)耗时监控:有慢请求,超时请求,以及 tp99,tp999 等;
  • 2)OPS 监控和报警;
  • 3)带宽监控和报警:支持对请求和响应的行,头,body 单独监控;
  • 4)响应码监控:特别是 400,和 404;
  • 5)连接监控:我们对接入端的连接,以及和后端服务的连接,后端服务连接上待发送字节大小也都做了监控;
  • 6)失败请求监控;
  • 7)流量抖动报警:这是非常有必要的,流量抖动要么是出了问题,要么就是出问题的前兆。

总体架构:

7、性能优化实践
7.1 对象池技术
对于高并发系统,频繁的创建对象不仅有分配内存的开销外,还有对gc会造成压力,我们在实现时会对频繁使用的比如线程池的任务task,StringBuffer等会做写重用,减少频繁的申请内存的开销。

7.2 上下文切换
高并发系统,通常都采用异步设计,异步化后,不得不考虑线程上下文切换的问题。

我们的线程模型如下:

我们整个网关没有涉及到io操作,但我们在业务逻辑这块还是和netty的io编解码线程异步。

是有两个原因:

  • 1)是防止开发写的代码有阻塞;
  • 2)是业务逻辑打日志可能会比较多,在突发的情况下,但是我们在push线程时,支持用netty的io线程替代,这里做的工作比较少,这里有异步修改为同步后(通过修改配置调整),cpu的上下文切换减少20%,进而提高了整体的吞吐量,就是不能为了异步而异步,zull2的设计和我们的类似。

7.3 GC优化
在高并发系统,gc的优化不可避免,我们在用了对象池技术和堆外内存时,对象很少进入老年代,另外我们年轻代会设置的比较大,而且SurvivorRatio=2,晋升年龄设置最大15,尽量对象在年轻代就回收掉, 但监控发现老年代的内存还是会缓慢增长,通过dump分析,我们每个后端服务创建一个链接,都时有一个socket,socket的AbstractPlainSocketImpl,而AbstractPlainSocketImpl就重写了Object类的finalize方法。

实现如下:

/**
 * Cleans up if the user forgets to close it.
 */
protected void finalize() throws IOException {
    close();
}

是为了我们没有主动关闭链接,做的一个兜底,在gc回收的时候,先把对应的链接资源给释放了。

由于finalize的机制是通过jvm的Finalizer线程来处理的,而且Finalizer线程的优先级不高,默认是8,需要等到Finalizer线程把ReferenceQueue的对象对于的finalize方法执行完,还要等到下次gc时,才能把该对象回收,导致创建链接的这些对象在年轻代不能立即回收,从而进入了老年代,这也是为啥老年代会一直缓慢增长的问题。

7.4 日志
高并发下,特别是 Netty 的 IO 线程除了要执行该线程上的 IO 读写操作,还有执行异步任务和定时任务,如果 IO 线程处理不过来队列里的任务,很有可能导致新进来异步任务出现被拒绝的情况。

那什么情况下可能呢?IO 是异步读写的问题不大,就是多耗点 CPU,最有可能 block 住 IO 线程的是我们打的日志。

目前 Log4j 的 ConsoleAppender 日志 immediateFlush 属性默认为 true,即每次打 log 都是同步写 flush 到磁盘的,这个对于内存操作来说,慢了很多。

同时 AsyncAppender 的日志队列满了也会 block 住线程,log4j 默认的 buffer 大小是 128,而且是 block 的。

即如果 buffer 的大小达到 128,就阻塞了写日志的线程,在并发写日志量大的的情况下,特别是堆栈很多时,log4j 的 Dispatcher 线程会出现变慢要刷盘。

这样 buffer 就不能快速消费,很容易写满日志事件,导致 Netty IO 线程 block 住,所以我们在打日志时,也要注意精简。

8、未来规划

现在我们都是基于 HTTP/1,现在 HTTP/2 相对于 HTTP/1 关键实现了在连接层面的服务,即一个连接上可以发送多个 HTTP 请求。

即 HTTP 连接也能和 RPC 连接一样,建几个连接就可以了,彻底解决了 HTTP/1 连接不能复用导致每次都建连和慢启动的开销。

我们也在基于 Netty 升级到 HTTP/2,除了技术升级外,我们对监控报警也一直在持续优化,怎么提供给业务方准确无误的报警,也是一直在努力。

还有一个就是降级,作为统一接入网关,和业务方做好全方位的降级措施,也是一直在完善的点,保证全站任何故障都能通过网关第一时间降级,也是我们的重点。

9、写在最后

网关已经是一个互联网公司的标配,这里总结实践过程中的一些心得和体会,希望给大家一些参考以及一些问题的解决思路,我们也还在不断完善中,同时我们也在做多活的项目,欢迎交流。

附录:更多相关资料

[1] NIO异步网络编程资料:

《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《有关“为何选择Netty”的11个疑问及解答》
《MINA、Netty的源代码(在线阅读版)已整理发布》
《详解Netty的安全性:原理介绍、代码演示(上篇)》
《详解Netty的安全性:原理介绍、代码演示(下篇)》
《详解Netty的优雅退出机制和原理》
《NIO框架详解:Netty的高性能之道》
《Twitter:如何使用Netty 4来减少JVM的GC开销(译文)》
《绝对干货:基于Netty实现海量接入的推送服务技术要点》
《新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析》
《写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略》
《少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别》
《史上最强Java NIO入门:担心从入门到放弃的,请读这篇!》
《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》
《Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!》
《史上最通俗Netty框架入门长文:基本介绍、环境搭建、动手实战》
《长连接网关技术专题(一):京东京麦的生产级TCP网关技术实践总结》
《长连接网关技术专题(五):喜马拉雅自研亿级API网关技术实践》

更多同类文章 ……

[2] 有关IM架构设计的文章:
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑:架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越:京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《如何解读《微信技术总监谈架构:微信之道——大道至简》》
《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》
《移动端IM中大规模群消息的推送如何保证效率、实时性?》
《现代IM系统中聊天消息的同步和存储方案探讨》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例,总结海量社交系统的架构设计步骤》
《子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等》
《即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?》
《从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践》
《瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)》
《阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!》
《阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践》
《一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等》
《一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等》
《从新手到专家:如何设计一套亿级消息量的分布式IM系统》

更多同类文章 ……

[3] 更多其它架构设计相关文章:
《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践:从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识:史上最全MySQL大表优化方案总结》
《小米技术分享:解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等》
《通俗易懂:如何设计能支撑百万并发的数据库架构?》
《多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了》
《从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路》
《美团技术分享:深度解密美团的分布式ID生成算法》
《12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)》

更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是:点此进入。同步发布链接是:http://www.52im.net/thread-35...

阅读 1.1k

即时通讯开发
实时推送、IM等即时通讯相关技术的研究、分享的专栏。让即时通讯技术能更好地学习、交流与传播,不再零...

专注即时通讯(IM/推送)技术学习和研究。

1.2k 声望
242 粉丝
0 条评论

专注即时通讯(IM/推送)技术学习和研究。

1.2k 声望
242 粉丝
文章目录
宣传栏