APISIX 面试题

15 道题

分类: Kubernetes
子分类: services-network
题目数: 15 道

已阅读 0 / 15 题

1 Apache APISIX 的整体架构由哪些核心组件构成？

答案：

APISIX 是一款基于 Nginx + Lua（OpenResty）构建的云原生 API 网关，核心由数据面（Data Plane）、控制面（Control Plane）和 etcd 组成。

数据面（APISIX Core）：基于 OpenResty + LuaJIT，运行实际流量代理；通过 apisix.lua 路由匹配、plugin.lua 插件链执行、balancer.lua 负载均衡，完成请求处理
控制面（Admin API + Dashboard）：通过 RESTful Admin API（默认 127.0.0.1:9180）下发/修改配置；Dashboard 提供可视化配置界面
配置中心（etcd）：存储所有路由、上游、插件、消费者配置；APISIX 通过 etcd v3 watch 监听变更，毫秒级热更新，无需 reload
服务发现（Service Discovery）：内置 Consul、Nacos、Eureka、Kubernetes、DNS 等发现器，自动同步服务节点
插件运行时（Plugin Runner）：Lua 插件直接运行在数据面；通过 plugin-runner 进程支持 Go/Java/Python/Node 多语言外部插件

数据流转：

Admin API/Dashboard → etcd (PUT/POST)
                     ↓ etcd watch
APISIX Core 拉取增量配置 → 内存路由表
                     ↓
外部请求 → Nginx → Lua Hook (路由/插件链) → Upstream

关键设计：

控制面与数据面分离：Dashboard 不直接接触 APISIX 节点，所有配置经 etcd 中转，天然支持多数据面节点
etcd watch + 全量内存：APISIX 节点在启动时全量同步 etcd 数据到内存，后续通过 watch 增量更新，路由匹配零磁盘 IO
Lua Hook 链：在 OpenResty 的 init_worker_by_lua、rewrite_by_lua、access_by_lua、log_by_lua 等阶段插入钩子，覆盖请求全生命周期

2 APISIX 的路由（Route）匹配机制是怎样的？

答案：

APISIX Route 通过 uri、uris、host、hosts、methods、priority 等字段定义匹配规则，按优先级匹配多条路由。

路由核心字段：

uri: "/api/v1/*"          # 单个 URI，支持 * 通配
uris:
  - "/api/v1/*"
  - "/api/v2/*"            # 多个 URI 数组
host: "api.example.com"    # 单 host
hosts:                     # 多 host
  - "api.example.com"
  - "*.example.com"
methods: ["GET", "POST"]   # HTTP 方法白名单
priority: 100              # 路由优先级，数值越大越优先
upstream_id: "upstream-1"  # 关联上游
plugins: {}                # 路由级插件

匹配规则：

路径匹配：uri 支持精确匹配（/api/v1/user）、前缀匹配（/api/v1/*）和通配符（/api/*/user）
域名匹配：host 精确匹配，*.example.com 子域名通配
优先级：所有路由按 priority 降序匹配（默认 0，数值越大越优先）；通过显式设置 priority 字段控制同 URI 多路由匹配顺序
变量提取：uri 中的命名变量（/user/{id}）可通过 Nginx 变量 $1、$2 在插件或上游中使用

