跳到主要内容
版本：3.19.0

部署模式

部署模式决定配置管理是否与请求代理运行在同一实例中，以及 APISIX 如何接收配置。传统模式将这两个角色合并，解耦模式将它们分离，独立模式则在不依赖 etcd 的情况下运行：

传统模式​

在传统模式下，每个 APISIX 实例同时作为控制面和数据面运行。APISIX 配置存储在 etcd 中。APISIX 实例动态路由请求和响应，并与 etcd 交互以同步配置。

此示例显示了在传统模式下部署 APISIX 的示例配置：

config.yaml
apisix:
  node_listen:
    - port: 9080
deployment:
  role: traditional
  role_traditional:
    config_provider: etcd
  admin:
    admin_listen:
      port: 9180
    admin_key_required: true
    allow_admin:
      - 127.0.0.0/24
    admin_key:
      -
        name: admin
        key: ${{CUSTOM_API_WRITE_KEY}}
        role: admin
      -
        name: viewer
        key: ${{CUSTOM_API_VIEW_KEY}}
        role: viewer

在传统模式下运行 APISIX 是启动 APISIX 的最简单方法，可以减少额外的配置管理和开销。但是，也有一些缺点。由于数据面和控制面的职责没有分离，在传统模式下部署 APISIX 可能无法满足生产环境在弹性和可用性方面的要求。

解耦模式​

在解耦模式下，数据面实例代理客户端请求，控制面实例则管理数据面使用的配置。在下面使用 etcd 的部署中，控制面将配置写入 etcd，数据面从 etcd 接收更新。客户端请求不会经过控制面。

此示例显示了在解耦模式下将 APISIX 部署为数据面的示例配置：

config.yaml
deployment:
  role: data_plane
  role_data_plane:
    config_provider: etcd

此示例显示了在解耦模式下将 APISIX 部署为控制面的示例配置：

config.yaml
deployment:
  role: control_plane
  role_control_plane:
    config_provider: etcd
  admin:
    admin_key_required: true
    allow_admin:
      - 127.0.0.0/24
    admin_key:
      -
        name: admin
        key: ${{CUSTOM_API_WRITE_KEY}}
        role: admin
      -
        name: viewer
        key: ${{CUSTOM_API_VIEW_KEY}}
        role: viewer

在解耦模式下运行 APISIX 会带来一些好处：

  • 提高可扩展性

    通过分离角色，可以在请求流量增长时增加数据面实例，而无需增加控制面实例。配置仍通过 etcd 下发给数据面。

  • 提高安全性

    分离控制面和数据面实例后，可以将 Admin API 的访问与代理监听端口分开限制。但这并非完整的安全边界：被攻陷的控制面可以更改数据面通过 etcd 接收的配置。如果控制面离线，数据面会继续使用最后一份配置运行。

这种分离也会增加运维复杂度：你需要管理这两种角色及它们与 etcd 的连接。只有当数据面接收到新配置后，该配置才会生效。

有关如何在解耦模式下开始使用 APISIX 的详细信息，请参阅 使用 Docker 在解耦模式下安装 APISIX。

独立模式​

独立模式在不依赖 etcd 的情况下运行。在文件驱动模式下，APISIX 使用数据面角色，并从 apisix.yaml 加载配置。在 API 驱动模式下，APISIX 使用传统模式角色和 YAML 配置提供者，通过独立 Admin API 接收配置，并将配置存储在内存中。

文件驱动​

此示例显示了在文件驱动的独立模式下部署 APISIX 的示例配置：

config.yaml
apisix:
  enable_admin: false
deployment:
  role: data_plane
  role_data_plane:
    config_provider: yaml   # yaml or json

独立模式和声明式配置的结合有许多好处：

  • 降低复杂性

    你不需要安装和管理 etcd。在此模式下，所有 APISIX 配置都存储在节点的内存中。

  • 整合你的 APISIX 配置

    所有 APISIX 配置都保存在单一事实来源中，以减少错误的可能性，甚至简化配置管理。

有关如何在文件驱动的独立模式下开始使用 APISIX 的详细信息，请参阅 使用 Docker 在独立模式下安装 APISIX。

有关如何配置 APISIX 的详细信息，请参阅 文件驱动的独立配置。

API 驱动​

API 驱动模式将路由配置存储在内存中，而不是配置文件中。控制器通过专用的独立 Admin API 发送完整快照。工作进程无需重启网关即可加载已接受的更新，但接受更新和工作进程完成同步是两个不同的事件。有限时长的等待可以确认接收实例上的同步状态；在多实例部署中，控制器仍须向每个实例交付配置并分别验证。

警告

此功能专为 APISIX Ingress Controller 设计，主要用于与 ADC 集成。APISIX 提供官方的、端到端的、无状态的 Ingress Controller 实现。除非你完全了解其内部工作原理和行为，否则不要直接使用此功能。

以下示例使用 YAML 配置提供程序，同时启动网关和 API 驱动的 Admin API：

config.yaml
deployment:
  role: traditional
  role_traditional:
    config_provider: yaml

这将禁用基于本地文件的配置源，转而支持 API。当 APISIX 启动时，它等待通过 API 进行配置更新。

有关如何使用独立 Admin API 的详细信息，请参阅 API 驱动的独立配置。