跳到主要内容

部署模式

你可以通过三种模式部署 APISIX：

传统模式​

在传统模式下，每个 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 可能无法满足生产环境在弹性和可用性方面的要求。

解耦模式​

在解耦模式下，APISIX 实例分为两个角色：数据面和控制面。数据面负责流经系统的实际数据，如请求和响应。控制面管理和编排整个系统，并设置数据面如何处理数据的规则和策略。

此示例显示了在解耦模式下将 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 会带来一些好处：

  • 提高可扩展性

    数据面和控制面的分离允许两个平面独立运行，而不相互依赖。这种独立性使数据面能够轻松扩展，而不会影响控制面。这种可扩展性确保网络架构可以无缝适应增长和增加的数据需求。

  • 提高安全性

    由于控制面和数据面是解耦的，一个平面的安全漏洞不会暴露给另一个平面。如果控制面脱机，数据面将使用其最后的配置运行。此外，解耦使得更容易为每个平面单独引入优化的安全机制。

  • 优化性能

    两个平面独立执行不同的功能。层的分离使每个平面能够专注于优化其特定任务。例如，控制面可以优先考虑高效的路由和决策。同时，数据面可以专注于快速有效的数据包转发和增强网络性能。

虽然解耦控制面和数据面提供了许多好处，但它也引入了一些挑战和缺点。

  • 增加延迟

    虽然解耦的平面彼此独立工作，但它们仍然需要相互通信以接收指令并执行任务。这可能会导致延迟增加，尤其是在分布式架构中，从而在通过网络传输数据包时引入延迟。

  • 增加复杂性

    解耦控制面和数据面还会增加额外的配置管理和开销。这需要大量的技能和专业知识来操作这两个独立的平面。寻找此类专业知识可能具有挑战性且成本高昂。

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

独立模式​

在独立模式下，APISIX 仅作为数据面运行。它可以在文件驱动模式下从 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 驱动模式是 APISIX 独立部署模式的最新补充。在此模式下，路由规则完全存储在内存中，而不是配置文件中。所有更新必须通过专用的独立 Admin API 执行。每次更新都会替换完整配置并通过热更新立即生效，无需重启网关。

警告

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

此示例显示了在 API 驱动的独立模式下部署 APISIX 的示例配置。它将 APISIX 角色设置为 traditional（以启动网关和 API 驱动的 Admin API 并使用 YAML 配置提供程序）：

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

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

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