企业官网建设流程全解析

这次我们直接聊一个面试和架构评审里都绕不开的问题：分布式和微服务到底有什么区别？

很多人在简历上写了“精通微服务架构，具备分布式系统开发经验”，但被问住最多的地方恰恰是这两个概念本身。更常见的情况是，Spring Cloud、Nacos、Seata 这些组件都在用，真要让讲讲“你现在的系统是分布式还是微服务”，反而说不清楚。这篇文章不绕概念，直接给结论：

微服务是架构风格，分布式是部署形态。两者经常组合出现，但本质上是两回事。文章会从定义、拆分维度、典型中间件、落地路线和踩坑排查几个角度展开，最后给出一套可以对照自己项目做架构判断的清单。

1. 核心概念速览

先建一张表，把两者的关系限定清楚，后面所有内容都围绕这张表展开：

结论先放在这里：分布式更偏向“多节点协同”的底层能力问题，微服务更偏向“业务如何拆”的架构设计问题。微服务天生是分布式的，但分布式不等于微服务。

2. 分布式：多节点协同，对外像一个整体

2.1 分布式的核心定义

分布式系统是指多个独立计算机节点通过网络通信协作，共同完成任务，并且对用户来说表现为一个统一的系统。

关键点有三个：

• 多个节点：至少两台机器，或者一台机器上多个进程。
• 网络通信：节点之间需要交换数据，不能各干各的。
• 对外统一：用户访问的是同一个服务入口，不需要关心背后有几个节点。

Hadoop 伪分布式就是一个很好的入门例子。所谓伪分布式，是在单台机器上模拟分布式环境，HDFS 的 NameNode、DataNode、SecondaryNameNode 以独立进程的方式运行。这说明分布式的本质是“多进程 + 通信 + 协作”，而不是必须有物理上的多台服务器。

2.2 分布式要解决什么问题

节点一多，新问题就出来了：

• 数据一致性：两个节点同时改同一份数据怎么办。
• 分布式事务：跨库、跨服务的数据操作如何保证原子性。
• 分布式锁：多节点抢同一个资源，如何保证只有一个节点能拿到。
• 分布式缓存：缓存数据分散在多个节点，如何保证访问路由和数据一致。
• 分布式定时任务：定时任务在多个节点部署后，如何避免重复执行。
• 分布式存储：数据量超过单机容量，如何分片存储。

这组问题不依赖具体业务，只要系统有多个节点协作，就一定会遇到。

2.3 分布式事务的四种典型方案

这里必须提分布式事务，因为它是分布式系统里最容易出问题、面试也最爱问的一块。常见方案是这四种：

Seata 是目前 Java 生态里用得非常多的分布式事务框架，AT 模式依赖全局锁和undo_log 表回滚。使用时要特别注意代理数据源配置，不能用默认的 DataSource，否则事务回滚不生效。

下面是一段 Seata AT 模式的 YAML 配置示例，结合 Spring Cloud 项目使用：

seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP

对应 Spring Boot 主类上需要启用全局事务：

@SpringBootApplication @EnableAutoDataSourceProxy public class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }

注意：Seata AT 模式需要业务表包含 undo_log 表，且每个分支事务都要走 Seata 代理的数据源，否则回滚时找不到原始数据。

3. 微服务：业务边界拆分，服务独立演进

3.1 微服务的核心定义

微服务是一种架构风格，将单个应用拆分成一组小型服务，每个服务围绕业务能力构建，独立开发、独立部署、独立扩展，服务之间通过轻量级通信机制（HTTP/RPC）交互。

微服务强调的是“边界”和“自治”。

• 边界：按业务域划分，比如订单服务、库存服务、用户服务。
• 自治：每个服务有自己的数据库、自己的代码仓库、自己的发布节奏。

3.2 微服务不是简单的“拆”

很多人拿到一个单体应用，直接复制一份再改改端口，以为这就是微服务。这其实是“分布式部署的单体应用”，不是微服务。

判断一个系统是不是微服务，可以看三个问题：

如果答案是“数据还共用一个库”“发布必须一起发”，那充其量是伪微服务，或者叫分布式的单体。

3.3 微服务落地的典型组件

以 Java 技术栈为例，一个完整的微服务架构需要这些能力：

用 Nacos 做注册中心时，服务配置示例：

spring: application: name: user-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: public

服务启动后，可以在 Nacos 控制台看到实例列表。调用方通过 OpenFeign 声明式调用：

@FeignClient(name = "user-service", path = "/api/user") public interface UserClient { @GetMapping("/info") UserInfo getInfo(@RequestParam("id") Long id); }

