微服务架构
欢迎来到微服务架构知识库！
🏗️ 微服务简介
微服务架构是一种将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，通过轻量级机制（通常是 HTTP REST API 或 gRPC）进行通信。
🎯 微服务 vs 单体架构
单体架构
┌─────────────────────────────┐
│ 单体应用程序 │
│ ┌────────┬────────┬────────┐│
│ │ 用户 │ 订单 │ 支付 ││
│ │ 模块 │ 模块 │ 模块 ││
│ └────────┴────────┴────────┘│
│ 统一数据库 │
└─────────────────────────────┘微服务架构
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 用户服务 │ │ 订单服务 │ │ 支付服务 │
│ DB │ │ DB │ │ DB │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└─────────────┴─────────────┘
API 网关
│
客户端📊 对比分析
| 特性 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发复杂度 | 🟢 低 | 🔴 高 |
| 部署 | 🟢 简单 | 🔴 复杂 |
| 扩展性 | 🔴 差 | 🟢 好 |
| 技术栈 | 统一 | 灵活 |
| 团队协作 | 🔴 容易冲突 | 🟢 独立开发 |
| 故障隔离 | 🔴 差 | 🟢 好 |
| 性能 | 🟢 好 | 🟡 网络开销 |
| 数据一致性 | 🟢 易保证 | 🔴 复杂 |
✅ 微服务优势
1. 独立部署
- 每个服务可以独立部署
- 不影响其他服务
- 快速迭代
2. 技术多样性
- 不同服务可以使用不同技术栈
- 选择最适合的技术
3. 可扩展性
- 按需扩展单个服务
- 资源利用更高效
4. 故障隔离
- 单个服务故障不影响整体
- 提高系统可用性
5. 团队协作
- 小团队负责小服务
- 减少沟通成本
⚠️ 微服务挑战
1. 分布式系统复杂性
- 网络延迟
- 服务间通信
- 分布式事务
2. 运维复杂度
- 服务数量多
- 部署、监控、日志收集
3. 数据一致性
- 分布式事务
- 最终一致性
4. 测试困难
- 集成测试复杂
- 需要搭建测试环境
🏗️ 微服务架构组件
1. 服务注册与发现
作用: 服务实例注册自己的位置，其他服务可以发现它们。
Service A
│
├──注册──> 注册中心 (Consul/Eureka/Nacos)
│ │
├────────────┘
│
└──发现──> Service B常用技术:
- Consul - HashiCorp 开发，功能丰富
- Eureka - Netflix 开源，Spring Cloud 生态
- Nacos - 阿里巴巴开源，国内流行
- etcd - CoreOS 开发，Kubernetes 使用
2. API 网关
作用: 统一入口，路由、认证、限流、监控。
客户端
│
├──> API 网关
│
├──> 用户服务
├──> 订单服务
└──> 支付服务功能:
- 路由转发
- 认证授权
- 限流熔断
- 日志监控
- 协议转换
常用技术:
- Kong - 基于 Nginx，插件丰富
- Traefik - 云原生，自动发现
- Spring Cloud Gateway - Spring 生态
- APISIX - 国产，高性能
3. 配置中心
作用: 集中管理配置，动态更新。
常用技术:
- Apollo - 携程开源，功能强大
- Nacos - 阿里巴巴开源
- Spring Cloud Config - Spring 生态
- Consul - 兼具服务发现和配置管理
4. 负载均衡
作用: 分发请求到多个服务实例。
策略:
- 轮询 - 依次分配
- 随机 - 随机选择
- 加权 - 根据权重分配
- 最少连接 - 选择连接数最少的
常用技术:
- Ribbon - 客户端负载均衡
- Nginx - 服务端负载均衡
- Envoy - 服务网格代理
5. 熔断降级
作用: 防止故障扩散，提高系统可用性。
熔断状态:
关闭 ──错误率过高──> 开启
↑ │
│ │ 超时后
└──测试成功── 半开启 <─┘常用技术:
- Hystrix - Netflix 开源（维护模式）
- Sentinel - 阿里巴巴开源
- Resilience4j - 轻量级
- Istio - 服务网格
6. 链路追踪
作用: 追踪请求在微服务间的调用链路。
请求 -> 网关 -> 用户服务 -> 订单服务 -> 支付服务
[1ms] [10ms] [20ms] [50ms]常用技术:
- Zipkin - Twitter 开源
- Jaeger - Uber 开源，CNCF 项目
- SkyWalking - 国产，功能全面
- OpenTelemetry - 统一标准
7. 日志聚合
作用: 集中收集、存储、查询日志。
架构:
服务 A -> 日志收集 -> 日志存储 -> 日志查询
服务 B -> (ES) (Kibana)
服务 C ->常用技术:
- ELK - Elasticsearch + Logstash + Kibana
- EFK - Elasticsearch + Fluentd + Kibana
- Loki - Grafana Labs 开发
🔄 服务间通信
1. 同步通信
REST API
Service A ──HTTP Request──> Service B
<─HTTP Response─┘优点: 简单、通用 缺点: 耦合度高、性能一般
gRPC
Service A ──gRPC Call──> Service B
<─gRPC Response─┘优点: 高性能、类型安全 缺点: 浏览器支持有限
2. 异步通信
消息队列
Service A -> 消息队列 -> Service B
-> Service C优点: 解耦、削峰填谷 缺点: 增加复杂度
常用技术:
- RabbitMQ - 功能丰富
- Kafka - 高吞吐
- RocketMQ - 阿里巴巴开源
🗄️ 数据管理
1. 数据库模式
每个服务一个数据库
用户服务 -> 用户DB
订单服务 -> 订单DB
支付服务 -> 支付DB优点: 数据隔离、独立扩展 缺点: 数据一致性复杂
共享数据库
用户服务 ─┐
订单服务 ─┼─> 共享DB
支付服务 ─┘优点: 简单、易于查询 缺点: 耦合度高
2. 分布式事务
Saga 模式
订单服务 -> 创建订单
↓
库存服务 -> 扣减库存
↓
支付服务 -> 扣款每步都有补偿操作：
- 创建订单 → 取消订单
- 扣减库存 → 恢复库存
- 扣款 → 退款
TCC 模式
- Try - 尝试执行，预留资源
- Confirm - 确认执行
- Cancel - 取消执行，释放资源
🚀 部署策略
1. 蓝绿部署
负载均衡
│
├──> 蓝环境 (旧版本) ──切换──> 绿环境 (新版本)2. 金丝雀发布
负载均衡
│
├──> 90% 旧版本
└──> 10% 新版本 (逐步增加)3. 滚动更新
实例1 -> 更新中
实例2 -> 运行中
实例3 -> 运行中
↓
实例1 -> 运行中 (新版本)
实例2 -> 更新中
实例3 -> 运行中💡 设计原则
1. 单一职责
每个服务只做一件事，做好一件事。
2. 服务自治
服务独立部署、独立运行、独立数据库。
3. 去中心化
避免单点故障，分布式治理。
4. 故障隔离
服务间隔离，防止故障扩散。
5. 持续交付
自动化部署，快速迭代。
📖 学习资源
推荐书籍
- 《微服务设计》
- 《微服务架构设计模式》
- 《Spring Cloud 微服务实战》
推荐文章
框架推荐
- Spring Cloud - Java 生态
- Go-Micro - Go 语言
- Dubbo - 阿里巴巴开源
- Istio - 服务网格
准备好了吗？开始你的微服务架构学习之旅！