基于 Docker Compose 部署 Apache APISIX:全栈 API 网关实践

基于 Docker Compose 部署 Apache APISIX:全栈 API 网关实践

本文基于 APISIX 3.9.1 + Dashboard 3.0.1 + etcd 3.5.15 + Prometheus + Grafana 的生产级 Docker Compose 部署实践。


一、整体架构

本次部署采用 Docker Compose 编排五大组件,形成从配置管理到流量监控的完整闭环:

整体架构

组件 版本 作用 端口
APISIX 3.9.1-debian API 网关核心,路由转发、插件执行 9080/9443
Dashboard 3.0.1-alpine 可视化配置管理界面 9000
etcd 3.5.15 分布式配置存储,APISIX 的数据后端 2379
Prometheus v2.53.1 指标采集与存储 9090
Grafana 11.1.1 监控数据可视化 3000

所有组件运行在 Docker Bridge 网络 apisix 中,通过容器名互访,对外通过宿主机端口映射提供服务。


二、端口映射设计

采用 2xxxx 系列高位端口,避免与宿主机常用端口冲突:

端口映射

服务 功能 宿主机端口 容器端口
APISIX Admin API 29180 9180
APISIX HTTP 代理 29080 9080
APISIX Prometheus Metrics 29091 9091
APISIX HTTPS 代理 29443 9443
APISIX Control API 29092 9092
Dashboard 管理界面 29000 9000
etcd 客户端通信 22379 2379
Prometheus Web UI 29090 9090
Grafana 可视化面板 23000 3000

三、数据流分析

整个系统包含两条核心数据流:配置流监控流

配置与监控数据流

3.1 配置流

  1. Dashboardetcd:运维人员通过 Dashboard 创建路由、配置插件,数据写入 etcd
  2. etcdAPISIX:APISIX 通过 etcd watch 实时感知配置变更,无需重启即可生效

这种 etcd 驱动的配置模式是 APISIX 的核心设计优势 —— 配置热更新,零中断

3.2 监控流

  1. APISIXPrometheus:APISIX 内置 prometheus 插件,在 9091 端口暴露指标端点,Prometheus 以 5 秒间隔持续采集
  2. PrometheusGrafana:Grafana 以 Prometheus 作为数据源,通过预配置的 Dashboard 实现可视化

四、APISIX 核心配置

4.1 Admin API 双角色认证

APISIX 的 Admin API 定义了两个角色,各自持有独立 API Key:

Admin API 双角色认证

角色 权限 说明
admin 全量管理权限 可创建/修改/删除路由、插件、上游等所有资源
viewer 只读查看权限 仅可查看配置,不可修改
deployment:
  admin:
    allow_admin:
      - 0.0.0.0/0
    admin_key:
      - name: "admin"
        key: <admin-api-key>
        role: admin
      - name: "viewer"
        key: <viewer-api-key>
        role: viewer

生产环境中应将 allow_admin 限制为可信 IP 资段,而非 0.0.0.0/0

4.2 etcd 连接配置

deployment:
  etcd:
    host:
      - "http://etcd:2379"
    prefix: "/apisix"
    timeout: 30
  • host 使用 Docker 网络内的容器名 etcd,无需硬编码 IP
  • prefix: "/apisix" 是 APISIX 在 etcd 中的键前缀,与 Dashboard 配置一致
  • timeout: 30 秒,适应容器启动初期的网络延迟

4.3 Prometheus 插件配置

plugin_attr:
  prometheus:
    export_addr:
      ip: "0.0.0.0"
      port: 9091

指标端点绑定 0.0.0.0:9091,允许 Prometheus 从 Docker 网络内访问。指标路径为 /apisix/prometheus/metrics

4.4 Control API

apisix:
  enable_control: true
  control:
    ip: "0.0.0.0"
    port: 9092

Control API 用于 APISIX 自身健康检查与运行时信息查询,独立于 Admin API。


五、Dashboard 配置

5.1 访问控制

conf:
  allow_list:
    - 127.0.0.1
    - ::1
    - 0.0.0.0/0

allow_list 定义了 Dashboard Manager API 的 IP 白名单。当前配置允许所有访问,生产环境应收紧。

5.2 认证体系

Dashboard 认证体系

Dashboard 定义了两个登录账号:

用户名 角色 说明
admin 管理员 可管理所有配置
user 普通用户 受限操作权限
authentication:
  secret: <jwt-secret>
  expire_time: 3600
  users:
    - username: admin
      password: <admin-password>
    - username: user
      password: <user-password>

认证机制基于 JWT,Token 有效期 3600 秒(1 小时)。secret 字段强烈建议修改,默认值会在启动时被随机替换。

5.3 etcd 连接

conf:
  etcd:
    endpoints:
      - etcd:2379

