企业官网建设流程全解析

分布式和微服务到底有什么区别？这个问题我在面试里问过很多人，也在团队内部讨论过很多次。最常见的答案有两种：一种是把两者混为一谈，觉得微服务就是分布式，分布式就是微服务；另一种是背了一堆定义，但一落到实际项目里还是不知道怎么选。我的判断很直接：分布式描述的是系统运行时的物理拓扑和协作方式，微服务描述的是业务架构的拆分风格和治理方式。两句话就能说清：分布式是“怎么把多台机器组织起来一起干活”，微服务是“怎么把业务拆成一个个独立交付的小服务”。

一个微服务架构的系统，通常一定是分布式系统；但一个分布式系统，不一定跟微服务有关系。Hadoop 集群是典型的分布式系统，但它不是微服务。微服务只是分布式系统里的一种组织形态，而且是非常偏业务拆分的一种形态。

这篇文章会把两者的定义、演进关系、核心差异和落地选择都拆开讲一遍，也会顺带回答那些高频面试题：分布式锁、分布式事务、分布式缓存、分布式压测到底属于哪一层的问题。

1. 一句话说清楚：分布式是部署形态，微服务是架构风格

1.1 为什么这两个词总被放在一起

打开任何技术社区，搜“微服务”，后面一定会跟着“分布式”。搜“分布式”，前面也一定挂着“微服务”。原因是它们在真实项目里经常同时出现。

微服务落地之后，服务之间要通信，要负载均衡，要注册发现，要配置中心，要链路追踪。这些能力一旦跨了多台机器、多个进程，就天然带上了分布式属性。反过来，当你去解决分布式系统的问题时，最典型的案例也是微服务场景。比如订单服务和库存服务分别部署在不同机器上，要保证扣库存和下单一致，这就是分布式事务问题。

所以大家默认把两个词绑在一起，不是没有道理。但绑在一起不代表等价，分布式是一个更大的概念，微服务是它下面的一种具体风格。

1.2 从架构演进看两者的真实关系

把演进过程捋一遍，关系就很清楚了。

最早是单体应用。一个 War 包或者一个进程，包含所有业务逻辑，数据库也往往只有一个。单体应用简单直接，但问题也明显：代码越来越膨胀，团队并行开发互相干扰，任何一个模块故障都可能拖垮整个系统。

然后是集群部署。同一个应用部署多份，前面挂负载均衡，扛住更大的并发。这个阶段仍然是单体，只是从一台机器变成了多台机器。严格说，这时候已经具备部分分布式特征了，但你并不会叫它分布式系统，因为应用内部没有拆分，节点之间只是简单复制。

再往后是服务化拆分。把用户、订单、库存、支付这些业务模块拆成独立的服务，通过 RPC 或 HTTP 调用。服务数量变多，部署节点变多，通信关系变复杂，这时候系统才真正成为分布式系统，也开始需要注册中心、配置中心、网关、熔断、限流这些基础设施。

到这里你会发现，分布式不是某一个具体技术阶段，而是从“多节点协作”那一刻就开始的。微服务则是服务化拆分做到比较彻底之后的一种架构风格。可以说微服务是分布式系统在业务架构层面的一种“理想形态”，但不是唯一形态。

2. 分布式系统和微服务各自解决什么问题

2.1 分布式系统：把任务拆到多台机器上协同完成

分布式系统要解决的根本问题是：单台机器的能力不够用，或者可靠性不够高，所以把任务分散到多台机器上。

这里的“能力不够用”分好几种：

• 算力不够：单机处理不了海量数据，所以用 Hadoop、Spark 做分布式计算。
• 存储不够：单块磁盘放不下，所以用 HDFS、分布式存储集群。
• 并发不够：单机扛不住高并发，所以用多节点加负载均衡。
• 可用性不够：怕机器宕机，所以要多副本、主从切换。

注意，这些场景里系统并不关心业务怎么拆分。Hadoop 伪分布式搭建就是在单机上模拟一个多节点环境，那里面的 NameNode 和 DataNode 属于分布式系统组件，但没有人会把它叫微服务。同样，Redis 集群、Kafka 集群、分布式版本控制系统 Git、分布式账本，都属于分布式系统，它们和业务微服务基本没有关系。

所以分布式系统的判断标准很简单：是否由多个节点通过网络协作完成同一件事，并且节点之间需要处理一致性、协调、容错的问题。

