本文介绍了景顺长城在金融云原生架构演进中选择 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：新增服务涉及步骤繁多
文章来源：https://www.toymoban.com/news/detail-401682.html
在新增文章来源地址https://www.toymoban.com/news/detail-401682.html
到了这里，关于景顺长城基于 Apache APISIX 在金融云原生的生产实践的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
