网关 vs 服务网格

概述

随着微服务架构的演化，网关从单体 API 网关发展到分布式网关，再到服务网格架构。本文对比主流网关和服务网格方案，帮助做出合理的选型决策。

技术演进路线

单体架构
  → Zuul 1.x（Servlet 阻塞模型）
    → Spring Cloud Gateway（WebFlux 非阻塞）
      → Kong/APISIX（独立网关 + 插件生态）
        → Istio 服务网格（Sidecar + 控制面）

一、方案对比矩阵

1.1 功能特性对比

特性	Spring Cloud Gateway	Zuul 1.x	Zuul 2.x	Kong	APISIX	Istio
模型	响应式 (WebFlux)	阻塞 (Servlet)	响应式 (Netty)	Nginx + Lua	Nginx + Lua	Envoy Sidecar
语言	Java	Java	Java	C/Lua	C/Lua	Go/C++
性能	高	低	高	高	极高	中
配置中心	Nacos/Consul/Eureka	Eureka	Eureka	数据库/Consul	etcd/APISIX Dashboard	K8s CRD
动态路由	✅	❌（需重启）	✅	✅	✅	✅
熔断	Resilience4j	Hystrix	Hystrix	插件	插件	超时重试
限流	Redis 令牌桶	手动	手动	计数器	计数器/Redis	无
灰度发布	权重/Header	手动	手动	插件	插件	流量镜像
mTLS	❌	❌	❌	✅	✅	✅（默认）
可观测性	Actuator	Actuator	Actuator	插件	插件	完整可观测
K8s 原生	❌	❌	❌	❌	✅	✅（K8s 核心）
性能损耗	5-10%	15-25%	5-10%	2-5%	1-3%	5-15%

1.2 Sidecar vs 网关架构

维度	Sidecar（Istio）	集中网关（Kong/APISIX）
部署方式	每个 Pod 附加代理	独立集群部署
流量路径	Pod → Sidecar → 目标 Pod	Pod → 网关 → 目标 Pod
配置管理	控制面下发（Push）	管理员配置（Pull）
运维复杂度	高	中
扩展性	自动随着 Pod 扩缩容	需手动扩缩容
排错难度	高（多一层)	中
适用团队	平台/基础设施团队	业务团队

二、Spring Cloud Gateway 详解

2.1 优势

Java 原生集成：与 Spring Boot / Spring Cloud 无缝集成
响应式非阻塞：基于 WebFlux，性能优于 Zuul 1.x
丰富的过滤器：内置 30+ 个过滤器工厂
声明式路由：配置简洁，支持 Java DSL

2.2 局限

仅限 Java 生态：非 Java 服务无法直接使用
单集群瓶颈：所有流量经过网关，需独立部署
无 mTLS：需要额外配置
运维成本：需自行管理部署、监控、扩缩容

2.3 适用场景

text

✅ 中小型微服务（< 50 个服务）
✅ 纯 Java 技术栈
✅ 需要深度定制过滤逻辑
✅ 已有 Spring Cloud 体系
❌ 多语言微服务架构
❌ 大规模 K8s 集群（> 100 服务）
❌ 需要内置 mTLS/零信任

三、Kong / APISIX 独立网关

3.1 共同特点

基于 Nginx + Lua：高性能，底层是成熟的 Nginx
插件生态：认证、限流、日志、缓存等开箱即用
独立部署：不绑定特定开发语言
管理界面：Kong Manager / APISIX Dashboard

3.2 Kong vs APISIX

特性	Kong	APISIX
性能	高	极高（延迟 < 1ms）
路由匹配	前缀/正则	前缀/正则 + 变量/权重
控制面	Kong Manager	APISIX Dashboard
配置存储	PostgreSQL/Cassandra	etcd
插件	50+（官方）	60+（官方）
热加载	✅	✅
K8s Ingress	Kong Ingress Controller	APISIX Ingress Controller
Apache 孵化	❌	✅

3.3 适用场景

text

✅ 多语言微服务（Java + Go + Python + Node.js）
✅ 需要高性能网关（APISIX < 1ms 延迟）
✅ 需要丰富插件（限流 + 认证 + WAF）
✅ K8s 原生 Ingress 替代
❌ 需要深度定制（Java 开发者不熟悉 Lua）

四、Istio 服务网格

4.1 核心架构

text

┌─────────────────────────────────────────────────┐
│                  Istio 控制面                     │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │  Pilot    │  │  Citadel  │  │  Galley  │       │
│  │ (路由)    │  │ (证书)    │  │ (配置)    │       │
│  └─────┬────┘  └────┬─────┘  └────┬─────┘       │
└────────┼─────────────┼─────────────┼────────────┘
         │             │             │
    ┌────▼────┐   ┌────▼────┐   ┌────▼────┐
    │ Envoy   │   │ Envoy   │   │ Envoy   │
    │ Sidecar │   │ Sidecar │   │ Sidecar │
    │ ServiceA│   │ ServiceB│   │ ServiceC│
    └─────────┘   └─────────┘   └─────────┘

