microservices

name	microservices
description	微服务架构模式 —— 服务拆分原则、通信模式、数据一致性与治理框架
category	架构设计
loading	on-demand
triggers	{"keywords":["微服务","microservices","服务拆分","服务治理","分布式","服务间通信"]}

微服务架构模式

概述

提供微服务架构从设计到运维的完整参考，覆盖服务拆分策略、通信模式选择、数据一致性方案和服务治理实践。

使用场景

• 评估是否应该从单体迁移到微服务
• 确定服务边界和拆分粒度
• 选择服务间通信方式（同步/异步）
• 设计分布式数据一致性方案

核心原则

1. 先单体再拆分：不确定边界时从模块化单体开始。边界稳定后再提取为独立服务。不要过早微服务化。
2. 按业务能力拆分：每个微服务对应一个业务领域（DDD 有界上下文），而非按技术层拆分。
3. 数据库独立：每个微服务拥有自己的数据库（或 Schema），共享数据库会导致紧耦合。
4. 异步通信优先：服务间用消息队列解耦，减少同步调用链。同步调用仅用于需要即时结果的场景。
5. 最终一致性接受：分布式系统中强一致性代价高昂。业务上接受短暂不一致，通过补偿/对账保证最终一致。

通信模式

• 同步：REST API、gRPC —— 适合查询类操作，需要即时响应
• 异步：消息队列（RabbitMQ/Kafka）、事件总线 —— 适合命令类操作，解耦服务
• 编排 vs 编排：Choreography（事件驱动无中心）vs Orchestration（Saga 编排器协调）

检查清单

• 是否有明确的理由选择微服务而非单体？
• 服务边界是否与业务领域边界对齐？
• 每个服务是否有独立数据库？
• 分布式事务是否采用了 Saga 或其他最终一致性方案？
• 是否有服务发现、负载均衡、配置中心的治理方案？