🏗️ 架构演进：单体 → 微服务 → 服务网格

点击标签页查看各阶段架构，了解为什么需要 Istio

① 单体架构
② 微服务架构
③ 服务网格
④ 对比总结
📦 单体架构（Monolith）
所有功能打包在一个应用里，部署简单，但扩展困难
👤 用户 / 浏览器
↓ HTTP
🏪 电商应用（单一进程）
用户模块
商品模块
订单模块
支付模块
购物车模块
通知模块
搜索模块
报表模块
↓
🗄️ 单一数据库（MySQL）
✅ 优点
❌ 缺点
开发简单，本地一键启动
任何模块改动需要全量重新部署
调试方便，日志集中
一个模块出Bug，整个应用崩溃
事务处理简单
技术栈固定，无法局部升级
适合小团队、早期项目
无法针对热点模块单独扩容
🔧 微服务架构（Microservices）
拆分为独立服务，灵活扩展，但服务间通信管理复杂
👤 用户 / 浏览器
↓
🌐 API Gateway（Nginx/Kong）
↓ 按路由分发
👤 用户服务
:8001
📦 商品服务
:8002
🛒 订单服务
:8003
💳 支付服务
:8004
🔔 通知服务
:8005
🗄️ 用户DB
🗄️ 商品DB
🗄️ 订单DB
🗄️ 支付DB
⚠️ 新问题：服务多了，怎么管理？
服务间调用如何加密？超时重试谁来处理？流量怎么控制？故障如何追踪？ → 每个服务都要写相同的代码！
🕸️ 服务网格（Service Mesh / Istio）
Sidecar 代理接管所有服务间通信，应用代码无需关心网络问题
👤 用户 / 浏览器
↓
🌐 Istio IngressGateway（VIP 10.20.50.50）
⚙️ istiod（控制面）— 下发路由规则 / 证书 / 策略
↓ 所有流量经过 Envoy Sidecar
E
👤 用户服务
Envoy代理
E
📦 商品服务
Envoy代理
E
🛒 订单服务
Envoy代理
E
💳 支付服务
Envoy代理
E
🔔 通知服务
Envoy代理
🔒 mTLS 自动加密
⚖️ 精确流量控制
🔄 自动重试
⏱️ 超时管理
🔭 全链路追踪
📊 指标收集
⚡ 熔断限流
🧪 故障注入
📊 三阶段对比总结
各阶段能力对比，理解为什么需要服务网格
能力
单体
微服务
服务网格
独立部署
❌ 全量部署
✅ 独立部署
✅ 独立部署
弹性扩容
❌ 整体扩容
✅ 按服务扩容
✅ 按服务扩容
服务间加密
❌ 明文
⚠️ 需手动实现
✅ mTLS自动
流量控制
❌ 无
⚠️ 粗粒度
✅ 精确权重
熔断限流
❌ 无
⚠️ 代码实现
✅ 配置实现
链路追踪
❌ 无
⚠️ 需集成SDK
✅ 自动采集
金丝雀发布
❌ 无
⚠️ 依赖副本数
✅ 精确1%粒度
故障注入
❌ 无
❌ 无
✅ 配置即可
运维复杂度
✅ 低
⚠️ 中
⚠️ 高（但收益大）
适用规模
小型项目
中型项目
大型/生产