2. 云原生网关基础：网关在微服务架构中的角色、常见云原生网关简介
2.1 网关在微服务架构中的核心角色
在微服务架构中，服务被拆分为多个独立的、可独立部署的单元。这种架构带来了灵活性，但也引入了新的挑战：客户端需要与多个服务交互、服务间通信复杂、安全与监控难以统一。云原生网关作为系统的统一入口，承担了以下关键角色：
- 流量入口与路由：所有外部请求首先到达网关，网关根据请求路径、Header、域名等规则将请求转发到对应的后端服务。
- 安全防护：在网关层统一实施认证（JWT/OAuth2）、授权、IP 白名单、限流、防 SQL 注入等安全策略，避免每个服务重复实现。
- 流量治理：实现请求级别的限流（Rate Limiting）、熔断（Circuit Breaking）、重试（Retry）、超时控制（Timeout），保障后端服务稳定性。
- 协议转换与适配：将外部 HTTP/HTTPS 请求转换为内部 gRPC、Dubbo 或 WebSocket 协议，或反向处理。
- 观测与审计：在网关层统一采集请求日志、延迟指标、错误率，为 SRE 和审计提供全局可观测性数据。
审计视角：网关是配置漂移审计的“第一道防线”。所有流量治理策略（如限流阈值、路由规则）都在网关层定义，一旦发生配置漂移，将直接影响后端服务的资源配额模型，导致过载或资源浪费。
2.2 常见云原生网关简介
当前主流的云原生网关包括 Kong、Apache APISIX 和 Envoy。它们在架构设计、性能、扩展性方面各有特点，但都支持动态配置、插件化扩展和丰富的流量治理能力。下表从审计视角对比三者核心差异：
| 特性维度 | Kong | Apache APISIX | Envoy |
|---|---|---|---|
| 架构模型 | 基于 Nginx + Lua（OpenResty） | 基于 Nginx + Lua（自研 core） | 自研 C++ 数据面，控制面独立 |
| 配置存储 | PostgreSQL / Cassandra | etcd / PostgreSQL / Redis | 通过 xDS API 从控制面获取 |
| 动态配置 | 支持（DB 变更触发 reload） | 支持（热加载，毫秒级生效） | 支持（xDS 流式推送） |
| 插件扩展 | Lua / Go（通过 PDK） | Lua / Go / Java / Python / Wasm | C++ / Lua / Wasm |
| 限流能力 | 计数器、滑动窗口、Redis 限流 | 计数器、滑动窗口、并发限流、自定义 | 全局/本地限流、令牌桶、速率限制过滤器 |
| 审计友好度 | DB 审计日志 + Admin API 变更记录 | etcd watch + 审计日志插件 | 访问日志 + xDS 版本追踪 |
| 社区活跃度 | 高（Kong Inc. 主导） | 高（Apache 基金会 + API7.ai） | 极高（CNCF 毕业项目） |
审计建议：在配置漂移审计场景中，APISIX 的 etcd watch 机制和 Envoy 的 xDS 版本追踪天然支持配置变更的实时监控；Kong 则需要额外配置 Admin API 的变更日志或使用审计插件。选择网关时，应优先考虑支持配置版本化与变更溯源能力的方案。
2.3 网关配置模型与资源配额的关系
云原生网关的配置模型通常包含以下核心对象，这些对象直接或间接影响后端服务的资源配额模型：
- Route（路由）：定义请求匹配规则（路径、方法、Host）和目标上游服务。路由的增删改会改变流量分布，影响后端服务的实际负载。
- Upstream（上游服务）：定义后端服务实例列表、负载均衡算法、健康检查策略。上游节点的增减会改变服务容量。
- Plugin（插件）：在路由或服务级别绑定限流、熔断、重试等策略。插件的参数（如限流阈值）直接构成资源配额模型。
- Consumer（消费者）：代表调用方身份，用于认证和差异化限流。消费者级别的配额管理是细粒度治理的基础。
2.4 从审计视角看网关配置漂移
配置漂移（Configuration Drift）是指网关的实际运行配置与预期基线配置之间产生偏差。在资源配额模型场景中，漂移可能表现为：
- 限流阈值被意外修改：运维人员手动调整了某个路由的限流 QPS，但未同步更新配额模型文档。
- 路由规则被覆盖：新部署的路由规则与旧规则冲突，导致流量被错误路由到不同上游服务。
- 插件参数不一致：同一服务在不同环境（开发/预发/生产）的限流插件参数不同，导致配额模型失效。
- 消费者配额被删除：某个消费者的限流配额被误删除，导致该消费者可以无限制访问后端服务。
审计风险提示：配置漂移是 SRE 事故的常见根因。在云原生网关中，由于配置变更频繁（CI/CD 自动部署、人工热修复、A/B 测试），漂移发生的概率远高于传统网关。建议建立配置基线版本管理、变更审批流程和定期审计机制。