本文介绍了景顺长城在金融云原生架构演进中选择 APISIX 作为网关工具的技术细节,同时分享了使用 APISIX 的实践细节,并对 APISIX 的未来展望进行了探讨。
作者李奕浩,景顺长城信息技术部研发工程师,负责公司网关和业务系统上云等工作。
业务背景
景顺长城基金管理有限公司成立于 2003 年,是一家专注于资产管理领域的企业。目前,公司主要业务涵盖量化投资、主动收益和固定收益,拥有超过 6200 亿的资金管理规模,为超过 6000 万的投资者提供服务。作者所在的信息技术部门为投资交易、产品运营、市场营销等服务系统提供技术支持和开发业务需求。
公司内众多业务都需要流量网关作为重要支撑,然而在采用 APISIX 之前,我们遇到了不少问题和痛点:
痛点 1:网关不统一,维护成本高
首先介绍景顺长城业务系统在架构上的演进,分为 3 大阶段,本文基于阶段 2 到 3 的转变背景:
- 单体服务方式。服务应用部署在物理机上,但是随着服务应用和业务的不断增长,运维和开发成本开始激增;
- 虚拟机方式。在虚拟机阶段,各业务系统使用的网关不统一,业务各自为政,网关相关的机器服务也很多,维护成本一直很高。在基金证券行业,网络分区方面存在一定的监管要求,每个网络分区都需要按照信息安全级别划分为不同的逻辑安全区域,或者是物理隔离安全的区域,各个区域使用防火墙达到网络隔离的目的。
- 结合在金融科技云战略以及数字化转型的需求,启动了上云工程。
当前业务系统大致分为了三个分区:交易区、生产区、管理区,每个分区部署的网关都不一样。原本景顺长城使用 NGINX 作为 Web 服务器和反向代理,在同网络分区中的业务,都是使用了同一个 NGINX,导致了每次服务变更或路由更新,都需要在这个 NGINX 上面手动更新和重载。

上图就是当前的系统架构,从上往下分别是用户接入层、负载均衡层、网关集群层以及业务系统层,其中网关安全集群层使用了 Zuul、Spring Cloud Gateway、Kong 还有 NGINX 等多个框架,架构管理不统一,管理起来比较繁琐。
痛点 2:网关承载能力弱
现存的网关只使用了很基本的能力,比如负载均衡、路由转发,鉴权、灰度发布、熔断能力都没有。
前面提到的单一的 NGINX 服务,每次服务变更和路由更新都需要在 NGINX 上面进行配置。由于业务前端的服务都集成在 NGINX 上面,没有对接 DevOps 平台生产环境,NGINX 的配置项数量如今已经相当庞大了,单个 Server 模块超过 700 行,维护成本相当高。
痛点 3:限流熔断、灰度发布配置繁琐
- 限流熔断能力缺失
- 灰度能力配置繁琐:需同步改动多个应用代码和数据库变更。现在使用的网关需要单独做对应的开发,并且业务侧也要做对应的代码修改,才能实现不同服务的灰度能力(全链路灰度)。
痛点 4:新增服务涉及步骤繁多

在新增服务的情况下,需要手动添加 NGINX、Gateway、业务系统等各个模块的配置步骤,无法配置自动化。这就意味着新增服务的一系列配置修改很是繁琐,导致在服务发布时面临很高的人力成本。

景顺长城在金融云原生架构中遇到网关不统一、承载能力弱等问题,选择 APISIX 解决智能路由、安全认证、可观测性和流量控制等挑战。通过 APISIX,实现了统一网关框架,提高了运维效率,支持热更新,降低了服务重启压力。未来期待 APISIX 在监控告警、etcd 连接及链路追踪方面的改进。
最低0.47元/天 解锁文章
9915

被折叠的 条评论
为什么被折叠?



