Apache APISIX 是开源、云原生、高性能的 API 网关，相当于所有后端服务的统一大门。
用户请求先打到 APISIX，由它判断转发到哪个后端服务，同时做鉴权、限流、监控、灰度发布等，改配置不用重启网关，这是它最大亮点。
它是 Apache 基金会顶级项目，底层基于 Nginx+LuaJIT，用 etcd 存配置，支持 HTTP/HTTPS/gRPC/WebSocket/TCP/UDP，现在也可以作为 AI 网关管理大模型接口。
一、架构：控制平面 + 数据平面（重点，小白最容易懵）
- 数据平面（Data Plane）：干活的
就是 APISIX 网关节点，监听端口（默认9080HTTP，9443HTTPS），接收用户请求、路由匹配、执行插件、转发到后端服务。
所有流量在这里处理，性能很高，单核心可达约 18000QPS，增加延迟只有 0.2ms 左右。 - 控制平面（Control Plane）：管配置的
etcd：分布式配置仓库，保存路由、上游、插件全部配置；所有网关节点实时监听 etcd 变化，配置热更新，不需要重启 APISIX（Nginx 原生改配置需要 reload）- Admin API：接口，用来增删改查配置（curl / 脚本调用）
- Dashboard（可选）：图形化网页后台，点点鼠标配置，小白首选
简单比喻：
数据平面 = 门店前台接待客户；控制平面 = 后台办公室，修改规则，前台立刻生效，不用关门重启。
二、6 大核心概念（必须看懂）
| 名词 | 通俗解释 | 作用 |
|---|---|---|
| Route 路由 | 导航规则 | 匹配请求（域名、路径、请求方法），决定这个请求交给谁，绑定插件 |
| Upstream 上游 | 后端服务集群 | 真实业务服务器，可以多台机器，自带负载均衡、健康检查；路由转发目标 |
| Service 服务 | 公共配置模板 | 多个路由共用同一套上游 + 插件，避免重复写配置 |
| Consumer 消费者 | API 调用方 | 调用接口的用户 / 应用，配置 key、token 身份认证，做权限控制 |
| Plugin 插件 | 功能插件包 | 网关能力，开箱即用，100 + 插件：限流、密钥认证、日志、监控、CORS、WAF、灰度发布等 |
| SSL | 证书 | HTTPS 证书，绑定域名，APISIX 统一管理证书 |
一个请求完整流程（浏览器访问 https://api.xxx.com/user/list）
- 用户请求到达 APISIX（9443 端口）
- APISIX 匹配 SSL 证书，完成 HTTPS 解密
- Route 路由匹配：看域名 + 路径
/user/list匹配哪条路由 - 执行路由绑定的插件：比如验证 token、限流、记录访问日志
- 找到对应的Upstream 上游，通过负载均衡选一台健康后端服务器
- 转发请求给后端业务服务
- 后端返回结果，APISIX 再经过插件处理，返回给浏览器
✨核心亮点：所有配置修改，实时生效，不用重启网关。传统 Nginx 改配置需要 reload，流量会短暂抖动。
三、常用功能（日常会用到）
- 动态路由：按域名、URL、请求头、IP 匹配转发
- 负载均衡：轮询、加权轮询、IP 哈希，自带健康检查，自动剔除宕机后端
- 身份认证：key-auth、JWT、Basic Auth，没有凭证直接拒绝访问
- 限流熔断：限制单用户每秒请求数，防止后端被打崩；后端故障自动熔断
- 灰度 / 金丝雀发布：一小部分流量转发新版本服务，用来测试新版本
- 可观测：采集请求耗时、状态码，对接 Prometheus、SkyWalking、ELK 日志
- HTTPS 证书管理：动态上传、更新证书，不用改 Nginx 配置
- 协议转换：HTTP 转 gRPC，支持 WebSocket、Dubbo、MQTT 等协议
四、APISIX vs Nginx / Kong（小白怎么选）
- Nginx：静态 web 服务器，也能反向代理；缺点：配置文件静态，改配置必须 reload，复杂服务治理需要自己写大量脚本。
- Kong：老牌 API 网关，也是 Nginx+Lua；APISIX 优势：原生云原生、etcd 动态配置、国内社区活跃、插件丰富，性能更强。
- APISIX：专为微服务 API 管理设计，动态配置是核心优势，K8s 友好，适合 API 统一入口、微服务集群。
简单选型：
- 只是简单网站反向代理：Nginx 足够
- 大量 API 接口、微服务、频繁变更路由、灰度发布：优先 APISIX
五、快速上手：Docker 一键启动（小白推荐，不用装一堆依赖）
前提：装好 Docker + Docker Compose
# docker-compose.yml
version: "3.8"
services:
apisix:
image: apache/apisix:3.16.0
restart: always
volumes:
- ./apisix_conf:/usr/local/apisix/conf
ports:
- "9080:9080"
- "9180:9180" # Admin API端口
- "9443:9443"
depends_on:
- etcd
etcd:
image: bitnami/etcd:3.5
restart: always
environment:
ETCD_ADVERTISE_CLIENT_URLS: http://etcd:2379
ETCD_LISTEN_CLIENT_URLS: http://0.0.0.0:2379
ALLOW_NONE_AUTHENTICATION: yes
启动：
docker-compose up -d
- 网关访问地址：
http://127.0.0.1:9080 - Admin API：
http://127.0.0.1:9180/apisix/admin - Dashboard：单独部署，网页可视化管理
创建第一条路由示例（curl 命令）
把/get请求转发到httpbin.org测试服务：
curl -i "http://127.0.0.1:9180/apisix/admin/routes/1" -X PUT -d '
{
"uri": "/get",
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
}
}'
测试访问：
curl http://127.0.0.1:9080/get
能返回 json 就代表成功了。
六、适合什么场景 & 不适合场景
✅适合：
- 微服务项目，统一所有 API 入口
- 对外提供开放 API 平台，需要鉴权、限流
- 需要灰度发布、蓝绿发布
- K8s 集群作为 Ingress 网关
- AI 大模型接口统一管理（AI 网关）
❌不适合：
- 纯静态网站，简单反向代理（Nginx 足够，没必要多维护一套组件）
- 单机极小项目，没有多个后端服务
七、小白常见坑提醒
- Admin API 端口 9180：生产环境一定要加 IP 白名单，不能对公网开放，否则任何人都能篡改网关配置
- etcd 是核心：etcd 挂掉，APISIX 无法更新配置；生产 etcd 必须集群部署
- 插件是热加载，但部分插件参数修改要看插件文档，不是所有修改都完全无感知
- 不要把 APISIX 直接暴露公网，前面可以套一层 CDN/WAF
八、学习路线（小白循序渐进）
- Docker 本地跑 APISIX+Dashboard，网页上手动新建 Route、Upstream，直观感受转发
- 练习插件：key-auth 密钥认证、limit-req 限流
- 学习灰度发布、健康检查
- 接入监控 Prometheus 看指标
- 集群部署、K8s Ingress 使用