中间件体系（Middleware Platform）
目标：为业务系统提供统一、稳定、高可用、可治理的基础运行能力
P0（运行基础）
├── 网关（Kong / APISIX）
├── 配置中心（Nacos）
├── RPC 平台（Dubbo）
├── 数据存储（MySQL / PostgreSQL / Mongo）
P1（解耦与性能）
├── MQ（Kafka / RabbitMQ）
├── 缓存平台（Redis / Memcached）
├── 搜索（Elasticsearch）
├── 文件存储（MinIO）
P2（治理与稳定）
├── 缓存失效监控 & 一致性
├── 任务调度（Airflow / XXLJob）
├── 中间件监控与告警
P3（平台化）
├── 中间件统一管控台
├── 多租户 / 资源隔离
├── 成本 & 容量管理
中间件体系的本质不是“技术选型”，而是“运行能力抽象”：
网关
下面我将以企业级平台视角，对 API 网关（Kong / Apache APISIX）做一次全面、可落地的系统性介绍。内容会覆盖定位、核心能力、架构机制、Kong vs APISIX 对比、平台化设计、典型场景、治理模型，而不是停留在工具层。
一、什么是 API 网关（Gateway）
API 网关是所有 南北向流量（Client → 服务） 的统一入口层，承担：
流量接入、协议适配、安全控制、流量治理、可观测性
在现代架构中，网关已经从：
“一个反向代理” 升级为 “流量治理与安全控制中枢”
二、网关在整体技术架构中的位置
Client（Web / App / IoT / Partner）
│
├── CDN / WAF（可选）
│
├── API Gateway（Kong / APISIX）
│ ├── 鉴权
│ ├── 限流
│ ├── 路由
│ ├── 协议转换
│ ├── 灰度
│
├── Service Mesh / RPC / HTTP
│
└── 后端微服务
网关解决 “进来之前的事”，Mesh 解决 “服务之间的事”。
三、网关的核心职责拆解
1️⃣ 流量接入与路由（Traffic Routing）
能力
- Path / Host / Header 路由
- 动态路由
- 重写（URI / Header）
- 多后端负载均衡
企业价值
- 屏蔽后端服务变化
- 对外提供稳定 API Contract
2️⃣ 认证与鉴权（AuthN / AuthZ）
常见方式
- API Key
- JWT
- OAuth2 / OIDC
- HMAC
- mTLS
企业级能力
- 与 IAM / SSO 打通
- 应用级 / 租户级鉴权
- Token 透传与转换
- 细粒度 API 权限控制
3️⃣ 流量治理（Traffic Governance）
核心能力
- 限流（QPS / 并发）
- 熔断
- 超时
- 重试
- 降级
典型场景
- 防止流量突刺
- 保护核心系统
- 黑产 / 爬虫防护
4️⃣ 灰度发布 & 流量调度
能力
- 按比例灰度
- 按 Header / 用户标签
- Canary / A/B Test
企业价值
- 风险可控上线
- 快速回滚
5️⃣ 协议与数据转换
支持
- HTTP ↔ HTTPS
- REST ↔ gRPC
- WebSocket
- GraphQL（部分支持）
6️⃣ 可观测性（Observability）
指标
- QPS / RT
- 错误率
- 限流命中率
日志
- Access Log
- 安全审计日志
Tracing
- TraceID 注入
- 调用链透传
四、Kong 与 APISIX 的核心架构差异
| 维度 | Kong | APISIX |
|---|---|---|
| 内核 | Nginx + Lua | OpenResty + LuaJIT |
| 配置中心 | PostgreSQL / DB-less | Etcd（强一致） |
| 动态配置 | 较慢（依赖 DB） | 毫秒级热更新 |
| 性能 | 高 | 更高（事件驱动） |
| 插件体系 | 成熟、商业化强 | 开源活跃、可定制 |
| 多协议 | HTTP / gRPC | HTTP / gRPC / TCP / MQTT |
| 云原生 | 良好 | 原生云原生友好 |
结论一句话：
- Kong：成熟稳健、生态与商业支持强
- APISIX：性能优先、动态性强、平台化更友好
五、插件机制（网关的“灵魂”）
插件执行链（简化）
Client Request
│
├── Auth Plugin
├── Rate Limit Plugin
├── WAF Plugin
├── Rewrite Plugin
│
└── Upstream
插件类型
- 安全类：Auth、IP 黑白名单
- 治理类：限流、熔断
- 流量类：灰度、镜像
- 可观测类：日志、Tracing
网关平台能力 ≈ 插件治理能力
六、企业级网关平台应该“多做的事”
1️⃣ 网关 ≠ 控制台
企业一定要在 Kong / APISIX 之上，构建 网关平台：
网关平台
├── API 管理
│ ├── 创建 / 发布 / 下线
│ ├── 版本管理
│
├── 应用 & 租户管理
│
├── 权限模型（RBAC）
│
├── 策略中心
│ ├── 限流
│ ├── 灰度
│ ├── 安全
│
├── 监控 & 告警
└── 审计
2️⃣ API 生命周期管理（非常关键）
| 阶段 | 能力 |
|---|---|
| 设计 | API 规范 / Mock |
| 发布 | 灰度 / 校验 |
| 运行 | 监控 / 限流 |
| 退役 | 下线通知 |
3️⃣ 多租户与隔离
- Namespace 隔离
- Rate Limit 隔离
- 独立证书 / Token
七、典型企业使用场景
场景 1：对外 OpenAPI
- 应用级 Token
- 强限流
- 审计日志
场景 2：内部 BFF
- 用户态鉴权
- 精细化路由
- 灰度发布
场景 3：安全防护
- 防刷
- IP 信誉
- 行为分析（联动风控）
八、与 Service Mesh 的边界划分
| 能力 | 网关 | Mesh |
|---|---|---|
| 客户端接入 | ✅ | ❌ |
| API 管理 | ✅ | ❌ |
| 服务间流量 | ❌ | ✅ |
| mTLS | 部分 | ✅ |
| 灰度 | 简单 | 复杂 |
网关管“入口”，Mesh 管“内部”。
九、落地建议（非常实用）
选型建议
- 高并发 + 动态规则多 → APISIX
- 生态 / 商业支持 → Kong
建设顺序
- 先“入口统一”
- 再“安全 & 限流”
- 然后“灰度 & 治理”
- 最后“API 资产化”
