SpringCloud五大组件

什么微服务区别于传统项目:

传统单体项目一个服务包含多个业务流程当某一服务节点由于某种原因宕掉导致整体服务崩溃。
从而引出微服务理念简单举个例子比如我们在某宝下订单时用户选择商品下单时由于后台接口出现异常导致下了订单库存无法减少这样存在很大漏洞风控一样，这时我们引入微服务理念由于整个业务由很多个单体项目组成一个发生故障不会引起其他服务，故障的服务我们也可以引入阿里官方开源的组件进行处理断言负载均衡、熔断、服务降级等方式。

微服务理念:

• 所谓微服务遵循CAP理论, 指的是之一个分布式系统，Consistency(一致性)、availability(可用性)、(partition tolerance)容错性。

• 一致性C:所有节点都可以访问到最新的数据
• 可用性A:每个请求的都是得到相应的,不管请求还是失败
• 分区容错性P:除了全部网络故障,其他故障不能导致整个系统不可用
• CAP理论就是说在分布式储存系统中、最多只能实现上面的两点。而由于当当前网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们一般只能在一致性和可用性之间进行权衡

一致性和可用性的权衡结果BASE理论

• 什么是BASE理论

CAP中的一致性和可用性进行一个权衡的结果，核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性，来自ebay的架构师提出

• Basically Available(基本可用)
  – 假设系统，出现了不可预知的故障，但还能用，可能会有性能或者功能上的影响(对非核心业务进行延迟处理)

• Soft state(软状态)
  – 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，既允许系统在多个不同节点的数据副本存在数据延时（服务降级处理）

• Eventually consistent(最终一致性)
  – 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能达到一致的状态，因此所有客户端对系统的数据访问最终都能够获得取到最新的值（软状态后最终达到一致性）

总结：

与传统ACID和CAP概念相反牺牲了强一致性来获得可用性并且允许数据在一段时间内是不一致的但最中达到一致性。

分布式事务核心思想
2pc:二阶段提交

第一阶段也称准备阶段：事务协调者 ；事务发起者
1.协调者向所有参与者发送事务内容，询问是否可以提交事务并等待答复
2.告知参与执行事务操作，将undo和redo信息记入事务日志中单不提交
3.如参与者执行成功，给协调者反馈同意，否则反馈终止

第二阶段也称提交阶段：事务参与者； 事务执行者
当协调者节点从所有参与者节点获得相应都为同意时
1.协调者所有节点像参与者节点正式发出提交请求
2.参与者节点正式完成操作，并释放事务占用资源
3.参与者节点像协调者发送ack完成消息
4协调者节点收到所有参与者节点反馈的ack消息，完成事务

方便理解的例子：

保持事务的一致性；

缺点1：性能问题；二阶段能保持事务的原子性但在执行过程中所有参与者都是事务阻塞型，当参与者占用公共资源时，其他第三方访问公共资源不得不阻塞

缺点2：可靠性问题；参与者发生故障，协调者需要给每个参与者额外指定超时机制，超时后整个事务失败，协调者故障参与者一直阻塞下去，需要容错处理

缺点3：数据一致性问题；二阶段协调者发出commit消息之后宕机，唯一接收这条消息的参与者也宕机，即使通过协议产生新的协调者，事务状态是不确定的，未知事务是否提交

3pc:三阶段提交
释义：三阶段提交是二阶段提交的改进版，三阶段提交有两个改动点

• 在协调者和参与者都引入超时机制
• 在第一阶段和第二阶段中插入一个准备阶段,保证了在最后的提交阶段之前各参与节点的状态是一样的

也就是说，除了引入超时机制外,3pc把2pc准备阶段再次一分为二，这样三阶段就有CanCommit，PreCommit，DoCommit

阶段一：CanCommit阶段

3pc的CanCommit ,协调者向参与者发送commit请求（询问）参与者如果可以提交就返回yes响应，否则返回no响应
1.事务期间 协调者向所有参与者发出包含事务内容的CanCommit请求。询问是否可以提交事务，并等待所有参与者答复。
2.响应反馈 参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈yes进入预备状态，否则反馈no

阶段二：PreCommit阶段

协调者根据参与者的反应情况来决定是否可以进行事务的PreCommit操作，可分为两种情况

• 假如所有参与者均反馈yes,协调者预执行事务
  1.发送预提交请求：协调者向参与者发送PreCommit请求，并进入准备阶段
  2.事务预提交：参与者收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中（但不提交事务）
  3.响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终命令。

阶段三：doCommit阶段

