分布式系统-体系结构需求-模型基础设计

文章详细介绍了分布式系统的设计原理,包括系统模型、服务器进程的对等设计、客户服务模型如RPC和REST、服务合并策略如负载均衡和微服务。同时,讨论了代理服务器和缓存的角色,对等进程的交互以及各种服务端模型的变种。文章还强调了性能问题、缓存一致性以及可依赖性,提出了冗余备份、负载均衡等容错策略,并涉及安全模型和保护机制,如认证和加密通信。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

分布式系统概念和设计

系统模型

无论系统在何种可能的环境下,保证功能正确性是主要建设目的。

体系结构模型

主要是系统可靠,可管理,适应性和成本效益。

简化和抽象分布式系统单个组件的功能

1.在计算机网络上的组件的放置,数据和负载分布寻找有用的模式定义

2.组件之间的关系,组件之间的功能角色和组件之间的通信模式

**最初的简化是服务器进程和客户进程的对等或者对称进程的设计方式,通过对称的方式协作和通信处理任务,进程分类是区分进程的责任设计。

3.一个进程的代码可以允许其他进程代理访问

4.分布式系统设计插拔方式允许服务自发现和自删除的提供服务

软件层

软件体系结构是同一计算机或不同计算机上进程之间请求和提供的服务

面向进程或者面向服务用服务层表达

关于分布式系统中的中间件的观点是端到端的能力之上抽象也许会更加复杂和抽象,更加不稳定的因素来源。

在这里插入图片描述

系统体系结构

系统组件(应用,服务器和其它进程)之间的责任的划分和网络上计算机组件的放置可能是分布式系统设计最明显的方面。

客户-服务模型

客户服务模型在分布式系统中,主要是指客户端和服务端之间的交互模式和通信方式。在分布式系统中,客户端和服务端可能分布在不同的地方,甚至可能分布在不同的网络中,因此客户服务模型需要考虑如何处理网络延迟和失效等问题,以保证系统的可靠性和稳定性。

常见的客户服务模型包括:RPC(Remote Procedure Call,远程过程调用)、REST(Representational State Transfer,表述性状态转移)、消息队列等。

RPC模型通常采用TCP协议进行通信,客户端通过调用远程服务端提供的API接口来访问服务端,服务端接收到请求后执行相应的操作,并将结果返回给客户端。RPC模型具有调用简单、性能高效等优点,但也存在一些问题,比如服务端的高并发处理能力和网络故障的容错能力等。

REST模型通常采用HTTP协议进行通信,客户端通过HTTP请求访问服务端提供的资源,服务端响应相应的状态码和资源数据。REST模型具有灵活性和可扩展性等优点,但也存在一些问题,比如性能相对较低、状态管理和安全性等方面需要特别关注。

消息队列模型通常采用消息中间件来实现,客户端将消息发送到消息队列中,服务端监听消息队列并处理其中的消息。消息队列模型具有异步处理、高可靠性等优点,但也存在一些问题,比如消息顺序性、消息重复等问题需要特别关注。

总之,在分布式系统中选择适合的客户服务模型是非常重要的,需要综合考虑系统的实际需求和技术特点,以达到最优的系统性能和用户体验。

在这里插入图片描述

多个服务器提供服务

复用性设计来源于提供可靠和高性能的需求,常见的就是数据分区能力。

在分布式系统中,多个服务可以通过合并提供服务,以提高系统的可用性、可靠性和性能。常见的服务合并方式包括:

  1. 负载均衡:将服务请求分配到多个服务实例中,以平衡负载和提高服务的可用性和性能。负载均衡可以通过硬件负载均衡器、软件负载均衡器或DNS负载均衡实现。
  2. 服务网关:将多个服务封装在一个网关中,对外提供统一的API接口,以简化客户端的调用和管理。服务网关可以通过API网关或微服务网关实现。
  3. 服务聚合:将多个服务的数据聚合在一起,形成一个新的服务,以提供更加丰富和综合的功能。服务聚合可以通过API聚合或数据聚合实现。
  4. 服务分解:将一个服务拆分成多个子服务,提高系统的可扩展性和灵活性。服务分解可以通过微服务架构实现。
  5. 服务缓存:将服务的结果缓存起来,以加快服务的响应速度和降低服务的负载。服务缓存可以通过缓存服务器或代理服务器实现。

以上服务合并方式可以单独使用,也可以组合使用,以满足不同的系统需求和场景。但需要注意的是,服务合并也会带来一些问题,如服务依赖关系、服务版本管理、服务监控和故障处理等,需要综合考虑并做好相应的设计和实现。

在这里插入图片描述

代理服务器和缓存

在分布式系统中,代理服务器和缓存服务器是两种常见的服务器类型,它们分别用于不同的用途。

  1. 代理服务器

