关于apisix:景顺长城基于-Apache-APISIX-在金融云原生的生产实践

本文介绍了景顺长城在金融云原生架构演进中抉择 APISIX 作为网关工具的技术细节，同时分享了应用 APISIX 的实际细节，并对 APISIX 的将来瞻望进行了探讨。

作者李奕浩，景顺长城信息技术部研发工程师，负责公司网关和业务零碎上云等工作。

业务背景

景顺长城基金治理有限公司成立于 2003 年，是一家专一于资产治理畛域的企业。目前，公司次要业务涵盖量化投资、被动收益和固定收益，领有超过 6200 亿的资金治理规模，为超过 6000 万的投资者提供服务。作者所在的信息技术部门为投资交易、产品经营、市场营销等服务零碎提供技术支持和开发业务需要。

公司内泛滥业务都须要流量网关作为重要撑持，然而在采纳 APISIX 之前，咱们遇到了不少问题和痛点：

痛点 1：网关不对立，保护老本高

首先介绍景顺长城业务零碎在架构上的演进，分为 3 大阶段，本文基于阶段 2 到 3 的转变背景：

1. 单体服务形式。服务利用部署在物理机上，然而随着服务利用和业务的一直增长，运维和开发成本开始激增；
2. 虚拟机形式。在虚拟机阶段，各业务零碎应用的网关不对立，业务各自为政，网关相干的机器服务也很多，保护老本始终很高。在基金证券行业，网络分区方面存在肯定的监管要求，每个网络分区都须要依照信息安全级别划分为不同的逻辑平安区域，或者是物理隔离平安的区域，各个区域应用防火墙达到网络隔离的目标。
3. 联合在金融科技云策略以及数字化转型的需要，启动了上云工程。

以后业务零碎大抵分为了三个分区：交易区、生产区、管理区，每个分区部署的网关都不一样。本来景顺长城应用 NGINX 作为 Web 服务器和反向代理，在同网络分区中的业务，都是应用了同一个 NGINX，导致了每次服务变更或路由更新，都须要在这个 NGINX 下面手动更新和重载。

上图就是以后的零碎架构，从上往下别离是用户接入层、负载平衡层、网关集群层以及业务零碎层，其中网关平安集群层应用了 Zuul、Spring Cloud Gateway、Kong 还有 NGINX 等多个框架，架构治理不对立，治理起来比拟繁琐。

痛点 2：网关承载能力弱

现存的网关只应用了很根本的能力，比方负载平衡、路由转发，鉴权、灰度公布、熔断能力都没有。

后面提到的繁多的 NGINX 服务，每次服务变更和路由更新都须要在 NGINX 下面进行配置。因为业务前端的服务都集成在 NGINX 下面，没有对接 DevOps 平台生产环境，NGINX 的配置项数量现在曾经相当宏大了，单个 Server 模块超过 700 行，保护老本相当高。

痛点 3：限流熔断、灰度公布配置繁琐

• 限流熔断能力缺失
• 灰度能力配置繁琐：需同步改变多个利用代码和数据库变更。当初应用的网关须要独自做对应的开发，并且业务侧也要做对应的代码批改，能力实现不同服务的灰度能力（全链路灰度）。

痛点 4：新增服务波及步骤繁多

在新增服务的状况下，须要手动增加 NGINX、Gateway、业务零碎等各个模块的配置步骤，无奈配置自动化。这就意味着新增服务的一系列配置批改很是繁琐，导致在服务公布时面临很高的人力老本。

痛点 5：接口调用存在安全隐患

此外，以后应用的网关未波及鉴权能力，各接口可间接调用，业务零碎存在很高的平安危险。

发现并抉择 APISIX

基于上述痛点，景顺长城在 API 网关产品选型过程中对以下几点更为关注。

因为金融畛域对服务的稳定性相较其余行业更加器重，因而 稳定性 放在第一位，另外也看重网关的扩展性，对于在虚拟机期间横蛮成长的网关服务，都须要一一满足其中的业务需要，这里就是比拟考验所选网关的 扩展性 ；再有就是 可观测性 ，对业务零碎的日志、链路追踪、监控都有很强烈要求；最初就是 热更新 的能力。

