微服务架构核心概念速查手册
微服务架构核心概念速查手册
一份全面的微服务架构参考手册，系统梳理 29 个核心概念，涵盖基础架构、可靠性保障、配置治理、可观测性、安全认证、数据管理、部署运维和高级模式等八大领域。每个概念都配有原理图解、实战代码和工具对比，适合作为日常开发的技术速查和架构设计的参考指南。
目录
基础架构层
- 1. 服务拆分（Service Decomposition）
- 2. API 网关（API Gateway）
- 3. RPC 与服务间通信（RPC & Inter-Service Communication）
可靠性保障
- 4. 熔断（Circuit Breaker）
- 5. 服务降级（Service Degradation）
- 6. 重试与超时（Retry & Timeout）
- 7. 隔离（Isolation）
- 8. 限流（Rate Limiting）
配置与治理
- 9. 服务发现与注册（Service Discovery & Registration）
- 10. 配置中心（Configuration Center）
- 11. 负载均衡（Load Balancing）
- 12. 服务网格（Service Mesh）
可观测性
- 13. 链路追踪（Distributed Tracing）
- 14. 日志聚合（Log Aggregation）
- 15. 监控告警（Monitoring & Alerting）
- 16. 健康检查（Health Check）
安全与认证
- 17. 认证与授权（Authentication & Authorization）
- 18. API 安全（API Security）
- 19. 服务间认证（Service-to-Service Auth）
数据管理
- 20. 分布式事务（Distributed Transaction）
- 21. 分布式缓存（Distributed Cache）
- 22. 数据一致性（Data Consistency）
- 23. 数据库分片（Database Sharding）
部署与运维
- 24. 容器化（Containerization）
- 25. CI/CD
- 26. 灰度发布（Canary Deployment）
高级模式
- 27. 事件驱动架构（Event-Driven Architecture）
- 28. BFF 模式（Backend for Frontend）
- 29. 领域驱动设计（DDD in Microservices）
基础架构层
1. 服务拆分（Service Decomposition）
📖 概念
服务拆分是将单体应用按照业务边界、功能模块或领域划分为多个独立的微服务，每个服务专注于特定的业务能力，可以独立开发、部署和扩展。
🎯 拆分策略
单体应用
┌─────────────────────────────────────┐
│ User | Order | Product | Payment │
│ ────────────────────────────────── │
│ 共享数据库 │
└─────────────────────────────────────┘│▼ 拆分
┌───────────┐ ┌───────────┐ ┌───────────┐
│ User │ │ Order │ │ Product │
│ Service │ │ Service │ │ Service │
├───────────┤ ├───────────┤ ├───────────┤
│ User DB │ │ Order DB │ │Product DB │
└───────────┘ └───────────┘ └───────────┘
💡 拆分维度
1.1 按业务能力拆分（推荐）
电商系统
├── 用户服务 (User Service)
│ ├── 注册登录
│ ├── 个人信息
│ └── 积分管理
├── 商品服务 (Product Service)
│ ├── 商品目录
│ ├── 库存管理
│ └── 价格管理
├── 订单服务 (Order Service)
│ ├── 下单
│ ├── 订单查询
│ └── 退换货
└── 支付服务 (Payment Service)├── 支付├── 退款└── 账户余额
1.2 按领域模型拆分（DDD）
┌──────────────────────────────────────┐
│ 限界上下文 (Bounded Context) │
├──────────────────────────────────────┤
│ 订单域 │ 库存域 │
│ ├─ 订单聚合 │ ├─ 商品聚合 │
│ ├─ 订单仓储 │ ├─ 库存仓储 │
│ └─ 订单服务 │ └─ 库存服务 │
└──────────────────────────────────────┘
1.3 按读写分离拆分（CQRS）
┌─────────────┐
│ Command │ (写操作)
│ Service │
└──────┬──────┘│▼┌─────────┐│写数据库 │└────┬────┘│ 同步▼┌─────────┐│读数据库 │└────┬────┘│▼
┌─────────────┐
│ Query │ (读操作)
│ Service │
└─────────────┘
🎯 拆分原则
| 原则 | 说明 | 示例 |
|---|---|---|
| 单一职责 | 每个服务专注一个业务能力 | 用户服务只管用户相关 |
| 高内聚低耦合 | 服务内部紧密，服务间松散 | 订单服务内聚订单逻辑 |
| 自治性 | 服务独立部署、独立数据库 | 各服务有独立数据库 |
| 业务完整性 | 避免一个业务跨多个服务 | 下单流程在订单服务内完成 |
| 适度拆分 | 避免过度拆分 | 不要拆分成几十上百个微服务 |
⚠️ 拆分陷阱
❌ 错误拆分示例：┌─────────────┐ ┌─────────────┐
│ Order CRUD │ ───> │ Order Query │ 过度拆分！
└─────────────┘ └─────────────┘✅ 正确拆分示例：┌──────────────────────┐
│ Order Service │ 职责清晰
│ ├── CRUD │
│ ├── Query │
│ └── Business Logic │
└──────────────────────┘
💡 适用场景
- 单体应用过于庞大，难以维护
- 不同模块有不同的技术栈需求
- 团队规模扩大，需要并行开发
- 需要独立扩展某些功能模块
📝 拆分步骤
1. 识别业务边界└─> 分析业务领域，识别核心能力2. 梳理数据依赖└─> 找出服务间的数据依赖关系3. 定义服务接口└─> 设计清晰的 API 契约4. 拆分数据库└─> 每个服务独立数据库（Database per Service）5. 处理跨服务事务└─> 使用分布式事务或最终一致性6. 逐步迁移└─> 采用绞杀者模式（Strangler Pattern）渐进式迁移
🔧 拆分工具
| 工具/方法 | 说明 |
|---|---|
| 事件风暴 | 识别领域事件和边界 |
| 依赖分析工具 | 分析代码调用关系 |
| 绞杀者模式 | 逐步替换单体模块 |
📝 示例代码
// 拆分前：单体应用
@Service
public class OrderService {@Autowiredprivate UserRepository userRepository;@Autowiredprivate ProductRepository productRepository;@Autowiredprivate OrderRepository orderRepository;public Order createOrder(CreateOrderRequest request) {// 查用户User user = userRepository.findById(request.getUserId());// 查商品Product product = productRepository.findById(request.getProductId());// 检查库存if (product.getStock() < request.getQuantity()) {throw new OutOfStockException();}// 创建订单Order order = new Order();order.setUserId(user.getId());order.setProductId(product.getId());return orderRepository.save(order);}
}// 拆分后：微服务
@Service
public class OrderService {@Autowiredprivate UserServiceClient userClient; // RPC 调用@Autowiredprivate ProductServiceClient productClient; // RPC 调用@Autowiredprivate OrderRepository orderRepository;public Order createOrder(CreateOrderRequest request) {// 通过 RPC 调用用户服务UserDTO user = userClient.getUser(request.getUserId());// 通过 RPC 调用商品服务ProductDTO product = productClient.getProduct(request.getProductId());// 检查库存if (product.getStock() < request.getQuantity()) {throw new OutOfStockException();}// 创建订单（只操作自己的数据库）Order order = new Order();order.setUserId(user.getId());order.setProductId(product.getId());return orderRepository.save(order);}
}// Feign Client 定义
@FeignClient(name = "product-service")
public interface ProductServiceClient {@GetMapping("/products/{id}")ProductDTO getProduct(@PathVariable Long id);
}
2. API 网关（API Gateway）
📖 概念
API 网关是微服务架构中的统一入口点，负责请求路由、协议转换、聚合、认证鉴权等功能，为客户端提供统一的应用层 API，屏蔽内部服务复杂性。
🎯 核心功能
客户端 (Web/Mobile/Third-party)│▼┌──────────────┐│ API Gateway │ ◄─── 统一入口└──────┬───────┘│┌────────┼────────┐│ │ │▼ ▼ ▼
┌────┐ ┌────┐ ┌────┐
│ S1 │ │ S2 │ │ S3 │ 微服务集群
└────┘ └────┘ └────┘
💡 主要职责
2.1 请求路由与转发
客户端请求: GET /api/users/123│▼API Gateway│├─ /api/users/* → User Service├─ /api/orders/* → Order Service└─ /api/products/* → Product Service
2.2 协议转换
HTTP/HTTPS (外部) ──> API Gateway ──> gRPC/Thrift (内部)
REST ──> API Gateway ──> Message Queue
WebSocket ──> API Gateway ──> HTTP
2.3 API 聚合（Aggregation）
移动端请求: GET /api/home│▼API Gateway/ \/ \▼ ▼User Service Product Service(用户信息) (推荐商品)\ /\ /▼ ▼聚合成一个响应返回{"user": {...},"recommendations": [...]}
2.4 认证与授权
请求 + Token│▼┌────────────┐│ API Gateway││ 验证Token │└─────┬──────┘│验证通过│▼转发到后端服务
🎯 核心模式
BFF (Backend for Frontend)
┌─────────────┐ ┌─────────────┐
│ Web Gateway │ │Mobile Gateway│
│ (BFF-Web) │ │ (BFF-Mobile) │
└──────┬──────┘ └──────┬───────┘│ │└───────────┬───────────┘│┌──────────┼──────────┐▼ ▼ ▼┌────┐ ┌────┐ ┌────┐│ S1 │ │ S2 │ │ S3 │└────┘ └────┘ └────┘
🔧 常用网关
| 网关 | 特点 | 适用场景 |
|---|---|---|
| Kong | 基于 Nginx, 插件丰富 | 企业级、高性能 |
| Spring Cloud Gateway | 响应式编程、Spring 生态 | Spring 技术栈 |
| Zuul | Netflix 开源（1.x 阻塞式） | 传统 Spring 项目 |
| APISIX | 云原生、动态路由 | Kubernetes、高并发 |
| Traefik | 自动服务发现、容器友好 | Docker、K8s |
| Nginx | 高性能、稳定 | 简单路由转发 |
💡 适用场景
- 需要统一的认证鉴权
- 需要对外提供聚合 API
- 跨域、限流、日志等横切关注点
- 需要协议转换（HTTP ↔ gRPC）
- 多端适配（Web、Mobile、小程序）
📝 核心配置示例
# Spring Cloud Gateway 配置
spring:cloud:gateway:routes:# 用户服务路由- id: user-serviceuri: lb://user-service # 负载均衡predicates:- Path=/api/users/**filters:- StripPrefix=1 # 去掉 /api 前缀- AddRequestHeader=X-Request-Source, gateway# 订单服务路由- id: order-serviceuri: lb://order-servicepredicates:- Path=/api/orders/**filters:- StripPrefix=1- name: CircuitBreakerargs:name: orderCircuitBreakerfallbackUri: forward:/fallback/order# 限流配置- id: product-serviceuri: lb://product-servicepredicates:- Path=/api/products/**filters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 10 # 令牌桶填充速率redis-rate-limiter.burstCapacity: 20 # 桶容量
📝 自定义过滤器示例
// 全局认证过滤器
@Component
public class AuthenticationFilter implements GlobalFilter, Ordered {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {ServerHttpRequest request = exchange.getRequest();// 白名单路径if (isWhitelist(request.getPath())) {return chain.filter(exchange);}// 获取 TokenString token = request.getHeaders().getFirst("Authorization");if (token == null || !validateToken(token)) {exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);return exchange.getResponse().setComplete();}// Token 验证通过，添加用户信息到请求头ServerHttpRequest mutatedRequest = request.mutate().header("X-User-Id", getUserIdFromToken(token)).build();return chain.filter(exchange.mutate().request(mutatedRequest).build());}@Overridepublic int getOrder() {return -100; // 优先级高}
}// API 聚合示例
@RestController
@RequestMapping("/api/aggregate")
public class AggregationController {@Autowiredprivate UserServiceClient userClient;@Autowiredprivate OrderServiceClient orderClient;@Autowiredprivate ProductServiceClient productClient;// 聚合用户主页数据@GetMapping("/home")public Mono<HomePageResponse> getHomePage(@RequestHeader("X-User-Id") String userId) {// 并行调用多个服务Mono<UserDTO> userMono = Mono.fromCallable(() -> userClient.getUser(userId));Mono<List<OrderDTO>> ordersMono = Mono.fromCallable(() -> orderClient.getRecentOrders(userId));Mono<List<ProductDTO>> recommendMono = Mono.fromCallable(() -> productClient.getRecommendations(userId));// 合并结果return Mono.zip(userMono, ordersMono, recommendMono).map(tuple -> {HomePageResponse response = new HomePageResponse();response.setUser(tuple.getT1());response.setRecentOrders(tuple.getT2());response.setRecommendations(tuple.getT3());return response;});}
}// Kong 插件配置（Lua）
-- 自定义认证插件
local function authenticate(conf)local token = kong.request.get_header("Authorization")if not token thenreturn kong.response.exit(401, { message = "Unauthorized" })end-- 验证 Token（调用 Redis 或认证服务）local is_valid = validate_token(token)if not is_valid thenreturn kong.response.exit(401, { message = "Invalid token" })end-- 添加用户信息到请求头kong.service.request.set_header("X-User-Id", user_id)
endreturn {[kong.PHASES.access] = authenticate
}
🎯 网关模式对比
单一网关模式:Client ──> API Gateway ──> 所有微服务优点: 简单、统一管理
缺点: 单点故障、性能瓶颈━━━━━━━━━━━━━━━━━━━━━━━━━━━━━BFF 模式:Web ──> Web Gateway ──> 微服务Mobile ──> Mobile Gateway ──> 微服务优点: 针对不同客户端优化
缺点: 维护成本高━━━━━━━━━━━━━━━━━━━━━━━━━━━━━分层网关:Client ──> 接入层网关 ──> 聚合层网关 ──> 微服务优点: 职责分离、灵活
缺点: 复杂度高、延迟增加
⚠️ 注意事项
| 问题 | 解决方案 |
|---|---|
| 单点故障 | 部署多个网关实例 + 负载均衡 |
| 性能瓶颈 | 异步非阻塞、缓存、限流 |
| 超时问题 | 设置合理的超时时间、熔断 |
| 日志追踪 | 生成唯一 Request ID 传递 |
💡 最佳实践
# 1. 统一日志格式
filters:- name: RequestLogargs:format: "RequestId: {requestId}, Path: {path}, Duration: {duration}ms"# 2. 统一异常处理
error:handler:class: GlobalExceptionHandler# 3. 灰度发布
routes:- id: user-service-v2uri: lb://user-service-v2predicates:- Path=/api/users/**- Header=X-Version, v2 # 只有带 v2 header 的请求才路由到新版本# 4. 响应缓存
filters:- name: LocalResponseCacheargs:size: 1000timeToLive: 60s
3. RPC 与服务间通信（RPC & Inter-Service Communication）
📖 概念
RPC (Remote Procedure Call) 是微服务之间进行同步通信的主要方式，允许服务像调用本地方法一样调用远程服务。除了 RPC，还有 REST、消息队列等多种通信方式。
🎯 通信方式对比
┌─────────────┐ ┌─────────────┐
│ Service A │ │ Service B │
└──────┬──────┘ └──────▲──────┘│ ││ 1. 同步通信 (RPC/REST) │└────────────────────────────┘│ │ 2. 异步通信 (Message Queue)▼ ┌─────────┐ ┌─────────┐│ MQ │──────────────>Service B│└─────────┘ └─────────┘
💡 主流通信协议
3.1 RESTful HTTP
优点: 简单、标准、易调试
缺点: 性能较差、数据冗余GET /api/users/123 HTTP/1.1
Host: user-service
Content-Type: application/json{"id": 123,"name": "张三","email": "zhangsan@example.com"
}
3.2 gRPC (推荐)
优点: 高性能、强类型、双向流
缺点: 学习曲线、调试困难基于 HTTP/2 + Protobuf// 定义接口 (user.proto)
syntax = "proto3";service UserService {rpc GetUser(GetUserRequest) returns (User);rpc ListUsers(ListUsersRequest) returns (stream User); // 流式
}message User {int64 id = 1;string name = 2;string email = 3;
}
3.3 Dubbo (阿里)
优点: 国内生态好、功能丰富
缺点: 主要支持 Java特性:
- 自动服务注册发现
- 负载均衡
- 容错机制
- 调用链追踪
3.4 Thrift (Facebook)
优点: 跨语言、高性能
缺点: 生态较弱支持语言:
Java, Python, C++, Go, Node.js...
🎯 通信模式对比
| 模式 | 特点 | 适用场景 | 工具 |
|---|---|---|---|
| 同步 RPC | 实时响应、强依赖 | 查询类操作 | gRPC, Dubbo |
| 异步消息 | 解耦、削峰填谷 | 非实时操作 | RabbitMQ, Kafka |
| REST API | 简单、标准 | 外部接口 | Spring REST |
| GraphQL | 按需查询、减少请求 | 前端驱动 | Apollo |
🔧 gRPC 实战示例
// 1. 定义接口 (order.proto)
syntax = "proto3";package order;service OrderService {// 创建订单rpc CreateOrder(CreateOrderRequest) returns (OrderResponse);// 查询订单rpc GetOrder(GetOrderRequest) returns (OrderResponse);// 订单流（服务端流）rpc StreamOrders(StreamOrdersRequest) returns (stream OrderResponse);// 双向流rpc TrackOrder(stream TrackRequest) returns (stream TrackResponse);
}message CreateOrderRequest {int64 user_id = 1;repeated OrderItem items = 2;string address = 3;
}message OrderResponse {int64 order_id = 1;string status = 2;double total_amount = 3;
}message OrderItem {int64 product_id = 1;int32 quantity = 2;
}
// 2. 服务端实现
@GrpcService
public class OrderServiceImpl extends OrderServiceGrpc.OrderServiceImplBase {@Overridepublic void createOrder(CreateOrderRequest request, StreamObserver<OrderResponse> responseObserver) {try {// 业务逻辑Order order = orderService.create(request);// 构造响应OrderResponse response = OrderResponse.newBuilder().setOrderId(order.getId()).setStatus(order.getStatus()).setTotalAmount(order.getTotalAmount()).build();// 返回结果responseObserver.onNext(response);responseObserver.onCompleted();} catch (Exception e) {responseObserver.onError(Status.INTERNAL.withDescription(e.getMessage()).asRuntimeException());}}// 服务端流示例@Overridepublic void streamOrders(StreamOrdersRequest request,StreamObserver<OrderResponse> responseObserver) {List<Order> orders = orderService.getOrders(request.getUserId());// 逐个发送for (Order order : orders) {OrderResponse response = toResponse(order);responseObserver.onNext(response);}responseObserver.onCompleted();}
}// 3. 客户端调用
@Service
public class OrderClient {@Autowiredprivate OrderServiceGrpc.OrderServiceBlockingStub orderStub;public OrderResponse createOrder(CreateOrderRequest request) {// 同步调用return orderStub.createOrder(request);}// 异步调用public void createOrderAsync(CreateOrderRequest request) {OrderServiceGrpc.OrderServiceStub asyncStub = OrderServiceGrpc.newStub(channel);asyncStub.createOrder(request, new StreamObserver<OrderResponse>() {@Overridepublic void onNext(OrderResponse response) {System.out.println("订单创建成功: " + response.getOrderId());}@Overridepublic void onError(Throwable t) {System.err.println("创建失败: " + t.getMessage());}@Overridepublic void onCompleted() {System.out.println("调用完成");}});}
}
📝 Dubbo 示例
// 1. 定义接口
public interface UserService {User getUser(Long userId);List<User> listUsers(UserQuery query);
}// 2. 服务提供者
@DubboService(version = "1.0.0", timeout = 3000)
public class UserServiceImpl implements UserService {@Overridepublic User getUser(Long userId) {return userRepository.findById(userId);}@Overridepublic List<User> listUsers(UserQuery query) {return userRepository.findAll(query);}
}// 3. 服务消费者
@Service
public class OrderService {@DubboReference(version = "1.0.0", timeout = 3000)private UserService userService;public void createOrder(CreateOrderRequest request) {// 调用远程服务User user = userService.getUser(request.getUserId());// 业务逻辑...}
}// 4. 配置
# application.yml
dubbo:application:name: order-serviceregistry:address: nacos://localhost:8848protocol:name: dubboport: 20880
📝 Spring Cloud OpenFeign 示例
// 1. 定义 Feign Client
@FeignClient(name = "user-service",path = "/api/users",fallback = UserServiceFallback.class // 降级
)
public interface UserServiceClient {@GetMapping("/{id}")UserDTO getUser(@PathVariable("id") Long id);@PostMappingUserDTO createUser(@RequestBody CreateUserRequest request);@GetMappingList<UserDTO> listUsers(@RequestParam("status") String status);
}// 2. 降级实现
@Component
public class UserServiceFallback implements UserServiceClient {@Overridepublic UserDTO getUser(Long id) {// 返回默认值return UserDTO.builder().id(id).name("默认用户").build();}@Overridepublic UserDTO createUser(CreateUserRequest request) {throw new ServiceUnavailableException("用户服务不可用");}@Overridepublic List<UserDTO> listUsers(String status) {return Collections.emptyList();}
}// 3. 使用
@Service
public class OrderService {@Autowiredprivate UserServiceClient userClient;public void createOrder(CreateOrderRequest request) {// 像调用本地方法一样UserDTO user = userClient.getUser(request.getUserId());// ...}
}
🎯 性能对比
请求响应时间对比 (1KB 数据):REST (JSON) ████████████████████ 100ms
gRPC (Protobuf) ████ 20ms
Dubbo ██████ 30ms
Thrift █████ 25ms数据量对比:
JSON ████████████ 1200 bytes
Protobuf ████ 400 bytes
💡 通信选型指南
决策树:需要跨语言支持?
├─ 是 → 性能要求高?
│ ├─ 是 → gRPC / Thrift
│ └─ 否 → REST
└─ 否 → Java 技术栈?├─ 是 → Dubbo (国内) / Spring Cloud (国外)└─ 否 → gRPC异步解耦需求?
└─ 是 → 消息队列 (RabbitMQ, Kafka)
⚠️ 最佳实践
// 1. 超时控制
@GrpcService
public class OrderServiceImpl extends OrderServiceImplBase {@Overridepublic void createOrder(CreateOrderRequest request,StreamObserver<OrderResponse> responseObserver) {// 设置超时Context.current().withDeadlineAfter(3, TimeUnit.SECONDS).run(() -> {// 业务逻辑});}
}// 2. 重试机制
@FeignClient(name = "user-service")
public interface UserServiceClient {@GetMapping("/{id}")@Retryable(value = {SocketTimeoutException.class},maxAttempts = 3,backoff = @Backoff(delay = 1000))UserDTO getUser(@PathVariable Long id);
}// 3. 熔断降级
@DubboService(timeout = 3000,retries = 2,cluster = "failfast",loadbalance = "roundrobin"
)
public class UserServiceImpl implements UserService {// ...
}// 4. 连接池管理
@Bean
public ManagedChannel grpcChannel() {return ManagedChannelBuilder.forAddress("localhost", 9090).usePlaintext().maxInboundMessageSize(10 * 1024 * 1024) // 10MB.keepAliveTime(30, TimeUnit.SECONDS).build();
}
🔧 常用工具
| 工具 | 功能 | 适用协议 |
|---|---|---|
| Postman | API 测试 | REST |
| grpcurl | gRPC 命令行工具 | gRPC |
| BloomRPC | gRPC GUI 客户端 | gRPC |
| Wireshark | 网络抓包 | 所有 |
可靠性保障
4. 熔断（Circuit Breaker）
📖 概念
熔断器是一种保护机制，当服务调用失败率达到阈值时，自动"断开"对该服务的调用，防止故障扩散，类似家里的电路保险丝。
🎯 核心原理
┌─────────────┐
│ Closed │ ──失败次数超阈值──> ┌─────────────┐
│ (正常状态) │ │ Open │
└─────────────┘ │ (熔断状态) │▲ └─────────────┘│ ││ │ 等待超时│ ┌──────▼──────┐└───────成功────────────────│ Half-Open ││ (半开状态) │└─────────────┘
三种状态：
- Closed（关闭）: 正常请求，统计失败率
- Open（打开）: 快速失败，直接返回错误
- Half-Open（半开）: 尝试恢复，放行少量请求测试
💡 适用场景
- 服务依赖较多，需要防止雪崩效应
- 下游服务不稳定，频繁超时或失败
- 需要快速失败，保护系统资源
🔧 常用工具
- Hystrix (Netflix，已停止维护)
- Resilience4j (推荐，轻量级)
- Sentinel (阿里，功能丰富)
📝 示例代码
// Resilience4j 示例
CircuitBreakerConfig config = CircuitBreakerConfig.custom().failureRateThreshold(50) // 失败率50%触发熔断.waitDurationInOpenState(Duration.ofSeconds(60)) // 熔断60秒.slidingWindowSize(10) // 滑动窗口大小.build();CircuitBreaker circuitBreaker = CircuitBreaker.of("userService", config);// 装饰业务方法
Supplier<User> supplier = CircuitBreaker.decorateSupplier(circuitBreaker, () -> userService.getUser(id));Try<User> result = Try.of(supplier::get);
2. 服务发现与注册（Service Discovery & Registration）
📖 概念
在微服务架构中，服务实例动态变化（扩容、缩容、故障），服务发现机制让服务消费者能够自动找到可用的服务提供者。
🎯 核心原理
┌──────────────────┐│ 注册中心 ││ (Registry) │└────────┬─────────┘│┌─────────────────┼─────────────────┐│ 1.注册 │ 2.发现 │▼ ▼ │┌────────────┐ ┌────────────┐ ││ Service A │ │ Service B │ ││ (提供者) │◄───│ (消费者) │ │└────────────┘ └────────────┘ ││ ▲ │└───────3.调用──────┘ │4.健康检查───┘
💡 工作流程
- 服务注册: 服务启动时向注册中心注册自己的地址和元数据
- 服务发现: 消费者从注册中心获取服务列表
- 健康检查: 定期心跳检测，剔除不健康实例
- 负载均衡: 从多个实例中选择一个进行调用
🔧 常用工具
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Consul | 健康检查强、支持多数据中心 | 企业级、多云环境 |
| Eureka | Spring Cloud 原生支持 | Spring 技术栈 |
| Nacos | 配置+注册中心二合一 | 国内阿里系 |
| Etcd | 强一致性、轻量级 | Kubernetes 环境 |
📝 示例代码
// Spring Cloud + Eureka 示例// 服务提供者
@SpringBootApplication
@EnableEurekaClient
public class UserServiceApplication {public static void main(String[] args) {SpringApplication.run(UserServiceApplication.class, args);}
}// application.yml
eureka:client:serviceUrl:defaultZone: http://localhost:8761/eureka/instance:preferIpAddress: truelease-renewal-interval-in-seconds: 30 # 心跳间隔// 服务消费者
@FeignClient(name = "user-service") // 通过服务名调用
public interface UserClient {@GetMapping("/users/{id}")User getUser(@PathVariable Long id);
}
3. 限流（Rate Limiting）
📖 概念
限流是控制流量速率的手段，防止系统被瞬时大量请求压垮，保障服务稳定性。
🎯 常见算法
3.1 固定窗口计数器
时间窗口: [0-1s] [1-2s] [2-3s]
请求数: 100 100 100
阈值: 100
缺点: 窗口临界点可能出现2倍流量
3.2 滑动窗口计数器
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│ │ │ │█│█│█│█│ │ │ │ 每个小格子统计请求数
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘◄────滑动窗口────►
优点: 平滑限流，更精确
3.3 令牌桶（Token Bucket）
┌─────────────┐│ Token Bucket││ [●][●][●] │ ← 固定速率放入令牌└──────┬──────┘│请求拿走令牌 ↓┌─────────────┐│ Request │└─────────────┘
特点: 允许突发流量（桶内有余量）
3.4 漏桶（Leaky Bucket）
请求 → ┌─────────┐│ ╔═══╗ ││ ║ ║ │ 匀速流出│ ║ ║ ││ ╚═══╝ │└────┬────┘↓ 固定速率
特点: 强制匀速处理，削峰填谷
💡 适用场景
| 场景 | 推荐算法 |
|---|---|
| API 限流保护 | 令牌桶 |
| 秒杀系统 | 令牌桶 |
| 消息队列消费 | 漏桶 |
| 简单限流 | 滑动窗口 |
🔧 常用工具
- Guava RateLimiter (单机)
- Redis + Lua (分布式)
- Sentinel (分布式，实时监控)
- Nginx limit_req (网关层)
📝 示例代码
// Guava RateLimiter (令牌桶)
RateLimiter limiter = RateLimiter.create(100); // 每秒100个令牌public void handleRequest() {if (limiter.tryAcquire()) {// 获取到令牌，处理请求processRequest();} else {// 限流，拒绝请求throw new RateLimitException("Too many requests");}
}// Redis + Lua (滑动窗口)
String luaScript = "local key = KEYS[1] " +"local limit = tonumber(ARGV[1]) " +"local window = tonumber(ARGV[2]) " +"local current = redis.call('INCR', key) " +"if current == 1 then " +" redis.call('EXPIRE', key, window) " +"end " +"if current > limit then " +" return 0 " +"end " +"return 1";
4. 链路追踪（Distributed Tracing）
📖 概念
在微服务架构中，一个请求可能经过多个服务，链路追踪帮助我们跟踪请求的完整路径，定位性能瓶颈和故障点。
🎯 核心概念
用户请求 → API Gateway → Service A → Service B → Database│ │ │└─Trace ID────┴────────────┘ (全局唯一)Trace (跟踪)│├─ Span 1 (API Gateway) [开始: 0ms, 耗时: 500ms]│ └─ Span 2 (Service A) [开始: 10ms, 耗时: 300ms]│ └─ Span 3 (Service B)[开始: 50ms, 耗时: 200ms]│ └─ Span 4 (DB) [开始: 60ms, 耗时: 150ms]
核心组件：
- Trace: 完整的请求链路
- Span: 单个操作单元
- Trace ID: 全局唯一标识
- Span ID: 当前操作标识
- Parent Span ID: 父操作标识
💡 追踪数据
{"traceId": "abc123","spanId": "span-1","parentSpanId": null,"serviceName": "api-gateway","operationName": "GET /users","startTime": 1609459200000,"duration": 500,"tags": {"http.method": "GET","http.url": "/users/123","http.status_code": 200},"logs": [{"timestamp": 1609459200100, "event": "cache_miss"}]
}
🎨 可视化界面
Timeline View (时间线视图):Service A ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 500ms
Service B ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 300ms
Service C ━━━━━━━━━━━━━━━━━━━━━━ 200ms
Database ━━━━━━━━━━━━━━━ 150ms
Cache ━━━━ 30ms| | | | | | | |0 50 100 150 200 250 300 350 (ms)
🔧 常用工具
| 工具 | 特点 | 生态 |
|---|---|---|
| Zipkin | 轻量级、易部署 | Twitter 开源 |
| Jaeger | 功能强大、云原生 | Uber 开源，CNCF 项目 |
| SkyWalking | APM 功能完整、国产 | Apache 顶级项目 |
| Pinpoint | 字节码注入、零侵入 | Naver 开源 |
💡 适用场景
- 性能分析：找出慢调用和瓶颈
- 故障排查：快速定位出错服务
- 依赖分析：理解服务间调用关系
- 容量规划：统计各服务负载
📝 示例代码
// Spring Cloud Sleuth + Zipkin
@RestController
public class UserController {@Autowiredprivate Tracer tracer;@GetMapping("/users/{id}")public User getUser(@PathVariable Long id) {// 自动注入 Trace ID 和 Span IDSpan span = tracer.currentSpan();span.tag("user.id", id.toString());try {// 创建自定义 SpanSpan customSpan = tracer.nextSpan().name("database-query").start();try {return userRepository.findById(id);} finally {customSpan.end();}} catch (Exception e) {span.tag("error", "true");span.tag("error.message", e.getMessage());throw e;}}
}// application.yml
spring:zipkin:base-url: http://localhost:9411sleuth:sampler:probability: 1.0 # 采样率 100% (生产环境建议 0.1)
5. 分布式事务（Distributed Transaction）
📖 概念
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，需要保证多个服务的数据一致性。
🎯 解决方案对比
5.1 两阶段提交（2PC）
协调者 参与者A 参与者B│ │ │├─────准备(Prepare)──>│ │├─────准备(Prepare)────────────────>││ │ ││<────可以提交───────┤ ││<────可以提交──────────────────────┤│ │ │├─────提交(Commit)──>│ │├─────提交(Commit)────────────────>││ │ │
优点: 强一致性
缺点:
- 同步阻塞，性能差
- 单点故障风险
- 不适合高并发场景
5.2 TCC（Try-Confirm-Cancel）
┌─────────┐ Try ┌─────────┐ Try ┌─────────┐
│ Order │────────>│ Payment │────────>│ Stock │
│ Service │ │ Service │ │ Service │
└─────────┘ └─────────┘ └─────────┘│ │ ││ Confirm │ Confirm │├──────────────────┼───────────────────┤│ │ ││ (失败时) │ ││ Cancel │ Cancel │└──────────────────┴───────────────────┘
阶段说明：
- Try: 预留资源（冻结库存、预扣款）
- Confirm: 确认提交（扣减库存、真实扣款）
- Cancel: 回滚操作（释放库存、退款）
优点: 性能好，无长时间锁定
缺点: 业务侵入性强，需要实现三个接口
5.3 SAGA 模式
正向流程:
Service A → Service B → Service C → Service D[T1] [T2] [T3] [T4]失败回滚:
Service A ← Service B ← Service C ✗ (失败)[C1] [C2] [C3]每个服务提供:
- Ti: 正向事务
- Ci: 补偿事务
优点:
- 长事务支持良好
- 无需预留资源
- 业务侵入小
缺点:
- 最终一致性（非强一致）
- 需要设计补偿逻辑
5.4 本地消息表
┌────────────────┐
│ Order Service │
├────────────────┤
│ order_table │ ──┐
│ msg_table │ │ 本地事务
└────────────────┘ ││ │▼ │定时扫描未发送 ││ │▼ ▼┌────────────────┐│ Message Queue │└────────────────┘│▼┌────────────────┐│ Payment Service│└────────────────┘
优点:
- 实现简单
- 无需第三方框架
- 可靠性高
缺点:
- 需要定时任务扫描
- 消息表维护成本
5.5 消息队列 + 最终一致性
┌─────────┐ 1.本地事务 ┌─────────┐
│ Service │────────────>│ MySQL │
│ A │ └─────────┘
└─────────┘ ││ ││ 2.发送消息 │▼ ▼
┌─────────┐ ┌─────────┐
│ MQ │ │ Binlog │
└─────────┘ └─────────┘│ ││ 3.消费消息 OR Canal监听▼ ▼
┌─────────┐ ┌─────────┐
│ Service │ │ MQ │
│ B │ └─────────┘
└─────────┘
💡 选型指南
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 金融交易、核心业务 | TCC | 强一致性需求 |
| 订单流程、长事务 | SAGA | 流程清晰，支持长流程 |
| 非核心业务 | 消息队列 | 简单高效 |
| 跨公司/跨平台 | SAGA | 独立部署，松耦合 |
| 遗留系统改造 | 本地消息表 | 侵入性小 |
🔧 常用框架
| 框架 | 支持模式 | 特点 |
|---|---|---|
| Seata | AT、TCC、SAGA、XA | 阿里开源，功能全面 |
| Hmily | TCC | 高性能 TCC 实现 |
| ByteTCC | TCC | 字节开源 |
| ServiceComb | SAGA | 华为开源，微服务治理 |
📝 示例代码
// Seata TCC 模式示例@LocalTCC
public interface OrderTccService {// Try 阶段：创建订单，冻结库存@TwoPhaseBusinessAction(name = "createOrder", commitMethod = "confirm", rollbackMethod = "cancel")boolean createOrder(@BusinessActionContextParameter(paramName = "orderId") Long orderId,BusinessActionContext context);// Confirm 阶段：确认订单，扣减库存boolean confirm(BusinessActionContext context);// Cancel 阶段：取消订单，释放库存boolean cancel(BusinessActionContext context);
}@Service
public class OrderTccServiceImpl implements OrderTccService {@Overridepublic boolean createOrder(Long orderId, BusinessActionContext context) {// 1. 创建订单记录（状态：待确认）Order order = new Order();order.setId(orderId);order.setStatus(OrderStatus.PENDING);orderRepository.save(order);// 2. 调用库存服务冻结库存stockService.freeze(orderId, productId, quantity);return true;}@Overridepublic boolean confirm(BusinessActionContext context) {Long orderId = context.getActionContext("orderId", Long.class);// 1. 更新订单状态为已确认orderRepository.updateStatus(orderId, OrderStatus.CONFIRMED);// 2. 确认扣减库存stockService.deduct(orderId);return true;}@Overridepublic boolean cancel(BusinessActionContext context) {Long orderId = context.getActionContext("orderId", Long.class);// 1. 更新订单状态为已取消orderRepository.updateStatus(orderId, OrderStatus.CANCELLED);// 2. 释放冻结的库存stockService.release(orderId);return true;}
}// SAGA 模式示例（使用 Seata）
@Service
public class OrderSagaService {@GlobalTransactionalpublic void createOrder(OrderRequest request) {// Step 1: 创建订单Order order = orderService.create(request);// Step 2: 扣减库存（如果失败会自动调用补偿）stockService.deduct(request.getProductId(), request.getQuantity());// Step 3: 扣减余额accountService.deduct(request.getUserId(), order.getAmount());// Step 4: 发送通知notificationService.send(order.getId());}
}// 补偿接口
@Service
public class StockCompensation {@Compensate(compensationMethod = "deduct")public void release(Long orderId) {// 补偿逻辑：增加库存stockRepository.increaseStock(orderId);}
}
📚 总结对比
| 概念 | 核心作用 | 关键指标 | 典型工具 |
|---|---|---|---|
| 熔断 | 防止故障扩散 | 失败率、响应时间 | Resilience4j, Sentinel |
| 服务发现 | 动态发现服务 | 可用性、注册延迟 | Consul, Nacos |
| 限流 | 保护系统稳定 | QPS、并发数 | Sentinel, Guava |
| 链路追踪 | 性能分析、故障定位 | 延迟、吞吐量 | Jaeger, SkyWalking |
| 分布式事务 | 保证数据一致性 | 一致性、性能 | Seata, Hmily |
🎯 最佳实践建议
1. 熔断 + 降级组合使用
@HystrixCommand(fallbackMethod = "getUserFallback", // 降级方法commandProperties = {@HystrixProperty(name = "circuitBreaker.enabled", value = "true")}
)
public User getUser(Long id) {return userService.getUser(id);
}// 降级返回默认数据
public User getUserFallback(Long id) {return User.builder().id(id).name("默认用户").build();
}
2. 限流分层设计
网关层 (Nginx/Gateway) → 100,000 QPS↓
服务层 (应用限流) → 10,000 QPS↓
资源层 (数据库/缓存) → 5,000 QPS
3. 链路追踪采样策略
# 生产环境配置
spring:sleuth:sampler:probability: 0.1 # 10% 采样率rate: 100 # 最少每秒100条
4. 分布式事务选型决策树
是否需要强一致性?
├─ 是 → 金额相关?
│ ├─ 是 → TCC
│ └─ 否 → 2PC (慎用)
└─ 否 → 长流程?├─ 是 → SAGA└─ 否 → 消息队列 + 最终一致性
5. 服务降级（Service Degradation）
📖 概念
服务降级是在系统压力过大或部分服务不可用时，主动关闭或降低某些非核心功能，保证核心业务正常运行的策略。
🎯 降级策略
正常情况:
用户请求 → 完整功能 (推荐算法 + 个性化 + 实时数据)降级情况:
用户请求 → 核心功能 (基础数据 + 缓存 + 默认值)
💡 降级级别
| 级别 | 降级内容 | 示例 |
|---|---|---|
| L1 轻度 | 关闭非核心功能 | 关闭推荐算法，显示热门商品 |
| L2 中度 | 使用缓存数据 | 显示昨天的数据 |
| L3 重度 | 返回默认值 | 显示固定内容 |
| L4 极度 | 拒绝服务 | 返回"系统繁忙" |
📝 示例代码
@Service
public class ProductService {@Autowiredprivate RecommendationService recommendationService;@Autowiredprivate CacheManager cacheManager;// 手动降级开关@Value("${degradation.recommendation.enabled:false}")private boolean degradationEnabled;public List<Product> getRecommendations(Long userId) {if (degradationEnabled) {// 降级：返回热门商品return getHotProducts();}try {// 正常：调用推荐算法return recommendationService.recommend(userId);} catch (Exception e) {// 异常降级log.warn("推荐服务异常，降级为热门商品", e);return getHotProducts();}}private List<Product> getHotProducts() {return cacheManager.get("hot_products", List.class);}
}// 配置中心动态开关
@RestController
@RequestMapping("/admin/degradation")
public class DegradationController {@Autowiredprivate ConfigurableEnvironment environment;@PostMapping("/recommendation/enable")public void enableDegradation() {System.setProperty("degradation.recommendation.enabled", "true");// 通知配置中心更新}
}
6. 重试与超时（Retry & Timeout）
📖 概念
重试机制在请求失败时自动重新发起请求，超时控制防止请求无限等待。两者配合使用可以提高系统可靠性。
🎯 重试策略
请求失败│▼是否可重试? (幂等性)│├─ 否 → 直接失败│└─ 是 → 重试│├─ 固定间隔: 1s, 1s, 1s├─ 递增间隔: 1s, 2s, 4s└─ 指数退避: 1s, 2s, 4s, 8s, 16s (推荐)
📝 示例代码
// Spring Retry
@Service
public class OrderService {@Retryable(value = {TimeoutException.class, IOException.class},maxAttempts = 3,backoff = @Backoff(delay = 1000, multiplier = 2))public Order createOrder(OrderRequest request) {return orderClient.create(request);}@Recoverpublic Order recover(Exception e, OrderRequest request) {// 重试失败后的兜底逻辑log.error("订单创建失败", e);throw new OrderCreationException("订单服务不可用");}
}// Resilience4j Retry
RetryConfig config = RetryConfig.custom().maxAttempts(3).waitDuration(Duration.ofSeconds(1)).retryExceptions(IOException.class, TimeoutException.class).ignoreExceptions(IllegalArgumentException.class).build();Retry retry = Retry.of("orderService", config);// 超时控制
@Configuration
public class HttpClientConfig {@Beanpublic RestTemplate restTemplate() {SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();factory.setConnectTimeout(3000); // 连接超时 3sfactory.setReadTimeout(5000); // 读取超时 5sreturn new RestTemplate(factory);}
}
7. 隔离（Isolation）
📖 概念
隔离是将系统资源（线程、连接、内存）分配给不同的服务调用，防止某个服务的故障影响其他服务。
🎯 隔离方式
7.1 线程池隔离
┌─────────────────────────────┐
│ Service A │
│ ThreadPool (10 threads) │
└─────────────────────────────┘┌─────────────────────────────┐
│ Service B │
│ ThreadPool (20 threads) │
└─────────────────────────────┘优点: 完全隔离
缺点: 线程切换开销
7.2 信号量隔离
Service A: Semaphore (100 permits)
Service B: Semaphore (200 permits)优点: 轻量级
缺点: 无超时控制
📝 示例代码
// Hystrix 线程池隔离
@HystrixCommand(commandKey = "getUserById",threadPoolKey = "userServicePool",threadPoolProperties = {@HystrixProperty(name = "coreSize", value = "10"),@HystrixProperty(name = "maxQueueSize", value = "100")}
)
public User getUser(Long id) {return userService.getUser(id);
}// Resilience4j Bulkhead (信号量隔离)
BulkheadConfig config = BulkheadConfig.custom().maxConcurrentCalls(25).maxWaitDuration(Duration.ofMillis(500)).build();Bulkhead bulkhead = Bulkhead.of("orderService", config);
配置与治理
10. 配置中心（Configuration Center）
📖 概念
配置中心集中管理微服务的配置信息，支持动态更新、版本管理、灰度发布等功能。
🎯 核心功能
┌──────────────────┐
│ Config Center │
│ (Nacos/Apollo) │
└────────┬─────────┘│┌────┼────┐│ │ │▼ ▼ ▼┌──┐ ┌──┐ ┌──┐│S1│ │S2│ │S3│ 监听配置变化└──┘ └──┘ └──┘ 自动刷新
📝 示例 (Nacos)
# bootstrap.yml
spring:application:name: user-servicecloud:nacos:config:server-addr: localhost:8848file-extension: yamlgroup: DEFAULT_GROUP
@RefreshScope // 支持动态刷新
@RestController
public class ConfigController {@Value("${feature.recommendation.enabled:false}")private boolean recommendationEnabled;@GetMapping("/config")public Map<String, Object> getConfig() {return Map.of("recommendationEnabled", recommendationEnabled);}
}
11. 负载均衡（Load Balancing）
📖 概念
负载均衡将请求分发到多个服务实例，提高系统可用性和性能。
🎯 负载均衡算法
客户端请求│▼负载均衡器│┌──┼──┐▼ ▼ ▼S1 S2 S3算法:
1. 轮询 (Round Robin) → 1,2,3,1,2,3...
2. 随机 (Random) → 2,1,3,2,1...
3. 加权轮询 → 1,1,2,3,1,1,2,3 (权重1:1:2:3)
4. 最少连接 → 选择连接数最少的
5. 一致性哈希 → 根据请求特征路由
📝 示例代码
// Ribbon 配置
@Configuration
public class RibbonConfig {@Beanpublic IRule ribbonRule() {// 随机策略return new RandomRule();// 或使用加权响应时间// return new WeightedResponseTimeRule();// 或使用最少并发// return new BestAvailableRule();}
}// Spring Cloud LoadBalancer
@LoadBalanced
@Bean
public RestTemplate restTemplate() {return new RestTemplate();
}// 使用
String url = "http://user-service/api/users/" + userId;
User user = restTemplate.getForObject(url, User.class);
12. 服务网格（Service Mesh）
📖 概念
服务网格通过 Sidecar 代理模式管理服务间通信，实现流量管理、安全、可观测性等功能，无需修改业务代码。
🎯 架构
┌──────────────┐ ┌──────────────┐
│ Service A │ │ Service B │
└──────┬───────┘ └──────┬───────┘│ │▼ ▼
┌──────────────┐ ┌──────────────┐
│ Sidecar │◄────>│ Sidecar │
│ (Envoy) │ │ (Envoy) │
└──────┬───────┘ └──────────────┘│▼Control Plane(Istio)
🔧 Istio 示例
# 流量管理
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: user-service
spec:hosts:- user-servicehttp:- match:- headers:version:exact: v2route:- destination:host: user-servicesubset: v2- route:- destination:host: user-servicesubset: v1weight: 90- destination:host: user-servicesubset: v2weight: 10 # 灰度 10%
可观测性
14. 日志聚合（Log Aggregation）
📖 概念
日志聚合将分散在各个服务的日志集中收集、存储和分析。
🎯 ELK 架构
Services → Filebeat → Logstash → Elasticsearch → Kibana(收集) (处理) (存储) (展示)
📝 配置示例
# logback-spring.xml
<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender"><destination>localhost:5000</destination><encoder class="net.logstash.logback.encoder.LogstashEncoder"><customFields>{"app":"user-service"}</customFields></encoder>
</appender>
15. 监控告警（Monitoring & Alerting）
📖 概念
监控系统实时采集指标数据，异常时触发告警。
🎯 Prometheus + Grafana
Services (暴露 /metrics) → Prometheus (采集存储) → Grafana (可视化)↓Alertmanager (告警)
📝 示例
@RestController
public class MetricsController {@Autowiredprivate MeterRegistry registry;public void recordOrder() {registry.counter("orders.created").increment();registry.timer("order.creation.time").record(() -> {// 业务逻辑});}
}
16. 健康检查（Health Check）
📖 概念
健康检查用于判断服务实例是否正常工作。
📝 Spring Boot Actuator
@Component
public class CustomHealthIndicator implements HealthIndicator {@Overridepublic Health health() {if (checkDatabase() && checkRedis()) {return Health.up().withDetail("status", "healthy").build();}return Health.down().withDetail("reason", "DB connection failed").build();}
}
# Kubernetes Probe
livenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 30periodSeconds: 10readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 10periodSeconds: 5
安全与认证
17. 认证与授权（Authentication & Authorization）
📖 概念
认证验证"你是谁"，授权控制"你能做什么"。
🎯 OAuth2 + JWT
Client → API Gateway (验证JWT) → Services│▼Auth Service (颁发Token)
📝 示例
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {@Overrideprotected void configure(HttpSecurity http) throws Exception {http.authorizeRequests().antMatchers("/api/public/**").permitAll().antMatchers("/api/admin/**").hasRole("ADMIN").anyRequest().authenticated().and().oauth2ResourceServer().jwt();}
}
18. API 安全（API Security）
📖 概念
保护 API 免受攻击，包括防重放、防篡改、限流等。
📝 签名验证
public class SignatureUtil {public static String sign(Map<String, String> params, String secret) {String content = params.entrySet().stream().sorted(Map.Entry.comparingByKey()).map(e -> e.getKey() + "=" + e.getValue()).collect(Collectors.joining("&"));return HMACSHA256(content + secret);}public static boolean verify(String sign, Map<String, String> params, String secret) {return sign.equals(sign(params, secret));}
}
19. 服务间认证（Service-to-Service Auth）
📖 概念
服务间调用的身份验证，常用 mTLS 或 Service Account Token。
📝 mTLS (Mutual TLS)
# Istio 配置
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: default
spec:mtls:mode: STRICT # 强制 mTLS
数据管理
21. 分布式缓存（Distributed Cache）
📖 概念
使用 Redis、Memcached 等分布式缓存提升性能。
📝 Spring Cache
@Service
public class UserService {@Cacheable(value = "users", key = "#id")public User getUser(Long id) {return userRepository.findById(id);}@CacheEvict(value = "users", key = "#user.id")public void updateUser(User user) {userRepository.save(user);}
}
22. 数据一致性（Data Consistency）
📖 概念
CAP 理论：一致性、可用性、分区容错性，三者只能取其二。
CAP 三角:C (Consistency)/ \/ \/ \A ───── P
(Availability) (Partition Tolerance)选择:
- CA: 传统关系型数据库 (单机)
- CP: Zookeeper, Etcd (强一致性)
- AP: Cassandra, DynamoDB (最终一致性)
23. 数据库分片（Database Sharding）
📖 概念
将数据分散到多个数据库实例，提高性能和扩展性。
🎯 分片策略
水平分片:
user_0: userId 0-999
user_1: userId 1000-1999
user_2: userId 2000-2999路由规则: userId % 3
📝 ShardingSphere
spring:shardingsphere:datasource:names: ds0,ds1,ds2sharding:tables:t_user:actual-data-nodes: ds$->{0..2}.t_usertable-strategy:inline:sharding-column: user_idalgorithm-expression: ds$->{user_id % 3}
部署与运维
24. 容器化（Containerization）
📖 概念
使用 Docker 容器化应用，实现一致的运行环境。
📝 Dockerfile
FROM openjdk:11-jre-slim
WORKDIR /app
COPY target/user-service.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
25. CI/CD
📖 概念
持续集成和持续部署自动化软件交付流程。
📝 GitHub Actions
name: CI/CD
on: [push]
jobs:build:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v2- name: Buildrun: mvn clean package- name: Docker Buildrun: docker build -t myapp:latest .- name: Deployrun: kubectl apply -f k8s/
26. 灰度发布（Canary Deployment）
📖 概念
新版本先发布到少量用户，验证无问题后逐步扩大范围。
V1 (90%) ████████████████████
V2 (10%) ██
高级模式
27. 事件驱动架构（Event-Driven Architecture）
📖 概念
通过事件进行服务间通信，实现松耦合。
Order Service (发布事件) → Event Bus → Inventory Service (订阅)→ Notification Service (订阅)
28. BFF 模式（Backend for Frontend）
📖 概念
为不同前端（Web/Mobile）提供定制化的后端服务。
Web BFF → 聚合多个服务返回完整数据
Mobile BFF → 返回精简数据节省流量
29. 领域驱动设计（DDD in Microservices）
📖 概念
使用 DDD 划分限界上下文，每个微服务对应一个限界上下文。
订单上下文:- 订单聚合根- 订单仓储- 订单领域服务用户上下文:- 用户聚合根- 用户仓储- 用户领域服务
📚 完整总结对比
| 概念 | 分类 | 核心作用 | 典型工具 |
|---|---|---|---|
| 服务拆分 | 基础架构 | 单体拆分为微服务 | DDD, 事件风暴 |
| API 网关 | 基础架构 | 统一入口、路由聚合 | Kong, Spring Cloud Gateway |
| RPC 通信 | 基础架构 | 服务间调用 | gRPC, Dubbo, Feign |
| 熔断 | 可靠性 | 防止故障扩散 | Resilience4j, Sentinel |
| 降级 | 可靠性 | 保证核心功能 | 配置开关 |
| 重试 | 可靠性 | 提高成功率 | Spring Retry |
| 隔离 | 可靠性 | 资源隔离 | Hystrix, Bulkhead |
| 限流 | 可靠性 | 流量控制 | Sentinel, Guava |
| 服务发现 | 配置治理 | 动态发现服务 | Consul, Nacos |
| 配置中心 | 配置治理 | 集中配置管理 | Nacos, Apollo |
| 负载均衡 | 配置治理 | 流量分发 | Ribbon, Nginx |
| 服务网格 | 配置治理 | 流量治理 | Istio, Linkerd |
| 链路追踪 | 可观测性 | 调用链分析 | Jaeger, SkyWalking |
| 日志聚合 | 可观测性 | 集中日志管理 | ELK, Loki |
| 监控告警 | 可观测性 | 指标监控 | Prometheus, Grafana |
| 健康检查 | 可观测性 | 实例健康状态 | Actuator, K8s Probe |
| 认证授权 | 安全 | 身份验证 | OAuth2, JWT |
| API 安全 | 安全 | 防攻击 | 签名, 加密 |
| 服务间认证 | 安全 | 内部认证 | mTLS, Token |
| 分布式事务 | 数据管理 | 数据一致性 | Seata, Saga |
| 分布式缓存 | 数据管理 | 性能优化 | Redis, Memcached |
| 数据一致性 | 数据管理 | CAP 理论 | 最终一致性 |
| 数据库分片 | 数据管理 | 水平扩展 | ShardingSphere |
| 容器化 | 部署运维 | 环境一致性 | Docker, Kubernetes |
| CI/CD | 部署运维 | 自动化交付 | Jenkins, GitLab CI |
| 灰度发布 | 部署运维 | 平滑升级 | Istio, K8s |
| 事件驱动 | 高级模式 | 异步解耦 | Kafka, RabbitMQ |
| BFF | 高级模式 | 前端适配 | GraphQL, 定制网关 |
| DDD | 高级模式 | 领域建模 | 限界上下文 |
📖 参考资料
官方文档
- Spring Cloud 官方文档
- Resilience4j GitHub
- Seata 分布式事务
- Apache SkyWalking
- Istio 服务网格
- Kubernetes 官方文档
经典文章
- Martin Fowler - Circuit Breaker
- Martin Fowler - Microservices
- Chris Richardson - Microservices Patterns
- Chris Richardson - SAGA Pattern
书籍推荐
- 《微服务架构设计模式》- Chris Richardson
- 《Spring Cloud 微服务实战》
- 《领域驱动设计》- Eric Evans
- 《凤凰架构》- 周志明
💡 使用建议
适用人群
- 初学者: 快速了解微服务全貌，建立完整知识体系
- 开发者: 日常开发时快速查阅技术细节和代码示例
- 架构师: 技术选型和架构设计的参考依据
- 面试准备: 系统复习微服务核心概念
阅读路径
🔰 入门路径（按顺序阅读）
1. 服务拆分 → 2. API 网关 → 3. RPC 通信 ↓
4. 服务发现 → 5. 负载均衡 → 6. 配置中心↓
7. 熔断 → 8. 降级 → 9. 限流
🚀 进阶路径（根据需要选读）
可靠性挑战 → 熔断、降级、重试、隔离、限流
可观测性问题 → 链路追踪、日志聚合、监控告警、健康检查
数据一致性 → 分布式事务、数据一致性理论、分布式缓存
⚡ 实战路径（问题驱动）
性能问题 → 分布式缓存、数据库分片、负载均衡
稳定性问题 → 熔断降级、隔离、限流
数据一致性 → 分布式事务、最终一致性
安全问题 → 认证授权、API 安全、服务间认证
实践建议
- 循序渐进: 不要一次性应用所有模式，根据实际需求逐步引入
- 工具选型: 优先选择团队熟悉的技术栈，避免过度追求新技术
- 监控先行: 在引入复杂机制前，先建立完善的监控体系
- 压测验证: 任何优化都要通过压测验证效果
- 文档同步: 架构演进时及时更新团队文档
常见误区
❌ 过度拆分: 不要为了微服务而微服务，初期可以保持适度粗粒度
❌ 忽略运维: 微服务增加了运维复杂度，需要完善的 DevOps 体系
❌ 数据共享: 避免服务间直接共享数据库，破坏服务自治性
❌ 同步调用链过长: 超过 3 层同步调用链会严重影响性能和稳定性
❌ 忽略分布式事务: 服务拆分后要提前规划数据一致性方案
💡 提示: 这是一份实用参考手册，每个概念在实际应用中都有更多细节和坑点。建议收藏本文档，在遇到具体问题时快速定位相关章节，结合官方文档深入学习。
📌 持续更新: 微服务技术栈不断演进，本手册会定期更新。如有疑问或建议，欢迎反馈。