基金交易场景下，如何利用 Apache APISIX 来稳固 API 安全

王晔倞，Apache APISIX Committer，公众号「头哥侃码」作者。

背景介绍

金融领域的企业中，安全是非常重中之重的因素。 通常各类金融企业都会花费大量成本去采购安全相关的设备和硬件，基金管理相关企业更是如此。

根据相关国内基金管理行业发展现状分析报告中可以看到：“我国基金管理行业在经历野蛮生长、严监管规范以及次贷危机冲击等阶段后，目前已经形成了监管规范化不断加强、公司格局完善的局面。在大众投资理念转变的背景下，基金管理行业规模稳步增长，行业发展空间有望持续扩大。”

从现实数据来看，大环境和人们理财意识的逐渐增强，使得基金行业在业务发展的过程中，对于技术业务上的呈现也开始有着更高的追求。

比如稳定性，这里说的稳定性并不是应对类似双十一那种突增流量时的业务表现，而是保证业务长久线上的稳定性和持续性。其次就是有效性和准确性，它与稳定性是相辅相成的。因为金融领域有着非常严格的交易时间，尤其是证券和基金行业。大量的交易都会发生在固定的时间段内，因此相关时间内的有效性和准确性是必须要保障的。即业务场景下允许系统慢，但不允许崩。

最后就是开头内容中提到的严监管规范，也就是政策层面的监管强度。因为行业的特殊性，在业务安全和企业治理中，很多时候它是需要考虑行业色彩和大环境的。

得益于这些业务色彩，我们也会对基金行业的一些业务架构产生兴趣，比如他们是运用哪些方式来保障高监管要求下的业务安全。在这里，我们选取了目前使用 APISIX 的一家基金行业用户，带来他们的业务网关架构演进与基于 APISIX 进行的业务安全实践细节。

行业现状与痛点

这家公司是从 2012 年开始搭建相关交易系统，API 规模大概在 12000+ 数量，包含 PaaS、BaaS、两地三中心、安全、运维、中间件和 DevOps 平台等等。公司业务的整个系统架构演进大体经历了三个阶段。

在业务刚起步阶段（1.0 时代），业务架构还非常单一，基本是能应对基金买卖的简单场景即可，属于单体架构模式。随着后续业务的扩充和国内市场环境的影响，架构也随之进行了初步的更新迭代。在这个阶段下，开始对业务进行了简易分割。

上图就是当时最简单的架构模式，相信大家对这种架构类型都比较熟悉。即有一套简单的前端配置，包括应用、网站等等。从整体来看，业务模型比较简单，因为只需搭建好交易体系即可，搭配上完整的支付业务和鉴权服务。后端主要是去维护相关的基金交易数据，然后存储到数据库里。

当然这里的鉴权服务并不是指网关层面的呈现，而是基金业务与其他第三方基金公司之间的连接鉴权。比如跟外部的基金业务对接时，需要进行双方数据的对接，这种时候就需要有一些 Token 去进行鉴别和限制等等。

当时还没有网关的概念。在这个架构下类似现在网关概念的就是图中的 HSB（服务总线），它其实就是网关的前身，主要用来控制南北向流量。

人们总说，在公司业务或者行业发展过程中，总会出现一些节点来加速或者改变某个行业的进程。2015 年国内股市的业务爆发，也导致了基金业务公司开始进行业务扩展。市场方向的快速推动下，业务也开始加速前进。

这种情况下，该基金公司的后端业务就需要进行大量的变动，开始演进到如下图所示的架构类型（2.0 时代）。

如上图红线圈出来的地方，可以明显看到，之前的服务总线模块开始变得复杂，各种业务组件纷纷出现。之所以变得复杂，是因为在业务野蛮生长阶段时，它会因为一些需求现状各自进行产出。

举个最简单的例子，就像各地的健康码系统一样，各省都不一样，甚至有的同一个省的不同地市还会有单独的系统。因为在产出过程中，我们会发现「自己造自己家的烟囱」是最快最快速的方式。

那么这种情况下就衍生出另外一个问题，也就是在系统发展过程中，一定会伴随所谓的技术债务问题。就是不同负责人在位时，所选择的技术栈或系统模型各不相同。