因为 NGINX 无奈动静变更配置，因而当面临配置变更场景时须要重载 NGINX 以载入新的配置，在长链接场景下，因为 NGINX 实现个性的起因，该过程将导致业务零碎呈现流量稳定，进而影响用户体验。

所以基于这 4 个关注点，景顺长城技术团队对 APISIX 和 Kong 进行了横向比照：

• 技术框架方面，APISIX 和 Kong 都是基于 OpenResty 的根底之上进行二次开发，配置核心方面 APISIX 选型了 etcd，Kong 选型了 PostgreSQL，因为 etcd 的云原生个性与 APISIX 的状态个性使得 APISIX 是云原生分布式网关；而 Kong 的配置核心选型会有可能呈现单点故障的问题，须要额定的基础设施保障做高可用。
• 社区活跃度方面，APISIX 和 Kong 都是属于比拟高热度的，每天的均匀 commit 量是在 20 次左右。
• 扩展性方面，APISIX 反对的语言十分多，并且还反对 WebAssembly，Kong 只反对应用 Lua 语言进行插件的编写。
• 热更新方面，这是团队重点关注的：APISIX 反对热更新，并且实现了毫秒级别的热更新响应；而 Kong 不反对热更新。
• 可观测性方面，选型的时候 Kong 还未能提供 SkyWalking 的反对。

基于以上关注点和比照点，最终景顺长城技术团队抉择了 APISIX 作为业务零碎的 API 网关。

基于 APISIX 的解决方案

如图所示，景顺长城的零碎架构改革重点是将网关集群都转换为 APISIX。因为 APISIX 部署在 Kubernetes 集群上，因而能够通过 YAML 以申明式配置的形式对立治理 API，并通过 APISIX Ingress Controller 主动监听 Kubernetes 资源变更事件，实现 APISIX 配置的实时同步，包含 AR（ApisixRoute）、SSL 等。

路由同步时序图：

上面具体介绍景顺长城团队在业务侧比较关心的 4 个场景，包含智能路由、平安认证、可观测性和流量管制。

场景一：智能路由

次要体现在 APISIX 反对的 7 层和 4 层负载平衡。7 层负载平衡上的计划如下：

而后是生产环境上的路由配置状况：

如图所示，通过 APISIX Ingress Controller 同步的路由信息，都是带上了特定的标签的，就是为了避免误删除操作。

通过测试环境验证，即便删除了数据，Kubernetes 也可能疾速主动同步到 APISIX 上，因而解决了数据失落的问题。

此外，路由更新在 APISIX 下面也达到毫秒级别响应，配置同步提早简直无感，体验十分好。

景顺长城技术团队应用 Consul 作为服务发现的中间件，在调研过程中发现 APISIX 2.15 版本尽管反对了 Consul 的服务发现插件，但仅作为配置核心的形式反对，而在服务发现局部的失常模式上尚未反对。随后，景顺长城技术团队基于该场景开发了反对 Consul 的服务发现插件，并已将其奉献给社区。

这里补充介绍一下 Consul 插件的外部细节，先看下图：

从上往下看，Consul 插件是通过 HTTP 形式去获取不同 Consul 集群的 Service 信息的，这里会获取服务信息会做校验，就是 last consul index(X-Consul-Index)，这个 index 字段是在 header 外面的，只有在服务信息变动的时候才会返回后果，所以这也很好地保障了 APISIX 和 Consul 之间的申请数量。

接下来，在 APISIX 中会有多个 worker 同步更新 all_services 表中的信息，该表蕴含了各个服务名称对应的 IP 和端口号。这些 worker 通过事件机制进行通信，并提供了 debugging API 以不便用户获取以后的服务信息。上面是流程的具体介绍：

Consul 提供了 Catalog 的 API 形式获取 services 信息，其中这里能够分成两步：

获取所有服务名称

• 获取所有服务信息中的 API：List Services，该 API 是反对 Blocking Queries，就是依据申请头的 X-Consul-Index 字段值不同去拉取服务列表，只有服务列表呈现变动的时候才会扭转 X-Consul-Index 字段的值；