2.2 微服务：把业务按边界拆成独立交付的服务

微服务要解决的根本问题是：业务规模变大、团队变大之后，单体应用越来越难维护，所以按业务边界拆成多个独立的小服务。

每个服务有自己独立的代码仓库、独立部署、独立伸缩，甚至可以使用不同的技术栈。服务之间通过明确的接口通信，比如 REST、gRPC、Dubbo 协议。每个服务对应一个小的业务领域，比如用户服务只管用户，订单服务只管订单，库存服务只管库存。

微服务不关心你底层是不是真的用了 Redis 集群、是不是分布式部署。理论上，微服务也可以在单机上跑，但实际项目中几乎不会这么干。因为微服务拆出来的目的之一就是独立扩缩容，你不把服务部署到多台机器上，这个能力就体现不出来。

到了这个时候，微服务和分布式的交集就出现了：微服务架构天然要跨进程跨机器通信，所以它必须解决分布式系统里那些协调问题。注册中心 Nacos、配置中心、分布式锁、分布式事务中间件 Seata，本质上都是在解决“多个节点怎么协作”的问题。

2.3 两者的交叉地带和判断标准

我整理了一个比较直接的对比，平时判断概念归属时可以用：

如果你在项目里看到一堆机器组成一个集群，那叫分布式。如果你看到的是用户服务、订单服务、库存服务各管一块，通过注册中心互相调用，那叫微服务。前者描述“机器怎么组织”，后者描述“代码怎么组织”。

3. 两者的核心差异：从拆分粒度到治理复杂度

3.1 拆分维度、驱动力和数据管理不同

拆分维度是两者最直观的区别。

分布式系统的拆分维度通常有以下几种：

• 计算任务拆分：一个大数据任务拆给多个节点并行计算，典型就是 MapReduce 和 Spark。
• 数据分片：把数据按 key 分散到多个节点，典型就是数据库分库分表、分布式存储。
• 角色拆分：集群内不同节点各司其职，比如主节点和从节点、元数据节点和数据节点。

这些拆分都不会改变业务逻辑的组织方式。订单还是那个订单，只是订单数据可能分布在多个库、多个节点上。

微服务的拆分维度则是业务能力。一个订单功能，会拆成订单服务、库存服务、支付服务、物流服务。每个服务自己管自己的数据，数据不共享。服务之间只通过接口交互，不直接访问对方的数据库。

数据管理方式的差异更明显。单体时代一个数据库搞定所有表；分布式数据库时代，一张表可能被拆分到多个节点；微服务时代，每个服务独立自己的 schema，数据库本身就变成了按服务划分的多个数据域。

这里有个很常见的坑：有同学以为把单体应用部署到多台机器上就是微服务了。不是的，那只是集群。微服务必须要有业务边界上的拆分和独立的数据归属，否则你得到的是一个运行在多台机器上的单体应用，只是看起来像微服务而已。

3.2 一致性、事务和锁的处理方式完全不同

分布式系统和微服务都要处理一致性问题，但处理的层级和工具不太一样。

分布式系统的一致性，更多是底层存储和计算的一致性。比如分布式缓存里多个副本之间、分布式存储里主副本和从副本之间，数据不能出现分歧。这个层面常用的思路是复制、选举、协议对齐，遇到并发修改时，需要分布式锁来保证同一时间只有一个节点在改同一个资源。

微服务的一致性，更多是跨服务的业务一致性。典型场景就是订单和库存：用户下单要扣库存，如果订单成功了、库存没扣，或者库存扣了、订单失败了，都不行。这就引出了分布式事务问题。

面试和实战里经常提到的“分布式事务四种方案”，就是指：

• 两阶段提交 2PC：强一致，性能差，适合对一致性要求极高的小范围操作。
• TCC 补偿：Try、Confirm、Cancel 三个阶段，适合需要明确补偿的业务。
• 本地消息表：业务操作和消息写入同一个本地事务，再异步通知其他服务。
• 最大努力通知：只保证最终尽量送达，适合对实时性要求不高的场景。

Seata 中间件实现了 AT 模式、TCC 模式、Saga 模式等方案，配合 Spring Cloud Alibaba 使用很常见。如果你看到“seata分布式事务原理”这类问题，其实问的就是：跨服务的多个本地事务，怎么在分布式环境下保持一致。

