从单体到分布式写给实习生的分布式系统入门指南写给只做过单机项目、刚进公司接触微服务项目的同学。如果你对分布式的理解还停留在前端发请求 → REST 接收 → Feign 转发 → 网关路由那这篇博客正好适合你。开篇你以为的分布式 vs 真正的分布式你以为的分布式前端 → REST → Feign → 网关 → 服务它并不是分布式系统的全部而只是微服务架构中的一次服务间调用。我先把两个概念掰扯清楚概念一句话定义通俗类比分布式系统跨多台机器协作完成同一个目标一支足球队微服务把一个大系统拆成多个小服务的架构风格把球队拆成前锋组、中场组、后卫组微服务是分布式系统的一种实现风格类似三十六计里的某一计。而分布式系统本身是一个更广泛的学科还包括共识算法、分布式事务、最终一致性、CAP 理论等深水区。所以你工作里接触到的 REST、Feign、网关本质上是分布式系统落地的一种具体做法不是分布式系统的定义。搞清楚这一点我们才能把后续的概念放在正确的位置上。第一章为什么需要分布式系统在聊什么是分布式之前先想想为什么需要它。单机项目单体应用长这样┌─────────────────────┐ │ 一台机器 │ │ ┌─────────────────┐ │ │ │ 前端 后端 │ │ │ │ 数据库 │ │ │ └─────────────────┘ │ └─────────────────────┘单体应用简单可靠开发快、调试容易、部署方便。但是它有三个致命问题1. 性能瓶颈一台机器的 CPU、内存、磁盘、网络都有上限。即使你把机器换成顶配也总有天花板。2. 单点故障这台机器宕机整个系统就不可用。不管你代码写得多好硬件终究会坏。3. 难以扩展双 11流量来了用户量翻了 10 倍你没办法通过加机器解决——因为所有代码都跑在一台机器上。类比一下让一个人送完整个城市的快递能行吗不能。我们需要的是快递网络——很多人协作每个人负责一个片区。分布式系统的核心目标就是用一堆普通机器协作对外表现得像一台超级计算机。听起来很美好但有个残酷的现实复杂度的爆炸。一旦机器数量超过 1你就要面对单机世界根本不存在的问题——这就是第二章要讲的内容。第二章分布式系统的核心挑战为什么分布式系统这么难因为它要解决一堆单机世界不存在的问题。我用五个最经典的挑战来解释1. 网络不可靠单机调用是函数调用几乎不会失败。跨机器调用是网络请求消息可能丢失、延迟、重复、乱序。类比你给隔壁工位的同事传纸条纸条可能掉地上丢失、可能晚到延迟、可能被传了两遍重复、可能被同事们传乱了顺序乱序。2. 节点会宕机任何机器随时可能挂——磁盘损坏、机房断电、操作系统崩溃。在分布式系统里节点宕机是常态不是异常。3. 没有全局时钟单机上你可以System.currentTimeMillis()拿到一个准确的时间。但跨机器时各机器的时钟是不同步的没有一个标准时间可以让所有节点对齐。类比三个分会场同时开会没有主持人喊现在是北京时间 10 点整每个会场的时钟都略有偏差。4. 部分失败最难的A 调用 BB 成功处理了但响应在网络中丢了。A 不知道 B 到底干了没。这种不知道成功还是失败的状态是分布式系统设计中最棘手的问题之一。5. 数据一致性同一份数据存在多台机器上怎么保证它们一致比如 A 机器改了数据B 机器什么时候能读到读到的是旧值还是新值类比你在微信群里发了一条消息有人秒看到有人 1 分钟后才看到。这是最终一致性——所有节点最终会达成一致但不是立刻。为了解决这些挑战计算机科学家提出了CAP 定理CConsistency 一致性所有节点看到的数据是一致的AAvailability 可用性每次请求都能得到响应不保证是最新的PPartition tolerance 分区容错网络分区部分节点失联时系统还能工作CAP 定理指出三者最多只能同时满足两个。实际工程中 P 是必选项网络一定会出问题所以工程师只能在 C 和 A 之间做权衡。比如银行转账必须一致不能差一分钱牺牲一点可用性微博点赞可用性优先点不到赞体验很差可以暂时不一致第三章你工作中的微服务是怎么回事好回到你最熟悉的那条链路。我把它重新放在分布式系统的语境下理解Feign 调用前端API 网关订单服务库存服务数据库注意这里只是简化版实际还有注册中心、配置中心、消息队列等等。各层角色API 网关Gateway分布式系统的门卫。统一入口所有外部请求都先进网关路由决定这个请求该转发给哪个服务限流 / 鉴权 / 灰度发布等单机项目时这些都不需要因为你只有一台机器、一个入口。拆成多个服务后必须有一个统一的入口来做总控。REST 接口Controller 层服务对外暴露的接口。你说用一个 REST 来接收前端传来的参数这个描述是对的。REST 是服务向外部前端、其他服务暴露能力的方式本质上就是 HTTP 接口。Feign 客户端服务对内调用其他服务时用的客户端工具。这里纠正一个常见的误解Feign 不是Feign 服务器它是一个客户端 SDK。你写一个 Feign 接口FeignClient(nameinventory-service)publicinterfaceInventoryClient{GetMapping(/inventory/{skuId})InventoryDtogetInventory(PathVariableStringskuId);}然后订单服务就可以像调用本地方法一样调用库存服务AutowiredprivateInventoryClientinventoryClient;publicvoidcreateOrder(StringskuId){InventoryDtostockinventoryClient.getInventory(skuId);if(stock.getQuantity()0){// 创建订单...}}Feign 在背后帮你做了服务发现找库存服务的地址、负载均衡选哪台机器、HTTP 调用、结果反序列化。服务注册中心Nacos / Eureka分布式系统的通讯录。每个服务启动时把自己的地址 端口报到注册中心调用方通过注册中心找到对方。单机项目时不需要这个因为服务的地址写死在配置里就行。但服务一多、机器一多、上下线频繁必须有自动发现机制。为什么需要这一整套单机项目时代代码、数据库、缓存全在一台机器上不需要网关只有一个入口注册中心地址写死就行Feign直接调用本地方法分布式事务只有自己的数据库一旦你把系统拆成多个服务这些问题瞬间出现问题解决办法外部怎么访问内部这么多服务API 网关服务之间怎么找到对方注册中心服务之间怎么调用Feign / OpenFeign一个服务挂了怎么办熔断 / 降级 / 限流多个服务的数据怎么保持一致分布式事务这就是为什么微服务项目看起来复杂——它解决的全是分布式系统固有的难题。第四章分布式系统中的常见概念速览新人最容易遇到的高频概念每个用一两句话点明。我把它们列成一张速查表概念一句话说明常用工具负载均衡把流量分给多台机器避免单台过载Nginx / Ribbon / Spring Cloud LoadBalancer服务注册与发现服务自动上报地址调用方自动发现Nacos / Eureka / Consul分布式事务跨多个服务的数据操作要么全成功要么全失败Seata / TCC / Saga分布式锁多个服务抢同一份资源时的互斥机制Redis (RedLock) / Zookeeper分布式 ID跨服务生成全局唯一 ID雪花算法 (Snowflake) / Leaf限流超过阈值的请求直接拒绝Sentinel / Hystrix / Resilience4j降级服务出问题时返回一个兜底结果Sentinel熔断下游服务持续失败时直接断开调用避免雪崩Sentinel / Hystrix配置中心集中管理配置改一处所有服务生效Nacos / Apollo消息队列服务间异步通信解耦流量峰值Kafka / RabbitMQ / RocketMQ分布式缓存多服务共享缓存数据Redis Cluster链路追踪一个请求经过了哪些服务、每一步耗时多少SkyWalking / Zipkin / Jaeger不要被这张表吓到。这些概念不需要你一上来就全部搞懂。建议的方式是先看工作中用到了哪几个搞清楚那几个分别解决什么问题有需要时再深入原理第五章实习生的上手建议推荐的学习路径会用 → 理解为什么 → 看实现原理很多新人一上来就啃《数据密集型应用系统设计》DDIA结果读了几章就放弃了。这本书是神书但不适合作为入门第一本。更合理的顺序第一阶段会用搞清楚你项目中用了上面表格里的哪几个组件能在本地把项目跑起来能调通一个请求第二阶段理解为什么这些组件为什么存在不引入会怎样读官方文档的设计理念和快速开始学会看架构图、链路追踪图第三阶段看实现原理读源码、看核心论文这时候再回头看 DDIA会顺畅很多学会看架构图和链路追踪图新人很容易陷在代码细节里一个 Service 类的方法被谁调用、一个字段为什么这么映射但实际上看图比看代码更高效。架构图告诉你整个系统有几层、哪些服务、谁调谁链路追踪图告诉你一个请求经过了哪些节点、每一步耗时多少、哪一步报错这两类图看多了你就有了全局观。推荐资料《数据密集型应用系统设计》DDIA分布式系统理论圣经但建议有基础后再看极客时间《从 0 开始学微服务》实战入门你公司内部的技术 wiki / Confluence最贴近实际工作工作中用的中间件官方文档最权威、最及时结尾分布式系统没有银弹最后想给你泼一盆冷水分布式系统不是银弹。很多新人崇拜分布式、觉得做了分布式就高大上。但事实上单体应用开发快、调试易、部署简单没有高并发需求时单体往往是最优解引入分布式带来的是复杂度的指数级增长数据一致性、调用链追踪、灰度发布、容量评估……每一个都是坑工程师真正值钱的能力不是我会搞分布式而是在简单和复杂之间做权衡什么时候该上微服务什么时候该用分布式事务什么时候一致性可以妥协对于实习生来说最重要的不是会用多少中间件而是建立对分布式系统的全局认知框架。这样以后遇到任何新概念你都能在脑子里找到它该待的位置。剩下的交给时间和项目慢慢补。如果你读完这篇博客能在脑子里画出我项目中那条调用链路在分布式系统里属于哪一层、为什么需要这一层那这篇博客就没白写。