Apache APISIX 扩展指南

Apache APISIX 提供了 50 多个插件、常用的几个负载均衡选择器，以及对主流服务发现（如 Nacos 和 DNS）的支持。API 网关和企业内部的业务紧密相关，为了满足企业的业务需求，用户通常需要在 Apache APISIX 的基础上添加一些代码，以实现业务所需的功能。如何拓展 Apache APISIX 成了许多用户的共同痛点：在保证 Apache APISIX 平稳运行的前提下，如何添加业务代码，满足实际需求？

本文提供了 Apache APISIX 的拓展指南，旨在为用户提供拓展 Apache APISIX 的一些思路。由于 Apache APISIX 处于高速发展阶段，版本迭代的频率比较高，所以本文会以 Apache APISIX 的首个 LTS 版本 v2.10.0 为基础进行说明。如果你使用的 Apache APISIX 版本低于 2.10.0，可能需要结合实际情况做一些变通。另外，虽然本文只讲解了 HTTP 相关的逻辑，但是 TCP 相关的部分，大体上也较为相似。

拓展方向1：Rewrite 还是 Access？

我们从请求的生命周期说起：当一个请求进入到 Apache APISIX 时，首先会由 http_access_phase 这个方法进行处理。熟悉 OpenResty phases 概念的读者可能会有些疑惑：OpenResty 一共有 6 个 phases，按照执行的先后顺序排列，分别是：rewrite、 access、 before_proxy、 header_filter、 body_filter 和 log，为什么一上来就是 access，rewrite 怎么不见了？

Apache APISIX 插件的 phases 概念和 OpenResty 的 phases 概念略有不同。为了提升 Apache APISIX 的性能，APISIX 插件的 rewrite 方法会在 OpenResty 的 access 阶段中运行。用户依然能够在插件层面自定义 rewrite 的逻辑，但是在代码层面，rewrite 实际上也是在 access 里面执行。

虽然说 rewrite 的逻辑和 access 的逻辑都在 access phase 里面运行，但是 rewrite 的逻辑还是会比 access 的逻辑先执行。为了避免后续插件执行 rewrite 失败后，没有继续执行 access，导致 trace 遗漏的问题，必须在rewrite 里面添加 trace 的逻辑。

除了执行的先后顺序外，rewrite 和 access 之间还有一个差别，就是它们之间有一个处理 consumer 的逻辑：

 plugin.run_plugin("rewrite", plugins, api_ctx)
        if api_ctx.consumer then
            ...
        end
        plugin.run_plugi