单机吞吐提升100%，响应时间降低50%：去哪儿网酒店高性能业务网关优化实践

一、背景

近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰，系统面临的压力主要来自两方面：首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移。其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。这就导致了一系列的问题：

• 业务网关吞吐性能变差

应对流量尖峰时期的单机最大吞吐量与合并之前相比，下降了20%

• 内部业务逻辑处理速度变差

主流程业务逻辑的处理时间与合并之前相比，上涨了10%

• 代码难以维护、开发效率低

主站内部各个模块之间严重耦合，边界不清，修改扩散问题非常明显，给后续的迭代增加了维护成本，开发新需求的效率也不高。

酒店业务网关作为直接面对用户的系统，出现任何问题都会被放大百倍，上述这些问题亟待解决。

二、现状分析

1、吞吐量下降分析

现有系统虽然业务处理部分是异步化的，但是并不是全链路异步化，如图所示：

同步 servlet 容器，servlet 线程与业务逻辑线程是同一个，高峰期流量上涨或者尤其是遇到流量尖峰的时候，servlet 容器线程被阻塞的时候，我们服务的吞吐量就会明显下降。

业务处理虽然使用了线程池确实能实现异步调用的效果，也能压缩同步等待的时间，但是也有一些缺陷：

• CPU 资源大量浪费在阻塞等待上，导致 CPU 资源利用率低。
• 为了增加并发度，会引入更多额外的线程池，随着 CPU 调度线程数的增加，会导致更严重的资源争用，上下文切换占用 CPU 资源。
• 线程池中的线程都是阻塞的，硬件资源无法充分利用，系统吞吐量容易达到瓶颈。

2、响应时间上涨分析

前期为了快速落地酒店 DDD 架构，合并大前台的重构中，并没有做到一步到位的设计。为了保证项目质量，将整个过程切分为了迁移+重构两个步骤。迁移之后，整个酒店业务网关的内部代码结构是割裂、混乱的。总结如下：

我们最核心的一个接口会调用70多个上游接口，上述问题：边界不清、不内聚、各种重复调用、依赖阻塞等问题导致了核心接口的响应时间有明显上涨。

三、解决方案

1、全流程异步化提升吞吐量

全流程异步化方案，我们主要采用的是 Spring WebFlux。

1.1 选择的理由

响应式编程模型：Spring WebFlux 基于响应式编程模型，使用异步非阻塞式 I/O，可以更高效地处理并发请求，提高应用程序的吞吐量和响应速度。同时，响应式编程模型能够更好地处理高负载情况下的请求，降低系统的资源消耗。

高性能：Spring WebFlux 使用 Reactor 库实现响应式编程模型，可以处理大量的并发请求，具有出色的性能表现。与传统的 Spring MVC 框架相比，Spring WebFlux 可以更好地利用多核 CPU 和内存资源，以实现更高的性能和吞吐量。

可扩展性：Spring WebFlux 不仅可以使用 Tomcat、Jetty 等常