如果你觉得这篇文章对你有帮助,请不要吝惜你的“关注”、“点赞”、“评价”、“收藏”,你的支持永远是我前进的动力~~~
一、分布式系统架构演进之路
好的架构是演进出来的,这张图展示了分布式系统架构从单体应用到微服务的演进过程。具体步骤如下:
- 单体应用架构:这是最基础的架构形式,所有的功能模块都集成在一个应用程序中。
- 垂直应用架构:随着业务的发展,开始对单体应用进行拆分,形成多个独立的垂直服务或子系统,每个服务负责一个特定的业务领域。
- SOA(面向服务的体系结构)架构:进一步将垂直应用中的各个服务抽象为独立的服务组件,通过标准的通信协议(如SOAP、WSDL等)实现这些服务之间的交互。
- 微服务架构:最终演变为微服务架构,这是一种更细粒度的服务划分方式,每个服务都是高度自治的,专注于完成单一的业务任务。
- 服务化网格架构:这种架构通常伴随着Service Mesh(服务网格)、SideCar模式以及FaaS(函数即服务)等技术来实现服务的动态发现、负载均衡和服务治理等功能。
总结来说,这张图描绘了一个典型的分布式系统架构从简单到复杂、从集中到分散的演变路径,体现了软件工程中对于可扩展性、灵活性以及维护性的不断追求。
二、分布式事务产生的场景
上图展示了分布式事务产生的场景,具体分为三个部分:
- 跨数据库实例:
- 商城系统依赖订单库和交易库两个独立的数据库实例。
- 商场系统与这两个数据库进行交互。
- 跨进程实例:
- 系统被拆分成多个微服务,如订单微服务和库存微服务。
- 订单微服务通过REST/RPC等协议与库存微服务通信。
- 每个微服务都有自己的独立数据库(订单库和库存库)。
- 多服务访问单数据库:
- 订单微服务和库存微服务,它们共享同一个商城库。
总结来说,这些场景说明了在分布式系统中,由于数据分布在不同的地方或由不同服务管理,导致在进行事务处理时需要考虑数据的同步性和一致性,从而引入了分布式事务的概念和技术来解决这些问题。
三、分布式事务的理论知识-CAP
“既要、又要、还要”是某互联网公司的一个笑谈,但又是真实的需求:
- 提升系统的可用性(A) :这指的是系统能够持续提供服务的能力,即使是在出现故障或高负载的情况下也能保持稳定运行。
- 保证数据的实时可见(C) :这意味着数据更新应该能够立即被所有相关节点看到,确保数据的一致性和时效性。
- 提升系统的容错能力(P) :这是指系统在面对错误、故障时能够继续运行并提供服务的能力,通常通过冗余设计来实现。
但真的“臣妾做不到啊!”
这张图片展示了分布式系统中的CAP定理(Consistency, Availability, Partition Tolerance),以及它们之间的关系。以下是详细解读:
CAP 定理概述
CAP定理指出,在分布式系统中,一致性、可用性和分区容错性这三个特性最多只能同时满足两个。这个理论是由计算机科学家Eric Brewer提出的,并在2000年首次提出,后来在2002年被证明。
C: 一致性(Consistency)
每次读取数据时,都能获得最近写入的数据,要么就返回一个错误。这意味着所有节点上的数据都是同步的,任何一次读操作都能获取到最新的写结果。
A: 可用性(Availability)
每次请求都能在合理的时间内得到响应,但不保证返回的是最新写入的数据。即使某个节点的数据可能不是最新的,但服务仍然能够正常处理请求并提供响应。
P: 分区容忍性(Partition tolerance)
尽管节点间存在网络丢失或延迟,但系统能够继续运行。这是指系统可以容忍部分节点之间的通信中断,而不会导致整个系统的崩溃。
人们对 CAP 有一些常见误解
- 误解一:认为分布式系统因为CAP定理放弃了C(一致性)或A(可用性)中的一个。
- 实际上,当没有出现分区问题的时候,系统可以有完美的数据一致性和可用性。
- 误解二:认为C(一致性)和A(可用性)之间的选择是针对整个分布式系统的,只能整体考虑C和A之间的选择。
- 这是不正确的,实际上在分布式系统中可以根据不同的场景和应用需求进行灵活的选择。
- 误解三:认为CAP的三个特性只有是和否两种极端选择,而不是一个范围。
- 实际上,CAP理论中的每个特性都有一定的实现程度和权衡空间,并不是非黑即白的简单选择。
四、分布式事务的理论知识-BASE
在CAP不能同时保障的情况下,我们只能退而求其次,追求最终一致性。
BASE理论是用于分布式系统设计的原理之一,主要目的是在保证可用性的前提下,允许系统在某些情况下不满足强一致性要求。以下是BASE理论的三个核心原则的解释:
- Basically Available(基本可用) :
- 这里的“基本可用”指的是即使系统出现故障或部分不可用的情况,系统的核心功能仍然能够保持运行状态。例如,如果一个网站的部分页面无法访问,但其他关键服务如登录、搜索等仍能正常工作,那么这个系统就满足了基本可用的条件。
- Soft State(软状态/柔性事务) :
- 软状态意味着系统并不总是处于一致的状态,而是可能存在中间状态或不一致的状态。这些状态不会影响系统的整体可用性,因为它们最终会通过某种机制达到一致。例如,数据库复制中的异步更新可能会导致数据在不同节点上的不一致,但这种不一致是暂时的,并不会影响数据的最终一致性。
- Eventually Consistent(最终一致性) :
- 最终一致性是指系统中的所有副本最终都会达到一致的状态。这意味着虽然系统中可能存在短暂的不一致,但随着时间的推移,所有的副本都将同步到最新的状态。这种一致性通常是通过后台进程或定时任务来实现的,而不是实时的一致性检查。
总的来说,BASE理论强调的是系统的可用性和灵活性,它允许系统在不牺牲用户体验的前提下容忍一定程度的暂时不一致性。这对于构建大规模分布式系统和应对复杂网络环境下的挑战非常有帮助。