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

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

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…