一份全面的微服务架构参考手册，系统梳理 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 {
    @Autowired
    private UserRepository userRepository;
    @Autowired
    private ProductRepository productRepository;
    @Autowired
    private 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 {
    @Autowired
    private UserServiceClient userClient;  // RPC 调用
    @Autowired
    private ProductServiceClient productClient;  // RPC 调用
    @Autowired
    private 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-service
          uri: lb://user-service  # 负载均衡
          predicates:
            - Path=/api/users/**
          filters:
            - StripPrefix=1       # 去掉 /api 前缀
            - AddRequestHeader=X-Request-Source, gateway
            
        # 订单服务路由
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1
            - name: CircuitBreaker
              args:
                name: orderCircuitBreaker
                fallbackUri: forward:/fallback/order
        
        # 限流配置
        - id: product-service
          uri: lb://product-service
          predicates:
            - Path=/api/products/**
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10  # 令牌桶填充速率
                redis-rate-limiter.burstCapacity: 20  # 桶容量

📝 自定义过滤器示例

// 全局认证过滤器
@Component
public class AuthenticationFilter implements GlobalFilter, Ordered {
    
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest request = exchange.getRequest();
        
        // 白名单路径
        if (isWhitelist(request.getPath())) {
            return chain.filter(exchange);
        }
        
        // 获取 Token
        String 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());
    }
    
    @Override
    public int getOrder() {
        return -100;  // 优先级高
    }
}

// API 聚合示例
@RestController
@RequestMapping("/api/aggregate")
public class AggregationController {
    
    @Autowired
    private UserServiceClient userClient;
    @Autowired
    private OrderServiceClient orderClient;
    @Autowired
    private 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 then
    return kong.response.exit(401, { message = "Unauthorized" })
  end
  
  -- 验证 Token（调用 Redis 或认证服务）
  local is_valid = validate_token(token)
  
  if not is_valid then
    return kong.response.exit(401, { message = "Invalid token" })
  end
  
  -- 添加用户信息到请求头
  kong.service.request.set_header("X-User-Id", user_id)
end

return {
  [kong.PHASES.access] = authenticate
}

🎯 网关模式对比

单一网关模式:
   Client ──> API Gateway ──> 所有微服务

优点: 简单、统一管理
缺点: 单点故障、性能瓶颈

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

BFF 模式:
   Web     ──> Web Gateway    ──> 微服务
   Mobile  ──> Mobile Gateway ──> 微服务

优点: 针对不同客户端优化
缺点: 维护成本高

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

分层网关:
   Client ──> 接入层网关 ──> 聚合层网关 ──> 微服务

优点: 职责分离、灵活
缺点: 复杂度高、延迟增加

⚠️ 注意事项

问题	解决方案
单点故障	部署多个网关实例 + 负载均衡
性能瓶颈	异步非阻塞、缓存、限流
超时问题	设置合理的超时时间、熔断
日志追踪	生成唯一 Request ID 传递

💡 最佳实践

# 1. 统一日志格式
filters:
  - name: RequestLog
    args:
      format: "RequestId: {requestId}, Path: {path}, Duration: {duration}ms"

# 2. 统一异常处理
error:
  handler:
    class: GlobalExceptionHandler

# 3. 灰度发布
routes:
  - id: user-service-v2
    uri: lb://user-service-v2
    predicates:
      - Path=/api/users/**
      - Header=X-Version, v2  # 只有带 v2 header 的请求才路由到新版本

# 4. 响应缓存
filters:
  - name: LocalResponseCache
    args:
      size: 1000
      timeToLive: 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 {
    
    @Override
    public 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()
            );
        }
    }
    
    // 服务端流示例
    @Override
    public 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 {
    
    @Autowired
    private 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>() {
            @Override
            public void onNext(OrderResponse response) {
                System.out.println("订单创建成功: " + response.getOrderId());
            }
            
            @Override
            public void onError(Throwable t) {
                System.err.println("创建失败: " + t.getMessage());
            }
            
            @Override
            public 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 {
    
    @Override
    public User getUser(Long userId) {
        return userRepository.findById(userId);
    }
    
    @Override
    public 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-service
  registry:
    address: nacos://localhost:8848
  protocol:
    name: dubbo
    port: 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);
    
    @PostMapping
    UserDTO createUser(@RequestBody CreateUserRequest request);
    
    @GetMapping
    List<UserDTO> listUsers(@RequestParam("status") String status);
}

// 2. 降级实现
@Component
public class UserServiceFallback implements UserServiceClient {
    
    @Override
    public UserDTO getUser(Long id) {
        // 返回默认值
        return UserDTO.builder()
            .id(id)
            .name("默认用户")
            .build();
    }
    
    @Override
    public UserDTO createUser(CreateUserRequest request) {
        throw new ServiceUnavailableException("用户服务不可用");
    }
    
    @Override
    public List<UserDTO> listUsers(String status) {
        return Collections.emptyList();
    }
}

// 3. 使用
@Service
public class OrderService {
    
    @Autowired
    private 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 {
    
    @Override
    public 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.健康检查───┘

💡 工作流程

1. 服务注册: 服务启动时向注册中心注册自己的地址和元数据
2. 服务发现: 消费者从注册中心获取服务列表
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: true
    lease-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 {
    
    @Autowired
    private Tracer tracer;
    
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        // 自动注入 Trace ID 和 Span ID
        Span span = tracer.currentSpan();
        span.tag("user.id", id.toString());
        
        try {
            // 创建自定义 Span
            Span 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:9411
  sleuth:
    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 {
    
    @Override
    public 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;
    }
    
    @Override
    public boolean confirm(BusinessActionContext context) {
        Long orderId = context.getActionContext("orderId", Long.class);
        
        // 1. 更新订单状态为已确认
        orderRepository.updateStatus(orderId, OrderStatus.CONFIRMED);
        
        // 2. 确认扣减库存
        stockService.deduct(orderId);
        
        return true;
    }
    
    @Override
    public 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 {
    
    @GlobalTransactional
    public 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 {
    
    @Autowired
    private RecommendationService recommendationService;
    
    @Autowired
    private 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 {
    
    @Autowired
    private 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);
    }
    
    @Recover
    public 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 {
    
    @Bean
    public RestTemplate restTemplate() {
        SimpleClientHttpRequestFactory factory = 
            new SimpleClientHttpRequestFactory();
        factory.setConnectTimeout(3000);     // 连接超时 3s
        factory.setReadTimeout(5000);        // 读取超时 5s
        return 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-service
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        file-extension: yaml
        group: 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 {
    
    @Bean
    public 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-service
  http:
    - match:
        - headers:
            version:
              exact: v2
      route:
        - destination:
            host: user-service
            subset: v2
    - route:
        - destination:
            host: user-service
            subset: v1
          weight: 90
        - destination:
            host: user-service
            subset: v2
          weight: 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 {
    
    @Autowired
    private 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 {
    
    @Override
    public 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/liveness
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

---

安全与认证

17. 认证与授权（Authentication & Authorization）

📖 概念

认证验证"你是谁"，授权控制"你能做什么"。

🎯 OAuth2 + JWT

Client → API Gateway (验证JWT) → Services
           │
           ▼
      Auth Service (颁发Token)

📝 示例

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Override
    protected 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,ds2
    sharding:
      tables:
        t_user:
          actual-data-nodes: ds$->{0..2}.t_user
          table-strategy:
            inline:
              sharding-column: user_id
              algorithm-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-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build
        run: mvn clean package
      - name: Docker Build
        run: docker build -t myapp:latest .
      - name: Deploy
        run: 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 安全、服务间认证

实践建议

1. 循序渐进: 不要一次性应用所有模式，根据实际需求逐步引入
2. 工具选型: 优先选择团队熟悉的技术栈，避免过度追求新技术
3. 监控先行: 在引入复杂机制前，先建立完善的监控体系
4. 压测验证: 任何优化都要通过压测验证效果
5. 文档同步: 架构演进时及时更新团队文档

常见误区

❌ 过度拆分: 不要为了微服务而微服务，初期可以保持适度粗粒度
❌ 忽略运维: 微服务增加了运维复杂度，需要完善的 DevOps 体系
❌ 数据共享: 避免服务间直接共享数据库，破坏服务自治性
❌ 同步调用链过长: 超过 3 层同步调用链会严重影响性能和稳定性
❌ 忽略分布式事务: 服务拆分后要提前规划数据一致性方案

---

💡 提示: 这是一份实用参考手册，每个概念在实际应用中都有更多细节和坑点。建议收藏本文档，在遇到具体问题时快速定位相关章节，结合官方文档深入学习。

📌 持续更新: 微服务技术栈不断演进，本手册会定期更新。如有疑问或建议，欢迎反馈。