1
核心定义
Mesh 化架构:把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦,从而使得:
- 中间件升级对业务进程没有影响
- 甚至迁移到另外一个平台的中间件也对业务透明
📦 分离后的结构特点
- 业务进程中只保留很"薄"的 Client 部分
- Client 通常很少变化,只负责与 Mesh 进程通信
- 原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成
2
架构对比图(教材图 14-1)
图 1:传统架构 → Mesh 化架构演进对比
3
Mesh 化架构带来的能力
实施 Mesh 化架构后,以下能力都由 Mesh 进程完成,即使业务代码的制品中并没有使用这些三方软件包。
🛡️ 由 Mesh 进程完成的分布式架构模式
熔断 限流 降级 重试 反压 隔仓
⭐ 这 6 项是必背考点,口诀:"熔限降重反隔"
🎁 额外获得的能力
| 能力 | 说明 |
|---|---|
| 更好的安全性 | 比如零信任架构能力 |
| 动态环境隔离 | 按流量进行动态环境隔离 |
| 流量测试能力 | 基于流量做冒烟 / 回归测试 |
4
Mesh 化架构的核心价值
| 价值维度 | 具体表现 |
|---|---|
| 解耦 | 中间件 SDK 与业务代码进一步解耦,业务代码更纯粹 |
| 独立升级 | 中间件升级对业务进程没有影响 |
| 平台透明 | 迁移到另外一个平台的中间件,对业务也是透明的 |
| 能力下沉 | 分布式治理能力(熔断/限流/降级等)从业务代码下沉到基础设施 |
| 非功能性剥离 | 大量非功能性特性从业务进程剥离到 Mesh 进程 |
5
延伸:服务网格(Service Mesh)
服务网格 (Service Mesh):是分布式应用在微服务软件架构之上发展起来的新技术,旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设施的解耦。
🎯 服务网格的核心思想
- 开发者无需关注微服务相关治理问题,聚焦于业务逻辑本身
- 提升应用开发效率并加速业务探索和创新
- 大量非功能性从业务进程剥离到另外进程中
- 以无侵入的方式实现了应用轻量化
🏗️ Istio 典型架构(教材图 14-4)
图 2:Istio 服务网格典型架构
🔧 Istio 三大主要组件
| 组件 | 中文释义 | 职责 |
|---|---|---|
| Pilot | 领航员 | 服务发现、流量管理 |
| Mixer | 混音器 | 访问控制、可观测性 |
| Citadel | 城堡 | 终端用户认证、流量加密 |
🎯 服务网格关注的能力
连接和流量控制 可观测性 安全 可运维性
📊 性能与收益分析
- 相比无服务网格场景,多了 4 个 IPC 通信的成本
- 整体调用延迟随软硬件能力提升影响不显著
- 对于百毫秒级别的业务调用,可控制在 2% 以内
- 服务化的应用不做任何改造即可获得:
- 强大的流量控制能力
- 服务治理能力 + 可观测能力
- 4 个 9(99.99%)以上高可用
- 容灾和安全等能力
- 整体收益远大于额外 IPC 通信支出
6
主流服务网格技术对比
| 方案 | 数据平面 | 控制平面 | 特点 |
|---|---|---|---|
| Istio | Envoy | Go 语言 | 2017 年发起;最主流方案;基于 Kubernetes;性能受业界诟病;2019 年 1.12 版达到小规模集群上线生产环境水平 |
| Linkerd | Rust(linkerd-proxy) | Go 语言 | 相对小众;时延、资源消耗比 Istio 更具优势;功能不如 Istio 完整 |
| Consul | 可选 Envoy | ConsulServer | 相对小众;功能不如 Istio 完整 |
| Conduit | Rust | Go 语言 | K8s 超轻量级 ServiceMesh;目标:最快、最轻、最简单、最安全;倾向 K8s 低资源部署 |
7
服务网格协议标准化
核心趋势:数据平面与控制平面间的协议标准化是必然趋势,围绕事实标准(共建开源软件)展开。
📜 主要协议 / 规范
| 协议/规范 | 提出方 | 说明 |
|---|---|---|
| xDS 协议 | Envoy 实现,Istio 采纳 | 作为数据平面和控制平面间的标准协议 |
| SMI Service Mesh Interface |
Microsoft 提出 | 致力于让数据平面和控制平面的标准化做更高层次的抽象;为 Istio、Linkerd 等方案在服务观测、流量控制等方面实现最大程度的开源能力复用 |
| UDPA Universal Data Plane API |
基于 xDS 发展 | 便捷地根据不同云厂商的特定需求进行扩展,由 xDS 承载 |
🧩 数据平面插件扩展与安全
- Envoy 的地位:得到 Google、IBM、Cisco、Microsoft、阿里云等大厂参与共建,成为事实标准
- Wasm 技术应用:正在探索将 Wasm 技术运用于对各种插件进行隔离
- 避免因某一插件软件缺陷导致整个数据平面不可用
- 优势:提供沙箱功能 + 很好地支持多语言
- 让掌握不同编程语言的开发者使用熟悉的技能扩展 Envoy
🔐 服务网格与零信任架构的结合
服务网格和零信任架构天然有很好的结合,包括:
- POD Identity(Pod 身份)
- 基于 mTLS 的链路层加密
- 在 RPC 上实施 RBAC ACL
- 基于 Identity 的微隔离环境(动态选取一组节点组成安全域)
8
记忆口诀 & 考试要点
口诀 1
Mesh 化核心一句话:把中间件框架(RPC/缓存/异步消息等)从业务进程分离,SDK 与业务解耦,业务进程只保留"薄 Client"。
口诀 2
由 Mesh 进程完成的 6 大分布式架构模式:熔 · 限 · 降 · 重 · 反 · 隔(熔断、限流、降级、重试、反压、隔仓)
口诀 3
Mesh 化的"三个透明":中间件升级透明 + 中间件迁移透明 + 治理能力无侵入(透明)
口诀 4
Istio 三大组件:Pilot(领航→服务发现/流量) + Mixer(混音→访问控制/可观测) + Citadel(城堡→认证/加密)
❗ 易混淆辨析:Mesh 化架构 vs 服务网格
| 对比项 | Mesh 化架构模式 | 服务网格(技术) |
|---|---|---|
| 层次 | 架构设计层面 | 具体技术实现层面 |
| 关注点 | 中间件 SDK 与业务的解耦 | 微服务间通信治理 |
| 典型代表 | 架构思想 / 模式 | Istio、Linkerd、Consul、Conduit |
| 所属章节 | 14.2.3 主要架构模式 | 14.3.4 云原生相关技术 |
9
知识全景图
图 3:Mesh 化架构模式知识全景图
🎯 一句话总结
Mesh 化架构 = 把中间件能力从业务进程剥离出来,下沉到独立的 Mesh 进程,让业务代码只保留"薄 Client",从而实现业务与中间件的彻底解耦、独立升级、平台透明,并把熔断、限流、降级、重试、反压、隔仓等分布式治理能力作为基础设施提供给业务,业务代码无需感知。这是云原生架构"非功能性大量委托"理念的典型体现。