代理服务器是一种充当客户端和服务器之间中间人的服务器。代理服务器接收客户端的请求,然后向目标服务器发送请求,并将目标服务器的响应返回给客户端。代理服务器可以用于多个用途,例如:

  • 负载均衡:代理服务器可以将客户端请求分发到多个服务器进行处理,以平衡负载并提高系统的可用性和性能。
  • 安全性:代理服务器可以用于安全性控制,例如防火墙、反向代理等。
  • 缓存:代理服务器可以缓存一些静态资源,例如图片、CSS、JS等,以减少客户端请求和提高访问速度。
  1. 缓存服务器

缓存服务器是一种将数据缓存在内存中的服务器,它可以加快数据的访问速度并减少对源服务器的请求。缓存服务器可以用于多个用途,例如:

  • 提高性能:缓存服务器可以缓存一些频繁访问的数据,例如网站的静态资源、数据库查询结果等,以提高系统的性能和响应速度。
  • 降低负载:缓存服务器可以缓存一些计算结果,以减少对源服务器的请求和负载。
  • 改善用户体验:缓存服务器可以缓存一些用户个性化数据,例如推荐结果、历史记录等,以提升用户体验和满意度。

需要注意的是,代理服务器和缓存服务器都需要根据实际需求进行设计和实现,并考虑到系统的可扩展性、可靠性、安全性等方面的问题。此外,代理服务器和缓存服务器也需要进行监控和维护,以保证系统的稳定性和可用性。

在这里插入图片描述

对等的进程

完成一项分布式活动或计算,所有进程扮演相同的角色,作为对等方进行协议交互,不缺分客户服务端。

对等进程中的代码在必要时维护应用层资源的一致性并同步应用层的动作。

在这里插入图片描述

客户-服务端模型变种

客户端服务器模型是一种常见的分布式系统架构模型,在此基础上可以衍生出多种变种,以下是其中的几种:

  1. P2P模型(Peer-to-Peer):P2P模型是一种点对点的架构模型,其中所有节点都可以作为客户端和服务器。在P2P模型中,每个节点都可以分享和获取资源,不存在中心化的服务器,因此具有高度的去中心化和可扩展性。
  2. C/S/B模型(Client/Server/Broker):C/S/B模型是一种三层架构的模型,其中客户端和服务器之间通过消息代理(Broker)来进行通信。消息代理可以将客户端的请求转发给服务器,并将服务器的响应返回给客户端。C/S/B模型可以实现异步通信和消息传递,具有较好的可靠性和扩展性。
  3. SOA模型(Service-Oriented Architecture):SOA模型是一种基于服务的架构模型,其中所有的功能都以服务的形式提供。客户端可以通过调用服务接口来访问服务,并获取服务提供的功能和数据。SOA模型具有高度的松耦合和可重用性,可以实现跨平台和跨语言的服务调用。
  4. MSA模型(Microservice Architecture):MSA模型是一种基于微服务的架构模型,其中所有的功能都以独立的微服务形式提供。每个微服务都可以独立部署、独立扩展和独立升级,客户端可以通过调用微服务接口来访问服务,并获取服务提供的功能和数据。MSA模型具有高度的可扩展性、灵活性和故障隔离能力。

以上是客户端服务器模型的一些变种,每种模型都有其独特的特点和适用场景,需要根据实际需求进行选择。

最新的微服务架构设计

在分布式系统中,除了SOA模型之外,还有一些替代品模式方式,如下:

  1. RESTful架构:RESTful架构是一种基于HTTP协议的架构模式,它通过简单的HTTP请求和响应来实现客户端和服务器之间的通信。RESTful架构具有轻量级、可扩展、可缓存等特点,适用于Web API等场景。
  2. Actor模型:Actor模型是一种基于消息传递的并发模型,其中所有的组件都被视为独立的个体,通过消息传递来进行通信和协作。Actor模型具有高度的并发性和可扩展性,适用于大规模分布式系统和高并发场景。
  3. Serverless架构:Serverless架构是一种基于事件驱动的架构模式,其中所有的功能都以函数的形式提供。客户端不需要管理服务器和网络,只需要编写和部署函数即可。Serverless架构具有高度的灵活性和可扩展性,适用于较小的、无状态的应用场景。
  4. GraphQL:GraphQL是一种新兴的API查询语言和运行时,它可以让客户端精确地描述它需要哪些数据,以及数据之间的关系。GraphQL具有高度的灵活性、可扩展性和可重用性,适用于复杂的、多种数据源的场景。
  5. GPT架构 a big deal huh?

需要注意的是,以上替代品模式方式并不是SOA模型的完全替代品,而是一些补充和辅助的方式。在选择模式方式时,需要考虑到系统的实际需求和技术特点,以达到最优的系统性能和用户体验。

接口和对象

在一个进程中可调用的函数集合由一个或多个接口定义指定。

