很多人聊架构，张嘴就把分布式和微服务混着说，好像换个词而已。
其实它俩关注的东西不一样。
分布式的核心，是让多个独立节点通过网络协同，完成一个系统的活。
微服务则是围绕业务能力，把系统拆成一组相对独立、能各自开发部署的服务。
说白了，分布式关注的是多个节点如何协同，微服务关注的是系统如何按业务能力拆分，并让各个服务能够独立演进。
分布式：先把机器这关过了
你开家公司，一开始所有人挤一间办公室，接单、写代码、算账全在一块。
人少的话没事，人一多就乱，一个人请假全公司卡住。
单体架构就是这样。
所有功能跑在一整块里，扛不住就多复制几份部署，应用本身没有拆分。
分布式的思路，是把活摊到多个节点上一起干。
很常见的一种做法，是把数据库、缓存、应用等组件分别部署到不同节点，让它们通过网络协同工作。
数据库单独放几台服务器。
缓存单独放几台。
应用服务也单独几台。
目的很明确：把压力分散到多个节点，同时为扩展和故障隔离提供基础。
但这里得说清楚，分布式不等于"把技术层拆开"这一种玩法。
订单服务的三份实例跑在三台机器上，前面挂负载均衡，这也是分布式，可它没动技术层。
真正该盯住的，是分布式关心"多个节点怎么协同"。
业务拆没拆，那是另一个维度。
业务代码还是完整的一块，只是复制到多台服务器上运行。
微服务：再把业务这关过了
即使做了分布式部署，代码也可能还是完整的一块，改一处怕动全身。
团队一大，谁都不敢动别人的模块，发布还得排队等。
微服务更进一步。
它围绕业务能力，把一整块代码切成一组能各自开发、各自部署的独立服务。
订单是一个服务，支付是一个服务，库存是一个服务。
每个服务有自己独立的代码和部署边界，数据边界也尽量跟着服务边界走，服务之间主要通过接口协作。
核心是业务边界。
每个服务围绕一块相对完整的业务能力负责，彼此互不干预。
类比一下：
分布式像把公司的打印、仓储、运输搬到不同楼，业务没有变。
微服务像把公司拆成一群独立子公司，每家只做一个业务线，人员、资金都独立，靠合同协作。
好处是解耦。
订单服务想改，不用等支付团队点头。
如果业务允许最终一致，下单时库存可以先不扣，订单服务先接住订单，之后通过消息等方式异步补库存。
一张表看清它俩
| 维度 | 分布式 | 微服务 |
|---|---|---|
| 核心关注 | 多节点协同 | 业务边界与服务自治 |
| 核心目标 | 扩展性、可用性、容错等 | 解耦业务、独立开发部署 |
| 数据边界 | 没有固定要求 | 强调服务数据自治 |
| 解决啥问题 | 单节点能力和可靠性有限 | 业务耦合、团队协作和发布成本 |
最容易被坑的误区：分布式就是微服务
错。
微服务通常会形成分布式系统。
多个服务一般通过网络通信，但它们也可以部署在同一台机器的不同进程里。
反过来不成立。
你把同一个庞大的单体应用复制 10 份，部署在 10 台服务器，前面挂个负载均衡分发请求。
这属于分布式部署的单体应用，它依然是单体架构，改一处，所有实例都得跟着改，根本不是微服务。
区别就在拆没拆业务。
复制只是把同一份代码部署到多台机器上，微服务是把系统拆成各自独立的几块。
微服务不是越细越好
听着很美，但微服务也有代价。
服务拆得越细，通常意味着更多的通信、治理和运维成本。
服务一多，相互之间的调用次数明显增加。
数据一致性更难保证，一个下单可能要跨多个服务、多个数据存储协同。
运维监控也得盯着一大片服务，出了问题定位更费劲。
所以小项目别硬上。
业务规模不大、团队也小的时候，强行拆微服务，运维负担反而可能压垮你。
老老实实用单体，或者只做简单的分布式部署，反而最稳。
回到它俩的关系。
分布式解决的是多节点协同、扩展和高可用这类问题。
微服务解决的是按业务边界拆系统、让团队和服务各自独立演进。
看清这层，选的时候就不绕了。
遇到多节点协同、扩展、高可用这类问题，往分布式想。
要理业务、要团队独立开发独立发布，往微服务想。