手记

【金秋打卡】第22天 Spring Boot打造企业微信点餐系统 5

第一模块:

课程名称: 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


第四模块:

学习截图:

0人推荐
随时随地看视频
慕课网APP