apisix 遇到的一些问题
内容提要
本文讨论了在使用 Apisix 网关过程中遇到的技术问题及解决方案，包括性能优化、架构重构、插件扩展性不足、Prometheus 性能问题、DNS 解析失败和路由匹配错误。通过重构代码、优化配置和引入新技术，提升了系统的稳定性和性能。
延伸解读
从自研网关到 APISIX 的权衡
文章回顾了团队从 Python 网关转向 Golang 自研网关，再于 2023 年接手基于 APISIX 的新版网关的过程。自研网关虽在性能上表现优异，但扩展性不足，Golang 插件开发成本高且生态缺乏。APISIX 提供了更丰富的插件生态，但迁移后也暴露出 DNS 解析、路由匹配、Prometheus 性能等一系列问题。这提醒读者，网关选型需在性能、扩展性和运维成本之间做权衡，没有一劳永逸的方案。
Prometheus 指标带来的性能陷阱
文章详细描述了 APISIX 中 Prometheus 插件可能引发的性能问题。使用 path 而非 matched_uri 作为标签会导致指标基数爆炸；默认的直方图 buckets 范围过大也会增加记录数；甚至特权进程处理 /healthz 时可能因指标过多打满 CPU 导致 Pod 被 kill。作者通过自定义 patch 关闭官方指标、调整 buckets 等方式缓解。这提示读者，监控指标的设计需谨慎，高基数标签和过大的 buckets 会显著影响性能。
路由匹配与 DNS 解析的稳定性风险
文章指出 APISIX 的 radixtree_uri_with_parameter 路由匹配并非严格最长路径优先，结果依赖路由加入顺序，可能导致请求被错误路由。此外，DNS 解析失败后，即使 DNS 服务恢复，APISIX 也可能无法自动恢复转发，需自行 patch 解析逻辑。这两个问题官方尚未修复，作者通过计算 priority 和切换 DNS 服务来规避。读者需注意这些边界情况，并在生产环境中做好监控和预案。
运维配置与发布中的注意事项
文章提到多个运维层面的坑：etcd 的 compaction 模式若为定时，可能导致 APISIX 全量拉取数据，引发 etcd 内存飙升，建议改为 revision 模式；发布时需支持平滑关闭，避免请求中断，同时注意 ipvs 和内核版本可能导致的流量残留；后端 keepalive 超时小于 APISIX 默认的 60s 可能引发偶发 502。这些经验提醒读者，网关的稳定运行不仅依赖代码，还需关注底层配置和发布流程。
Q&A
使用 Apisix 遇到的主要技术问题有哪些？
主要问题包括性能优化、架构重构、插件扩展性不足、Prometheus 性能问题、DNS 解析失败和路由匹配错误。
如何提升 Apisix 的性能？
通过重构代码、优化配置和引入新技术来提升系统的稳定性和性能。
在使用 Apisix 时，如何解决 DNS 解析失败的问题？
需要自行修复解析逻辑，并切换到更为稳定的 DNS 服务。
Prometheus 性能问题的主要原因是什么？
使用自定义指标导致性能下降，需要优化配置以解决该问题。
如何处理 Apisix 中的路由匹配错误？
通过计算优先级来解决最长路径匹配失败的问题。
在 Apisix 中如何优化管理端的性能？
通过定期重建 radixtree 而不是实时重建，避免整体服务性能抖动。
