面经策

什么是服务网格？ ​

  • 标签：服务网格、微服务、Spring Cloud

🏛 业务架构师 ​

服务网格（Service Mesh）是把服务间通信能力（负载均衡、熔断、超时重试、加密、鉴权、流量治理）从应用代码下沉到基础设施层的架构形态：在每个服务实例旁部署一个边车代理（Sidecar，如 Envoy），接管该实例的全部进出流量；控制平面（如 Istio）统一下发策略，管理所有边车——应用只管业务逻辑，"微服务治理"与"业务代码"彻底解耦。

它解决的业务痛点：

  1. 治理能力异构收敛：Java 有 Spring Cloud，Go/Python/Node 服务呢？治理逻辑进 Sidecar 后语言无关——多语言团队一套治理体系；
  2. 业务代码减负：升级治理策略（超时策略、mTLS）不再要求所有服务改代码发版——治理变更与业务发布解耦，这是大型组织最大的收益；
  3. 统一可观测：所有流量经过边车，拓扑、指标、链路天然齐全。

架构师视角的清醒判断（2026）：

  1. Sidecar 有税：每实例一代理 = 资源开销 + 一跳延迟 + 运维复杂度（Istio 的学习成本是真实的）——小团队上网格是自找的；
  2. 职责重叠取舍：K8s + Gateway 已吃掉部分职能（发现、入口治理），Istio 的增量价值在精细流量治理（按权重/ Header 灰度）、零信任安全（mTLS）、多语言——需要这些再上；
  3. 趋势是"瘦身边车"：Sidecarless 模式（Istio Ambient、Cilium eBPF）正在削减边车税——技术在向更低的采用成本演进，不急的场景等成熟是合理策略。

一句话：网格是治理能力平台化的终极形态，但采用时机取决于组织规模能覆盖它的成本。

🏗 系统架构师 ​

定义：把服务间通信能力（LB、熔断、重试、mTLS、流量切分、遥测）从应用 SDK 下沉到基础设施——每 Pod 旁挂 sidecar 代理（Envoy），控制面（istiod）统一下发策略；应用只管业务，治理对所有语言透明。

数据面与控制面：应用间流量被透明劫持到 sidecar，由它执行实际转发与策略；控制面不碰数据流，只做配置分发（xDS 协议）——控制面故障不影响已建立的转发。

价值与代价（我的权衡框架）：

  • 价值：多语言治理统一（Go/Python/Java 一套策略）、mTLS 零改造、金丝雀与流量镜像变平台能力、升级治理不用重发应用；
  • 代价：每跳增加 sidecar 转发（RTT 加约 0.5~2ms）、每 Pod 内存开销（百 MB 级）、运维复杂度上移平台团队、排障多两层。

2026 趋势：sidecar-less——Istio Ambient（ztunnel 节点级 L4 加按需 waypoint L7）、Cilium eBPF 内核层治理，逐步消化 sidecar 的资源税。

选型判断：单语言 JVM 小规模，Spring Cloud SDK 性价比更高；多语言、大组织、统一安全合规需求，mesh 的平台化收益压倒成本。两者会长期混布共存。

💻 全栈开发专家 ​

把服务治理能力（发现、负载均衡、熔断、限流、加密、观测）从应用代码下沉到基础设施层（sidecar 代理）的架构形态。代表：Istio + Envoy。

核心结构：每个 Pod 注入一个 sidecar（Envoy），应用所有进出流量被劫持到 sidecar，由它执行路由/LB/熔断/mTLS——业务进程退化为纯业务，治理零侵入。控制面（istiod）下发规则到所有 sidecar，"控制面管策略、数据面管转发"。

对比 Spring Cloud：

  • Spring Cloud：治理在应用层（Feign/Sentinel 的代码与依赖），Java 绑定，升级治理能力 = 改依赖重新发布
  • Mesh：治理在平台层，语言无关（Java/Go/Python 统一策略），改策略秒级生效不动应用；代价是 sidecar 每跳约 1~2ms 开销、链路多一跳排障更绕、运维 istiod 复杂

实践路线感：国内大厂普遍"Spring Cloud 开发 + 逐步下沉治理"——先网关化，再 Mesh 化；eBPF / Sidecar-less（Istio Ambient 模式）在砍 sidecar 开销，是近两年的演进方向。我的建议：中小团队先把 K8s + 网关 + Nacos 用明白，Mesh 是规模与多语言痛点出现后的选项。