Apache APISIX 扩展指南

本文介绍了如何扩展Apache APISIX,包括在Rewrite和Access阶段的逻辑处理,配置服务发现、负载均衡,响应处理以及上报日志和监控参数。Apache APISIX提供了丰富的插件和功能,允许用户根据业务需求进行定制,例如使用Nacos进行服务发现,自定义负载均衡策略,并在请求生命周期的不同阶段添加业务逻辑。
摘要由CSDN通过智能技术生成

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,按照执行的先后顺序排列,分别是:rewriteaccessbefore_proxyheader_filterbody_filterlog,为什么一上来就是 accessrewrite 怎么不见了?

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 的逻辑。

除了执行的先后顺序外,rewriteaccess之间还有一个差别,就是它们之间有一个处理 consumer 的逻辑:

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

consumer 代表一种身份。你可以针对不同的 consumer 进行权限控制,比如使用 consumer-restriction 这个插件实现基于角色的权限控制,也就是大家所说的 RBAC。另外,你也可以给不同的 consumer 设置对应的限流策略。

Apache APISIX 里面的鉴权插件(在插件定义里面有 type = "auth"),需要在 rewrite 阶段选好 consumer。这里我们用 key-auth 插件举个例子:

local _M = {
    vers
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值