Java架构师笔记丨百亿流量微服务网关的设计与实现【巴分巴秒】-CFANZ编程社区

本文从百亿流量交易系统微服务网关（API Gateway）的现状和面临的问题出发，阐述微服务架构与 API 网关的关系，理顺流量网关与业务网关的脉络，分享API网关知识与经验。

API网关概述

“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。”

——David Wheeler

分布式服务架构、微服务架构与 API 网关

1. 什么是API网关（API Gateway）

其实，网关跟面向服务架构（Service Oriented Architecture，SOA）和微服务架构（MicroServicesArchitecture，MSA）有很深的渊源。

十多年以前，银行等金融机构完成全国业务系统大集中以后，分散的系统都变得集中，也带来了各种问题：业务发展过快如何应对，对接系统过多如何集成和管理。为了解决这些问题，业界实现了作用于渠道与业务系统之间的中间层网关，即综合前置系统，由其适配各类渠道和业务，处理各种协议接入、路由与报文转换、同步异步调用等操作，如图7-1所示。

图7-12

3. 网关系统典型的应用场景

我们的API网关系统为Web端、移动App端客户提供服务，也为大量API客户提供API调用服务，同时支持REST API和WebSocket协议。

作为实时交易系统的前置系统，必须精准及时为客户提供的行情和交易信息。一旦出现数据的延迟或错误，都会给客户造成无法挽回的损失。

另外针对不同的客户和渠道，网关系统需要提供不同的安全、验证、流控、缓存策略，同时可以随时聚合不同视角的数据进行预处理，保障系统的稳定可靠和数据的实时较精确。

4. 交易系统API的特点

作为一个全球性的交易系统，我们的API特点总结如下。

访问非常集中：最核心的一组API占据了访问量的一半以上；

访问非常频繁：QPS非常高，日均访问量非常大；

数据格式固定：交易系统处理的数据格式非常固定；

报文数据量小：每次请求传输的数据一般不超过10KB；

用户全世界分布：客户分布在全世界的各个国家；

分内部调用和外部调用：除了API客户直接调用的API，其他的API都是由内部其他系统调用的；

7×24小时不间断服务：系统需要提供高可用、不间断的服务能力，以满足不同时区客户的交易和自动化策略交易；

外部用户有一定技术能力：外部API客户，一般是集成我们的API，实现自己的交易系统。

5. 交易系统API网关面临的问题

问题1：流量不断增加。

如何合理控制流量，如何应对突发流量，如何较大限度地保障系统稳定，都是重要的问题。特别是网关作为一个直接面对客户的系统，出现的任何问题都会放大百倍。很多千奇百怪的从来没人遇到的问题随时都可能出现。

问题2：网关系统越来越复杂。

现有的业务网关经过多年发展，里面有大量的业务嵌入，并且存在多个不同的业务网关，相互之间没有任何关系，也没有沉淀出基础设施。

同时技术债务太多，系统里硬编码实现了全局性网关策略及很多业务规则，导致维护成本较大。

问题3：API网关管理比较困难。

海量并发下API的监控指标设计和数据的收集也是一个不小的问题。7×24小时运行的技术支持也导致维护成本较高。

问题4：选择推送还是拉取。

使用短连接还是长连接，REST API还是WebSocket？业务渠道较多（多个不同产品线的Web、App、API等形成十几个不同的渠道），导致用户的使用行为难以控制。

业务网关的设计与较佳实践

1. API网关1.0

我们的API网关1.0版本是多年前开发的，是直接使用OpenResty定制的，全局的安全测试、流量的路由转发策略、针对不同级别的限流等都是直接用Lua脚本实现。

这样就导致在经历了业务飞速发展以后，系统里存在非常多的相同功能或不同功能的Lua脚本，每次上线或维护都需要找到受影响的其中几个或几十个Lua脚本，进行策略调整，非常不方便，策略控制的粒度也不够细。

2. API网关2.0

在区分了流量网关和业务网关以后，2017年开始实现了流量网关和业务网关的分离，流量网关继续使用OpenResty定制，只保留少量全局性、不经常改动的配置功能和对应的Lua脚本。

业务网关使用Vert.x实现的Java系统，部署在流量网关和后端业务服务系统之间，利用Vert.x的响应式编程能力和异步非阻塞I/O能力、分布式部署的扩展能力，初步解决了问题1和问题2，如图7-13所示。

图7-15

一个高性能的API网关系统，缓存是必不可少的部分。无论分发冷热数据，降低对业务系统的压力，还是作为中间数据源，为服务聚合提供高效可复用的业务数据，缓存都发挥了巨大作用。

3. API网关的日常监控

我们使用多种工具对API进行监控和管理，包括全链路访问跟踪、连接数统计分析、全世界重要国家和城市的波测访问统计。网关技术团队每时每刻都关注着数据的变化趋势。各个业务系统研发团队每天安排专人关注自己系统的API性能（吞吐量和延迟），推进性能问题解决和持续优化。这就初步解决了问题3。

4. 推荐外部客户使用WebSocket和API SDK

由于外部客户需要自己通过API网关调用API服务来集成业务服务能力到自己的系统。各个客户的技术能力和系统处理能力有较大差异，使用行为也不同。对于不断发展变动的交易业务数据，客户调用API频率太低会影响数据实时性，调用频率太高则可能会浪费双方的系统资源。同时利用WebSocket的消息推送特点，我们可以在网关系统控制客户接收消息的频率、单个用户的连接数量等，随时根据业务系统的情况动态进行策略调整。综合考虑，WebSocket是一个比REST API更加实时可靠、更加易于管理的方式。另外对于习惯使用REST API的客户，我们也通过将各种常见使用场景封装成多种不同语言的API SDK（包括Java/C++/C#/Python），进而统一用户的API调用方式和行为。在研发、产品、运营各方的配合下，逐步协助客户使用WebSocket协议和API SDK，基本解决了问题4。

5. API网关的性能优化

API网关系统作为API服务的统一接入点，为了给用户提供最优质的用户体验，必须长期做性能优化工作。不仅API网关自己做优化，同时可以根据监控情况，时刻发现各业务系统的API服务能力，以此为出发点，推动各个业务系统不断优化API性能。

举一个具体的例子，某个网关系统连接经常强烈抖动（如图7-16所示），严重影响系统的稳定性、浪费系统资源，经过排除发现：

（1）有爬虫IP不断爬取我们的交易数据，而且这些IP所在网段都没有在平台产生任何实际交易，较高单爬虫IP的每日新建连接近100万次，平均每秒十几次。

（2）有部分API客户的程序存在bug，而且处理速度有限，不断地重复“断开并重新连接”，再尝试重新对API数据进行处理，严重影响了客户的用户体验。

针对如上分析，我们采取了如下处理方式：

（1）对于每天认定的爬虫IP，加入黑名单，直接在流量网关限制其访问我们的API网关。

（2）对于存在bug的API客户，协助对方进行问题定位和bug修复，增强客户使用信心。

（3）对于处理速度和技术能力有限的客户，基于定制的WebSocket服务，使用滑动时间窗口算法，在业务数据变化非常大时，对分发的消息进行批量优化。