完整路由示例：

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri": "/api/v1/*",
  "host": "api.example.com",
  "methods": ["GET", "POST"],
  "priority": 100,
  "vars": [
    ["http_user_agent", "==", "Mozilla"]
  ],
  "upstream": {
    "type": "roundrobin",
    "nodes": [
      {"host": "10.0.0.1", "port": 8080, "weight": 1},
      {"host": "10.0.0.2", "port": 8080, "weight": 2}
    ]
  }
}'

3 APISIX 的 Upstream（上游）与负载均衡策略

答案：

Upstream 定义后端服务节点集合及负载均衡规则，Route 通过 upstream_id 或内联 upstream 字段引用。

节点定义方式：

"upstream": {
  "type": "roundrobin",
  "nodes": [
    {"host": "10.0.0.1", "port": 8080, "weight": 1, "metadata": {"version": "v1"}},
    {"host": "10.0.0.2", "port": 8080, "weight": 2, "metadata": {"version": "v2"}}
  ],
  "retries": 3,
  "timeout": {
    "connect": 30,
    "send": 30,
    "read": 60
  },
  "checks": {
    "active": {
      "type": "http",
      "http_path": "/health",
      "interval": 5,
      "timeout": 2,
      "healthy": {"interval": 2, "successes": 2},
      "unhealthy": {"interval": 1, "http_failures": 2}
    }
  }
}

负载均衡策略：

类型	算法	适用场景
`roundrobin`	加权轮询	默认策略，后端性能相近
`chash`	一致性哈希（vars/header/cookie/key）	缓存亲和、灰度按用户路由
`ewma`	指数加权移动平均（延迟感知）	长连接、延迟敏感
`least_conn`	最少连接	长连接服务

主动健康检查：

type: http 周期性探测 /health；tcp 探测端口连通性
healthy.successes 连续成功 N 次标记为健康；unhealthy.http_failures 连续失败 N 次摘除
健康节点写入 balancer 内存，节点恢复后自动加入

4 APISIX 的插件体系（Plugin）是如何组织与执行的？

答案：

APISIX 插件是流量处理能力的核心扩展点，采用 Lua 编写、内置 100+ 插件（含 AI Gateway 系列），支持在 Route/Service/Upstream/Consumer 多层级挂载。

插件执行阶段（Lua Hook）：

rewrite phase:    serverless-pre-function（请求重写）
access phase:     limit-req, limit-conn, jwt-auth, key-auth, ip-restriction
header-filter:    cors, response-rewrite
log phase:        prometheus, http-logger, tcp-logger

插件挂载优先级（合并顺序）：

global_rule → Route plugin → Service plugin → Upstream plugin → Consumer plugin

同 key 字段后挂载者覆盖前者；不同 key 字段全部生效。

典型插件分类：

类别	插件	用途
限流	`limit-req`、`limit-conn`、`limit-count`	漏桶/连接级/计数限流
认证	`jwt-auth`、`key-auth`、`basic-auth`、`oauth2`、`openid-connect`	鉴权链
安全	`ip-restriction`、`referer-restriction`、`csrf`、`uri-blocker`	黑白名单
可观测性	`prometheus`、`skywalking`、`opentelemetry`、`zipkin`	指标/链路追踪
流量治理	`traffic-split`、`proxy-mirror`、`redirect`、`proxy-rewrite`	灰度/蓝绿/重定向
协议转换	`grpc-transcode`、`mqtt-proxy`、`dubbo-proxy`	协议互通
日志	`http-logger`、`tcp-logger`、`kafka-logger`、`rocketmq-logger`、`syslog`	异步落盘

插件热加载： APISIX 通过 apisix.plugin.init_worker() 在 worker 启动时加载所有启用插件；插件配置变更经 etcd watch 后通过 config_util 推送，Lua 内存结构原地更新，无需 reload。

5 APISIX 与 Kong 的核心差异是什么？

答案：

APISIX 与 Kong 均基于 OpenResty/Nginx，但架构、协议、数据存储上有本质差异。

维度	APISIX	Kong
数据存储	etcd（原生）	PostgreSQL（也支持 DB-less + DBLESS）
配置变更	etcd watch，毫秒级	DB 轮询（默认 5 秒）或 DBLESS 模式
多语言插件	plugin-runner：Go/Java/Python/Node	Go 进程（`go-pluginserver`），依赖 ABI 兼容
多协议	HTTP/HTTPS、gRPC、Dubbo、MQTT、UDP、TCP	主要 HTTP/HTTPS（gRPC 通过插件）
控制面	Admin API + Dashboard + Ingress Controller	Admin API + Kong Manager + Ingress Controller
路由变量	`uri` 支持 `{var}` 内联提取	需配合 `request-transformer`
部署模式	全开源	CE 社区版 + EE 企业版（含部分高级插件）
社区	Apache 顶级项目（2021），中国云厂商主导，AI Gateway 方向（2024+）持续扩展	Kong Inc. 商业公司主导
性能	LuaJIT 优化，QPS 较高（实测 23k+）	性能略低（Lua 调度开销）

架构对比：

APISIX:  Dashboard → etcd ← watch ← APISIX Core (LuaJIT)
                                            ↓
                                       Plugin Runner (Go/Java/...)
                                            ↓
                                          Upstream

Kong:    Kong Manager → PostgreSQL ← poll ← Kong Core (OpenResty)
                                            ↓
                                     Go Plugin Server
                                            ↓
                                          Upstream

选型建议：

APISIX 适用：云原生、etcd 已落地、需要多语言插件、gRPC/Dubbo 协议、高性能场景
Kong 适用：企业级付费支持、与 Kong Service Mesh 联动、已有 PostgreSQL 运维体系

6 APISIX Ingress Controller 的工作机制是什么？

答案：

APISIX Ingress Controller 通过 CRD 将 K8s Ingress/HTTPRoute/Gateway API 翻译成 APISIX 路由/上游资源，实现 Ingress 网关统一管理。

核心 CRD：

# ApisixRoute 自定义资源
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: product-api
spec:
  http:
  - name: rule-1
    match:
      paths:
      - /api/*
      hosts:
      - api.example.com
    backends:
    - serviceName: product-svc
      servicePort: 8080
      weight: 100
    plugins:
    - name: limit-req
      enable: true
      config:
        rate: 100
        burst: 200

Controller 同步流程：

K8s API Server (Ingress/CRD)
       ↓ watch
ApisixRoute Controller (Deployment)
       ↓ 翻译为 APISIX 资源（Route/Upstream/Service）
Admin API 写入 etcd
       ↓
APISIX Core 监听 etcd 变更
       ↓
内存路由表更新，新请求生效

支持的 K8s 资源类型：

Ingress（标准 + 自定义注解）
ApisixRoute、ApisixUpstream、ApisixTls、ApisixClusterConfig（APISIX 专属 CRD）
HTTPRoute、Gateway、GatewayClass（Gateway API）

高可用： Controller 本身无状态，可多副本部署；通过 LeaderElection（基于 K8s Lease）选主，避免 etcd 重复写入；APISIX Core 节点独立扩缩容，与 Controller 解耦。

7 APISIX 如何实现灰度发布与蓝绿部署？

答案：

APISIX 通过 traffic-split 插件和路由优先级实现灵活的灰度与蓝绿发布。

traffic-split 灰度（按权重）：

{
  "uri": "/api/*",
  "plugins": {
    "traffic-split": {
      "rules": [
        {
          "weighted_upstreams": [
            {"upstream": {"name": "api-v1", "type": "roundrobin", "nodes": [{"host": "10.0.0.1", "port": 8080}]}, "weight": 90},
            {"upstream": {"name": "api-v2", "type": "roundrobin", "nodes": [{"host": "10.0.0.2", "port": 8080}]}, "weight": 10}
          ]
        }
      ]
    }
  }
}

按 Header 灰度：

{
  "plugins": {
    "traffic-split": {
      "rules": [
        {
          "match": [{"vars": [["http_user_agent", "==", "Chrome"]]}],
          "weighted_upstreams": [
            {"upstream": {"name": "api-v2", "nodes": [{"host": "10.0.0.2", "port": 8080}]}, "weight": 100}
          ]
        },
        {
          "weighted_upstreams": [
            {"upstream": {"name": "api-v1", "nodes": [{"host": "10.0.0.1", "port": 8080}]}, "weight": 100}
          ]
        }
      ]
    }
  }
}

蓝绿部署（DNS/路由切换）：

旧版本: api-v1 (10.0.0.1)  ← 100% 流量
       ↓ 部署 api-v2 (10.0.0.2)
       ↓ traffic-split 渐进迁移 90/10 → 50/50 → 100% 切到 v2
       ↓ 保留 api-v1 上游可快速回滚
新版本: api-v2 (10.0.0.2)  ← 100% 流量

细粒度灰度：

按用户：vars: [["http_cookie", "==", "user=premium"]] 指定特定用户命中新版本
按地区：vars: [["http_x_forwarded_for", "==", "192.168.1.0/24"]] 按 IP 段分流
按版本号：vars: [["http_app_version", "==", "1.0.0"]] 按客户端版本路由

8 APISIX 如何与 Consul / Nacos 集成实现服务发现？

答案：

APISIX 内置 Consul/Nacos/Eureka/Kubernetes/DNS 发现器，Upstream 通过 discovery_type 字段自动同步服务节点。

Consul 集成：

# config.yaml
discovery:
  consul:
    hosts:
      - "http://10.0.0.100:8500"
    kv:
      prefix: "upstreams"

{
  "upstream": {
    "service_name": "product-service",
    "discovery_type": "consul",
    "type": "roundrobin",
    "checks": {
      "active": {"type": "http", "http_path": "/health", "interval": 5}
    }
  }
}

Nacos 集成：

# config.yaml
discovery:
  nacos:
    hosts:
      - "10.0.0.200:8848"
    namespace_id: "public"
    username: "nacos"
    password: "nacos"

{
  "upstream": {
    "service_name": "order-service",
    "discovery_type": "nacos",
    "type": "chash",
    "hash_on": "vars",
    "key": "remote_addr"
  }
}

服务发现机制：

Upstream 声明 service_name + discovery_type
        ↓
APISIX 启动 Nacos/Consul 长连接（默认每 5 秒）
        ↓
注册中心返回 healthy 实例列表
        ↓
内存 balancer 节点列表更新
        ↓
新增/下线实例自动从负载均衡池加入/摘除

健康检查联动：

注册中心标记不健康的实例，APISIX 直接跳过
APISIX 主动健康检查与注册中心状态合并判断（双重保险）
节点变更走 etcd watch 推送，毫秒级生效

9 APISIX 如何处理跨域（CORS）请求？

答案：

APISIX 通过 cors 插件快速启用 CORS，支持精细控制 origin/headers/methods/credentials。

基础 CORS 配置：

{
  "uri": "/api/*",
  "plugins": {
    "cors": {
      "allow_origins": "https://app.example.com",
      "allow_methods": "GET,POST,PUT,DELETE,OPTIONS",
      "allow_headers": "Content-Type,Authorization,X-Token",
      "expose_headers": "X-Trace-Id",
      "allow_credentials": true,
      "max_age": 3600
    }
  }
}

全域名放行（带凭据场景需谨慎）：

{
  "plugins": {
    "cors": {
      "allow_origins": "*",
      "allow_methods": "*",
      "allow_headers": "*",
      "expose_headers": "*",
      "allow_credentials": false,
      "max_age": 86400
    }
  }
}

OPTIONS 预检处理：

OPTIONS 预检请求
    ↓
APISIX cors 插件识别方法
    ↓
直接返回 204 + CORS 头（不转发上游）
    ↓
浏览器发送正式 GET/POST 请求
    ↓
APISIX 注入 cors 头 → 上游

注意事项：

allow_origins: * 与 allow_credentials: true 不能同时使用（违反 CORS 规范）
多个 origin 需要在 Nginx 侧做动态反射（map $http_origin $cors_origin），APISIX 通过 allow_origins: * + 后端 reflect 模式可绕过
复杂请求需在 expose_headers 暴露业务自定义响应头（如 X-Request-Id）

10 APISIX 的 Admin API 如何进行认证与权限控制？

答案：

APISIX Admin API 默认仅监听 127.0.0.1:9180（本地回环），生产环境通过 admin_key 与独立 control API 实现认证。

Admin Key 配置：

# config.yaml
deployment:
  admin:
    admin_key:
      - name: "admin"
        key: "edd1c9f034335f136f8787ad84b625c8f1"
        role: "admin"           # 完整权限
      - name: "viewer"
        key: "1234567890abcdef"
        role: "viewer"          # 只读
    allow_admin:
      - 127.0.0.0/24            # 仅允许本地
      - 10.0.0.0/8              # 或内网网段

角色权限：

角色	权限
`admin`	读写所有资源（routes、upstreams、plugins、consumers）
`viewer`	仅 GET 查询，不可修改
`metadata`	仅管理元数据（仅限元信息 API）

调用方式：

# 创建路由
curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
  -X PUT -d '{"uri":"/api/*","upstream":{"nodes":[{"host":"10.0.0.1","port":8080}]}}'

# 查询所有上游
curl http://127.0.0.1:9180/apisix/admin/upstreams \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'

生产安全加固：

外网隔离：Admin API 不对外暴露，仅内网运维跳板机访问
HTTPS + mTLS：通过 ssl 字段在 Admin API 上启用双向证书认证
审计日志：Admin API 写入审计到 syslog/kafka-logger，所有变更可追溯
最小权限：通过 RBAC 拆分 key，给运维/DevOps/开发分配不同角色

11 APISIX 的可观测性体系（Prometheus + SkyWalking + 日志）如何配置？

答案：

APISIX 通过 prometheus、skywalking、opentelemetry 插件暴露指标/链路，通过 http-logger/kafka-logger 异步落盘访问日志。

Prometheus 指标：

# 全局启用
plugins:
  - prometheus

# 暴露 /apisix/prometheus/metrics（默认 9091 端口）
curl http://127.0.0.1:9091/apisix/prometheus/metrics

核心指标：

指标	含义
`apisix_http_status`	HTTP 状态码分布（带 uri、code 标签）
`apisix_http_latency`	请求延迟（bandwidth 类型：0.005/0.01/…/10s）
`apisix_bandwidth`	流量字节数（in/out 区分）
`apisix_nginx_http_current_connections`	当前连接数
`apisix_upstream_status`	上游响应状态

SkyWalking / OpenTelemetry 链路追踪：

{
  "plugins": {
    "opentelemetry": {
      "tracer": {
        "endpoint": "http://otel-collector:4318/v1/traces"
      },
      "sampler": {
        "sampler_name": "parent_base",
        "params": {"rate": 1.0}
      },
      "additional_header_prefix": ["X-My-"]
    }
  }
}

访问日志（Kafka 异步落盘）：

{
  "plugins": {
    "kafka-logger": {
      "brokers": [
        {"host": "10.0.0.50", "port": 9092}
      ],
      "topic": "apisix-access-log",
      "key": "remote_addr",
      "batch_max_size": 1000,
      "max_retry_count": 3,
      "buffer_duration": 60,
      "log_format": {
        "host": "$host",
        "client_ip": "$remote_addr",
        "request_time": "$request_time",
        "upstream_time": "$upstream_response_time",
        "status": "$status"
      }
    }
  }
}

12 APISIX 在 Kubernetes 中如何实现外部服务暴露与 TLS 终止？

答案：

APISIX 通过 ApisixTls CRD 管理证书，在 Gateway 节点实现 TLS 终止，与 Upstream 通过 HTTP/2 后端通信。

证书管理（Secret 方式）：

# 1. 上传证书到 K8s Secret
apiVersion: v1
kind: Secret
metadata:
  name: example-tls
  namespace: ingress-apisix
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>
# 2. ApisixTls 自动同步（v2 是 Ingress Controller 1.5+ 稳定版，1.7 移除所有 v2beta）
apiVersion: apisix.apache.org/v2
kind: ApisixTls
metadata:
  name: example-tls
spec:
  hosts:
    - api.example.com
  secret:
    name: example-tls
    namespace: ingress-apisix

APISIX Pod 配置 HTTPS 监听：

# configmap apisix
apisix:
  ssl:
    enable: true
    listen:
      - port: 443
      - enable_http2: true

TLS 终止 + Upstream HTTPS 透传：

{
  "uri": "/api/*",
  "host": "api.example.com",
  "upstream": {
    "type": "roundrobin",
    "nodes": [{"host": "backend-svc", "port": 8443, "weight": 1}],
    "retries": 2,
    "timeout": {"connect": 5, "read": 30}
  }
}

外网暴露方式：

NodePort/LoadBalancer：Service type: LoadBalancer 暴露 80/443
HostNetwork：APISIX Pod 直接使用宿主机网络（牺牲端口隔离换性能，K8s 中需注意端口冲突；生产更常用 HostPort 或 type: LoadBalancer Service）
Ingress 对接：外层用云厂商 LB（ALB/CLB/NLB）→ APISIX Gateway Service

mTLS 双向认证：

{
  "ssl": {
    "cert": "<server-cert>",
    "key": "<server-key>",
    "client_ca": "<ca-cert>",
    "verify_client": true
  }
}

13 APISIX 在多集群/多 K8s 集群场景下如何部署？

答案：

APISIX 支持独立集群模式（共享 etcd）与多 K8s 集群模式（每集群独立 etcd，Ingress Controller 独立部署）。

模式一：共享 etcd（多 K8s 集群统一网关）

Cluster-A (K8s Service) ←─┐
                          ├─→ 共享 etcd Cluster → APISIX Gateway 集群
Cluster-B (K8s Service) ←─┘   (独立 etcd 集群)    (无状态，多副本)

APISIX 与 etcd 跨集群网络互通
Upstream service_name + discovery_type: kubernetes 跨集群发现
适合多区域统一 API 入口

模式二：独立 etcd（每集群自管）

Cluster-A: Ingress Controller-A + APISIX-A + etcd-A
Cluster-B: Ingress Controller-B + APISIX-B + etcd-B

每套集群独立部署 Helm chart
集群间通过全局 LB（GSLB/F5）做 DNS 级别流量调度
适合数据合规、跨区域容灾

模式三：APISIX Standalone（无 etcd）

# 配置文件方式启动
apisix:
  config_center: yaml
  admin:
    admin_key: ""
  standalone_config_path: "/usr/local/apisix/conf/apisix.yaml"

# /usr/local/apisix/conf/apisix.yaml
routes:
  - uri: /api/*
    upstream:
      nodes:
        - host: 10.0.0.1
          port: 8080

无 etcd 依赖，启动即用
配置变更需 reload（牺牲动态性换取简单性）
适合边缘网关、IoT、嵌入式场景

14 APISIX 在生产环境的典型故障排查与性能优化案例

答案：

生产环境常见问题集中在 etcd 同步、上游超时、插件链过长、内存泄漏四个方向。

案例一：etcd watch 中断导致路由不生效

现象：Admin API 创建路由后部分节点不生效
根因：etcd v3 watch 长连接被网络抖动打断，APISIX 节点未触发重连
排查：
  1. `tailf /usr/local/apisix/logs/error.log` 查 "etcd watch" 错误
  2. `curl http://127.0.0.1:9090/v1/healthcheck` 检查 etcd 状态（Control API 端口 9090，不是 Admin API 9180）
  3. 检查节点到 etcd 9443 端口连通性
解决：
  - 升级 APISIX ≥ 3.13（最新 LTS，Ingress Controller 2.0 配套要求）
  - 调整 etcd `election-timeout`、`heartbeat-interval`
  - 部署多 etcd 节点，APISIX 节点分散连接

案例二：上游响应慢导致 P99 延迟飙升

# 优化前：默认 60s read timeout 拖垮连接池
upstream:
  timeout:
    connect: 60s
    send: 60s
    read: 60s

# 优化后：分阶段超时 + 重试
upstream:
  timeout:
    connect: 1s
    send: 5s
    read: 10s
  retries: 2                    # 失败重试 2 次
  retry_timeout: 3s             # 重试总耗时上限
  checks:
    active:
      type: http
      http_path: /health
      interval: 2               # 缩短探活间隔
      unhealthy:
        http_failures: 2        # 快速摘除

性能优化清单：

LuaJIT 调优：lua_shared_dict 大小与 zone 数量，避免 worker 间 cache 抖动
插件精简：仅启用必要插件，禁用 serverless-pre-function 等重计算钩子
连接复用：upstream.keepalive_pool 启用 Upstream 连接池
HTTPS 硬件加速：ssl_protocols: TLSv1.2 TLSv1.3 + 启用 ssl_ecdh_curve 优化握手
日志异步化：kafka-logger/tcp-logger 替代 file-logger，避免磁盘 IO 阻塞 worker

案例三：插件链过长导致 QPS 下降

现象：路由挂载 jwt-auth + oauth2 + limit-req + prometheus + kafka-logger 后 QPS 减半
优化：拆分插件到不同 Route（认证路由 + 业务路由），减少单请求 Lua 钩子执行次数
监控：apisix_http_latency + apisix_nginx_http_current_connections 关联 worker CPU 使用率定位瓶颈

15 APISIX 的 mTLS、动态证书与 Zero-Trust 安全体系如何落地？

答案：

APISIX 通过 SSL 协议配置 + Secret 动态加载 + 外部证书管理器（cert-manager）集成，实现完整的 mTLS 与 Zero-Trust 网关层。

静态证书 + mTLS：

{
  "ssl": {
    "sni": "api.example.com",
    "cert": "<PEM 服务端证书>",
    "key": "<PEM 服务端私钥>",
    "client_ca": "<CA 证书，用于验证客户端>",
    "verify_client": true,
    "depth": 2,
    "protocols": ["TLSv1.2", "TLSv1.3"],
    "ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"
  }
}

动态证书（K8s Secret + ApisixTls + cert-manager）：

# 1. ClusterIssuer 自动签发
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-example-com
  namespace: ingress-apisix
spec:
  secretName: api-example-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
# 2. ApisixTls 自动同步 Secret → APISIX 内存
apiVersion: apisix.apache.org/v2
kind: ApisixTls
metadata:
  name: api-example-com
spec:
  hosts: [api.example.com]
  secret:
    name: api-example-com-tls
    namespace: ingress-apisix

Zero-Trust 落地链路：

客户端 → 携带 mTLS 客户端证书
    ↓
APISIX (verify_client=true) 验证证书合法性
    ↓
身份提取（证书 CN/SAN 提取为 consumer 字段）
    ↓
jwt-auth / oauth2 插件二次身份认证
    ↓
ip-restriction + referer-restriction 限制来源
    ↓
限流（limit-req）+ 风控（自定义插件）
    ↓
审计日志（kafka-logger 推送 SIEM）
    ↓
放行到后端 mTLS 服务

证书热更新机制：

ApisixTls Controller 监听 Secret 变更 → 调用 Admin API 更新 SSL 资源
etcd watch 推送至 APISIX 节点 → OpenResty ssl_certificate 内存指针替换（无 reload）
TLS 握手 0 中断（RSA/ECC 握手复用 session cache）

与 SPIFFE/Istio 联动：

APISIX 通过 ext-plugin-pre-req 调用外部 Go 插件解析 SPIFFE Workload Identity
与 Istio Service Mesh 互信：APISIX 信任 Mesh Root CA，验证 Pod 证书
实现"零信任"边界 + 服务网格细粒度鉴权双层防御