4.2 Istio 核心功能

功能	说明	配置 CRD
流量路由	蓝绿/灰度/金丝雀	VirtualService + DestinationRule
弹性	超时、重试、熔断、限流	DestinationRule
安全	mTLS、RBAC、JWT 认证	PeerAuthentication + AuthorizationPolicy
可观测性	指标、追踪、日志	Telemetry
故障注入	延迟、异常注入	FaultInjection

4.3 Istio 路由示例

yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - match:                    # 灰度版本（V2 5% 流量）
        - headers:
            x-version:
              exact: v2
      route:
        - destination:
            host: order-service
            subset: v2
    - match:                    # 金丝雀（权重 5%）
        - weight: 5
      route:
        - destination:
            host: order-service
            subset: v2
        - destination:          # 95% 流量到 V1
            host: order-service
            subset: v1
            weight: 95
    - route:                    # 默认路由到 V1
        - destination:
            host: order-service
            subset: v1
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
  trafficPolicy:
    connectionPool:              # 连接池
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        http2MaxRequests: 1000
    outlierDetection:            # 熔断
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s

4.4 适用场景

text

✅ 大规模 K8s 集群（> 50 个服务）
✅ 多语言微服务
✅ 需要 mTLS + 零信任安全
✅ 平台团队支持
✅ 需要完善的流量管理
❌ 小团队（< 10 人）
❌ 简单微服务（< 20 个服务）
❌ 非 K8s 环境

五、功能边界与迁移路径

5.1 分层职责

层次	功能	谁负责
网关层	认证鉴权、限流、路由聚合、请求/响应转换	业务/中间件团队
Sidecar	服务发现、负载均衡、熔断、mTLS、遥测	基础设施团队
应用层	业务逻辑、数据校验、事务	业务团队

5.2 迁移路径

阶段 1：Spring Cloud Gateway（团队 < 20 人，服务 < 30）
  └─ 使用 Gateway + Nacos + Resilience4j

阶段 2：独立网关（团队 20-50 人，服务 30-100）
  └─ 引入 APISIX/Kong 作为统一入口
  └─ Gateway 降级为内部路由
  └─ 增加 API 管理平台

阶段 3：服务网格（团队 > 50 人，服务 > 100）
  └─ 引入 Istio 控制流量
  └─ APISIX 仅做入口网关（Ingress Gateway）
  └─ 内部使用 Sidecar 通信
  └─ 逐步从 Gateway 迁移到 VirtualService

六、选型决策树

text

团队是否有 K8s 运维能力？
├── 否 → 是否纯 Java 技术栈？
│   ├── 是 → Spring Cloud Gateway ✅
│   └── 否 → APISIX ✅
└── 是 → 服务数量？
    ├── < 50 → Spring Cloud Gateway + APISIX 入口 ✅
    ├── 50-100 → APISIX/Kong + 部分 Istio ✅
    └── > 100 → Istio + APISIX Ingress Gateway ✅

七、总结

维度	推荐方案
中小型 Java 项目	Spring Cloud Gateway
多语言/高性能	APISIX
大规模 K8s	Istio + APISIX
迁移路径	Gateway → APISIX → Istio
核心原则	网关层做业务横切，Sidecar 做基础设施

参考链接：
Istio 文档
Apache APISIX 文档
Kong 文档
Spring Cloud Gateway 文档

网关 vs 服务网格 ​

概述 ​

技术演进路线 ​

一、方案对比矩阵 ​

1.1 功能特性对比 ​

1.2 Sidecar vs 网关架构 ​

二、Spring Cloud Gateway 详解 ​

2.1 优势 ​

2.2 局限 ​

2.3 适用场景 ​

三、Kong / APISIX 独立网关 ​

3.1 共同特点 ​

3.2 Kong vs APISIX ​

3.3 适用场景 ​

四、Istio 服务网格 ​

4.1 核心架构 ​

4.2 Istio 核心功能 ​

4.3 Istio 路由示例 ​

4.4 适用场景 ​

五、功能边界与迁移路径 ​

5.1 分层职责 ​

5.2 迁移路径 ​

六、选型决策树 ​

七、总结 ​

网关 vs 服务网格

概述

技术演进路线

一、方案对比矩阵

1.1 功能特性对比

1.2 Sidecar vs 网关架构

二、Spring Cloud Gateway 详解

2.1 优势

2.2 局限

2.3 适用场景

三、Kong / APISIX 独立网关

3.1 共同特点

3.2 Kong vs APISIX

3.3 适用场景

四、Istio 服务网格

4.1 核心架构

4.2 Istio 核心功能

4.3 Istio 路由示例

4.4 适用场景

五、功能边界与迁移路径

5.1 分层职责

5.2 迁移路径

六、选型决策树

七、总结