这个过程中就会出现一些业务库的拼装，因为当下的服务场景开始变得复杂。所有的这些新增动作等都需要通过后台系统的组合，来完成前端的某一个动作。因此这种组合的过程中将，势必要用到很多种类的组件以及经历几次产品更替，系统就开始变得复杂和繁重。

上述业务现状的演变下，不少问题就开始涌现。如下图所示，从三个层面进行了一些汇总。

当然除了上述提到的这些在外，在业务层面还会有其他一些问题。比如：

• 技术成本开始变高，整体性能有所影响。 网关技术栈的不统一，导致需要同时维护多种协议与微服务框架，开发维护成本较高；随着业务的规模越来越大，像大部分金融企业都选择基于 Java 做中间件，在处理大流量 QPS 时所需的服务器资源越来越多，整体性能冗杂。

• 微服务框架的侵入性强，存在安全隐患。 当下无论是 API 治理、审计还是鉴权，基本都依赖微服务框架和 SDK 来进行。因此每次版本的更新，不仅带来运维风险，还容易引发大量内部业务矛盾。

• 缺少更高阶功能的需求满足。 如果一个架构中，业务系统网关都是自研的，那么任何功能都要从 0 进行开发编写，这个过程中需要考虑一些时间成本问题，同时在业务层面可能只会实现相对简单的功能，比如缺少服务发现和部分监控指标等功能。这对于后续的业务发展就会造成一些技术上的瓶颈。

技术选型与架构更新

在后续业务发展过程中，这家基金公司在 2020 年时开始对网关产品进行单独选型。

在 2018 年左右时，Spring Cloud 其实非常盛行，金融行业内有很多企业都开始使用 Spring Cloud Gateway。同时金融行业的架构中，大多都是基于 Java 进行的，所以开发人员中大多都是熟悉 Java 的。

而当时这家基金公司并没有跟随行业的普遍方案，去选择 Spring Cloud Gateway，而是最终确定了 Apache APISIX 作为他们的网关。之所以没有选择 Spring Cloud Gateway，主要原因如下图所示。

当然除了上述原因外，还有一些实际大环境的因素。2019 年左右，P2P 事件开始曝光，很多 P2P 公司倒闭。当时整个金融领域尤其是基金交易领域，发生了翻天覆地的变化。各家企业都开始进行成本压缩，所以在架构选型中，还需要面对成本压缩的考虑因素，去进行选型。

因为公司要压成本，同时也开始要求把一些非交易系统放置到云上。作为技术人员，这种情况下就会考虑如何让上云时更方便更高效，因此面临这种场景时，技术栈能被统一地越少越好。所以他们就开始往云原生方向的网关产品去观望。最终，结合业务表现和技术栈统一相关的成本因素，最终选择了 APISIX。

基于 APISIX，该基金公司的业务架构更新成了如下图所示的全新模块（3.0 时代），这其中将架构分成了前中后模式，并对代码进行了分层。

从外部进入的流量（南北向流量）经过 APISIX 后，可以进行一些安全控制、流量管控和准入控制（比如灰度）等。而在应用层与业务层以及业务层与基础层中间，会用 APISIX 来解决东西向的流量。由于该基金公司当时大部分的系统是运行在 VMWare 虚拟机上，只有测试的交易系统是跑到 K8s 上的，所以他们的 CI/CD 比较复杂，因此 APISIX 在这里处理东西向流量时，主要是进行统一入口、监控报警、分流和鉴权相关操作。

基于 APISIX 的业务安全实践

微服务治理

微服务主要解决东西向流量。APISIX 在进行整个微服务治理的过程中，主要会帮助企业解决统一入口、API 配置管理、分流鉴权、服务监控、协议转换等问题，具有分布式和可拓展的特性。

前文我们提到过该公司业务架构中也存在比如鉴权模块，但当时他们用 Java 的一些扩展包进行了自研。但发展到后期，业务开始进行统一时，各个平台都需要对接进来，问题就开始出现了。

因为除了产品、中间件等等业务平台，还包括账户中心等等，这些之间的相互联动，不止需要进行 HTTPS 的相关加密，还会存在一些单点必要需求等。

为了满足这些业务间联动和相关加密处理需求等，该基金公司就利用 APISIX 在中间件部分（APISIX 作为网关是其中一部分）作为单点入口，去处理这些联动和安全层面的需求对接，如下图所示。