每个服务器进程可看成是一个具有固定接口的实体,其中的接口定义了能被调用的能力。

在进程之间和计算机之间责任和分布的设计思考方式

分布式体系结构的设计需求

大规模的数据共享如果存在随着时间变化或者事件的变化会发下最终数据修改问题还是一个未解的问题

性能问题

资源分布引起的问题远远超过了并发修改的管理

1.反应能力

主要关注交互速度和数据的最终一致性和可用性问题,大数据产生的延迟问题

2.吞吐量

传统衡量标准是计算机系统性能的度量是计算工作进行的比例

3.平衡计算负载

分布式系统的一个目的是使得应用和服务进程能不竞争一个资源,并发运行,开发可用计算资源

服务质量

系统影响客户和用户感知服务质量的主要非功能特征是可靠,安全和性能

满足变化的系统配置和资源可用性的适应性是阿里云一直解决的问题

Robin新的思想是下面这些可靠性依然考虑的同时是上面提供模型可用性的能力 (GPUs,Frameworks,GPT,Applications )

基础模型(交互,故障,安全模型)

缓存和复制的使用

性能问题经常是分布式系统设计和落地中的根本性问题

缓存一致性问题是分布式系统中的常见问题之一。当多个节点同时访问同一个缓存时,可能会出现数据不一致的情况。为了解决这个问题,可以采用以下方案:

  1. 强一致性方案:在分布式系统中,强一致性方案是最常用的解决方案。它能够保证数据的一致性,但是会牺牲一定的性能。在这种方案下,每次修改缓存数据时,都需要将修改同步到所有节点,确保每个节点的缓存数据都是最新的。这种方案适用于对数据一致性要求非常高的场景,如金融系统。
  2. 弱一致性方案:弱一致性方案相对于强一致性方案来说,会在一定程度上牺牲数据的一致性,但是可以提高系统的性能。在这种方案下,每个节点都有自己的缓存,修改数据时,只需要将修改同步到部分节点,而不需要同步到所有节点。这种方案适用于对数据一致性要求不高的场景,如社交网络。
  3. 最终一致性方案:最终一致性方案是弱一致性方案的一种改进。在这种方案下,节点之间的数据同步是异步的,即修改数据后,并不保证所有节点都能立即看到最新的数据,但是最终所有节点都会达到一致的状态。这种方案适用于对数据一致性要求不高,但是需要提高系统性能的场景,如电子商务系统。
  4. 缓存失效方案:当缓存数据发生变化时,可以通过缓存失效来解决缓存一致性问题。当数据被修改后,可以将该数据对应的缓存失效,从而避免其他节点使用过期数据的情况。这种方案适用于对数据一致性要求不高,但是需要保证数据的及时性的场景,如新闻、天气等信息。
  5. 一致性哈希方案:一致性哈希方案是一种将缓存数据分散到多个节点中的方案。在这种方案下,每个节点都负责一部分数据的缓存,当数据被修改时,只需要同步到负责该数据的节点,从而避免了所有节点都需要同步的情况。这种方案适用于数据量较大、节点数量较多的场景,如搜索引擎。
可依赖性问题

正确,安全,容错

  1. 冗余备份方案:冗余备份方案是最常用的解决方案之一。在这种方案下,系统中的某个组件或节点出现故障时,可以自动切换到备份节点,从而保证系统的可用性。例如,数据库集群中可以使用主从复制或者多主复制来实现冗余备份。
  2. 负载均衡方案:负载均衡方案可以将请求分发到多个节点上,从而避免单点故障导致整个系统不可用的问题。例如,可以使用负载均衡器来分发请求到多个Web服务器上,从而提高系统的可用性。
  3. 自动容错方案:自动容错方案可以自动检测系统中的故障节点,并尝试自动修复或替换故障节点,从而保证系统的可用性。例如,可以使用Kubernetes等容器编排工具来实现自动容错。
  4. 服务降级方案:服务降级方案可以在系统出现故障时,临时关闭某些服务或功能,从而保证系统的可用性。例如,可以关闭某些不重要的服务或功能,让系统继续运行,直到故障被修复。
  5. 多活方案:多活方案可以将系统部署在多个地理位置上,从而避免单点故障导致整个系统不可用的问题。例如,在电商系统中,可以将系统部署在多个城市或国家,从而提高系统的可用性。
基础模型

系统模型应该解决的问题:

1.什么是系统中的主要实体?

2.实体之间如何交互?

3.影响实体的个体和集体行为的特征是什么?

4.显示有关我们正在建模的系统的假设?

5.给定假设给出适当分析?

:直接系统设计带来的能做和不能做的,能帮助我们确定不确定的情况

交互模型

单个系统中的算法通过步骤完成计算任务,分布式系统通过多进程的步骤完成计算任务

