日200亿次调用，喜马拉雅网关的架构设计

我就是我 2024-03-08 08:04 155阅读 0赞

### 说在前面 ###

在40岁老架构师 尼恩的**读者社区**(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。

最近，尼恩指导一个小伙伴简历，写了一个《**API网关项目**》，此项目帮这个小伙拿到 **字节/阿里/微博/汽车之家** 面邀， 所以说，这是一个牛逼的项目。

为了帮助大家拿到更多面试机会，拿到更多大厂offer，

尼恩决定：9月份給大家出一章视频介绍这个项目的架构和实操，《33章: 10Wqps 高并发 Netty网关架构与实操》，预计月底发布。然后，提供一对一的简历指导，这里简历金光闪闪、脱胎换骨。

《33章: 10Wqps 高并发 Netty网关架构与实操》 海报如下：

![bab3c6c08da54f04841cf437267d2717.png][]

配合《33章: 10Wqps 高并发 Netty网关架构与实操》， 尼恩会梳理几个工业级、生产级**网关案例**，作为架构素材、设计的素材。

前面梳理了

*  《[日流量200亿，携程网关的架构设计][200]》
 *  《[千万级连接，知乎如何架构长连接网关？][Link 1]》

这里又是一个漂亮的生产级案例：《**喜马拉雅自研亿级API网关技术实践**》，又一个非常 牛逼的工业级、生产级**网关案例**。

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

#### 文章目录 ####

*   *  说在前面
     *  喜马拉雅自研亿级API网关技术实践
     *  1、第1版：Tomcat NIO+Async Servlet
     *  2、第2版：Netty+全异步
     *   *  2.1 接入层
         *  2.2 业务逻辑层
         *  2.3 服务调用层
         *   *  2.3.1 异步 Push
             *  2.3.2 连接池
             *  2.3.3 Connection:close
             *  2.3.4 写超时
     *  3、全链路超时机制
     *  4、监控报警
     *  5、性能优化实践
     *   *  5.1 对象池技术
         *  5.2 上下文切换
         *  5.3 GC优化
         *  5.4 日志
     *  6、未来规划
     *  说在最后：有问题可以找老架构取经
     *  推荐阅读

### 喜马拉雅自研亿级API网关技术实践 ###

网关作为一种发展较为完善的产品，各大互联网公司普遍采用它作为中间件，以应对公共业务需求的不断浮现，并能迅速迭代更新。

如果没有网关，要更新一个公共特性，就得推动所有业务方都进行更新和发布，这无疑是效率极低的。然而，有了网关之后，这一切都不再是问题。

喜马拉雅也如此，用户数量已增长到 6 亿级别，Web 服务数量超过 500 个，目前我们的网关每天处理超过 200 亿次的调用，单机 QPS 峰值可达 4w+。

除了实现基本的反向代理功能，网关还具备许多公共特性，如黑白名单、流量控制、身份验证、熔断、API 发布、监控和报警等。根据业务方的需求，我们还实现了流量调度、流量复制、预发布、智能升级、流量预热等相关功能。

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

![ea396bb349e8456eaf62821b9df0ad79.png][]

> **注意：请点击图像以查看清晰的视图！**

本文将介绍在喜马拉雅 API 网关面临亿级流量的情况下，我们如何进行技术演进，以及我们的实践经验总结。

### 1、第1版：Tomcat NIO+Async Servlet ###

在架构设计中，网关的关键之处在于接收到请求并调用后端服务时，不能发生阻塞（Block），否则网关的处理能力将受到限制。

这是因为最耗时的操作就是远程调用后端服务这个过程。

如果此处发生阻塞，Tomcat 的工作线程会被全部 block 住了，等待后端服务响应的过程中无法处理其他请求，因此这里必须采用异步处理。

**架构图如下**：

![62dc8ccaf7154d9bbdbc6189730b3443.png][]

> **注意：请点击图像以查看清晰的视图！**

在这个版本中，我们实现了一个单独的 Push 层，用于在网关接收到响应后，响应客户端，并通过此层实现与后端服务的通信。

该层使用的是 HttpNioClient，支持业务功能包括黑白名单、流量控制、身份验证、API 发布等。

然而，这个版本仅在功能上满足了网关的要求，处理能力很快成为瓶颈。当单机 QPS 达到 5K 时，会频繁发生 Full GC。

通过分析线上堆，我们发现问题在于 Tomcat 缓存了大量 HTTP 请求。因为 Tomcat 默认会缓存 200 个 requestProcessor，每个处理器都关联一个 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 的关系图**：

![d2f7aea3a49447a5862fb017d9f7fe19.png][]

> **注意：请点击图像以查看清晰的视图！**

从上图中，我们能够明显观察到，Tomcat 的封装功能相当完善，但在内部默认设置下，会有三次 copy。

**HttpNioClient 的问题**：在获取和释放连接的过程中都需要进行加锁，针对类似网关这样的代理服务场景，会导致频繁地建立和关闭连接，这无疑会对性能产生负面影响。

鉴于 Tomcat 存在的这些难题，我们在后续对接入端进行了优化，采用 Netty 作为接入层和服务调用层，也就是我们的第二版，成功地解决了上述问题，实现了理想的性能。

### 2、第2版：Netty+全异步 ###

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

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

![67c782095fcf4d37b541a657746297a8.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 2.1 接入层 ####

Netty 的 IO 线程主要负责 HTTP 协议的编解码工作，同时也监控并报警协议层面的异常情况。

我们对 HTTP 协议的编解码进行了优化，并对异常和攻击性请求进行了监控和可视化处理。

例如，我们对 HTTP 请求行和请求头的大小都有限制，而 Tomcat 是将请求行和请求头一起计算，总大小不超过 8K，而 Netty 是分别对两者设置大小限制。

如果客户端发送的请求超过了设定的阀值，带有 cookie 的请求很容易超过这个限制，一般情况下，Netty 会直接响应 400 给客户端。

在优化后，我们只取正常大小的部分，并标记协议解析失败，这样在业务层就可以判断出是哪个服务出现了这类问题。

对于其他攻击性的请求，例如只发送请求头而不发送 body 或者只发送部分内容，都需要进行监控和报警。

#### 2.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 操作时影响业务线程。

#### 2.3 服务调用层 ####

服务调用对于代理网关服务非常关键，这个环节，性能必须很高：必须采用异步方式，

我们利用 Netty 实现了这一目标，同时也充分利用了 Netty 提供的连接池，实现了获取和释放的无锁操作。

##### 2.3.1 异步 Push #####

在发起服务调用后，网关允许工作线程继续处理其他请求，而无需等待服务端返回。

在这个设计中，我们为每个请求创建一个上下文，发送请求后，将该请求的 context 绑定到相应的连接上，当 Netty 收到服务端响应时，会在连接上执行 read 操作。

解码完成后，再从连接上获取相应的 context，通过 context 可以获取到接入端的 session。

这样，push 通过 session 将响应写回客户端，这个设计基于 HTTP 连接的独占性，即连接和请求上下文绑定。

##### 2.3.2 连接池 #####

**连接池的原理如下图**：

![a8dfa76f85e74e429e648607cca7daa7.png][]

> **注意：请点击图像以查看清晰的视图！**

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

HTTP 与 RPC 不同，HTTP 连接是独占的，所以在释放连接时需要特别小心，必须等待服务端响应完成后才能释放，此外，连接关闭的处理也需要谨慎。

**总结如下几点**：

*  1）Connection:close；
 *  2）空闲超时，关闭连接；
 *  3）读超时关闭连接；
 *  4）写超时，关闭连接；
 *  5）Fin、Reset。

上面几种需要关闭连接的场景，下面主要说下 *Connection:close* 和空闲写超时两种，其他情况如读超时、连接空闲超时、收到 fin、reset 码等都比较常见。

##### 2.3.3 Connection:close #####

后端服务采用的是 Tomcat，它对连接的重用次数有规定，默认为 100 次。

当达到 100 次限制时，Tomcat 会在响应头中添加 *Connection:close*，要求客户端关闭该连接，否则再次使用该连接发送请求会出现 400 错误。

还有就是如果前端的请求带了 *Connection:close*，那 Tomcat 就不会等待该连接重用满 100 次，即一次就关闭连接。

在响应头中添加 *Connection:close* 后，连接变为短连接。

在与 Tomcat 保持长连接时，需要注意这一点，如果要利用该连接，需要主动移除 close 头。

##### 2.3.4 写超时 #####

首先，网关在何时开始计算服务的超时时间？

如果从调用 writeAndFlush 开始计算，实际上包含了 Netty 对 HTTP 的编码时间和从队列中发送请求即 flush 的时间，这样对后端服务不公平。

因此，需要在真正 flush 成功后开始计时，这样最接近服务端，当然还包含了网络往返时间和内核协议栈处理时间，这是无法避免的，但基本稳定。

因此，我们在 flush 成功回调后启动超时任务。

**需要注意的是**：如果 flush 不能快速回调，例如遇到一个大的 POST 请求，body 部分较大，而 Netty 发送时默认第一次只发送 1k 大小。

如果尚未发送完毕，会增大发送大小继续发送，如果在 Netty 发送 16 次后仍未发送完成，将不再继续发送，而是提交一个 flushTask 到任务队列，待下次执行后再发送。

此时，flush 回调时间较长，导致此类请求无法及时关闭，后端服务 Tomcat 会一直阻塞在读取 body 部分，基于上述分析，我们需要设置写超时，对于大的 body 请求，通过写超时及时关闭连接。

### 3、全链路超时机制 ###

![b30f48a4efca44989fab0f11b8ce91df.png][]

> **注意：请点击图像以查看清晰的视图！**

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

*  1）协议解析超时；
 *  2）等待队列超时；
 *  3）建连超时；
 *  4）等待连接超时；
 *  5）写前检查是否超时；
 *  6）写超时；
 *  7）响应超时。

### 4、监控报警 ###

对于网关的业务方来说，他们能看到的是监控和警报功能，我们能够实现秒级的报警和监控，将监控数据定时上传到我们的管理系统，由管理系统负责汇总统计并存储到 InfluxDB 中。

我们对 HTTP 协议进行了全面的监控和警报，涵盖了协议层和服务层的问题。

**协议层**：

*  1）针对攻击性请求，只发送头部，不发送或只发送部分 body，我们会进行采样并记录，还原现场，并触发警报；
 *  2）对于 Line 或 Head 或 Body 过大的请求，我们会进行采样记录，还原现场，并及时发出警报。

**应用层**：

*  1）**监控耗时**：包括慢请求，超时请求，以及 tp99，tp999 等；
 *  2）**监控 OPS**：并及时发出警报；
 *  3）**带宽监控和报警**：支持对请求和响应的行，头，body 单独监控；
 *  4）**响应码监控**：特别是 400，和 404；
 *  5）**连接监控**：我们对接入端的连接，以及与后端服务的连接，以及后端服务连接上待发送字节大小都进行了监控；
 *  6）**失败请求监控**；
 *  7）**流量抖动报警**：这是非常必要的，流量抖动可能是出现问题，或者是问题即将出现的预兆。

**总体架构**：

![0389c48cc90d4e748b86d3dedb63f06b.png][]

> **注意：请点击图像以查看清晰的视图！**

### 5、性能优化实践 ###

#### 5.1 对象池技术 ####

针对高并发系统，不断地创建对象不仅会占用内存资源，还会对垃圾回收过程产生压力。

为了解决这个问题，我们在实现过程中会对诸如线程池的任务、StringBuffer 等频繁使用的对象进行重用，从而降低内存分配的开销。

#### 5.2 上下文切换 ####

在高并发系统中，通常会采用异步设计。异步化后，线程上下文切换的问题必须得到关注。

**我们的线程模型如下**：

![66124a20217146aa8871e624fb4e6a4f.png][]

> **注意：请点击图像以查看清晰的视图！**

我们的网关没有涉及 I/O 操作，但在业务逻辑处理方面仍然采用了 Netty 的 I/O 编解码线程异步方式。

**这主要有两个原因**：

*  1）防止开发人员编写的代码出现阻塞现象；
 *  2）在突发情况下，业务逻辑可能会产生大量的日志记录，我们允许在推送线程时使用 Netty 的 I/O 线程作为替代。这种做法可以减少 CPU 上下文切换的次数，从而提高整体吞吐量。我们不能仅仅为了异步而异步，Zuul2 的设计理念与我们的做法相似。

#### 5.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 线程处理的，其优先级不高，默认为 8。它需要等待 Finalizer 线程把 ReferenceQueue 的对象对应的 finalize 方法执行完，并等到下次垃圾回收时，才能回收该对象。这导致创建链接的这些对象在年轻代不能立即回收，从而进入了老年代，这也是老年代持续缓慢增长的原因。

#### 5.4 日志 ####

在高并发系统中，尤其是 Netty 的 I/O 线程，除了执行 I/O 读写操作外，还需执行异步任务和定时任务。如果 I/O 线程处理不过队列中的任务，可能会导致新进来的异步任务被拒绝。

在什么情况下可能会出现这种情况呢？异步读写问题不大，主要是多耗点 CPU。最有可能阻塞 I/O 线程的是日志记录。目前 Log4j 的 ConsoleAppender 日志 immediateFlush 属性默认为 true，即每次记录日志都是同步写入磁盘，这对于内存操作来说，速度较慢。

同时，AsyncAppender 的日志队列满了也会阻塞线程。Log4j 默认的 buffer 大小是 128，而且是阻塞的。即当 buffer 大小达到 128 时，会阻塞写日志的线程。在并发写日志量较大且堆栈较深的情况下，Log4j 的 Dispatcher 线程可能会变慢，需要刷盘。这样 buffer 就不能快速消费，很容易写满日志事件，导致 Netty I/O 线程被阻塞。因此，在记录日志时，我们需要注意精简。

### 6、未来规划 ###

目前，我们都在使用基于 HTTP/1 的协议。

相对于 HTTP/1，HTTP/2 在连接层面实现了服务，即在一个连接上可以发送多个 HTTP 请求。

这就意味着 HTTP 连接可以像 RPC 连接一样，建立几个连接即可，完全解决了 HTTP/1 连接无法复用导致的重复建连和慢启动的开销。

我们正在基于 Netty 升级到 HTTP/2，除了技术升级外，我们还在不断优化监控报警，以便为业务方提供准确无误的报警。此外，我们还在作为统一接入网关与业务方实施全面的降级措施，以确保全站任何故障都能通过网关第一时间降级，这也是我们的重点工作。

### 说在最后：有问题可以找老架构取经 ###

架构之路，充满了坎坷

架构和高级开发不一样 ， 架构问题是open/开放式的，架构问题是没有标准答案的

正由于这样，很多小伙伴，尽管耗费很多精力，耗费很多金钱，但是，遗憾的是，**一生都没有完成架构升级**。

**所以，在架构升级/转型过程中，确实找不到有效的方案，可以来找40岁老架构尼恩求助.**

前段时间一个小伙伴，他是跨专业来做Java，现在面临转架构的难题，但是经过尼恩几轮指导，顺利拿到了**Java架构师+大数据架构师offer** 。所以，如果遇到职业不顺，找老架构师帮忙一下，就顺利多了。

### 推荐阅读 ###

《[百亿级访问量，如何做缓存架构设计][Link 2]》

《[多级缓存 架构设计][Link 3]》

《[消息推送 架构设计][Link 4]》

《[阿里2面：你们部署多少节点？1000W并发，当如何部署？][2_1000W]》

《[美团2面：5个9高可用99.999%，如何实现？][2_5_9_99.999]》

《[网易一面：单节点2000Wtps，Kafka怎么做的？][2000Wtps_Kafka]》

《[字节一面：事务补偿和事务重试，关系是什么？][Link 5]》

《[网易一面：25Wqps高吞吐写Mysql，100W数据4秒写完，如何实现？][25Wqps_Mysql_100W_4]》

《[亿级短视频，如何架构？][Link 6]》

《[炸裂，靠“吹牛”过京东一面，月薪40K][40K]》

《[太猛了，靠“吹牛”过顺丰一面，月薪30K][30K]》

《[炸裂了…京东一面索命40问，过了就50W+][40_50W]》

《[问麻了…阿里一面索命27问，过了就60W+][27_60W]》

《[百度狂问3小时，大厂offer到手，小伙真狠！][3_offer]》

《[饿了么太狠：面个高级Java，抖这多硬活、狠活][Java]》

《[字节狂问一小时，小伙offer到手，太狠了！][offer]》

《[收个滴滴Offer：从小伙三面经历，看看需要学点啥？][Offer]》

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓

[bab3c6c08da54f04841cf437267d2717.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/ec7a463aac564ff3b6a01d9d4f4250dc.png
[200]: https://blog.csdn.net/crazymakercircle/article/details/132672467
[Link 1]: https://blog.csdn.net/crazymakercircle/article/details/132675308
[ea396bb349e8456eaf62821b9df0ad79.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/fdbbfa47fc10445fb23098cbcd612f91.png
[62dc8ccaf7154d9bbdbc6189730b3443.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/f5534b90e6414792b23dab35c96eb880.png
[d2f7aea3a49447a5862fb017d9f7fe19.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/20203eb720614c1eaace2e669aea6f6b.png
[67c782095fcf4d37b541a657746297a8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/609e6e2f4457443face2df85fb605d22.png
[a8dfa76f85e74e429e648607cca7daa7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/c8af0c59e8bf418c90eebf3ccce22f93.png
[b30f48a4efca44989fab0f11b8ce91df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/0feb6d2365be43ec810b8b2068a146cd.png
[0389c48cc90d4e748b86d3dedb63f06b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/a6727ca611504db08d91c30fe335a3de.png
[66124a20217146aa8871e624fb4e6a4f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/e57f4a69ccfc40acbbfddcc6eab4fbaf.png
[Link 2]: https://blog.csdn.net/crazymakercircle/article/details/132628780
[Link 3]: https://blog.csdn.net/crazymakercircle/article/details/132637261
[Link 4]: https://blog.csdn.net/crazymakercircle/article/details/132561087
[2_1000W]: https://blog.csdn.net/crazymakercircle/article/details/132526730
[2_5_9_99.999]: https://blog.csdn.net/crazymakercircle/article/details/132509763
[2000Wtps_Kafka]: https://blog.csdn.net/crazymakercircle/article/details/132479866
[Link 5]: https://blog.csdn.net/crazymakercircle/article/details/132456546
[25Wqps_Mysql_100W_4]: https://blog.csdn.net/crazymakercircle/article/details/132403212
[Link 6]: https://blog.csdn.net/crazymakercircle/article/details/132379306
[40K]: https://blog.csdn.net/crazymakercircle/article/details/132150378
[30K]: https://blog.csdn.net/crazymakercircle/article/details/132000420
[40_50W]: https://blog.csdn.net/crazymakercircle/article/details/131615296
[27_60W]: https://blog.csdn.net/crazymakercircle/article/details/131147192
[3_offer]: https://blog.csdn.net/crazymakercircle/article/details/131027012
[Java]: https://blog.csdn.net/crazymakercircle/article/details/130989697
[offer]: https://blog.csdn.net/crazymakercircle/article/details/130956376
[Offer]: https://blog.csdn.net/crazymakercircle/article/details/129317821