这套结构是当前大部分 Java 微服务项目的通用骨架，若依微服务版本也是基于 Spring Cloud + Nacos 搭建的。

4. 分布式和微服务的核心区别

把两者放在一起对比，核心区别可以归结为四个层次。

4.1 拆分维度不同

4.2 关注问题不同

分布式关注的是多节点带来的技术问题：数据一致性、网络分区、节点故障、时钟漂移。

微服务关注的是架构管控问题：服务怎么拆、接口怎么定义、依赖怎么管理、故障怎么隔离。

4.3 是否共享数据

这一点是很多人的盲区。

分布式系统可以共享底层数据，比如 Redis Cluster 每个节点负责一部分 slot，MySQL 主从共享同一份逻辑数据。微服务则明确要求数据独立，服务之间只能通过接口访问数据，不能直接共享数据库表。

4.4 一句话总结

• 分布式解决的是“多台机器如何一起干活”的问题。
• 微服务解决的是“一个复杂系统如何拆成小块维护”的问题。
• 分布式是基础设施层面的特征，微服务是应用架构层面的选择。
• 微服务系统一定是分布式的，但分布式系统可以是单体应用的集群部署。

5. 从单体到分布式，再到微服务

5.1 单体阶段

所有功能在一个应用里，部署一个 jar/war，共用一个数据库。

优点：开发简单、部署简单、事务天然一致。 缺点：代码膨胀后无法维护，任何一个功能发布都要整体回归。

5.2 集群/分布式阶段

单体应用复制多份部署到多台机器，前面加负载均衡。这是“单体的分布式”。

解决了高可用和高并发，但没有解决代码耦合问题。这时候会遇到 Redis 分布式锁、分布式定时任务不重复执行等问题。Redisson 就是常用来解决分布式锁的框架：

