本页脑图：微服务和分布式
微服务分布式
微服务
- DDD 拆分
- 独立部署
- 独立数据
- 接口契约
治理
- 网关
- 注册发现
- 配置中心
- 熔断限流
- 链路追踪
CAP/BASE
- CP/AP 取舍
- 基本可用
- 软状态
- 最终一致
事务
- 2PC/3PC
- TCC
- Saga
- 本地消息表
单体、SOA、微服务对比
| 维度 | 单体 | SOA | 微服务 |
|---|---|---|---|
| 部署 | 整体部署，一处改动常全量发布。 | 服务可复用，常依赖 ESB。 | 服务独立部署、独立扩缩容。 |
| 粒度 | 模块在一个应用内。 | 企业级服务，粒度偏粗。 | 围绕业务能力，粒度较细。 |
| 数据 | 常共享数据库。 | 可能共享企业数据模型。 | 强调服务自治，数据库独立。 |
| 适合 | 小团队、业务简单、快速起步。 | 异构系统集成。 | 复杂业务、高并发、快速迭代。 |
| 风险 | 耦合、发布慢、扩展困难。 | 中心化总线可能重。 | 分布式复杂、运维治理成本高。 |
论文里不要把微服务写成“拆多个服务”就完了，要强调独立部署、独立数据、接口契约、服务治理和故障隔离。
微服务治理组件
API 网关
统一入口，负责路由、鉴权、限流、协议转换。适合写安全和流量治理前置。
注册发现
服务实例动态上下线，调用方通过注册中心发现地址，适合弹性扩缩容。
配置中心
统一管理配置、开关、阈值，支持动态刷新和灰度。
熔断降级
下游慢或故障时快速失败，返回兜底结果，防止线程耗尽。
限流
令牌桶、漏桶、滑动窗口，保护系统不被突发流量压垮。
链路追踪
记录一次请求经过的服务路径，用于定位慢点和错误源。
口诀：网关进，注册找，配置管，熔断保，限流挡，链路查。
治理组件细化：每个组件解决什么问题
| 组件 | 没有它的问题 | 它解决什么 | 常见技术 | 案例题关键词 |
|---|---|---|---|---|
| API 网关 | 客户端直接访问多个服务，鉴权和限流分散。 | 统一入口、路由、鉴权、限流、协议转换。 | Spring Cloud Gateway、Kong、Nginx | 统一入口、外部访问、安全前置。 |
| 注册中心 | 服务地址写死，扩缩容后调用方不知道新实例。 | 服务实例注册、发现、上下线感知。 | Nacos、Eureka、Consul | 动态扩容、服务发现。 |
| 配置中心 | 配置散落在各服务，改阈值要重新发版。 | 集中配置、动态刷新、灰度开关。 | Nacos、Apollo、Spring Cloud Config | 动态阈值、开关、灰度。 |
| 熔断降级 | 下游慢导致线程池耗尽，引发级联故障。 | 快速失败、返回兜底、隔离故障。 | Sentinel、Resilience4j、Hystrix | 雪崩、超时、兜底。 |
| 链路追踪 | 调用链长，出错后不知道慢在哪。 | 记录请求路径、延迟、错误位置。 | SkyWalking、Zipkin、Jaeger | 定位慢调用、根因分析。 |
DDD 指导微服务拆分
DDD 的价值是让服务边界来自业务，而不是来自数据库表或技术层次。考试中提到“服务拆分依据”，优先写 DDD。
战略设计
统一语言、限界上下文、上下文映射。用来确定服务边界和团队边界。
战术设计
实体、值对象、聚合根、领域服务、领域事件。用来组织服务内部模型。
用户认证例子：认证上下文负责登录、Token 生成和会话；权限上下文负责角色、资源、授权策略；审计上下文负责登录日志和异常检测。跨上下文通过领域事件同步，避免服务之间直接共享数据库。
服务拆分原则和反模式
好的拆分
- 围绕业务能力，而不是围绕 controller/service/dao 技术层。
- 一个服务拥有自己的数据，避免多个服务共享表。
- 服务边界内强一致，边界之间最终一致。
- 高内聚、低耦合，团队可以独立开发部署。
常见反模式
- 按数据库表一表一服务，导致服务过细。
- 所有服务共用一个数据库，逻辑拆了数据没拆。
- 服务之间互相同步调用过多，形成分布式单体。
- 没有网关、监控和熔断，拆完稳定性更差。
CAP 与 BASE
CAP
C 是一致性，A 是可用性，P 是分区容错性。分布式系统网络分区不可避免，所以常在 CP 与 AP 之间取舍。金融核心偏 CP，评论点赞通知偏 AP。
BASE
基本可用、软状态、最终一致。高并发互联网业务常用：先保证系统可用，再通过重试、补偿、对账达到最终一致。
分布式事务方案
| 方案 | 思想 | 优点 | 缺点 | 适用 |
|---|---|---|---|---|
| 2PC | 准备 + 提交，由协调者统一提交或回滚。 | 强一致。 | 阻塞、性能低、协调者风险。 | 强一致、低并发场景。 |
| 3PC | 增加预提交阶段，降低阻塞。 | 比 2PC 更少阻塞。 | 实现复杂，工程少用。 | 理论题常见。 |
| TCC | Try 预留，Confirm 确认，Cancel 取消。 | 业务可控，性能较好。 | 业务侵入强，需处理幂等和空回滚。 | 秒杀库存、优惠券、支付预授权。 |
| Saga | 长事务拆成本地事务，每步有补偿。 | 松耦合，适合长流程。 | 中间状态可见，补偿复杂。 | 订单、物流、跨系统流程。 |
| 本地消息表 | 业务和消息同库提交，再异步投递。 | 实现稳妥，最终一致。 | 有延迟，需要去重。 | 下单后发积分、发通知。 |
事务方案选择口诀
| 业务特征 | 优先方案 | 原因 | 例子 |
|---|---|---|---|
| 强一致、参与方少、并发不高 | 2PC/数据库事务 | 一致性优先，能接受阻塞和性能损耗。 | 内部资金记账、核心对账。 |
| 高并发、资源可预留 | TCC | Try 先冻结资源，Confirm/Cancel 控制业务一致性。 | 秒杀库存、优惠券、支付预授权。 |
| 长流程、跨多个系统 | Saga | 每步本地提交，失败后执行补偿。 | 订单、仓储、物流、退款。 |
| 主业务成功后异步通知 | 本地消息表/可靠消息 | 业务和消息同库提交，后续重试投递。 | 下单后发积分、发短信、写审计。 |
案例与论文写法
服务拆分依据 → 治理能力 → 数据一致性 → 故障隔离 → 量化效果。
例如：我基于 DDD 将用户认证系统拆为认证、权限、Token、审计四个服务；通过网关、注册发现、配置中心、熔断限流和链路追踪实现服务治理；对跨服务数据采用领域事件和本地消息表保证最终一致；当权限服务超时时，认证主链路通过降级策略返回受限访问结果并记录审计事件，避免故障扩散。