与 APISIX 使用相同的 etcd 地址,确保配置读写一致性。

5.4 日志级别

conf:
  log:
    error_log:
      level: warn

日志级别设为 warn,平衡了信息量与性能开销,适合生产环境。


六、插件生态

Dashboard 配置中声明了完整的插件列表,涵盖六大核心类别:

核心插件分类

类别 代表插件 典型场景
认证鉴权 jwt-auth, basic-auth, key-auth, openid-connect, cas-auth API 身份验证、OAuth2 集成
限流熔断 limit-conn, limit-count, limit-req, api-breaker 流量控制、过载保护
可观测性 prometheus, skywalking, zipkin, opentelemetry 指标采集、分布式追踪
流量管控 traffic-split, proxy-mirror, proxy-rewrite, cors, gzip A/B 测试、灰度发布、跨域处理
安全防护 ip-restriction, uri-blocker, csrf, consumer-restriction IP 黑白名单、URL 过滤
日志记录 http-logger, kafka-logger, clickhouse-logger, syslog 请求日志收集、审计追踪

插件通过 etcd 配置动态加载,无需重启 APISIX 即可生效。


七、监控体系

7.1 Prometheus 采集配置

监控数据流水线

global:
  scrape_interval: 1s
  external_labels:
    stack: "apisix"

scrape_configs:
  - job_name: "prometheus"
    scrape_interval: 5s
    static_configs:
      - targets: ["localhost:9090"]
  - job_name: "apisix"
    scrape_interval: 5s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["apisix:9091"]

关键配置:

  • 全局默认采集间隔 1 秒,Prometheus 自身和 APISIX 各 5 秒
  • APISIX job 的 metrics_path 指定 /apisix/prometheus/metrics(APISIX 插件默认路径)
  • targets 使用 Docker 容器名 apisix,与 docker-compose 网络一致
  • external_labels.stack: "apisix" 为所有指标添加栈标签,便于多环境区分

7.2 Grafana 自动配置

Grafana 通过 provisioning 机制实现了 开箱即用

数据源自动配置:

datasources:
  - access: 'proxy'
    editable: true
    is_default: true
    name: 'apisix'
    org_id: 1
    type: 'prometheus'
    url: 'http://prometheus:9090'
    version: 1

数据源指向 Docker 内网的 Prometheus,Grafana 启动后即可直接查询 APISIX 指标。

Dashboard 自动加载:

providers:
  - name: 'default'
    orgId: 1
    folder: ''
    type: file
    options:
      path: /var/lib/grafana/dashboards

预置了 apisix-grafana-dashboard.json,启动后自动呈现 APISIX 专用监控面板,无需手动配置。

7.3 Grafana 安全配置

[security]
allow_embedding = true
content_security_policy = true

[auth.anonymous]
enabled = true
  • allow_embedding = true:允许 Dashboard 将 Grafana 面板嵌入 iframe
  • auth.anonymous.enabled = true:匿名访问,适合内部监控场景
  • CSP 中允许了内网 IP 段的 frame-src,支持 Dashboard 嵌入 Grafana 面板

八、etcd 配置要点

# etcd docker-compose 环境变量
ETCD_ENABLE_V2: "true"
ALLOW_NONE_AUTHENTICATION: "yes"
ETCD_ADVERTISE_CLIENT_URLS: "http://etcd:2379"
ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379"

关键配置:

  • ETCD_ENABLE_V2: "true":APISIX 依赖 etcd V2 API,必须启用
  • ALLOW_NONE_AUTHENTICATION: "yes":无认证模式,适合内网部署;生产环境应启用认证
  • advertise URL 使用容器名:确保 Docker 网络内客户端能正确发现 etcd
# etcd.conf.yml 关键参数
heartbeat-interval: 100
election-timeout: 1000
auto-compaction-mode: periodic
auto-compaction-retention: "1"
  • auto-compaction-mode: periodic + retention: "1":每小时自动压缩历史数据,防止 etcd 数据无限膨胀
  • strict-reconfig-check: false:放宽重新配置检查,简化单节点部署

九、部署流程

部署流程

步骤 1:配置文件准备

根据实际环境修改以下关键配置:

  • apisix_conf/config.yaml:Admin API Key、etcd 地址
  • dashboard_conf/config.yaml:登录密码、JWT Secret、allow_list
  • prometheus_conf/prometheus.yml:采集目标地址
  • grafana_conf/config/grafana.ini:CSP 域名白名单

步骤 2:启动服务

docker-compose up -d

验证所有容器状态:

docker-compose ps

步骤 3:访问 Dashboard

浏览器打开 http://<宿主机IP>:29000,使用 admin 账号登录。

步骤 4:配置路由与插件

在 Dashboard 中创建 Route、Upstream,并绑定所需插件(如限流、认证、日志等)。

