Java工程师必懂：分布式演进中，分布式与微服务常被混淆，但二者在设计理念、架构边界和实践落地层面存在本质区别。

一、架构本质：从流程图看核心差异

分布式系统的核心是“资源共享”，通过网络连接多台独立主机协同工作；微服务则是“业务解耦”，将单体应用拆分为独立部署的业务单元，本质是分布式架构的一种特定实现形式。

1. 分布式系统架构流程图

该架构中，ServerA与ServerB部署相同应用代码，通过共享数据库、缓存等资源实现负载分担，核心目标是提升系统吞吐量和可用性，未关注业务边界。

2. 微服务架构流程图

微服务架构中，每个服务聚焦单一业务域，拥有独立数据库（数据隔离），通过服务间调用协同工作，核心目标是业务解耦、独立迭代和团队自治。

二、交互逻辑：时序图对比实践场景

以“用户下单”场景为例，对比分布式与微服务的交互差异。

1. 分布式系统时序图

关键问题：应用服务器同时处理用户、订单、商品逻辑，代码耦合度高；共享数据库存在锁竞争，高并发下性能瓶颈明显；一次故障可能导致整个系统不可用。

2. 微服务架构时序图

核心优势：订单服务仅聚焦下单逻辑，通过服务调用和消息队列解耦依赖；各服务独立部署，某服务故障（如商品服务）不影响订单提交（可通过降级返回默认库存）；独立数据库避免锁竞争，支持按需扩容。

三、项目实践：电商平台从分布式到微服务的演进

某电商平台初期采用“分布式单体”架构：3台应用服务器部署相同WAR包，共享MySQL主从数据库，Redis集群缓存热点数据。随着业务增长，出现三大痛点：

1. 迭代效率低：商品模块改一行代码需全量发布，日均发布次数≤1，无法响应促销活动快速迭代需求；
2. 性能瓶颈突出：大促期间，订单插入与商品查询竞争数据库锁，TPS仅能达到800，远低于预期的3000；
3. 故障影响范围大：一次商品图片处理代码内存泄漏，导致所有应用服务器OOM，系统整体不可用15分钟。

为解决上述问题，我们启动微服务改造，核心动作包括：

1. 业务域拆分：按DDD思想将系统拆分为用户、订单、商品、支付4大核心服务，每个服务由独立团队负责，采用Spring Boot+Spring Cloud构建；
2. 数据隔离：拆分共享数据库为4个独立MySQL实例，订单服务采用分库分表（Sharding-JDBC）处理海量订单，商品服务引入Elasticsearch存储商品详情；
3. 通信与容错：同步调用采用OpenFeign+Ribbon实现负载均衡，异步场景（如库存扣减）用RocketMQ解耦，通过Sentinel实现服务熔断降级（如商品服务故障时，返回“商品暂时无法购买”提示）；
4. 监控与运维：引入Prometheus+Grafana监控服务指标（响应时间、错误率），ELK收集日志，SkyWalking实现分布式链路追踪。

改造后效果显著：服务迭代周期从“天级”缩短至“小时级”，大促期间订单服务TPS提升至5000+，单服务故障影响范围缩小至单个业务域，系统可用性从99.9%提升至99.99%。

四、大厂面试深度追问

追问1：微服务架构中，如何解决服务间调用的分布式事务问题？（阿里P6+高频题）

解决方案：

分布式事务的核心是保证“跨服务操作的原子性”，需根据业务场景选择合适方案，以下是三种生产级实践：

1. 可靠消息最终一致性方案（推荐）
   适用于非实时性场景（如订单创建后发送短信通知），基于RocketMQ/RabbitMQ实现。以“订单创建+积分增加”为例：

• 步骤1：订单服务本地事务先插入订单记录，再发送“订单创建成功”半消息（未提交状态）；
• 步骤2：MQ确认消息发送成功后，订单服务提交本地事务；
• 步骤3：MQ将半消息转为确认消息，积分服务消费消息并增加用户积分；
• 兜底机制：若积分服务消费失败，MQ会自动重试（设置重试次数和间隔）；若订单服务提交事务失败，MQ会删除半消息，避免脏数据。
  优势：低耦合、性能好；局限：不保证实时一致性，需业务容忍短暂不一致。

