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_plugin("access", plugins, api_ctx)
consu

本文详细介绍了如何扩展Apache APISIX,包括Rewrite与Access的处理,配置服务发现如Nacos,设定负载均衡策略,处理响应以及上报日志和监控参数。Apache APISIX作为高性能API网关,提供了丰富的功能,用户可以根据业务需求添加自定义代码,以实现更灵活的管理和服务控制。
最低0.47元/天 解锁文章
9916

被折叠的 条评论
为什么被折叠?



