概念
集群
相当于很多人一起 做一样的事
- 一个业务模块,部署在多台服务器上
分布式
相当于很多人一起,做不一样的事,这些事情合起来是一件大事;也就是变成了流水线工作
- 一个大的业务系统,拆分成多个小的业务模块,分别部署在不同的机器
理论
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和大中间件绑定 | 服务之间点对点通信,强调独立性与自治性 |