基于 TiDB 的 Apache APISIX 高可用配置中心的最佳实践

项目背景

什么是 Apache APISIX？

API 网关作为微服务架构中的重要组件，是流量的核心出入口，用于统一处理和业务相关的请求，可有效解决海量请求、恶意访问等问题，保障业务安全性与稳定性。

作为开源的云原生 API 网关，Apache APISIX 兼具动态、实时、高性能三大优势，可提供负载均衡、动态上游、灰度发布、服务熔断、鉴权认证、可观测性等丰富的流量管理功能，帮助企业快速、安全地处理 API 和微服务流量，可应用于网关、Kubernetes Ingress 和服务网格等场景。

同时，Apache APISIX 已通过广泛的生态合作建立起丰富的社区生态。Apache APISIX 也支持高度定制化，支持 Wasm，可用 Java、Go、Python 等主流计算机语言编写插件。

Apache APISIX 技术架构

在这里插入图片描述

Apache APISIX 采用了数据平面与控制平面分离的架构方式，通过配置中心接收、下发配置，使得数据平面不会受到控制平面影响。

在此架构中，数据平面负责接收并处理调用方请求，使用 Lua 与 Nginx 动态控制请求流量，可用于管理 API 请求的全生命周期。控制平面则包含了 Manager API 和默认配置中心 etcd，可用于管理 API 网关。管理员在访问并操作控制台时，控制台将调用 Manager API 下发配置到 etcd，借助 etcd watch 机制，配置将在网关中实时生效。

配置中心默认为 etcd，也支持 Consul、Nacos、Eureka 等。etcd 天然支持分布式、高可用，支持集群，并且在 K8s 等领域有大量的应用实践，使得 APISIX 可以轻松支持毫秒级配置更新、支撑数千网关节点，且网关节点无状态，可任意扩缩容。

etcd 的局限性

1. 自身架构问题

首先，etcd 基于 BoltDB，容量具有上限 。etcd 的默认存储上限为 2 GB，如果上限要求超过 2 GB，则可以通过 --quota-backend-bytes 标记配置存储，最大可调整至 8 GB。一个 etcd 集群如果有 8 GB 的存储量，则足以服务一个网关，但如果同时服务 N 个 APISIX 集群，容量可能不够用，有可能会带来一些麻烦。

其次，etcd 本质上是一个 CP 系统，无法承载大量的客户端连接。