步骤 5:监控可视化

浏览器打开 http://<宿主机IP>:23000,查看预配置的 APISIX 监控面板。


十、生产环境加固建议

配置项 当前值 建议值 原因
Admin API allow_admin 0.0.0.0/0 限制为可信 IP 资段 防止未授权访问
Dashboard allow_list 0.0.0.0/0 限制为运维网段 防止未授权访问
etcd 认证 无认证 启用密码认证 防止配置数据泄露
Dashboard JWT Secret 默认值 自定义强密码 防止 Token 伪造
Admin API Key 硬编码值 自定义强随机字符串 防止 API 被滥用
Grafana 匿名访问 enabled 按需关闭 仅允许认证用户查看监控
CSP frame-src 内网 IP 按需收紧 防止 XSS 嵌入攻击

十一、实践总结

要点 说明 核心收益
Docker Compose 编排 五组件一键部署 简化运维,环境一致性
高位端口映射 2xxxx 系列端口 避免端口冲突
etcd V2 API 必须启用 APISIX 依赖 V2 读写配置
Admin 双角色 admin + viewer 权限分离,安全可控
Prometheus 5s 采集 高频指标收集 实时感知流量异常
Grafana 开箱即用 预配置数据源 + Dashboard 零配置即可可视化
CSP 嵌入允许 Dashboard 嵌入 Grafana 统一运维入口
etcd 自动压缩 periodic 1h 防止数据膨胀
插件动态加载 etcd 驱动热更新 配置即时生效,零重启
全栈可观测性 Metrics + Tracing + Logging 全方位洞察网关状态

阅读更多

Skills系统:可扩展AI能力设计

Skills系统:可扩展AI能力设计

概述 Skills系统是AI-Native架构中的重要组件,它允许通过声明式配置扩展AI的能力。本文将介绍Skills系统的设计与实现,让大模型能够像人类专家一样具备特定领域的能力。 什么是Skills系统 概念 Skills(技能)是一种声明式的AI能力扩展机制,类似于人类的"专业技能": 与Function Calling的区别 特性 Skills Function Calling 目的 改变AI的"思维"方式 扩展AI的"工具"能力 实现 系统提示词注入 API调用 持久性 会话级别 单次调用 复杂度 简单(配置) 复杂(开发) 灵活性 高(声明式) 低(编程式) 系统设计 架构 SKILL.

By 菱角
插件化架构设计模式

插件化架构设计模式

概述 插件化架构是一种将核心功能与扩展功能分离的设计模式,允许系统在运行时动态加载和卸载功能模块。本文将介绍如何在微服务平台中设计和实现插件化架构。 为什么需要插件化 插件化优势 1. 模块化:功能独立,边界清晰 2. 可扩展:按需加载,动态增删 3. 隔离性:插件间互不干扰 4. 可维护:独立开发、测试、部署 5. 可定制:用户按需选择功能 核心设计 架构概览 核心组件实现 1. 插件接口定义 // core/plugin.interface.ts // 插件接口 export interface IPlugin { // 插件名称 readonly name: string // 插件版本 readonly version: string // 插件配置 getConfig(): PluginConfig // 插件清单

By 菱角
gRPC服务通信设计与实践

gRPC服务通信设计与实践

概述 在微服务架构中,服务间通信是关键环节。相比REST API,gRPC提供了更高的性能和更强的类型安全。本文将介绍如何在微服务平台中设计和实现gRPC服务通信。 为什么选择gRPC gRPC vs REST对比 特性 gRPC REST 协议 HTTP/2 HTTP/1.1 序列化 Protocol Buffers (二进制) JSON (文本) 性能 高(二进制+压缩) 中(文本开销) 类型安全 强(代码生成) 弱(运行时检查) 流式通信 原生支持(双向流) 需额外实现(SSE/WebSocket) 代码生成 自动生成 手动编写 浏览器支持 需gRPC-Web 原生支持 调试难度

By 菱角
多语言微服务架构:Node.js与Python协作

多语言微服务架构:Node.js与Python协作

概述 在微服务架构中,根据场景选择最适合的编程语言是最佳实践。本文将介绍如何在微服务平台中实现Node.js与Python的协作,发挥各自技术优势。 技术选型策略 为什么混合使用 服务划分 Node.js服务(7个) 服务 功能 选择Node.js的原因 llm.api 大模型服务 高并发SSE流式响应 ucenter.api 用户中心 RESTful API标准实践 doc.api 文件服务 流式上传下载处理 resource.api 资源管理 gRPC高性能通信 rag.api 知识库服务 MongoDB集成便利 statistic.api 统计分析 事件驱动架构 pptonline.api PPT服务 与前端技术栈统一 Python服务(1个) 服务 功能 选择Python的原因

By 菱角