分布式锁也是同一类问题。Redis 分布式锁和 Redisson 分布式锁经常被拿来对比，前者要自己处理过期时间、续期和误删问题，后者内置了看门狗自动续期。锁要解决的是多个节点同时操作共享资源时的互斥，而不是业务拆分问题。所以它属于分布式系统的通用能力，微服务里用，非微服务的分布式应用里也可以用。

3.3 运维监控和故障处理的差异

分布式系统最麻烦的是硬件和网络故障。节点可能宕机，网络可能分区，消息可能丢失或重复。所以分布式系统要设计超时重试、心跳检测、主从切换、数据副本恢复。

微服务架构在此基础上还要额外处理服务治理问题。服务数量一多，你要知道每个服务在哪儿，于是需要注册中心和配置中心。服务之间调用关系复杂，你需要链路追踪。某个服务挂了，你不能让它拖垮调用链，于是需要熔断、降级、限流。

所以如果你去看微服务架构图，通常会看到网关层、注册中心、配置中心、监控告警、日志系统一整套东西。这些不是业务逻辑，而是为了管理大量服务而建的基础设施。这也是为什么微服务的落地成本高：业务拆分只是第一步，治理体系才是真正的重头。

4. 从单体到微服务的实际落地路径

4.1 什么时候该引入分布式

判断要不要引入分布式，一个原则就够了：单机是否真的成了瓶颈。

如果每天就几万请求，一台服务器绰绰有余，那根本没有必要上分布式。强行上一套分布式架构，只会引入网络延迟、数据一致性、运维复杂度这些新问题。很多项目不是被功能压垮的，是被过早的架构设计压垮的。

真正的信号通常是：

• CPU、内存长期打满，扩容也解决不了。
• 单库单表数据量太大，查询越来越慢。
• 单机需要承接的并发量超过了一个物理节点能承受的上限。
• 对可用性要求高，不允许单点故障。

在这些情况下，你可以先做集群、做主从、做缓存和分库分表，这些都属于分布式能力。先不要急着拆微服务。

4.2 什么时候该上微服务

微服务的引入信号和分布式不太一样。它更多是组织和开发效率的问题：

• 团队规模变大，多个团队同时开发同一个代码库，冲突不断。
• 发布频率变高，单体应用每次发版都要整个系统回归，风险很大。
• 不同模块的流量特征差异大，比如搜索服务需要大量计算资源，而用户服务流量稳定，独立伸缩更合理。
• 某个功能需要不同的技术栈，比如推荐模块用 Python，主流程用 Java。

需要说明的是：微服务适合解决的是“开发协作”和“独立伸缩”问题，不是“系统性能”问题。如果你的系统是求快求简单，业务也没有复杂到必须拆分，那微服务带来的治理成本会明显超过收益。

我在实际项目里见过不少团队，业务用户量还没上去，先照着若依微服务、Spring Cloud Alibaba 那一整套搭好了基础设施。结果服务拆了十几个，注册中心、网关、分布式事务中间件都上了，但真正需要分布式事务的业务一个都没有。最后大家都在维护框架，而不是在写业务。这个优先级是反的。

4.3 用 Spring Cloud、Nacos、Seata 理解微服务生态

如果要从零搭一个微服务框架，主流的路径就是 Spring Cloud 加 Spring Cloud Alibaba，再加上 Nacos 和 Seata。

• Nacos 负责服务注册、发现和配置管理。服务启动时把自己注册进去，其他服务通过它找到目标服务的地址。
• Spring Cloud Gateway 或 Zuul 做网关，统一入口、鉴权、路由、限流。
• OpenFeign 做服务间声明式调用。
• Sentinel 或 Hystrix 做熔断限流。
• Seata 处理分布式事务。
• Redis 做分布式锁和分布式缓存。
• 分布式定时任务则要用支持分片和调度的框架，比如 XXL-Job。

这套东西搭起来不难，难的是理解每一层解决什么问题。比如“java 管理微服务的平台”这种搜索词，本质上就是问服务治理平台怎么选。市面上的主流选择基本就是 Nacos、Consul、Eureka，Java 生态里 Nacos 使用很普遍。

但我也建议新手不要一上来就追求完整版。先用 IDEA 创建一个 Spring Boot 项目，加一个 Nacos，注册两个服务，互相调一次接口，把服务发现跑通。然后再加网关、加配置中心。最后如果确实有跨服务事务需求，再引入 Seata。每一步都确认能跑，再继续下一步，比一次性搭一个大型脚手架要实用得多。

