API 网关 Apache APISIX 助力雪球双活架构演进

背景

雪球成立于 2010 年，起步于投资社区，现已成为国内领先的集投资、交流和交易为一体的在线管理平台，为投资者提供优质内容、实时行情、交易工具、财富管理等多种服务。

其中实时行情服务对接了多种上游数据源，通过数据流式计算、存储与分发，为投资者提供稳定的数据服务。所以实时行情一直是雪球业务系统中的资源消耗大户，持续在高水位运行。雪球内部一项重要的工作就是持续进行稳定性建设，其中包括对行情服务进行性能优化。即便如此，在偶然发生极端行情的情况下，部分系统仍会因为数据量激增而发生响应变慢，甚至是不可用的情况，从而影响用户体验。

在此背景下，雪球为了向广大投资者提供稳定优质的服务，启动了服务双活改造计划。Apache APISIX 能极大地简化双活架构的实施复杂度。同时 APISIX 自身的云原生功能特性、丰富的社区生态和插件等，也为雪球未来云原生架构的演进打下了良好基础。本文将介绍雪球公司是如何借助 Apache APISIX 实现内部双活架构的演进。

上图是雪球单机房时期的简单架构描述，用户流量从云端入口（SLB）进来后，经网关进行简单的公共性逻辑处理，向后端服务转发。后端服务会通过 SDK 的方式，由集成在服务中的鉴权模块向雪球用户中心发起用户鉴权，通过后则继续进行后续的业务处理。

双活改造痛点

在实践业务场景中，该架构下一些痛点也开始逐渐显现。

1. SDK 鉴权模块复杂

在双活改造实施过程中，微服务的提供方和消费方无法完全同步进行部署上线。当行情服务首先在云端上线，而雪球用户中心还不具备云端服务能力时，便会出现跨机房调用的情况。根据用户中心统计，其 RPC 调用量日均约数十亿，峰值可达到 50K QPS，在行情高的 QPS 场景下会带来较高延迟。

同时雪球鉴权业务复杂度较高，除 OAuth2.0 / JWT 协议外，还需要兼顾客户端版本、雪球旗下多个 APP 等多种因素。由于鉴权模块嵌入了服务内，导致升级也变得较为困难。

2. OpenResty 功能性稍有不