浅谈：分布式系统基础理论

关于文章内容仅是个人理解以及知识积累，如有版权问题，请联系我删除，谢谢。

学习分布式系统我是根据以下问题开始的：

1. 为什么使用分布式系统？
2. 什么是分布式系统？

1、前言

为什么使用分布式系统？我总结了以下几点：

总结当下企业级应用的特点：

• 联网设备数量激增，上网用户指数爆炸
• 业务功能更繁多，更新频繁，业务复杂度几何级增长
• 数据量趋于海量
• 系统稳定性要求更高，可用性要求极高

单体应用弊端：

• 代码间关系复杂，难以理解和维护

• 项目体积变大，开发、测试、部署的过程都无比困难

• 无法使用新框架

• 可靠性下降

可见当下的企业级应用使用单体框架已经无法满足业务实现，因此一个单体应用被拆分成多个服务，每个服务有自己独立的数据库，每个单个服务的复杂度降低，单个服务与服务之间需要通信，协调。

这个就是简单的微服务架构，即单体项目拆分为分布式系统。

微服务架构图例：

​ 微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务，我们仅做最低限度的集中管理。

2、什么是分布式系统？

分布式系统就是一组部署在同一个网络下的多个通过网络来通信和协调的组件，对外部而言表现的如同一个系统。

分布式系统有多种层面的理解，比如，

• 可以指多个不同组件分布在网络上互相协作，比如前例所说的电商网站
• 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余，当数据修改时也需要通信来复制数据

结论：

1. 微服务架构 是 分布式系统，但是分布式系统不一定是微服务架构
2. 应用系统当中，这两种集群模式都有出现

3、CAP原理 和 BASE原理

CAP原理：

​ 加州大学的计算机科学家 Eric Brewer提出：分布式系统的三个指标（CAP）无法同时满足。

这个结论称之为CAP定理。

C ：Consistency 一致性

一致性是指，在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于访问任一节点得到的都是最新的数据副本）

下例是一个分布式存储系统，当某个节点更新时的情况，更新前后符合一致性的

A： Availability 可用性

可用性是指，在集群中一部分节点故障后，集群整体是否还能正常响应客户端的读写请求。（对数据更新具备高可用性）

下例仍然是分布式存储系统，如果某个节点出现故障，集群整体仍然是可用的，满足可用性

P ：Partition tolerance 分区容错性

分区容错性是指 系统必须能够处理组件之间因为通信失败（或者延迟）而造成分区的情况。通信出现故障就会形成多个分区，此时系统无法同时保证数据的一致性和可用性。

继续以三个节点的存储系统为例，若是S1与另外两个节点的通信出现问题，那么就形成了S1和S2+S3两个分区，此时数据必然无法达成一致性。

此时有两个解决方案

一是暂停或关闭所有节点，等待网络恢复，数据达成一致，这样保证了数据一致性。

另一个是继续提供服务，保证可用性，那么访问S1和访问S2、S3得到的将会不同的数据，不满足一致性

无论使用哪一种方案，都无法保证CAP同时成立

BASE原理：

因为CAP原理太难满足了，BASE原理的出现其实就是设计上的妥协和折中。

Basically Available(基本可用)，Soft state（软状态）和 Eventually consistent（最终一致性）

在分布式系统设计中引入柔性因素，降低设计和实现的难度，但又不影响基本使用。

Basically Available(基本可用)：

算作完全可用和完全不可用中的一种折中，互联网上的应用，如果是完全不可用的，那这个系统就没存在必要了；而在互联网上，用户量等有时候难以预见，就造成了用户超出系统设计的标准，想一直保持完全可用就很难，所以折中下，我们可以通过延迟响应，流量削峰等手段来保障系统的核心功能的正常，从而实现基本可用。

Eventually consistent(最终一致性)：

我们希望获取的数据就是正确的，这像一句废话，如果获取到的数据是不确定正确与否，那我们拿这些错误的数据干嘛。但是由于这样那样的问题，我们不能随时都保障数据的一致，所以我们有了数据的中间状态，即软状态，经过一定时间后，数据最终回归于最终一致，这些短暂的数据不一致性，对用户的影响很小，比如你更新一条微博动态，可能有的地方用户可以看到你这条微博消息，另外的用户看不到这条微博消息，这个影响不大，只要最终所有用户都可以看到你这条微博消息就可以了。

最终一致性的系统不承诺写入数据成功后，立刻就从系统中读出最新的数据，也不承诺具体多久之后可以读到最新的数据，而是尽可能保障特定时间级别之后的数据可用，这取决于很多因素，比如网络快慢，比如副本的多少等。如果我们设置过DNS域名就知道，DNS域名我们配置A记录后，域名和IP的关系不是立刻生效的，过多久也不好说，这就是个最新一致性的系统。

Soft state(软状态)：

软状态故名思意就是可以变动的状态，强调的是数据状态处于一种临界状态。相对于软状态，就是硬状态，就是数据的状态是确定的。对于满足ACID的数据状态是硬状态。最终一致性的系统中，数据的读出来的不一定是最新的，我理解就是一种软状态即一种短暂的临时状态。

4、构建微服务架构

Spring-Cloud提供了搭建微服务架构所需用的各种工具，借由这些工具，开发人员可以快速的搭建一个微服务架构，可以视Spring-Cloud为微服务架构工具集。

Spring Cloud称为 伞形项目，由多个子项目组成，留意三个子项目：

4.1 spring-cloud-netflix ( 美国奈飞公司 ) spring-cloud第一个子项目，应用广泛

• 服务发现：spring-cloud-netflix-eureka

• 负载均衡：ribbon

• 服务容错：hystrix

• 配置管理：archius

• 服务调用：feign

• 服务网关： zuul

  4.2 spring-cloud-alibaba 阿里巴巴出品，在国内采用比较多

• 服务发现：spring-cloud-alibaba-nacos

• 服务容错：sentinel

• 配置管理：nacos

• 服务调用：dubbo

• 分布式事务：seata

• 消息队列：rocketmq

4.3 spring-cloud官方组件

• 服务网关：spring-cloud-gateway
• 服务调用：openfeign

总结：使用不同组件的组合来构建微服务架构。

标签：服务,浅谈,spring,分布式系统,一致性,基础理论,数据,cloud
来源： https://blog.csdn.net/Dragon_Cool/article/details/122420137