5. 面试和实战中的高频问题，这样答不会跑偏

5.1 分布式锁和分布式事务到底属于哪个层面的问题

面试里出现“分布式锁面试题”“分布式事务四种方案”“seata分布式事务原理”，本质上都在考察你对分布式系统的理解深度。

先分清楚层次：

• 分布式锁解决的是“多个节点互斥访问共享资源”，属于分布式协调层的通用能力。典型用 Redis 加 Redisson，或者 ZooKeeper。
• 分布式事务解决的是“多个服务的本地事务怎么保持最终一致”，属于业务一致性层的专项能力。典型用 Seata、TCC、本地消息表。
• 分布式缓存解决的是“热点数据多节点共享读取”，属于性能优化层。
• 分布式存储解决的是“数据量超出单机容量后的扩展问题”。

如果你在面试里把这些问题混在一起讲，考官很容易判断出你只是背过名字，没有真正处理过。更好的回答方式是先说出归属，再给出你在项目里的实际取舍。

比如分布式事务，不要一上来就背四种方案。可以先说：我们核心交易链路不允许不一致，所以用了 Seata 的 AT 模式；但团队运营后台的异步通知场景对强一致没有要求，就用了本地消息表加最大努力通知。这样既体现了你知道方案，也体现了你会根据场景选方案。

5.2 压测、缓存、定时任务的场景归属

再看几个热词：jmeter分布式压测、分布式缓存、分布式定时任务。

Jmeter 分布式压测不属于业务架构，它是测试工具本身采用主从模式，由一个调度端把压测任务分发给多个压测机。这反而说明了一个现象：连压测工具都用了分布式设计，但它是分布式系统，不是微服务。

分布式缓存，比如 Redis Cluster，解决的是缓存容量和读写并发的问题。缓存归属于基础设施，被多个服务共享。它服务于微服务，但自己不是微服务。

分布式定时任务，解决的是多个业务实例同时跑定时任务时重复执行的问题。如果没有统一调度，每个实例都可能在同一时刻执行一遍任务，造成重复处理和脏数据。XXL-Job 这类平台通过分片和调度锁来避免冲突。它是微服务生态里的一个通用组件。

这些例子都很适合用来回答“分布式和微服务有什么区别”，因为它们证明了：一个平台或组件可以很“分布式”，但完全不属于“微服务”。

5.3 给新人和架构师的建议

新人最容易犯的错误，是把分布式、微服务、集群、高并发这些词揉在一起背。我的建议是每个词从两个角度理解：它解决的问题是什么，它适合什么场景而不适合什么场景。

对刚开始接触的人，可以按这个顺序学习：

1. 先把单体应用写好，理解事务、缓存、锁在单机环境下的行为。
2. 再做集群部署，理解负载均衡和会话共享。
3. 然后用 Nacos 加两个服务，理解服务注册发现。
4. 再用 Redisson 写一个分布式锁，理解跨节点互斥。
5. 再引入 Seata 处理一笔跨服务事务，理解一致性成本。
6. 最后再做压测和监控，理解治理体系。

对已经在做架构选型的人，我更建议用“最简够用”原则。分布式和微服务都是手段，不是目的。单体阶段能解决就不要上集群，集群能解决就不要拆服务，微服务能解决就不要过早引入分布式事务。每次引入一个新概念，都要能回答出一个明确的问题：不加它，代价是什么。

还要提醒一点：微服务的边界拆分是最难的部分。同一个团队，不同人画出来的拆分方案可能完全不同。判断标准不是谁的技术热门，而是拆完之后能不能独立部署、独立伸缩、独立发布，团队成员之间是不是真的减少了对同一份代码的竞争。如果拆完之后，服务之间频繁做同步调用，任何一次改动都要跨多个服务联调，那说明边界并不合理。

分布式和微服务的区别，说到底就一句话：分布式是你不得不面对的多节点现实，微服务是你主动选择的业务组织方式。理解到这一层，再去看各种框架和中间件，心里就会稳很多。真正落地时，最值得盯住的不是功能列表，而是你的业务规模、团队结构、一致性和运维能力。把单点的问题用单点方案解决，把多节点的问题用分布式手段解决，把业务拆分的问题用微服务思路解决，这样才能把事情做对。