第一模块：

课程名称： Spring Boot打造企业微信点餐系统

章节名称：6-8 ~ 6-13

讲师姓名：廖师兄

第二模块：

内容概述：

6-8 ~ 6-13小节主要讲解了订单的service取消、finish和paid，以及api_A，api_B，api_C和api_D等相关知识点

第三模块：

学习心得：

8.分布式核心概念

ACID、CAP、BASE

个人理解分布式：在现实中，要实现一个完整的业务闭环，是需要多个系统进化有序交互的，系统之间存在上下游的关系，即工作流的模式；可以想一个这么一个极限情况：所以系统全部整合到一块，变成一个系统，从工作流的模式（流模式），变成“点模式”，那么这时就不存在什么“分布式”的概念了，因为。所以系统都耦合在一块，成一个整体了，自然就不存在分布式了。

这样做可行吗？理论上可行

但是，实际操作起来就是一场恶梦！！！这样做会让后期的维护和二次开发变的举步维艰！！！

所以，一定要分布式！！！

分布式：将一个大系统进行“分割”，从业务层面解耦，分出若干个小系统，形成工作流，变成流模式，系统之间通过数据交接来协调工作。

微服务：微服务本质上是分布式发展的极致！是对系统的进一步分割，这次是从功能层面对系统解耦，一个系统，有些功能用的多，有些功能用的少，那么一个系统就存在“功能负载不均”的问题，怎么办呢？用微服务对系统进行进一步“分割”，用的多的功能多集群一些，用的少的功能少集群一些，所以：服务就是功能！！！

小结：

应用软件发展的历程，其实就是一个不断被分解的过程。

从“大单体点”--->“小单体流”--->"小单体功能流"

可以发现：越来越扁平化！！！

分布式、微服务的本质是一样的，所以，都存在一个问题：数据一致性

我们来看现在解决分布式数据一致性的主流解决手段：核心是事务！！！

1.ACID(核心是数据库层面解决数据一致性问题，思想是：过程一致，则最终一致)

一般关系型数据库都会保证ACID这个特性，那么ACID对于一致性来说，就是一种最直接且最有效的强一致性。比如： 订单和库存的问题，如果在数据量较小的情况下，可以利用关系型数据库的强一致性解决。无非就是把订单表和库存表放到同一个关系型数据库之中去操作，利用其ACID的特性去达到一致性。

这种处理方式可以，但是不适用于互联网电商，因为互联网电商系统往往都是具有大规模、高并发的特性，必须采用对高并发压力的”分而治之，大事化小，小事化了”的思想去做，否则难以抗住动辄就是上亿级别流量的需求、以及吞吐量和性能上的需求。

正常来说：互联网大厂不会加任何的事务，也不应该加事务处理，什么所谓的TCC、两阶段提交或三阶段提交基本不会应用在生产；都是应用补偿方式、记录日志方式将分布式事务进行解决；加事务就代表降性能。

2.CAP(核心是业务层面解决数据一致性问题，思想是：过程可以不一致，但最终必须一致)

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP理论首先把分布式系统中的三个特性进行了如下归纳：

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

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

•分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求，也就是尽管网络上有部分消息丢失，但是系统仍然可以继续工作。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

•CAP原理证明任何分布式系统只可以同时满足两点，无法满足三者兼顾。

CP经典框架：Zookeeper

采用原子消息广播，是唯一使用Paxos算法来保障数据的强一致性，但是其做不到强可用性，ZK集群大的时候会出现局部崩溃等事件，所以其满足了CP，宁愿服务不对外提供数据，也不会出现提供不一致的数据，所以其架构的核心是满足CP原则；注释：Zookeeper的单调性：https://blog.csdn.net/paincupid/article/details/80610441

 ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障（注：由于交换机故障导致交换机底下的子网间不能互访）；那么ZooKeeper会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的；所以导致到达这些节点的服务请求被丢失了。（注：这也是为什么ZooKeeper不满足CAP中A的原因）

AP经典框架：springcloud、Eureka

目前： springcloud比较适合中小型互联网公司快速搭建；

3.BASE(上面两者的技术结合，是实践出的工程方法)

BASE是互联网实际操作过程中不断发展而成，即前辈经验积累而成；

•如果说我们用化学的角度去衡量一致性的问题，那么ACID 就是（酸），而BASE理论就是（碱）。

•BASE思想解决了CAP理论所提出的分布式系统的一致性和可用性不可兼得的问题。

•BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

BASE中的三要素：

•BA： 基本可用，应用策略保障请求可以执行；

•S：软状态，这个状态可以在一段时间内不同步，业务可以容忍；

•E：最终一致，在一定的时间窗口内，数据达到最终的一致性即可。

开发笔记：https://blog.csdn.net/zxylwj/article/details/96475369

9.微服务和Spring Cloud的关系

轻量级的通信机制：基于Http的Restful API

微服务：粒度足够细的单体应用

微服务架构：首先得知道架构是什么意思？架构——应用的构成

比如：B/C架构、C/S架构、MVC架构等等，值得注意的是：从不同的角度去看一个应用的构成，会有不同的结果，比如，B/S架构常常也是MVC架构。

所以，微服务架构就是：基于微服务思想和微服务技术构成的应用，就是微服务架构的应用

微服务框架：帮助开发者快速搭建“微服务架构”应用的框架，比如：SpringCloud

SpringCloud与SpringBoot的关系：

SpringBoot用于快速搭建单体应用；

SpringCloud用于搭建微服务架构的应用；

这里注意，SpringBoot和SpringCloud的分工不一样，SpringBoot负责构建单体应用，SpringCloud负责将这些单体应用注册成一个个服务，将这些服务管理起来，进行有效的服务治理，即：将这些散兵游勇变成一只“能打仗的正规部队”，做到服务之间互相协调,互相配合,为用户提供最终价值

所以：SpringBoot负责创造士兵，SpringCloud负责将士兵们组织成一个军队！！！

spring家族的调用链：Spring、SpringMVC < SpringBoot < SpringCloud

所以，基于上面的调用链，Spring家族的依赖链也出来：

SpringCloud依赖SpringBoot，SpringBoot依赖Spring、SpringMVC

第四模块：

学习截图：