分布式系统学习（一）：相关概念及理论

概念

集群

相当于很多人一起 做一样的事

• 一个业务模块，部署在多台服务器上

分布式

相当于很多人一起，做不一样的事，这些事情合起来是一件大事；也就是变成了流水线工作

• 一个大的业务系统，拆分成多个小的业务模块，分别部署在不同的机器

理论

CAP理论

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

1. 一致性（Consistency） : 所有节点访问同一份最新的数据副本
2. 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
3. 分区容错性（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和大中间件绑定	服务之间点对点通信，强调独立性与自治性