获取每个服务节点信息

• 依据第一步获取的服务列表进行遍历，把每个服务的 node 信息获取并记录到 table 中，对应 Consul API：List Nodes for Service，同时通过事件的形式实时更新，上面是简略的流程图：

这就是整个 Consul 服务发现插件的外部实际细节。

场景二：平安认证

在平安验证方面，咱们应用了对立认证和 HTTPS 重定向插件。在引入对立网关之前，每个业务都须要独自开发 Auth 相干内容，以爱护其数据接口的安全性。

在业务侧，每个业务零碎开发雷同的鉴权性能，一方面是开发成本绝对比拟高，另一方面各自业务零碎开发进去的性能品质不一，反复造轮子。所以景顺长城技术团队打算把对立认证性能放在网关上，同时解决后面提到的问题，极大进步了业务零碎的研发效率，让开发者更专一业务开发。

上图是 APISIX 动静治理 SSL 证书详情，景顺长城技术团队通过 Kubernetes 的 cert-manager 对立进行证书的颁发和治理。在对立网关之前，服务的 HTTPS 证书都是在 HA 端进行解析，当初对立放在 APISIX 中，并且 APISIX 反对动静加载 SSL 证书。

场景三：可观测性

原业务零碎在可观测性方面反对绝对较弱，因而团队心愿可能疾速接入 APISIX 提供的日志监控、Tracing 等多个插件。此外，团队还在调研并应用 Apache SkyWalking 进行链路追踪、Prometheus 进行监控、ELK 进行日志收集。对于网关层，只需进行简略的配置即可间接应用这些工具。

上图是景顺长城技术团队在生产上接入 SkyWalking 后的服务拓扑图，该图清晰地展现了服务之间的调用关系，包含通过网关的流量方向和成功率等要害信息。通过该拓扑图，团队能够疾速定位链路谬误点的地位。

场景四：流量管制

在流量管制的场景下，有基于灰度和基于权重这两种策略。

• 基于灰度策略的场景中，网关须要通过 HTTP 申请调用上游某个接口以获取特定的数据，并依据返回后果进行判断，以确定是否须要将申请发送到灰度环境。
• 基于权重策略的场景，虚拟机和容器的服务并行对外提供服务，例如将 90% 的流量命中虚拟机服务，10% 的流量命中云服务，以验证云服务的稳定性。目前，景顺长城的生产环境曾经配置了基于权重的灰度公布。

收益与瞻望

接入 APISIX 后，景顺长城的业务团队取得了以下收益：

1. 对立了 API 网关框架，升高了业务零碎开发的运维老本，目前生产环境曾经接入了大概 10% 的业务；
2. 在 DevOps 和流水线的联合方面，极大地提高了路由公布和服务公布的稳定性；
3. APISIX 的热更新能力大大降低了服务重启的压力。

最初，对于 APISIX 的将来高效稳固运行，景顺长城技术团队提出了以下三点冀望：

1. 监控告警方面，心愿 APISIX 可能不断完善路由可用性的高级配置，例如邮件告警、微信指标告警等。
2. APISIX 和 etcd 的稳固连贯方面，目前 APISIX 和 etcd 通过 HTTP 进行通信，但在 etcd v3 版本之后，API 协定曾经切换到了 gRPC 协定，因而心愿 APISIX 和 etcd 通过 gRPC 进行通信，以提高效率和稳定性，并防止通过 gRPC Gateway 进行转换。
3. 链路追踪方面，心愿通过 APISIX 网关接入实现服务的全链路追踪。

以上是景顺长城技术团队对于 APISIX 将来的冀望，感激浏览。

对于 API7.ai 与 APISIX

API7.ai（干流科技）是一家提供 API 解决和剖析的开源根底软件公司，于 2019 年开源了新一代云原生 API 网关 — APISIX 并捐献给 Apache 软件基金会。尔后，API7.ai 始终踊跃投入反对 Apache APISIX 的开发、保护和社区经营。与千万贡献者、使用者、支持者一起做出世界级的开源我的项目，是 API7.ai 致力的指标。