分布式系统
简单理解
分布式系统 = 多台机器一起干活，对外看起来像一台
想象一下：你开了一家奶茶店。最开始你一个人搞定所有事------接单、做奶茶、收钱。但生意太好了，一个人忙不过来，于是你雇了3个员工：一个专门接单，一个专门做奶茶，一个专门打包。虽然分工不同，但顾客只看到"这家店"，并不关心里面几个人在干活。
这就是分布式系统的核心思想：把一个大任务拆成多个小任务，交给多台服务器（或进程）协作完成，但对用户来说，它还是"一个系统"。
分布式系统是由多个独立计算机组成的网络，这些计算机通过消息传递协同工作，对外表现为一个统一的整体。
或者这样理解：
想象一下一个大公司，不同部门分布在不同的办公楼里，每个部门各司其职，但又需要互相配合完成公司整体业务------这就是分布式系统的核心思想。
简单定义：一个系统被拆分成多个部分，部署在多台机器（或服务器）上，这些部分通过网络通信协作，对外提供统一的服务。
分布式系统的关键特征
多节点部署：系统组件运行在不同的计算机或服务器上
网络通信：节点之间通过网络进行通信和数据交换
资源共享：各个节点可以共享计算、存储等资源
并发处理：不同节点可以同时处理任务，提高效率
分布式系统
当你的系统满足以下条件之一时，它就是一个分布式系统：
数据库主从复制：一个数据库写数据，多个数据库读数据
应用集群部署：同一个应用部署在多台服务器，通过负载均衡分发请求
前后端分离：前端、后端、数据库分别部署在不同服务器
缓存与数据库分离：Redis缓存和MySQL数据库部署在不同机器
常见的：
用户量大的系统（比如淘宝、微信）
数据量太大，单机存不下（比如日志系统、大数据平台）
需要高可用（不能因为一台机器挂了整个系统瘫痪）
只要你的系统部署在两台及以上服务器上，并且需要协同工作，就是分布式系统。
面试官常问问题：
为什么用分布式？
单机性能有瓶颈（CPU、内存、磁盘、网络）
提升可用性（一台挂了，其他还能撑）
横向扩展方便（加机器就行）
"单台服务器能力有限，就像一个人搬不动太重的东西。分布式系统可以把工作分摊给多台机器，提高处理能力、可靠性和扩展性。"
技术点：
高并发处理（应对大量用户访问）
高可用性（一台机器挂了，其他还能继续服务）
横向扩展（通过增加机器提升系统能力）
分布式系统有哪些挑战？
网络延迟 & 不可靠（可能丢包、超时）
数据一致性问题（CAP 理论）
分布式事务（比如跨库转账）
服务发现与负载均衡
"就像多部门协作，沟通成本会增加。分布式系统面临网络延迟、数据一致性、节点故障等问题。"
核心挑战：
-
网络问题：延迟、丢包、超时
-
数据一致性：多个节点数据如何保持同步
-
节点故障：如何容错和自动恢复
CAP 理论是什么？
C（Consistency）一致性 （所有节点数据同步）
A（Availability）可用性 （每次请求都有响应）
P（Partition tolerance）分区容错性 （网络分区时系统仍能工作）
三者最多只能同时满足两个。实际系统通常选 AP 或 CP。
实际中通常要取舍，比如电商库存系统优先保证一致性，
而用户评论系统可能优先保证可用性。"
微服务架构
简单理解
微服务 = 把一个大应用拆成一堆小应用，每个小应用独立开发、部署、运行
继续用奶茶店举例：
以前你有一个"全能系统"------前台+后厨+仓库全在一个程序里。现在你把它拆成：
订单服务（管下单）
库存服务（管原料）
支付服务（管收钱）
用户服务（管会员）
每个服务都是独立的 Java 应用，可以单独上线、扩缩容、用不同技术栈。它们之间通过 HTTP 或 RPC 通信。
/微服务是分布式系统的一种具体实现方式。
如果把传统单体应用比作一个"全能型手工作坊"，那么微服务架构就像是一个"现代化专业工厂"，每个车间（服务）专门负责一个生产环节。
简单定义：将一个大型应用拆分为一组小型、独立的服务，每个服务围绕特定业务功能构建，可以独立开发、部署和扩展。
微服务架构是一种将单一应用程序划分为一组小型服务的方法，每个服务运行在自己的进程中，服务间通过轻量级通信机制（如 REST、gRPC）协作。
核心思想
单体应用 → 拆解 → 多个微服务
（一个巨人） （一群专业小团队）
微服务架构
系统模块边界清晰（比如电商的订单、商品、用户）
团队规模大，需要并行开发
需要快速迭代、独立部署某个功能
只要你的系统被拆成多个独立部署的服务，且每个服务职责单一，就是微服务架构。
微服务架构的典型特征：
-
服务拆分：按业务领域划分，如用户服务、订单服务、商品服务
-
独立部署：每个服务可以单独部署，不影响其他服务
-
技术异构：不同服务可以使用不同的技术栈
-
独立数据库：每个服务有自己的数据库（或数据库表）
yaml
用户服务 商品服务 订单服务 支付服务
↓ ↓ ↓ ↓
独立部署 独立部署 独立部署 独立部署
↓ ↓ ↓ ↓
用户数据库 商品数据库 订单数据库 支付数据库面试官常问问题：
微服务 vs 单体架构？
单体：开发简单，但部署慢、扩展难、技术栈统一
微服务：灵活、可扩展，但运维复杂、调试困难
"微服务让系统更灵活。比如双十一时，订单服务压力大，可以单独给订单服务增加服务器，而不需要扩容整个系统。"
主要优点：
独立开发部署：团队可以独立工作，互不干扰
技术栈灵活：不同服务可用最适合的技术
容错性更好：一个服务出问题，不影响整个系统
易于扩展：可以按需扩展某个具体服务
微服务怎么通信？
同步：HTTP（REST）、gRPC、Dubbo
异步：消息队列（Kafka、RabbitMQ）
微服务有什么缺点或挑战？
"管理复杂度增加了。原本一个应用现在变成了几十个服务，需要考虑服务通信、监控、部署等问题。"
主要挑战：
运维复杂度：需要管理大量服务实例
分布式事务：跨多个服务的数据一致性难以保证
网络延迟：服务间通信增加延迟
测试难度：需要测试服务间交互
怎么保证微服务的数据一致性？
最终一致性（通过消息队列补偿）
分布式事务（Seata、TCC、Saga 模式）
Spring Cloud在微服务中起什么作用？
"Spring Cloud就像是微服务架构的'工具箱'，提供了各种标准解决方案。
比如
Eureka做服务注册发现（服务之间如何找到对方），
Feign做服务调用（服务之间如何通信），
Hystrix处理故障（一个服务挂了怎么办）。"
微服务有哪些组件？
注册中心（Nacos、Eureka、Consul）
配置中心（Apollo、Nacos、Config）
网关（Spring Cloud Gateway、Zuul）
链路追踪（SkyWalking、Zipkin）
熔断限流（Sentinel、Hystrix）
服务调用：Feign、RestTemplate
负载均衡：Ribbon
分布式系统 vs 微服务架构：关系与区别
| 方面 | 分布式系统 | 微服务架构 |
|---|---|---|
| 核心概念 | 多台机器协作 | 按业务拆分独立服务 |
| 拆分依据 | 技术层面拆分 | 业务领域拆分 |
| 通信方式 | 各种网络协议（如 TCP、消息队列等） | 通常 HTTP/REST 或 gRPC/RPC |
| 数据管理 | 可能共享数据库 | 每个服务独立数据库（Database per Service） |
| 典型场景 | 数据库集群、应用集群 | 电商系统、大型互联网平台 |
总结：
分布式系统：强调"多机协作"，解决性能和可用性问题。
微服务架构：强调"业务拆分"，解决开发和维护复杂度问题。
分布式系统：关注"在哪里运行"（多台机器）
微服务架构：关注"如何组织"（按业务拆分）