多进程中的消息传递步骤,传递的消息用于状态转移和协调

每个进程维护自己的状态:

1.通信信道进程经常受限

2.全局时间的概念无法维护

信道的性能

进程之间的信息传输延迟是等待时间

  • 比特从网络传输到目的地的时间
  • 访问网络延迟,等待发送站点网络空闲
  • 操作系统输入输出的时间

计算机网络带宽指在给定时间内网络能传递信息总量,多信道传输会共享网络带宽

抖动是传递一系列消息所用时间的变化值

计算机时钟和时序事件

因为绝对时间和计算机时钟之间的偏差导致即使两个进程同时读取本地时间也会读取不一样的时间信息,在分布式系统中,即使最开始设置时间是一样的,最终工作的时候还是很大的差别,来源于时钟的漂移率的不同,和物理世界的时钟偏差不一样

时钟更正方法分布式系统中

在分布式系统中,由于不同节点之间存在网络延迟和时钟漂移等问题,因此需要对时钟进行同步和校准。常用的方法包括NTP(网络时间协议)和PTP(精确时间协议)等。

NTP是一种基于UDP协议的网络时间同步协议,通过多个参考时钟源进行时间同步,并对时钟进行漂移调整。而PTP则是一种更为精确的时间同步协议,可以实现微秒级别的时间同步,并且支持硬件加速。

交互模型的变种

1.同步分布式系统

  • 已知进程执行每一步的时间有一个上下限的概念——对时间没有假设
  • 通过通道传递的每个消息能计算出在一定范围内接收到(已知时间范围)
  • 每个进程有一个本地时间,用于与实际时间的一个漂移率在一定的范围内

保证边界值的设计方式,基于边界的设计。

2.异步分布式系统:没有限制

  • 对进程的执行速度没有限制,可以一步执行一个世纪
  • 消息传递延迟,任意
  • 时钟漂移率,任意

现实中的分布式系统设计方式更多的是异步分布式系统,因为需要共享处理器和共享网络的信道。

事件排序

一个进程中的事件是发生在另一个进程中的另一个事件之前还是之后,系统的执行需要用事件的顺序描述

在一个分布式系统中因为时间无法精准同步,使用逻辑时间的模型,用于在分布式系统中给运行在不同计算机上的进程的事件提供顺序。

在这里插入图片描述

故障模型

分布式系统中进程和信道都可能发生故障,使用故障模型处理异常问题

遗漏故障

1.进程主要的遗漏故障时服务崩溃,进程不执行任何动作。

一个进程不能通过获得对另一个进程调用消息的应答得到另一个进程崩溃的信息。

可以使用调用超时的方法假设定义另一个线程崩溃的事实。

2.通信遗漏故障,通信原语(send & receive)

一个进程将消息放入外发缓存后执行send,信道将消息传递到另一个进程消息缓冲区

另一个进程通过缓冲区执行receive完成消息的接收,通常有操作系统完成这一步骤

在这里插入图片描述

随机故障

拜占庭故障时进程随机的省略处理步骤忽略步骤的执行

时序故障

在同步系统中,进程的执行时间,消息传递时间和时钟漂移率均有时间限制,任意故障导致指定间隔内客户端没有响应.

故障屏蔽

分布式系统中的每个组件都是基于其他组件构造,存在故障的组件如何构造可靠的服务.

持有复制数据的服务器集群能提供可靠的服务。

了解组件的故障特性在设计的时候能够通过设计屏蔽能力进行故障屏蔽保障服务可靠性。

一对一通信的可靠性
  • 有效性:在外发消息缓冲区的任何消息最终被发送到接收消息的缓冲区
  • 完整性:接收消息与发送消息一致,没有消息被发送两次
  • 任何重发消息但不拒绝两次的消息的协议,协议能附加顺序号检测消息是否达到两次。
  • 防止攻击时维护完整性。
安全模型

基于资源共享能力的分布式系统,安全模型的作用是通过封装对象的进程和通过与其他进程交互访问。

通过使进程和用于进程交互的通道获得安全以及所封装的对象不被未经授权的用户访问而获得分布式系统的安全能力。

保护对象

代表或共享用户管理(鉴权)一组对象的一个服务器

用户通过客户端调用服务器完成对象的操作,服务器将对象的操作结果放回给客户端。

在这里插入图片描述

保护进程和进程交互方式

网路和通信访问公开造成的进程间交互的安全问题,

识别和解除威胁,鉴权,接口管理,加密,通信加密,凭证,服务器安全链接

解除安全威胁

1.密码学和共享秘密:

两个或多个进程间共享秘密,通过秘密通信建立安全模型

2.密码学的数据加密处理进行传输

3.认证:

通过秘密和密码加密方式的基础建立认证体系,即证明发送方的身份

4.安全通道

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

P("Struggler") ?

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值