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

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

背景介绍

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

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

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

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

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

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

行业现状与痛点

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

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

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

当然这里的鉴权服务并不是指网关层面的呈现，而是基金业务与其他第三方基金公司之间的