微服务和分布式和SpringCloud三者的关系

微服务架构和分布式

分布式

分布式系统：由一组为了完成共同任务而协调工作和计算机节点组成，通过网络通信

​

特点：大数据存储、高并发、快速响应、分而治之的思想

分布式的好处

高性能：大量请求分摊到不同的节点，降低了每台服务器的压力，并且处理请求的速度也会变快，处理的数据多

高可用：如果单机系统，某个服务崩了，全部奔溃，但是分布式中，其中一个节点坏了，就还有另外一个节点

可伸缩性：当需要更新某个服务，只需要更新后，路由到新的服务器就好，同时还能下线不用的服务器

可维护性：如果某台出现故障，只需要停止故障的节点就好，维护好后，再上线

分布式的切分法：

水平切分和垂直切分分

所谓水平切分，就是将同一个系统部署到多台机器

垂直切分：按照业务的维度进行拆分，将各个业务独立出来

一般我们在开发使用都是两者的结合：混合切分

分布式存在的问题

数组的不一致性、丢包、延时

数据不一致性（1）

数据不一致性2

事务回滚问题

T3时刻是扣减库存服务提供操作，而到了T4时刻则是交易订单生成服务提供操作。因为它们不是在同一个事务内进行操作的，所以不能通过一个简单的事务进行处理。因此，需要通过分布式事务或者其他方式提供保证。

分布式事务设计的理论

CAP 原则和BASE 理论

CAP

一致性（C）：保持所有系欸但在同一时刻，具有相同的逻辑数据

可用性(A)：保证请求不管成功还是失败，都有响应

分区容忍性§：系统中的任何信息丢失或者失败都不会影响系统的继续运作

但是任何分布式系统都不能同时满足三个，只能满足两个

在当今互联网中，保持可用性往往是第一位的，其次是性能。因为从客户的感知来说，可用和快速响应能够提供更好的体验。一致性可以通过其他手段来保证，本书后面会给出具体的方法。
微服务主要追求可用性和分区容忍性（AP），弱一致性（C）。

BASE

其中我们在上面所讲的一致性就是强一致性，但是呢，在BASE 中，将一致性划分为强一致性和弱一致性

强一致性：当用户完成数据更新操作之后，任何后续线程或者其他节点都能访问到最新值

弱一致性：当用户完成数据更新操作之后，并不能保证后续线程或者其他节点马上访问到最新值。它只能通过某种方法来保证最后的一致性

BA(基本可用)：基本可用性，在双11 即使购买失败，你也要给我信息返回，比如服务器繁忙

S(软状态)：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

E（最终一致性）：是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，以保证数据的正确性

BASE理论的核心思想是：即使分布式系统无法做到强一致性，也可以采用适当的方法达到最终一致性

微服务架构

概念：微服务架构只是将一个单体应用程序拆分为多个相对独立的服务，每一个服务拥有独立的进程和数据，每一个服务都是以轻量级的通信机制进行交互的。微服务是一个模糊的概念，而不是一个标准，没有明确的定义。但微服务存在一定的风格，只要系统架构满足一定的风格，就可以被称为微服务架构

特性好处：

交互：一般为HTTP API（现今最流行的是REST风格）。

一般来说，这些服务都是围绕着业务模块来建设的，是独立的产品，因此完全可以独立地自动化部署和维护，这样更加有利于我们进行更小粒度的开发、维护和部署。

这些服务可以由不同的语言编写，采用不同的数据存储，最低限度地集中管理。

微服务风格

1. 组件化和服务：把一个单体系统拆分为一个可以独立维护和升级的组件，每个组件通信通过服务（RPC）来完成
2. 围绕业务功能组织团队：避免把错误原因丢来丢去，按业务模块划分团队
3. 是产品不是项目：之前可能开发完，把软件交给维护部门，团队就解散了，现在不是，谁负责模块，要一直关注、改善省级。
4. 分散治理：主要是技术选型上，根据模块的不同，选择最佳的语言去实现
5. 分散数据管理：每个组件，都有自己的数据库源，但是有弊端，事务ACID 将不复存在。
6. 容错性设计：某个组件坏了，就断电，相当于熔断器，还要有监控的仪表盘，检查是否正常和吞吐量的情况。
7. 设计与改进：就是业务的改变，比如用户量的暴增，就需要改进，满足业务的需求

微服务和分布式的关系

微服务是分布式系统设计和架构的理念之一。但是从微服务的风格来看，它并不是为了克服所有的分布式系统的缺陷而设计的，而是为了追求更高的可读性、可用性和简易性。但与此同时，也弱化了其一致性，正如这句老话——“两害相较取其轻者”。

SpringCloud和微服务的关系

Spring Cloud渐渐成了构建微服务系统的主要方案，成为市场的主流