插件
API7 企业版的插件扩展了其核心功能，以满足组织或用户在流量管理、可观测性、安全性、请求/响应转换、无服务计算等方面的特定需求。
API7 企业版提供了许多可以自定义和编排的插件，以满足你的各种需求。这些插件可以全局启用，作用于每个传入的请求；也可以局部绑定到其他对象上，例如路由（Routes）、服务（Services）或消费者（Consumers）。
如果现有的 API7 企业版插件无法满足你的需求，你还可以使用 Lua 或其他语言（如 Java、Python、Go 和 Wasm）编写自定义插件。
插件的执行生命周期
配置插件时，系统会根据定义的 JSON Schema 检查配置，以确保插件配置的结构和数据类型正确无误。
当请求经过 API7 企业版时，插件对应的方法会在以下一个或多个阶段中执行：rewrite、access、before_proxy、header_filter、body_filter 和 log。这些阶段很大程度上受到了 OpenResty 指令的影响。
要了解更多关于自定义插件开发阶段的信息，请参阅插件开发指南。
插件的执行顺序
通常情况下，插件按照以下顺序执行：
-
全局规则（Global Rules）中的插件
rewrite阶段的插件access阶段的插件
-
绑定到其他对象上的插件
rewrite阶段的插件access阶段的插件
在每个阶段内，你可以在插件的 _meta.priority 属性中定义一个新的优先级值，在执行期间，该值将优先于默认的插件优先级。具有较高优先级值的插件将首先执行。
插件的合并优先级
当一个插件同时在全局规则和局部对象（如路由）中配置时，这两个插件实例将按顺序依次执行。
但是，如果同一个插件在多个局部对象上进行了配置，则只会使用其中一份配置。在执行过程中，这些对象上配置的插件将按照特定的优先级顺序进行合并：
Consumer（消费者）> Route（路由）> Service（服务）
因此，如果一个插件在不同的对象中有不同的配置，系统将使用优先级最高的那个对象上的插件配置。
插件的执行过滤
默认情况下，所有插件都会被与路由中配置规则相匹配的传入请求触发。但有时，你可能需要对插件的执行进行更细粒度的控制。
API7 企业版允许通过将 _meta.filter 配置应用于插件，来动态控制插件的执行。该配置支持评估各种内置变量和 API7 企业版表达式。
插件的全局规则
插件全局规则（Global Rules）对象用于创建在每个传入请求上触发的插件。全局规则会在局部绑定到对象的其他插件之前执行。某些插件（如限流和可观测性插件）经常被全局启用，以提供对 API 的一致且全面的保护。
下图展示了如何全局启用 prometheus 插件以处理所有传入请求，并在特定路由上启用 proxy-rewrite 插件以修改请求的 HTTP 请求头。
这个例子展示了如何作为全局规则以及在路由上分别启用两个不同的插件。如果相同的插件同时配置在两个对象上，该插件将按顺序依次执行。
插件元数据
插件元数据（Plugin Metadata）用于配置所有共享相同插件名称的插件实例的公共元数据字段。当一个插件在多个对象中启用，并且需要统一更新它们的元数据字段时，这个功能非常有用。
下图说明了插件元数据的概念： namespace: api7
默认情况下，插件元数据对象上的 log_format 应该统一应用相同的日志格式到两个 syslog 插件。然而，由于 /order 路由上的 syslog 插件配置了不同的 log_format，因此发送到该路由的请求将生成由该路由中插件指定的 log_format 格式的日志。
如果一个插件字段同时定义在插件元数据和其他对象中，则该对象的定义优先级高于插件元数据中的定义。
插件元数据对象应该仅用于具有元数据字段的插件。有关哪些插件具有元数据字段的更多详细信息，请参阅插件文档。