Apache APISIX应对数万高频变更upstream的问题及最佳实践问询

默认实现存在的核心问题 #

• 全量配置同步开销过高：默认架构下etcd存储全量路由、upstream配置，数万upstream规模下，任意一次配置变更都会触发所有APISIX节点拉取全量配置快照。变更频率高时会产生大量冗余网络传输，etcd集群压力陡增，甚至出现配置同步延迟、节点间配置不一致的问题。
• 内存占用与GC压力陡增：每个upstream实体、关联的健康检查器、负载均衡状态计数器都会常驻所有Worker进程内存，数万upstream量级下单Worker内存占用会飙升至数GB级别，同时Lua VM的GC压力大幅上涨，会出现周期性的请求延迟毛刺。
• 健康检查资源开销失控：默认主动健康检查会为每个upstream维持独立的探测协程和连接池，数万upstream场景下每秒产生的探测请求可达十万级，很容易打满节点内网带宽，协程调度开销也会挤占正常业务请求的CPU资源，导致请求延迟上涨。
• 路由匹配性能下降：如果upstream直接绑定路由规则，数万级upstream关联的路由条目会拉长路由匹配的遍历链路，高QPS场景下路由匹配耗时会出现明显上涨。
• 配置变更生效粒度过粗：默认配置更新是按配置类别全量刷新，哪怕只变更1个upstream的单个节点信息，也会触发对应Worker进程所有同类别配置的重新加载，变更高峰时会出现频繁的配置刷新抖动。

对应问题的解决路径 #

• 配置分层拆分，缩小同步范围：将高频变更的upstream节点信息，和低频变更的路由、插件配置拆分存储，路由层只绑定upstream的逻辑标识，不直接绑定固定节点列表，节点信息的变更不需要触发全量路由配置同步。
• 轻量化upstream实体设计：关闭非必要的upstream级独立计数器、独立负载均衡状态缓存，复用通用的负载均衡计算逻辑，压缩单upstream的内存占用。
• 健康检查能力下沉：将单APISIX节点独立执行的主动健康检查，替换为集中式探测集群统一完成节点状态探测，APISIX节点只需要订阅最终探测结果，不需要自行发起探测请求，大幅降低节点侧的探测开销。
• 增量同步替代全量同步：改造配置同步链路，基于etcd的watch机制只接收变更的增量upstream数据，本地直接更新内存缓存，替代原有定时拉取全量配置快照的逻辑，降低配置同步的网络和计算开销。
• upstream按需加载与卸载：不提前将所有upstream加载到内存，请求匹配到对应逻辑upstream时再拉取对应节点信息完成初始化，长时间无请求的冷upstream自动从内存中卸载，降低常驻内存占用。

场景适配最佳实践 #

• 优先对接服务发现实现动态upstream：不要将数万upstream的节点列表静态写入APISIX的etcd配置中心，对接内部服务发现组件，通过APISIX的服务发现插件按需拉取对应服务的节点列表，节点变更通过订阅机制增量更新，完全绕开全量配置同步流程。
• 优化健康检查配置：非核心业务upstream关闭主动健康检查，改用被动健康检查；必须开启主动健康检查的场景，适当调大探测间隔、降低单次探测超时阈值，合并同后端节点不同upstream的探测任务，减少无效探测请求量。
• 开启upstream资源复用：对后端节点列表重合度高的upstream，配置upstream模板复用负载均衡实例和健康检查状态，避免重复创建相同的内存对象。
• 隔离控制面与数据面流量：配置同步、服务发现拉取的控制面流量，和业务请求的数据面流量走不同网卡、不同网络队列，避免配置同步高峰时挤占业务请求的带宽资源。
• 针对性调优Worker运行参数：根据upstream总规模调大单个Worker的Lua VM内存上限，调整GC参数缩小渐进式GC的步长，避免一次性GC导致的长暂停；单节点部署的Worker数量不超过CPU物理核数，减少多Worker间upstream状态同步的额外开销。
• 变更请求削峰聚合：高频率的upstream变更不要实时推送给所有APISIX节点，做本地变更聚合，比如将1s内的多次upstream变更合并为一次批量更新，减少配置刷新的次数。

内容的提问来源于stack exchange，提问作者hanzhenfang