---

下边来介绍少阿里微服务全家桶：
服务注册中心:nacos区别于Eruake不同点
1.nacos配置中心是nacos
2.Erueka配置中心是config
3.Nacos与Eureka自我保护机制对比

相同点：
①保护阈值都是个比例，0-1 范围，表示健康的 instance 占全部instance 的比例。
②都支持服务注册和服务拉取
③都支持服务提供者心跳方式做检测

不同点：
①erueka注册中心服务定时拉取服务提供者(pull)、nacos是消息推送(pull+push)每隔一段时间去更新
②nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时采用主动检测模式
③nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；
erueka采用AP方式

Nacos: 中包含注册进来的服务下可分为集群(默认调用本地集群，既相同的集群名)，集群下又包含多个实例

nacos：可以配置环境隔离(test、dev)在yml中配置命名空间的ID,只有在同一个环境下才可以相互调用

nacos:临时实例(服务像注册中心发出心跳没有则剔除)永久实例(注册中心像服务询问是否健康不会剔除）

nacos:多服务共享配置(服务名-profile.yml>服务名称.yml>本地配置)

跨域请求: 网关底层 CORS 解决方案;
浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截

---

1）保护方式不同

Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enable-self-preservation: false)

Nacos保护方式：当域名健康实例 (Instance) 占总服务实例(Instance) 的比例小于阈值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。

2）范围不同

Nacos 的阈值是针对某个具体 Service 的，而不是针对所有服务的。但 Eureka的自我保护阈值是针对所有服务的。

负载均衡
Ribbon
意义:

是netifix发布的开源项目，主要功能提供客户端软件负载均衡算法，是一个基于HTTP和TCP的客户端负载均衡工具。

所有客户端节点下的服务清单，需要自己从服务注册中心获取，结合cloud上通过自动化配置对象RestTemplate通过LoadBalanced开启对象调用时的负载均衡。

分布式系统中一个非常重要的理念，当访问的服务具有多个实例，需要根据某种均衡的策略决定请求发往哪个节点，这就是所谓的负载均衡，
原理是将数据流分摊到多个服务器执行，减轻每台服务的压力，从而提高了数据的吞吐量

• 从端的角度分析负载均衡有俩种
  – 服务端负载均衡 例如 nginx
  – 客户端负载均衡 例如Ribbon
• 常见的负载均衡策略有如下几种
  –节点轮询(每个请求按顺序分配到不同的后端服务器)
  – 权重配置(weight和访问成正比,数字越大,分配到的流量越高)
  – 固定分发(根据请求访问ip的hash结果分配,这样用户固定访问后端一个服务)
  – 随机选择、最短连接

新一代负载均衡组件open-feign

底层时Ribbon的实现

• 什么是Feign：
  释义：一种仿Http客户端进行远程调用其底层基于Ribbon之上，默认采用负载均衡轮询策略

– Open-Feign实现远程方法调用

SpringCloud提供的伪http客户端(本质还是http)，封装了http调用流程、更适合面向接口化让用Java接口注解的方式调用http请求.
不用像Ribbon中通过封装HTTP请求调用 Feign默认集成了Ribbon

– Feign可以支持很多种自定义配置

Sentinel流量防卫兵

sentinel分为两部分

1.核心库(java客户端)不依赖任何库，能够运行java运行时环境，同时对Dobbo、SpringCloud也有较好的支持

2.控制台(Dashboard)基于Spring Boot开发、打包后直接运行，不需要额外的Tomcat等应用容器

包括以下常用功能

• 限流(令牌桶算法、漏桶算法)

• 熔断(上游服务请求下游服务是发生故障隔一段时间在请求)

• 降级(抛弃一些非核心的接口和数据，返回兜底数据)

• 隔离(服务和资源互相隔离，两个服务固定分配内存不会导致崩溃)

• Sentinel控制台搭建包含如下功能
  

网关组件gateway

可用于用户请求服务时进行身份认证、权限校验、负载均衡、请求限流、以及服务路由下发

• 网关路由配置 routes
  – (id)路由id自定义
  – (uri)路由的目标地址,lb负载均衡,后边是服务名称
• 路由断言 predicates
  – 路由断言,判断请求是否符合路由规则的条件
• 全局过滤器 default-filters
• 自定义全局过滤器 GlobalFilter
• 过滤器执行链顺序
  – 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前
  – 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
  – 当order值一样时会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行
  – GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定

---

欢迎码农们入驻技术交流群：2597967958

*如果不爱了 就别勉为其难 *