1、英文名 / 缩写：
Service Mesh（缩写 SM），别名：服务网格、Service Mesh
2、标准定义：
Service Mesh（服务网格）是处理服务间通信（east-west 流量）的基础设施层，通常以 Sidecar 代理模式与应用容器一同部署，将流量管理、安全、可观测性、策略等横切关注点从业务代码中剥离到统一的代理层。其核心思想是：用基础设施接管网络，让业务代码专注业务逻辑；CNCF 将其定义为云原生技术栈的关键拼图，Istio 与 Linkerd 是两个事实标杆项目。
3、核心信息卡：
· 中文名：服务网格
· 英文名：Service Mesh
· 缩写：SM
· 别名：服务网格、Service Mesh
· 提出者：概念由 Linkerd 创始人 William Morgan 等于 2016-2017 年提出并推广；CNCF 推动生态成熟
· 提出时间：2016-2017 年
· 所属类别：云原生 > 网络与通信 > 微服务基础设施
· 核心技术：Sidecar 代理（如 Envoy）、控制面（Istiod / Linkerd Control Plane）、mTLS、流量管理
· 主要应用：Kubernetes 上的微服务治理、多语言微服务流量管理、零信任网络、可观测性
4、工作原理：
1. 注入 Sidecar：在每个业务 Pod 中注入一个代理（如 Envoy），所有进出应用的流量都经过该代理（数据面 Data Plane） → 2. 控制面下发策略：控制面（如 Istiod、Linkerd Control Plane）统一管理路由、TLS 证书、熔断、重试、限流等策略 → 3. 流量劫持：通过 iptables / init container / eBPF 把进出 Pod 的流量重定向到 Sidecar → 4. mTLS 安全：Sidecar 自动为服务间通信颁发并轮换 mTLS 证书，实现零信任传输加密 → 5. 可观测采集：Sidecar 统一上报 L7 指标（请求率、错误率、延迟）至 Prometheus / OpenTelemetry → 6. 策略执行：限流、熔断、灰度、重试等策略在 Sidecar 上执行，业务无感知
5、发展历程：
· 2016 年 9 月：Lyft 开源 Envoy 高性能边缘代理，成为后续 Service Mesh 数据面事实标准
· 2017 年 5 月：Google、IBM、Lyft 联合开源 Istio 1.0，统一服务网格控制面
· 2017 年：Buoyant 公司发布 Linkerd 2.0，基于 Rust 重写，专为 Kubernetes 设计
· 2018-2020 年：CNCF 将 Istio、Linkerd、Envoy 纳入毕业/孵化项目，Service Mesh 成为云原生标配
· 2021-2023 年：Ambient Mesh、Sidecar-less 模式出现，简化运维；Cilium Service Mesh 用 eBPF 替代 Sidecar
· 2024-2025 年：Service Mesh 与 AI Gateway、API Gateway 融合，向统一网络可观测层演进
6、主要类型 / 分类：
· 按数据面形态：Sidecar 模式（Istio、Linkerd）、Sidecar-less 模式（Istio Ambient Mesh、Cilium Service Mesh）
· 按控制面：集中式控制面（Istio） vs 轻量化控制面（Linkerd）
· 按协议层：L4 Service Mesh（仅 TCP/HTTP）vs L7 Service Mesh（支持 HTTP/gRPC/Kafka 路由）
· CNCF 主流项目：Istio、Linkerd、Consul Connect、AWS App Mesh、Kuma
7、应用场景：
· Kubernetes 微服务治理：金丝丝雀发布、A/B 测试、蓝绿部署
· 零信任网络：自动 mTLS 加密 + 基于身份的访问控制
· 多语言微服务统一通信：业务侧无需关心重试、超时、熔断
· 全链路可观测：统一采集 RED（Rate / Error / Duration）指标与分布式追踪
· API 与 AI Gateway 融合：现代 Service Mesh 与 API Gateway 边界逐渐模糊
8、优缺点 / 局限性：
优点：业务无侵入：所有横切关注点（路由、安全、可观测）下放到基础设施；多语言友好：业务用 Go、Java、Python 都能获得一致的网络治理能力；统一安全：mTLS + 身份策略默认覆盖全部服务间流量；统一可观测：无需在每个业务服务中接入 SDK 即可获得 L7 指标
缺点：性能开销：每跳请求额外经过 Sidecar，延迟与资源占用上升（Linkerd、eBPF Mesh 已显著降低）；运维复杂度高：控制面、Sidecar 升级、证书轮换需要专门运维；调试困难：流量被劫持后问题定位链路变长；对非 Kubernetes 环境支持弱：传统 VM、裸金属场景落地成本高
9、常见误区：
· Service Mesh = API 网关（错：Mesh 专注 east-west 内部服务通信，API Gateway 处理 north-south 南北向入口流量；二者正逐步融合）
· Service Mesh 取代微服务框架（错：Spring Cloud、Dubbo 等是业务内部框架，Mesh 是集群级基础设施，二者长期共存）
· 上 Mesh 就安全了（错：Mesh 默认仅覆盖传输加密与身份，应用层漏洞、API 鉴权仍需单独设计）
· 所有场景都该上 Service Mesh（错：服务数量 < 20 时引入 Mesh 的运维成本往往超过收益）
10、相关术语：
父概念：云原生、Kubernetes容器编排、Microservices · 微服务
子概念：Istio、Linkerd、Envoy、Cilium、Sidecar · 边车模式
兄弟概念：API 网关、eBPF内核技术、Observability · 可观测性、零信任 Zero Trust
对比概念：API 网关、Microservices · 微服务
应用相关：Istio、Linkerd、Kubernetes容器编排、零信任 Zero Trust
11、参考资料：
· 来源：Istio 官方文档
· 来源：Linkerd 官方文档
· 来源：CNCF Istio 项目页
· 来源：CNCF Linkerd 项目页
· 来源：Wikipedia: Service mesh
