★ FEATURED ARTICLE 1. 微服务治理演进史阶段 1单体应用所有模块在一个进程内进程内方法调用不存在跨网络服务调用不需要服务治理。阶段 2第一代微服务 — SDK 侵入式治理治理逻辑嵌入业务代码服务注册发现、负载均衡、重试、熔断、限流、埋点、TLS 都封装在 SDK 里。优点上手简单无额外网络代理开销缺点语言绑定一套 SDK 只支持一种语言。Java 用 SpringCloudGo/Python 需要自己重写治理逻辑多语言异构系统成本极高侵入业务业务代码依赖治理 SDK业务代码和通信治理逻辑耦合SDK 升级灾难SDK 漏洞、版本升级所有微服务必须重新打包发布几十个上百个服务升级周期极长能力统一管控难策略散落在各个服务实例很难全局统一灰度、流量镜像、细粒度访问控制运维侧无法独立调整流量策略必须改代码发版本。核心矛盾通信治理逻辑是基础设施能力却被写进业务代码。阶段 3第二代微服务 — 服务网格Sidecar 代理模式思想把服务间通信治理能力从业务代码剥离下沉到独立的基础设施代理进程Sidecar。业务进程完全不用感知治理逻辑无需引入 SDK、无需修改代码。核心口号业务只负责业务逻辑流量治理交给 Sidecar。2. 服务网格定义、核心思想、分层架构定义服务网格是专门负责微服务之间东西向网络通信的基础设施层由一组分布式代理Sidecar和中心化控制组件组成以透明、非侵入方式提供微服务通信治理能力。两大平面服务网格永远分为控制平面 Control Plane和数据平面 Data Plane二者职责严格分离。数据平面载体Sidecar边车代理进程典型Envoy部署和业务容器在同一个 Pod共享网络命名空间职责实际转发数据包执行流量策略。所有流量转发、路由、熔断、mTLS 加密、日志采集都是 Sidecar 实时执行。特点分布式每个业务 Pod 都有独立 Sidecar不保存全局配置配置由控制平面推送。控制平面部署独立的一组服务不和业务 Pod 混部职责不转发任何业务数据包只做配置管理、服务发现、证书管理、策略下发。工作流程运维编写规则 CRD → 控制平面校验规则 → 转换成 Sidecar 能识别的配置 → 推送给所有 Sidecar。特点中心化管控控制平面挂掉不会影响已经在运行的业务流量Sidecar 会使用本地缓存配置继续工作这是重要容灾特性。通俗类比数据平面 Sidecar马路上每辆车随车安全员现场执行限速、安检安全员不制定法规只执行。流量发生在安全员和安全员之间。控制平面交通局制定法规、下发规则交通局不参与路上车辆通行交通局宕机路上车辆还能按旧规则继续跑。3. Sidecar 模式原理、流量劫持完整机制K8s 下 Istio 最经典Pod 内业务容器 Envoy Sidecar 容器共享net网络命名空间。 流量劫持依靠iptables 端口重定向实现透明代理业务完全感知不到 Sidecar。劫持完整流程业务容器发起 TCP 请求目标地址是serviceA:8080流量到达 Pod 内的网络栈被iptables OUTPUT 链捕获iptables 规则把 Pod 内所有出站 TCP 流量劫持转发到本机 Sidecar 的监听端口默认 15001Envoy Sidecar 接收流量解析请求Sidecar 根据控制平面下发的 VirtualService/DestinationRule 执行策略路由选择、权重分流、熔断、mTLS 加密Sidecar 建立新连接将请求转发给目标 Pod 的 Sidecar目标 Pod Sidecar 接收连接解密 mTLS校验访问策略iptables 把流量转发给目标 Pod 内业务容器响应流量原路返回再次经过两端 Sidecar。入站流量流量进入 Podiptables PREROUTING 链捕获入站流量转发到 Sidecar 的 15006 端口Sidecar 校验策略、解密转发给本地业务容器。iptables 劫持要点注入 Sidecar 的时候istio-init 初始化容器负责在 Pod 里写入 iptables 规则初始化容器执行完就退出可以配置流量劫持范围可以只劫持特定端口或者排除某些端口缺点iptables 规则过多时会带来内核网络栈开销大规模 Pod 场景下 iptables 管理成本上升。补充透明代理的目标业务代码写死目标 IP / 端口不需要配置代理地址流量自动被劫持这就是透明代理。Sidecar 模式优缺点✅ 优点非侵入多语言统一治理独立升级 Sidecar业务无需改动 ❌ 缺点每个 Pod 额外进程占用 CPU 内存多一层网络转发增加延迟Pod 数量越多Sidecar 总资源开销越大iptables 带来内核开销排障链路变长。4. 数据平面核心能力详解Envoy 是高性能 C 开发的七层代理Istio、Kuma 都基于 Envoy。Envoy 是事件驱动架构支持热配置更新配置变更不需要重启进程。4.1 流量管理服务发现Sidecar 本地维护后端实例列表控制平面持续同步实例状态健康实例、异常实例七层路由基于 HTTP 请求头、URL、Cookie 做路由例如user-typetest的请求路由到 v2 版本加权路由灰度按百分比分配流量90% v110% v2流量镜像影子流量真实请求正常发给 v1复制一份相同请求异步发给 v2镜像流量返回结果丢弃。用来做线上版本验证不影响真实用户负载均衡策略轮询、随机、加权轮询、最小请求数、会话保持超时、重试配置调用超时可配置只对幂等请求重试限制重试次数、重试间隔熔断与实例隔离后端实例错误率超过阈值 → 将实例从可用列表摘除一段时间后恢复防止服务雪崩连接池管理控制到每个后端实例最大并发连接数防止后端被打满故障注入混沌工程主动注入延迟、5xx 错误人为制造故障验证服务容错能力。只作用于被劫持流量业务代码不用改。4.2 安全能力mTLS 双向 TLS服务之间通信加密客户端 Sidecar 和服务端 Sidecar 互相校验证书身份不是普通 HTTPS单向。证书由控制平面自动签发、自动轮换业务完全不用管理证书细粒度访问控制 AuthorizationPolicy定义服务访问白名单。例只有 order 服务可以调用 payment其他服务访问直接拒绝支持 JWT 校验Sidecar 层直接校验请求 token不用业务代码处理鉴权。4.3 可观测性Sidecar 在流量经过时自动采集业务无需埋点Metrics 指标请求量 QPS、响应码分布、延迟 P50/P90/P99、连接数、失败率Trace 分布式追踪自动生成 traceId把调用链串联对接 Jaeger、ZipkinAccess Log 访问日志每条请求记录源服务、目标服务、耗时、状态码、请求头注意Sidecar 只能采集经过它的网络调用业务内部代码异常无法捕获。4.4 限流支持客户端侧限流调用方 Sidecar 限制对外请求速率服务端侧限流被调用方 Sidecar 限制收到请求速率维度按服务、IP、请求头维度限流。5. 控制平面原理配置推送、服务发现、证书分发新版 Istio 将多个组件合并为istiod单体控制平面简化架构。旧版是 Pilot、Citadel、Galley 分离组件软考有时候会考旧版组件名称。istiod 内部模块Pilot流量配置 服务发现监听 K8s 资源Deployment、Service、Pod监听 Istio 自定义 CRDVirtualService、DestinationRule维护服务实例信息将 K8s 资源 Istio 规则翻译成 Envoy 可识别的配置通过 gRPC 协议xDS 协议推送给所有 SidecarxDS 协议Envoy 的动态配置协议。包含 LDS监听器、RDS路由、CDS集群、EDS端点实例。xDS 支持增量推送配置变更不需要重启 Envoy。这是 Envoy 核心能力。CitadelCA 证书中心负责给每个服务签发身份证书自动轮换证书提供 mTLS 证书。Galley校验 Istio CRD 配置合法性过滤无效配置新版 istiod 内部整合 Galley不再独立部署。重点xDS 是 Envoy 和控制平面之间的核心通信协议。控制平面工作流程完整示例用户编写VirtualServiceDestinationRule提交到 K8s APIServeristiod 监听 CRD 变更触发配置更新Pilot 解析规则结合 K8s 服务实例列表生成 Envoy xDS 配置istiod 通过 gRPC 长连接增量推送配置给集群所有 SidecarSidecar 收到 xDS 配置热加载不需要重启 Envoy 进程新流量立刻按照新灰度规则执行旧连接不受影响。容灾特性控制平面宕机已经下发到 Sidecar 的配置保存在本地Sidecar 继续使用旧配置转发流量业务调用不受影响。控制平面是管控面不是数据面控制平面故障不中断业务流量。软考高频考点6. Istio CRD 资源详解Istio 扩展 K8s API自定义资源 CRD用来定义流量、安全策略。CRD作用VirtualService虚拟服务定义路由规则。流量匹配、权重、流量镜像、故障注入。定义请求怎么转发。DestinationRule目标规则定义目标服务的策略。负载均衡、熔断、连接池、mTLS 模式、版本子集。VirtualService 依赖 DestinationRule 的子集。Gateway网关定义集群入口南北向流量外部流量进入网格。PeerAuthentication对等认证控制服务之间 mTLS 模式关闭 / 允许 / 强制AuthorizationPolicy访问授权策略服务间访问权限黑白名单SidecarSidecar 资源细粒度控制 Sidecar 监听端口、服务发现范围用来优化大规模集群性能减少 Sidecar 配置大小关系VirtualService 回答请求往哪发DestinationRule 回答发到目标服务之后用什么策略。举例灰度发布 CRD 逻辑Deployment 部署 order-v1、order-v2打标签version: v1/version:v2K8s Service order选择所有带标签 apporder 的 PodDestinationRule 定义 order 服务划分两个子集 v1、v2配置熔断策略VirtualService匹配 order 服务流量90% 流量路由到子集 v110% 路由 v2istiod 感知配置变更xDS 推送给 Sidecar。7. 主流服务网格产品横向对比Istio数据平面Envoy控制平面istiod特点功能最全生态最强企业落地最多支持复杂路由、镜像、mTLS、鉴权缺点组件多资源开销大早期版本复杂学习曲线陡峭适合中大规模集群。适用企业生产复杂微服务场景软考默认示例。Linkerd数据平面自研 Linkerd2-proxyRust 开发控制平面轻量化特点极简部署简单资源占用低开箱即用短板高级流量能力弱流量镜像、复杂路由能力不如 Istio适合中小型集群。Kuma基于 Envoy轻量支持 K8s 虚拟机混合环境适合异构混合云。Consul ConnectHashiCorp Consul 配套强服务发现K8s 和 VM 混合部署场景。8. 服务网格与周边组件辨析8.1 服务网格 vs API 网关 / Ingress GatewayAPI 网关Ingress Gateway南北向流量外部客户端 → 集群内部服务是集群入口。服务网格 Sidecar东西向流量集群内部服务 ↔ 集群内部服务。Istio Gateway 本质就是 Envoy作为网格入口网关同时支持南北向。 一句话区分网关管进集群Sidecar 管集群内部互相调用。两者经常搭配使用。8.2 服务网格 vs K8s ServiceK8s Service四层 IP 负载均衡基于 iptables/ipvs只能基础转发没有七层路由、灰度、熔断、mTLS、流量镜像。 服务网格是 K8s 之上七层流量治理增强。K8s Service 依然保留作为服务发现基础。8.3 服务网格 vs SpringCloud/Dubbo SDKSDK 模式侵入业务代码语言绑定治理逻辑在业务进程内部 服务网格 Sidecar 模式进程外代理非侵入多语言统一治理。8.4 服务网格 vs 分布式追踪系统分布式追踪Jaeger是可观测组件服务网格 Sidecar 自动生成 trace 数据输出给 Jaeger网格不替代追踪系统。9. 服务网格落地适用场景、不适合场景、收益与代价✅ 适合落地场景K8s 集群微服务数量≥10 个多语言异构服务Java、Go、Python 混合需要频繁灰度发布、蓝绿发布、流量镜像做线上验证安全要求高希望全集群服务之间自动 mTLS 加密基础设施团队统一管控流量策略业务团队不希望关心通信治理需要统一可观测业务不能到处埋点需要全局服务访问权限控制混沌工程故障注入。❌ 不适合场景小规模集群微服务很少引入网格带来的复杂度 收益极致低延迟场景无法容忍 Sidecar 代理增加的网络延迟资源紧张边缘集群无法承担 Sidecar CPU 内存开销单体应用简单架构不需要灰度、mTLS、细粒度流量控制。收益业务代码和通信治理能力解耦非侵入接入多语言微服务统一治理标准流量策略集中管控运维独立变更策略无需发布业务内置安全mTLS、服务身份认证统一可观测自动采集指标、日志、链路追踪故障隔离能力降低雪崩风险。代价资源开销每个 Pod 增加 Sidecar 进程大规模集群资源消耗明显网络延迟增加请求多一次代理转发架构复杂度提升新增整套基础设施故障排查链路变长业务 Pod → Sidecar → istiod网络抓包、问题定位难度上升学习、运维成本高需要团队掌握 Envoy、xDS、CRDiptables 劫持带来内核网络开销大规模集群调优工作量大。工程最佳实践不要全集群一次性开启 Sidecar 注入采用渐进式部分命名空间、部分服务开启网格逐步验证。10. 典型业务场景原理详解10.1 灰度发布需求新版本 v2 上线只放 10% 流量观察指标异常快速切回 v1。 原理VirtualService 权重分流流量由调用方 Sidecar 做路由不需要修改业务代码。10.2 蓝绿发布两套完整环境 v1、v2通过 VirtualService 一键切换全部流量。v2 验证有问题立刻切回 v1。10.3 流量镜像线上真实请求发给 v1复制一份异步发给 v2镜像请求返回结果丢弃。用于新版本压测、功能验证不影响真实用户。注意镜像流量会放大后端压力需要评估容量写请求镜像可能产生脏数据。10.4 故障注入在 Sidecar 层对指定比例请求注入延迟或者错误测试系统容错能力。混沌工程能力。10.5 服务访问隔离PeerAuthentication 开启 mTLSAuthorizationPolicy 配置策略只有 order 服务可以调用 payment。11. 服务网格性能瓶颈、常见问题与优化方案瓶颈点Sidecar CPU / 内存开销Pod 越多总开销越大iptables 规则膨胀内核网络栈开销xDS 推送压力集群几千 Pod 的时候istiod 推送配置压力大额外一跳网络转发带来延迟增加大量日志、指标采集带来开销。优化手段选择性注入 Sidecar不是所有 Pod 都注入只给需要治理的服务开启使用 Sidecar CRD 缩小 Sidecar 服务发现范围减少 Sidecar 本地配置量调优 Sidecar 资源 limit 和 request对不需要的能力关闭关闭日志、关闭不必要的指标采集调大连接池参数减少连接建立开销istiod 水平扩容避免过多复杂 VirtualService 规则。常见故障Sidecar 和 istiod 连接中断无法更新配置旧配置继续运行iptables 规则错误流量劫持失败mTLS 策略配置错误服务之间无法通信xDS 配置推送延迟新策略不生效。12. 下一代eBPF 无 Sidecar 服务网格传统服务网格Sidecar 进程代理流量在用户态转发带来开销。 eBPFLinux 内核可编程技术在内核中挂载钩子在内核层完成流量劫持、路由、观测。不需要每个 Pod 部署 Sidecar 进程。 代表项目Cilium。Sidecar 网格 vs eBPF 网格对比Sidecar 网格用户态代理每个 Pod 一个进程开销大实现简单成熟IstioeBPF 网格内核态处理流量无每个 Pod Sidecar 进程开销更低延迟更低依赖 Linux 内核版本能力目前弱于成熟 Sidecar 网格。行业现状eBPF 是下一代方向但生产大规模落地、复杂流量治理能力还不如 Istio。
阅读完成 · 觉得有帮助？