2. TCC（Try-Confirm-Cancel）方案
   适用于强一致性场景（如支付系统），需业务代码侵入式开发。以“订单支付+库存扣减”为例：

• Try阶段：订单服务冻结用户余额，商品服务冻结商品库存（均为预操作，不实际提交）；
• Confirm阶段：若Try阶段全部成功，订单服务实际扣减余额，商品服务实际扣减库存；
• Cancel阶段：若某服务Try失败，订单服务解冻余额，商品服务解冻库存；
• 实现要点：需设计幂等接口（防止Confirm/Cancel重复执行），通过Seata等框架管理事务上下文。
  优势：强一致性；局限：开发成本高，需处理空回滚、幂等性问题。

3. SAGA模式
   适用于长事务场景（如电商下单涉及订单、支付、物流多个环节），将分布式事务拆分为多个本地事务，通过补偿机制保证最终一致。

• 正向流程：订单创建→支付处理→库存扣减→物流创建；
• 补偿流程：若物流创建失败，执行反向操作（库存恢复→支付退款→订单取消）；
• 实现要点：通过状态机管理事务阶段，记录每个阶段的执行状态，失败时触发对应补偿逻辑。
  优势：支持复杂长事务；局限：补偿逻辑设计复杂，可能出现部分补偿失败的情况。

选型建议：优先采用可靠消息方案，强一致性场景用TCC，长事务用SAGA，避免过度设计（如非核心业务可通过定时任务对账补单简化实现）。

追问2：微服务架构下，如何设计服务网关以应对高并发和安全问题？（字节跳动后端面试题）

解决方案：

服务网关作为微服务入口，需同时承担路由转发、流量控制、安全防护等核心职责，推荐基于Spring Cloud Gateway（非阻塞异步架构，性能优于Zuul）的设计方案：

1. 高并发架构设计

• 集群部署+负载均衡：网关节点部署多实例，前端通过Nginx或云负载均衡（如阿里云SLB）分发请求，避免单点故障；
• 异步非阻塞处理：利用Gateway基于Netty的异步特性，设置合理的线程池参数（如worker线程数=CPU核心数×2），避免线程阻塞；
• 缓存热点数据：将服务路由表、API权限配置等热点数据缓存到本地Caffeine中，减少对配置中心（如Nacos）的请求，提升路由效率；
• 限流降级：通过Sentinel整合Gateway，按接口维度（如/order/create）或IP维度设置限流规则（如QPS=1000），触发限流时返回自定义响应（如429 Too Many Requests）。

2. 安全防护实现

• 身份认证：集成OAuth2.0+JWT，客户端请求需携带Token，网关验证Token有效性（避免每个服务重复认证），无效Token直接拦截；
• 接口授权：基于RBAC模型，在网关配置“角色-API”权限映射，如普通用户无法访问/admin/*接口，权限校验失败返回403；
• 防攻击防护：实现IP黑名单（拦截恶意请求IP）、请求参数校验（防止SQL注入、XSS攻击）、接口幂等性处理（如通过请求ID+Redis防止重复提交）；
• HTTPS加密：网关层统一配置SSL证书，所有外部请求通过HTTPS接入，内部服务间通信可采用HTTP（减少加密开销）。

3. 可观测性设计

• 日志追踪：通过MDC注入请求ID，记录请求入参、出参、耗时等信息，结合ELK实现日志检索；
• 指标监控：采集网关QPS、响应时间、错误率等指标，通过Prometheus+Grafana展示，设置告警阈值（如错误率>5%触发短信告警）；
• 链路追踪：集成SkyWalking，将网关请求作为链路起点，追踪请求在各个微服务中的流转路径，快速定位慢请求瓶颈。

压测验证：通过JMeter模拟10万并发请求，优化后的Gateway集群可支持单机QPS=8000+，平均响应时间<50ms，限流触发时无服务雪崩风险。

以上内容从多方面解析了分布式与微服务的区别及相关技术点。若你对某部分内容想进一步深化，或有其他面试知识点需补充，可随时告知。