RLock lock = redissonClient.getLock("order:create:123"); boolean locked = lock.tryLock(3, 30, TimeUnit.SECONDS); if (locked) { try { // 执行订单创建逻辑 } finally { lock.unlock(); } }

5.3 微服务阶段

按业务能力拆分成多个服务，每个服务独立部署、独立数据库。服务之间通过 OpenFeign、Dubbo 或者 HTTP 调用。

这时候需要引入服务注册中心、网关、配置中心、熔断降级和链路追踪。

5.4 三者关系演化表

6. 分布式带来的典型问题：拆完之后更难了

这是写代码之外最需要理解的部分。架构迁移到分布式或微服务后，原本单体里简单的问题会变得复杂。

6.1 分布式事务

单体时代一个 @Transactional 就能保证订单和库存同时更新。微服务拆分后，订单服务和库存服务各自有库，事务边界越界了。

解决方案在 2.3 节已经列过，实际项目建议按一致性要求选型。无法接受最终一致性、要求强一致的场景，用 Seata AT 或 TCC。允许延迟一致、异步链路，用事务消息和本地消息表，比如订单创建成功后发送“库存扣减”消息。

6.2 分布式锁

在集群部署下，传统的 synchronized 只能锁住单个 JVM 内的线程，锁不住多节点。

常见做法是 Redis 分布式锁，使用 Redisson 封装好的 RLock，避免自己写 setnx 出现释放锁错误。用 Zookeeper 临时顺序节点也可以实现分布式锁，适合对一致性要求更高的场景。需要特别注意的是锁粒度、锁超时、可重入性，以及业务执行时间超过锁过期时间导致的提前解锁问题。

6.3 分布式缓存

缓存从单机本地缓存变成 Redis Cluster 后，要解决缓存穿透、缓存击穿、缓存雪崩、缓存一致性问题。面试老四样，但在分布式环境下才真正变得严重。

6.4 分布式定时任务

定时任务在单机部署没问题，多节点部署后同一个任务会被重复执行。方案有三类：

6.5 分布式压测

这也是搜索结果里经常出现的词。JMeter 支持分布式压测，master 节点分发脚本，多台 slave 节点同时发起请求。目的不是让压力更大，而是突破单机端口和连接数限制，模拟更真实的流量。

JMeter 分布式压测的格式：

# 在 slave 节点启动服务 jmeter-server -Dserver.rmi.port=1099 # 在 master 节点执行远程测试 jmeter -n -t test.jmx -R 192.168.1.101:1099,192.168.1.102:1099 -l result.jtl

注意：master 和 slave 的 JDK 版本最好一致，否则 RMI 通信会报错；测试脚本中用到的 CSV 数据文件要手工同步到每个 slave 节点，因为 JMeter 不会自动分发文件。

7. 架构选型：该用分布式还是微服务

这是文章最实用的一节。很多开发者在“要不要微服务化”上反复纠结，提供一套判断标准。

7.1 什么时候用分布式

• 单体应用遇到单机性能瓶颈，需要横向扩容。
• 需要高可用，一台机器挂了服务不能断。
• 数据量超过单库存储能力，需要分库分表或引入分布式存储。
• 需要多节点协作，但业务不需要拆成独立服务。

这时候选择“单体应用多实例部署”，加 Nginx 做负载均衡，再引入 Redis 做分布式缓存，就已经是分布式系统了。不需要上微服务。

7.2 什么时候需要微服务

• 单体代码量快速膨胀，模块之间耦合严重，想拆拆不动。
• 团队规模扩大，多个团队需要在同一个系统并行开发。
• 某个模块的流量远高于其他模块，需要独立扩展。
• 需要不同的技术栈实现不同业务域。
• 业务变更频繁，希望隔离故障，单个模块出错不影响全局。

7.3 什么时候不要上微服务

• 团队只有几个人，业务逻辑简单。
• 没有独立运维能力，没有监控、日志、链路追踪。
• 项目还是原型验证阶段，业务边界本身不清晰。
• 事务一致性要求极高，又不想承担分布式事务的技术成本。

**不建议为了简历写“微服务经验”硬拆系统。**微服务是手段，不是目的。拆完之后引入的注册中心、网关、配置中心、分布式事务、链路追踪，每一样都是实实在在的运维负担。

8. 常见问题与排查方法

从搜索结果看，分布式和微服务相关的坑集中在事务、锁、服务注册和配置管理上。

9. 最佳实践与使用建议

结合真实项目经验，给出几条工程化建议。

9.1 先小参数验证，再大规模拆分

不要一次性把整个系统拆成几十个服务。先选一个业务边界清晰、相对独立的模块试点，比如用户服务或者日志服务。跑通注册中心、网关、配置中心、日志链路之后，再逐步扩大拆分范围。

9.2 保留一套最小可运行配置

把 Nacos、Seata、Redis、Sentinel 的最小配置模板存到代码仓库里。新服务拉下来改端口和数据库就能跑。不要每次新服务都重新配置一遍中间件。最小可运行配置至少包括：

spring: application: name: ${service.name} cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: public datasource: url: jdbc:mysql://127.0.0.1:3306/${db.name}?useUnicode=true&characterEncoding=utf8 username: root password: root seata: enabled: true application-id: ${service.name}

9.3 目录和命名规范

模型文件、输入素材、输出结果分目录管理。放到项目里对应的是：代码、配置、日志、数据要分离。配置放到 Nacos 统一管理，日志按 traceId 落盘，输出结果统一走接口。服务命名用“业务域-子模块”的格式，例如 order-service、stock-service。

9.4 批量任务要加日志和失败重试

分布式环境里批量任务一旦失败，排查成本很高。每个任务要有任务 ID、执行日志、失败重试机制。推荐结合 MQ 做失败重试，或者用 XXL-Job 的失败告警。

9.5 接口服务和数据访问要限制范围

将服务注册到 Nacos 后，接口不能随意暴露到公网。网关层做鉴权，内网服务之间通过 service name 调用，不直接暴露 IP。数据库账号按服务隔离，单个服务只能访问自己的 schema。

9.6 发布或商用前要做效果复核

微服务化之后，每次发布都要做接口回归和压测。建议在测试环境完整跑一遍核心链路，特别注意分布式事务和缓存一致性在真实请求量下是否稳定。

10. 总结与下一步

最值得记住的一句话是：分布式是部署形态，微服务是架构风格。

• 如果面试官问区别，从拆分维度、关注问题、数据共享三个角度回答，能直接讲完核心。
• 如果自己在做架构选型，先问一个问题：现在系统是单机遇到瓶颈，还是单体代码耦合到无法维护？前者考虑分布式集群，后者才需要认真思考微服务拆分。
• 最容易踩的坑是：把单体复制多份，起了一个分布式集群，就对外宣称是微服务。代码层面没有边界拆分、数据层面没有独立、治理层面没有服务发现，这就不是微服务。
• 分布式事务和分布式锁，是上手分布式后最先会碰到的技术难点。Seata 和 Redis/Redisson 是最快见效的组合。
• 后续可以继续扩展的方向：链路追踪（SkyWalking）、分布式定时任务（XXL-Job）、JMeter 分布式压测、服务网格（Istio）。

建议先把 Nacos + Seata + Redisson 这三件套在一个 Spring Cloud 项目里跑通，对照本文第 2、3 节的配置，把注册、发现、事务、锁链完整验证一遍。这一套跑下来，分布式和微服务的区别就不是概念问题了。