其中在服务治理层，会涉及到一些协议转换，而 APISIX 具备成熟的服务治理框架去对接 Dubbo 以及进行 MQ 服务之间解耦。APISIX 的基础协议支持的类型非常多，包括 HTTPS、MQTT、Dubbo、gRPC 和 WebSocket 等多种类型。比如在实际使用时，可以通过 APISIX 内置的 dubbo-proxy 插件来实现代理 Dubbo 协议，无需再进行相关配置的从 0 到 1，而是直接开箱即用，轻松地将 Dubbo Service 发布为 HTTP 服务。

认证授权

身份认证在日常生活当中是非常常见的一项功能，大家平时基本都会接触到。比如用支付宝消费时的人脸识别确认、公司上班下班时的指纹/面部打卡以及网站上进行账号密码登录操作等，其实都是身份认证的场景体现。可以说身份认证是保证基金交易安全稳定运行的重要因素之一。

之前该公司是利用 Java 的一些自研组件或者程序逻辑等来作为「类似网关作用」进行相关的认证授权。但整体会出现负载压力大，且不支持流量控制和灰度等能力，同时还缺少相关项目维护人员。

在使用 APISIX 后，他们开始利用 APISIX 去提供认证和授权的相关能力，来帮助自家业务进行统一管理和高效运维。目前 APISIX 所支持的插件也已达到 80+，其中也内置不少认证鉴权相关的插件。

比如借助 APISIX 内置的 jwt-auth 插件或 openid-connect 插件，在业务内部和外部之间进行一些认证交互，实现如下一些场景：

• 应用级：内部应用通过应用级 AT 到账号系统，然后根据用户 ID 等数据直接查询用户的信息，无需用户授权；

• 用户级：用户授权应用，应用通过用户授权生产的用户级 AT，到账号查询用户的 openid、unionid 和头像等用户信息。

SSL 证书

在系统建设的初期，该公司架构基本都是基于 HTTP 协议或一些自定义协议进行互相调用。但是通过 HTTP 协议传输的是明文数据，不会对数据进行加密。但在基金交易系统中，无论是因为政策监管还是安全需要，即使在内网也需要通过 HTTPS 访问数据。

在之前的安全功能呈现上，该公司都是直接采购安全类产品进行防护，但是使用过程中必然少不了三方的维护等环节。在架构演进过程中引入 APISIX 后，刚好解决了该场景下的一些需求。从而方便根据业务需要进行灵活调整，同时在成本层面抛弃防火墙等产品，优化了运维流程，最重要的是也满足了相关监管需求。

比如 APISIX 在 SSL 证书功能上就支持单一域名、泛域名、多域名和单域名多证书的多种场景。

APISIX 支持通过 TLS 扩展 SNI 实现加载特定的 SSL 证书，以实现对 HTTPS 的相关支持。启用该特性后，将允许客户端在服务器端向其发送证书之前向服务器端发送请求的域名，服务器端将会根据客户端请求的域名选择合适的 SSL 证书发送给客户端。

所以在安全相关的功能准备中，很多东西都是顺应着大环境的要求和一些架构更新过程中的业务统一而进行的。并不是说因为有了 APISIX 这种类型的云原生网关，才开始去重视业务上的安全问题，而是说有了 APISIX 网关，可以让企业业务安全更高效更简易地进行管理和操作。

总结

以上就是从基金交易业务的场景下，带来了泛金融行业在进行业务架构迭代过程中的变更与相关安全实践。在业务机构更新的过程中，如果没有类似 APISIX 这种网关中间件的能力加持，或许就没法轻易地满足业务上的高速发展，也没有办法轻易解决行业野蛮增长过程之后的复杂技术债问题。

所以不管是企业治理还是稳固业务安全，选择一个健康持续发展的中间件产品，是非常有利于业务架构的升级与后续拓展的，同时可以最大限度地帮助企业去解决技术债务。为什么选择技术债务这个点，因为它是我们在社区通过一些企业用例反馈之后，发现的一些企业选择 APISIX 的痛点之一。

纵观该基金企业的整个系统演化过程，都是用业务去推动选型。通过对性能、可拓展性以及安全等层面，Apache APISIX 都用更实际的数据和效果证明了它作为网关和中间件属性的作用，在保证性能的同时，也为金融行业的业务安全带来了最稳定的保障。