flowchart LR
N0["01 故障与一致性"]
N1["02 服务通信"]
N2["03 发现与配置"]
N3["04 网关与保护"]
N4["05 事务与事件"]
N5["06 版本与兼容"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
分布式与微服务
现代 Java Backend Engineering 学习路线：分布式与微服务
0 子目录10 文档
CHAPTER OVERVIEW · 章节概览
先理解部分失败和一致性取舍，再处理通信、发现、保护与跨服务流程；组件组合须核对兼容关系。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
10分布式系统与微服务：从零开始的阶段导学调用本地方法失败，通常能直接得到异常；调用远程服务超时，却未必知道对方有没有执行成功。分布式系统的很多设计都从这种不确定性展开。先理解失败，再学注册、网关和事务组件。分布式基础：故障模型、CAP、BASE、复制与共识两台机器之间的网络断开时，系统仍要决定是否接受新的读写请求。CAP 讨论的就是带有明确前提的取舍，不是随意选两个字母。下面会把术语放回具体故障场景，再介绍复制与共识。服务通信：HTTP、OpenFeign、Dubbo、gRPC 与 Netty远程调用写起来像普通方法，并不表示它具有相同的失败行为。下面从请求编码、连接、超时和返回结果看 RPC，再比较 HTTP、gRPC、Dubbo 等工具各适合什么需求。Nacos：服务注册、发现、健康检查与配置治理服务实例不断增加或重启，调用方怎样知道该连哪个地址？配置改变后，又怎样让正确的实例收到更新？注册发现与配置管理分别回答这些问题，下面再看 Nacos 如何参与其中。API 网关、负载均衡、限流、熔断、降级与重试下游已经很慢时，继续重试可能把它压得更严重。限流、熔断和重试的目的不同，组合方式也很重要。先看一次请求经过哪些地方，再给每个机制设定范围、等待上限和恢复条件。分布式 ID、分布式事务、Outbox、Saga 与可靠事件订单、库存、支付分别由不同服务管理后，原来一个数据库事务能完成的工作被拆开了。下面从“哪些结果绝对不能出现”开始，选择幂等、事件或补偿机制，而不是先寻找万能的分布式事务注解。Spring Cloud 与 Spring Cloud Alibaba 组件图Spring Cloud 的组件图可以当索引，但不必把图上的组件全部装进项目。先确认你缺的是寻址、配置还是流量控制，再选择对应组件。最后再核对 Spring Boot 和发行版本是否配套。Seata、Sentinel 与 SkyWalking 实战边界事务没完成、请求量过大、故障原因不明，是三类不同的问题。Seata、Sentinel 和 SkyWalking 分别提供相关能力，彼此不能替代。下面把它们放进实际调用过程，看接入之后还需要自己处理哪些事。Spring Cloud Compatibility Matrix 与升级检查升级 Cloud 项目时，单独改一个 Boot 版本可能带来组合问题。把 JDK、Boot、Cloud 发行列车和第三方组件一起核对，再执行回归测试。本页记录的是指定日期的兼容关系，后续升级仍要重新检查。分布式系统与微服务推荐阅读微服务资料里组件很多，建议先读网络故障和一致性，再挑一个小的跨服务调用练习。只有看见超时、重复和部分成功的问题，才知道注册中心、重试与补偿分别在解决什么。