apisix~14在自定义插件中调用proxy_rewrite

简介: 在 Apache APISIX 中,通过 proxy-rewrite 插件来修改上游配置时,需要确保插件的执行顺序和上下文环境正确。你提到在自己的插件中调用 proxy_rewrite.rewrite({host="new_upstream"}, ctx),但新上游没有生效,这可能是由于以下几个原因:1. 插件执行顺序:确保你的自定义插件在 proxy-rewrite 插件之后执行,proxy-rewrite.priority是1008。

在 Apache APISIX 中,通过 proxy-rewrite 插件来修改上游配置时,需要确保插件的执行顺序和上下文环境正确。你提到在自己的插件中调用 proxy_rewrite.rewrite({host="new_upstream"}, ctx),但新上游没有生效,这可能是由于以下几个原因:

  1. 插件执行顺序:确保你的自定义插件在 proxy-rewrite 插件之后执行,proxy-rewrite.priority是1008。
  2. 上下文环境:确保在正确的阶段(如 rewrite 阶段)进行上游修改。

下面是一个示例,展示如何在自定义插件中调用 proxy-rewrite 插件并修改上游配置。

自定义插件示例

假设你的插件名为 my-plugin,我们需要在 rewrite 阶段调用 proxy-rewrite 插件来修改上游。

local core = require("apisix.core")
local proxy_rewrite = require("apisix.plugins.proxy-rewrite")
local plugin_name = "my-plugin"
local _M = {
    version = 0.1,
    priority = 1000, -- 设置插件的优先级,值超大,优先级越高,越先执行
    name = plugin_name,
}
-- 定义插件的 schema
_M.schema = {
    type = "object",
    properties = {
        new_host = {type = "string"}
    },
    required = {"new_host"}
}
function _M.check_schema(conf)
    return core.schema.check(_M.schema, conf)
end
function _M.rewrite(conf, ctx)
    local rewrite_conf = {
        host = conf.new_host
    }
    -- 调用 proxy-rewrite 插件的 rewrite 方法
    proxy_rewrite.rewrite(rewrite_conf, ctx)
    core.log.info("Upstream host rewritten to: ", conf.new_host)
end
return _M

使用示例

在配置文件中启用并配置该插件:

{
    "plugins": {
        "my-plugin": {
            "new_host": "new_upstream"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    }
}

注意事项

  1. 插件优先级:确保你的插件优先级低于proxy_rewrite,你插件的priority要小于1008
  2. 插件依赖:确保 proxy_rewrite 插件已加载,并且可以被调用。
  3. 日志检查:通过 APISIX 日志检查插件是否正确执行,并输出相关调试信息。

通过以上方法,你应该能够在自定义插件中调用 proxy-rewrite 插件,并成功修改上游配置。如果问题仍然存在,请检查 APISIX 的错误日志以获取更多信息。

相关文章
|
负载均衡 算法 数据安全/隐私保护
|
资源调度 监控 API
开源API网关APISIX分析与使用
开源API网关APISIX分析与使用
1556 0
|
负载均衡 应用服务中间件 API
Nginx、Kong、Apisix、Gateway网关比较
Nginx、Kong、Apisix、Gateway网关比较
5683 1
Nginx、Kong、Apisix、Gateway网关比较
|
JSON 缓存 应用服务中间件
开源API网关APISIX源码分析(一)
开源API网关APISIX源码分析
628 0
|
Linux Perl
Centos8 yum源配置方法
本文介绍了Centos8 版本中yum的配置
11906 30
Centos8 yum源配置方法
|
存储 负载均衡 Kubernetes
Openresty动态更新(无reload)TCP Upstream的原理和实现
本文介绍了对Openresty或Nginx的TCP Upstream的动态更新(无需Reload)的一种实现方式,这种实现对于正在尝试做Nginx扩展的开发者是一种参考。文中我们对nginx结合lua对一次请求的处理流程和可扩展方式也进行了说明,重要的是给出了实际代码帮助开发者理解。目前社区中比如Kong、nginx-ingress-controller等基于Nginx扩展的项目都是类似的思路。
12165 1
Openresty动态更新(无reload)TCP Upstream的原理和实现
|
10月前
|
人工智能 Java API
MCP客户端调用看这一篇就够了(Java版)
本文详细介绍了MCP(Model Context Protocol)客户端的开发方法,包括在没有MCP时的痛点、MCP的作用以及如何通过Spring-AI框架和原生SDK调用MCP服务。文章首先分析了MCP协议的必要性,接着分别讲解了Spring-AI框架和自研SDK的使用方式,涵盖配置LLM接口、工具注入、动态封装工具等步骤,并提供了代码示例。此外,还记录了开发过程中遇到的问题及解决办法,如版本冲突、服务连接超时等。最后,文章探讨了框架与原生SDK的选择,认为框架适合快速构建应用,而原生SDK更适合平台级开发,强调了两者结合使用的价值。
12947 33
MCP客户端调用看这一篇就够了(Java版)
|
12月前
|
人工智能 自然语言处理 Java
对话即服务:Spring Boot整合MCP让你的CRUD系统秒变AI助手
本文介绍了如何通过Model Context Protocol (MCP) 协议将传统Spring Boot服务改造为支持AI交互的智能系统。MCP作为“万能适配器”,让AI以统一方式与多种服务和数据源交互,降低开发复杂度。文章以图书管理服务为例,详细说明了引入依赖、配置MCP服务器、改造服务方法(注解方式或函数Bean方式)及接口测试的全流程。最终实现用户通过自然语言查询数据库的功能,展示了MCP在简化AI集成、提升系统易用性方面的价值。未来,“对话即服务”有望成为主流开发范式。
8506 7
|
JSON 应用服务中间件 API
【干货】将参数传递给 Apache APISIX 的五种方式
【干货】将参数传递给 Apache APISIX 的五种方式
488 0

热门文章

最新文章