type
status
date
slug
summary
tags
category
icon
password
1. 为什么需要 Service Mesh？
假设你写了一个 Spring Boot 微服务系统，有用户服务、订单服务、支付服务。最开始服务之间直接用 HTTP/Feign 调用，没啥问题。
但系统一旦复杂，问题就来了：
- 服务通信复杂：跨服务的调用链越来越多，想追踪问题很难。
- 负载均衡、熔断、限流、重试：每个服务都得自己写逻辑，重复代码很多。
- 安全：服务间通信需要加密，但自己写 TLS 成本太高。
- 多语言支持：如果有部分服务用 Python/Go，拦截通信的逻辑就要重复造轮子。
这就是 Service Mesh 的用武之地 —— 把服务间通信的复杂治理逻辑抽出来，交给一个独立层来处理，应用代码专心写业务。
2. 核心思想
传统微服务治理：
👉 应用里集成 Netflix OSS、Hystrix、Ribbon、Feign 等库来处理熔断、限流、路由。
Service Mesh 治理：
👉 把这些逻辑放到 Sidecar 代理（如 Envoy） 里，应用只管业务逻辑，网络治理由 Service Mesh 负责。
类比一下：
- 没有 Service Mesh：你写的每个 Java 服务都得自己处理网络治理，就像每个开发都写一套日志系统。
- 有 Service Mesh：治理逻辑被抽出来，像 Logback/ELK 一样统一处理。
3. 核心组件（以 Istio 为例）
- Data Plane（数据平面）
👉 Sidecar 代理（比如 Envoy），负责真正的流量转发、熔断、限流、加密。
👉 每个 Pod/服务边上都会挂一个 Sidecar，就像给服务套了个“防护罩”。
- Control Plane（控制平面）
👉 比如 Istio 的 Pilot、Citadel，负责下发规则（路由策略、安全策略、监控配置）。
👉 类似于 K8s 的“调度器”，自己不处理流量，但会告诉代理们怎么处理。
4. 开发人员需要理解的关键点
（1）零侵入
你写的 Java 微服务代码里 不需要改一行 Feign/RestTemplate，流量自动走 Envoy 代理。
（2）可观测性
- 自动获取 调用链 Trace（Jaeger/Zipkin）
- 自动采集 Metrics（Prometheus/Grafana）
- 甚至可以看到 A → B → C 的完整调用链
（3）流量治理
你能用 YAML 配置 做到：
- 灰度发布（10% 流量走新版本，90% 走旧版本）
- 熔断/重试（失败自动重试 3 次）
- 限流（某接口每秒最多 100 个请求）
- 请求路由（按 Header、用户 ID 把流量导到不同版本）
5. 实操示例（Istio on K8s）
假设你有两个版本的订单服务：
order-v1（稳定版本）
order-v2（新版本，准备灰度）
Step 1: 安装 Istio 并开启 Sidecar 注入
Step 2: 部署服务
Step 3: 定义虚拟服务（灰度发布）
👉 这个配置表示：90% 的流量走
order-v1，10% 的流量走 order-v2，不用改一行 Java 代码。6. Java 开发人员能获得什么？
- 不用再在代码里写 Hystrix/Resilience4j，治理逻辑交给 Service Mesh。
- 跨语言统一治理：不管是 Java、Go、Python 服务，统一标准。
- 可观测性增强：更容易排查问题，少写监控埋点。
- 研发效率提高：业务逻辑与治理逻辑彻底解耦。
7. 总结一句话
Service Mesh 就像微服务的“透明网络代理层”，帮你处理流量治理，让 Java 代码更纯粹地专注业务逻辑。
架构对比图
