概念
集群
相当于很多人一起 做一样的事
- 一个业务模块，部署在多台服务器上
分布式
相当于很多人一起，做不一样的事，这些事情合起来是一件大事；也就是变成了流水线工作
- 一个大的业务系统，拆分成多个小的业务模块，分别部署在不同的机器
理论
CAP理论
CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。
CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：
- 一致性（Consistency） : 所有节点访问同一份最新的数据副本
- 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
- 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。
网络分区：分布式系统中，多个节点之间的网络本来是连通的，但是因为 某些故障（比如部分节点网络出了问题） 某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。
CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。
因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。
为啥不可能选择 CA 架构呢？
举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。
- 为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。
- 为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。
另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。
架构演进
单体架构
优点：
- 简单，开发部署方便，小型项目首选
缺点：
- 项目启动慢
- 可靠性差
- 可伸缩性、扩展性、可维护性差
- 性能低
垂直架构
指：将单体架构中的多个模块拆分为多个独立的项目，形成多个单体架构，每个项目之间没有交互，共用一个数据库。
存在的问题： 重复功能太多
分布式架构
指：在垂直架构的基础上，将公共业务模块拆分出来，作为独立的服务，供其他调用者消费，实现服务共享和重用。
存在的问题： 服务提供方一旦发生变更，所有消费方都需要变更
SOA架构
在分布式架构的基础上，通过服务暴露接口完成把服务消费方和提供方解耦，通过ESB实现服务集中治理。
ESB：企业服务总线，相当于一个中介，让服务与服务之间可以进行交互。
功能包括：负载均衡，流量监控，异常处理等等【也就是服务治理和监控】
存在的问题：ESB 一旦宕机，整个系统通信受阻
微服务架构
在SOA架构上进行升华。 强调：【业务彻底的组件化和服务化】业务系统拆分为多个可以独立开发、设计、运行的小应用，它们之间通过服务完成交互。
SOA VS 微服务
| SOA | 微服务 | |
|---|---|---|
| 通信方式 | 依赖 ESB（企业服务总线），通过统一中间层转发请求 | 采用 轻量级通信机制（如 RESTful API、gRPC、消息队列） |
| 治理方式 | 通过ESB进行统一治理（如日志、路由、监控、安全） | 通过 服务注册中心 + 配置中心 + API网关 + 容器编排（如Kubernetes） 实现分布式治理 |
| 依赖关系 | 理论上独立，但常被ESB和大中间件绑定 | 服务之间点对点通信，强调独立性与自治性 |