王晔倞,Apache APISIX Committer,公众号「头哥侃码」作者。
背景介绍
金融领域的企业中,安全是非常重中之重的因素。 通常各类金融企业都会花费大量成本去采购安全相关的设备和硬件,基金管理相关企业更是如此。
根据相关国内基金管理行业发展现状分析报告中可以看到:“我国基金管理行业在经历野蛮生长、严监管规范以及次贷危机冲击等阶段后,目前已经形成了监管规范化不断加强、公司格局完善的局面。在大众投资理念转变的背景下,基金管理行业规模稳步增长,行业发展空间有望持续扩大。”
从现实数据来看,大环境和人们理财意识的逐渐增强,使得基金行业在业务发展的过程中,对于技术业务上的呈现也开始有着更高的追求。
比如稳定性,这里说的稳定性并不是应对类似双十一那种突增流量时的业务表现,而是保证业务长久线上的稳定性和持续性。
其次就是有效性和准确性,它与稳定性是相辅相成的。因为金融领域有着非常严格的交易时间,尤其是证券和基金行业。大量的交易都会发生在固定的时间段内,因此相关时间内的有效性和准确性是必须要保障的。即业务场景下允许系统慢,但不允许崩。
最后就是开头内容中提到的严监管规范,也就是政策层面的监管强度。因为行业的特殊性,在业务安全和企业治理中,很多时候它是需要考虑行业色彩和大环境的。
得益于这些业务色彩,我们也会对基金行业的一些业务架构产生兴趣,比如他们是运用哪些方式来保障高监管要求下的业务安全。在这里,我们选取了目前使用 APISIX 的一家基金行业用户,带来他们的业务网关架构演进与基于 APISIX 进行的业务安全实践细节。
行业现状与痛点
这家公司是从 2012 年开始搭建相关交易系统,API 规模大概在 12000+ 数量,包含 PaaS、BaaS、两地三中心、安全、运维、中间件和 DevOps 平台等等。公司业务的整个系统架构演进大体经历了三个阶段。
在业务刚起步阶段(1.0 时代),业务架构还非常单一,基本是能应对基金买卖的简单场景即可,属于单体架构模式。随着后续业务的扩充和国内市场环境的影响,架构也随之进行了初步的更新迭代。在这个阶段下,开始对业务进行了简易分割。
上图就是当时最简单的架构模式,相信大家对这种架构类型都比较熟悉。即有一套简单的前端配置,包括应用、网站等等。从整体来看,业务模型比较简单,因为只需搭建好交易体系即可,搭配上完整的支付业务和鉴权服务。后端主要是去维护相关的基金交易数据,然后存储到数据库里。
当然这里的鉴权服务并不是指网关层面的呈现,而是基金业务与其他第三方基金公司之间的