在当今的云原生时代，企业级微服务架构往往面临着“既要又要”的挑战：既需要 Spring Cloud 生态带来的开发便利性和业务定制能力，又渴望 Istio 这样的 Service Mesh 带来的语言无关性、透明流量劫持以及强大的可观测性。
1. 引言
在微服务架构的演进过程中，流量管理一直是核心议题。传统上，我们习惯将南北向流量（North-South）的管理交给 API 网关（如 Spring Cloud Gateway, SCG），而将东西向流量（East-West）的治理交给服务发现与 RPC 框架（如 Eureka + Feign/Ribbon）。
然而，随着 Kubernetes 的普及和服务网格（Service Mesh）技术的成熟，Istio 逐渐成为基础设施层的标准。很多团队面临着一个架构抉择：是用 Istio Ingress Gateway 完全取代 Spring Cloud Gateway，还是两者共存？
对于拥有复杂业务逻辑（如复杂的鉴权、协议转换、报文聚合）的企业而言，Spring Cloud Gateway 的可编程性是 Envoy（Istio 的数据面）难以替代的。因此，“SCG 作为业务网关 + Istio 作为基础设施底座”成为了一种兼顾灵活性与先进性的架构模式。本文将探讨如何将两者深度整合，构建一个弹性、安全且可观测的微服务平台。
2. 核心概念与架构定位
在整合架构中，我们需要明确两者的职责边界，避免功能重叠导致的维护混乱。
2.1 职责划分
- Spring Cloud Gateway (业务网关)：
- 位置：处于集群边缘或服务网格的入口处。
- 职责：
- 认证与鉴权：处理 OAuth2、JWT 验证，对接企业 IAM 系统。
- 协议适配：HTTP/WebSocket 转换，甚至是对旧系统的协议桥接。
- BFF (Backend for Frontend)：响应聚合、裁剪。
- 业务路由：基于业务参数（非标准 Header）的复杂分流。
- Istio (基础设施层)：
- 位置：渗透在每个服务的 Sidecar（边车）中，包括 SCG 自身。
- 职责：
- 流量治理：金丝雀发布、蓝绿部署、流量镜像。
- 网络安全：服务间 mTLS 加密、基于角色的访问控制（RBAC）。
- 弹性能力：透明的重试、超时、断路器（无需修改业务代码）。
- 可观测性：统一的指标（Metrics）、链路追踪（Tracing）和日志。
2.2 部署架构
最推荐的整合模式是“网关入网”，即 Spring Cloud Gateway 本身也作为一个服务部署在网格内，注入 Envoy Sidecar。
