Service Mesh 与 API 网关的分工：流量入口治理的两个层次

Service Mesh 与 API 网关的分工流量入口治理的两个层次一、服务网格不是有 Ingress Gateway 吗为什么还要 API 网关这个问题是 Service Mesh 初学者最常见的困惑。Istio 有 Ingress Gateway、Envoy 能做 L7 路由——为什么还要在前面放一个 Kong/APISIX/Nginx答案是关注点分离Service Mesh 负责服务间通信东西向流量API 网关负责业务接入南北向流量。它们的治理层次不同、关注点不同、配置也应该分开管理。flowchart TD A[外部客户端] -- B[API 网关br/Kong/APISIX] B -- C{API 网关职责} C -- C1[认证鉴权 JWT/OAuth] C -- C2[限流/配额管理] C -- C3[API 版本路由] C -- C4[请求/响应转换] C -- C5[API 文档/Swagger] C -- C6[计费/分析] B -- D[Istio Ingress Gateway] D -- E{Service Mesh 职责} E -- E1[TLS/mTLS 终止] E -- E2[流量分割/灰度] E -- E3[超时/重试策略] E -- E4[熔断/故障注入] E -- E5[可观测性 span] D -- F[Service A] D -- G[Service B] F --|mTLS 东西向| G二、职责边界的清晰划分API 网关的职责业务层认证/鉴权JWT 验证、OAuth2 流程、API Key 管理流量控制基于用户/应用级别的限流和配额协议转换gRPC-Web → gRPC、SOAP → RESTAPI 管理版本路由、文档生成、开发者门户请求转换Header 注入/改写、请求/响应体的修改Service Mesh 的职责基础设施层传输安全自动 mTLS、证书轮换流量治理超时、重试、熔断、负载均衡可观测性分布式追踪 span 注入、指标暴露故障注入延迟注入、错误注入灰度发布金丝雀/蓝绿流量分割为什么不能合并关注点不同API 网关关注谁在调什么 APIMesh 关注服务间调用是否可靠运维团队不同API 网关由平台/API 团队管理Mesh 由基础设施/SRE 团队管理变更频率不同API 网关配置随业务频繁变更Mesh 配置变更频率低三、双层的生产配置# 第一层APISIX API 网关业务接入层 # APISIX Route 配置——面向业务 routes: - id: product-api-v1 uri: /api/v1/products/* upstream: type: roundrobin nodes: # 注意这里指向 Istio Ingress Gateway 的 Service # 而非直接连业务 Pod istio-ingressgateway.istio-system.svc.cluster.local:80: 1 plugins: # API 网关层次认证 jwt-auth: key: user_key secret: your-256-bit-secret # API 网关层次限流——基于用户维度 limit-count: count: 100 time_window: 60 key_type: var key: http_x_user_id rejected_code: 429 # API 网关层次请求转换——业务层面 proxy-rewrite: headers: set: X-API-Version: v1 X-Route-By: apisix-gateway - id: product-api-v2 uri: /api/v2/products/* upstream: type: roundrobin nodes: istio-ingressgateway.istio-system.svc.cluster.local:80: 1 plugins: jwt-auth: key: user_key secret: your-256-bit-secret proxy-rewrite: headers: set: X-API-Version: v2 # Istio 用这个 Header 做路由# 第二层Istio VirtualService流量治理层 apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: product-service namespace: production spec: hosts: - product-service http: # 基于 API 网关注入的 Header 做版本路由 # 这比基于 URL 路径更灵活——网关可以动态控制灰度策略 - match: - headers: X-API-Version: exact: v2 route: - destination: host: product-service subset: v2 weight: 10 # v2 10% 金丝雀流量 - destination: host: product-service subset: v1 weight: 90 # Istio 层次超时策略 timeout: 5s retries: attempts: 2 perTryTimeout: 3s retryOn: 5xx,reset # 主路由默认走 v1 - route: - destination: host: product-service subset: v1 timeout: 10s四、两层之间的协调机制Header 契约API 网关和 Service Mesh 之间通过 HTTP Header 传递路由信息。网关注入X-API-Version、X-Consumer-ID等Envoy 基于这些 Header 做路由决策。认证链用户 → API Key (APISIX 验证) → JWT Token (APISIX 签发) → Istio (通过 RequestAuthentication 验证 JWT) → Service (从 JWT 提取用户信息)可观测性两层都要有日志、指标和追踪。但维度不同API 网关关注API 使用量、消费者行为、计费Mesh 关注服务延迟、错误率、拓扑依赖五、总结API 网关处理谁可以调什么Service Mesh 处理调了之后是否可靠。两层职责互不重叠、各有专注。不要为了简化架构而合并——合并后的配置复杂度和故障域会爆炸。正确的做法是保持两层独立但建立清晰的 Header 契约、认证链和可观测性桥接。