Spring Cloud Alibaba
1. Spring Cloud Alibaba的五大组件
- Sentinel: 把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
- Nacos:一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
- RocketMQ:一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务.
- Dubbo: Apache DubboTm 是 款高性能 Java RPC 框架。
- Seata: 阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
其他组件扩展 - Alibaba Cloud 0SS:阿里云对象存储服务 (Object Storage Service,简称 0SS)，是里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
- Alibaba Cloud Schedulerx:阿里中间件团队开发的一款分布式任务调度产品，提供秘级、精准、高可靠、高用的定时(基于 Cron表达式)任务调度服务。
- Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道.
2. Seata有哪几种模式,分别有什么优缺点
Seata只有四种模式: XA、AT(默认)、TCC、Seaga
- XA: 强一致性，基于数据库隔离，无代码侵入，在一阶段不提交事务
- AT:默认模式，基于全局锁离，无代码侵入，一阶段提交事务，在提交事务前，会记录undolog日志，性合XA模工好，二阶段TC通知回滚，则根据undolog回滚，通知提交，则删除undolog日志
- TCC:性能最好，不需要依赖关系型数据库，但代码入侵读高。Try:冻结可用数据，Confirm:确认提交数据，删除冻数据 Canel:恢复数据，将冻结数据恢复
- Seaga: 用于长事务，例如A项目调另外一个公司的项目接口。优缺点:
- XA:强一致性，无代码侵入、但一阶段事务不提交、会锁住资源，导致性能低。需要依赖数据库的事务特性
- AT:默认，弱一致性，无代码侵入，一阶段事务直接提交，失败则根据undolog日志回滚，隔离性引入全局锁，但并发几率低，所以性能会比XA好。
- TCC:无需依赖关系型数据库，基于资源预留隔离。try、confim、canel需要人工手写，而且需要考虑空悬挂、空回滚、幂等性判断较为复杂、性能最好，但成本太高。
- Seaga:适用于长事务类型，无太多应用场景
- 下图为AT模式
**3. 负载均衡策略
负载均衡分两种: 一种是服务端负载均衡,一种是客户端负载均衡
服务端负载均衡: 通常所说的负载均衡指服务器负载均衡,是有服务器来决定调用哪个节点;
通过硬件或软件实现负载均衡均会 维护一个服务端清单，利用心跳检测等手段进行清单维护，保证清单中都是可以正常访问的服务节点 。当用户发送请求时，会先到达负载均衡器 (也相当于服务)， 负载均衡器根据负载均衡算法(轮训、随机、加权轮训)从可用的服务端列表中取出一台服务端的地址，接着进行转发，降低系统的压力。
客户端负载均衡:实际上是指服务器调用者,在SpringCloud中调用者本身继承负载均衡,由调用者决定调用哪个节点的服务;
Ribbon 维护了一个服务列表，如果服务实例注销或死掉，Ribbon 能够自行将其剔除。 Ribbon 提供了客户端负载均衡的功能，Ribbon 利用从注册中心中读取到的服务信息列表(存储在本地即客户端中)，在调用某个服务时，根据负载均衡算法直接请求到具体的微服务实例，常用的负载均衡算法有: 轮循、随机、加权轮循、加权随机、地址哈希等方法 。
拓展知识:
两者的区别:两者主要区分点在于服务清单的存放位置: 在客户端负载均衡中，客户端会存储一份服务端清单，它是通过从注册中心进行抓取得到的，同时也需要对此进行维护。而在服务端负载均衡中，服务端自己会维护一份服务端清单。
4.Nacos在服务器中突然挂掉怎么办
1.缩短默认的健康检查时间
通过Nacos提供的心跳周期配置，再结合自身的业务场景，我们就可以选择最适合的心跳检测机制，尽最大可能避免对业务的影响。
这个方案看起来心跳周期越短越好，但这样会对Nacos服务端造成一定的压力。如果服务器允许，还是可以尽量缩短的。
2.Nacos的保护阈(yu)值
本质上，保护阈值是⼀个⽐例值（当前服务健康实例数/当前服务总实例数）。
⼀般流程下，服务消费者要从Nacos获取可⽤实例有健康/不健康状态之分。Nacos在返回实例时，只会返回健康实例。
但在⾼并发、⼤流量场景会存在⼀定的问题。比如，服务A有100个实例，98个实例都处于不健康状态，如果Nacos只返回这两个健康实例的话。流量洪峰的到来可能会直接打垮这两个服务，进一步产生雪崩效应。
保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时，说明健康的实例不多了，保护阈值会被触发（状态true）。
Nacos会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也⽐造成雪崩要好。牺牲了⼀些请求，保证了整个系统的可⽤。
3.SpringCloud的请求重试
即便上面我们对心跳周期进行了调整，但在某一实例发生故障时，还会有短暂的时间出现Nacos服务没来得及将异常实例剔除的情况。此时，如果消费端请求该实例，依然会出现请求失败。
为了构建更为健壮的应用系统，我们希望当请求失败的时候能够有一定策略的重试机制，而不是直接返回失败。这个时候就需要开发人来实现重试机制。
在微服务架构中，通常我们会基于Ribbon或Spring Cloud LoadBalancer来进行负载均衡处理。除了像Ribbon、Feign框架自身已经支持的请求重试和请求转移功能。Spring Cloud也提供了标准的loadbalancer相关配置。
4.如果单节点Nacos挂了,不会导致整个系统不可用,而是会先使用本地缓存的数据,等Nacos恢复后再重新拉去最新的数据
Nacos源码种通过putService()方法将服务缓存到内存，service.init()建立心跳机制，通过consistencyService.listen实现数据 致性监听
总结: Nacos客户端通过Open API的形式发送服务注册请求，Nacos服务端收到请求后，做以下二件事: 构建一个Service对象保存到ConcurrentHashMap集合中，使用定时任务对当前服务下的所有实例建立心跳检测机制，基于数据一致性协议服务数据进行同步
Sentinel 的主要功能
1.流量控制
sentinel可以根据需要把随机的请求调整成合适的形式
2.熔断降级
检测到调用链路中某个资源出现不稳定的表现 (如: 请求响应时间长或者异常比例升高)，则对这人资源的调用进行限制，让请求快速失败，避免影响到其它的资源导致级联故障sentient对熔断提供了两种方案:1: 通过并发线程数进行限制2: 通过响应时间对资源进行降级。通过响应时间来快速降级不稳定的资源，当依赖的资源出现响应故障后，所有对该资源的访问都会被直接拒绝，直到符合指定的时间窗口之后才会重新回复
与hystrix:相同点: 原则是一致的，当一个资源出现问题时快速让其失败，不波及到其他服区别:hystrix采用的是线程池的隔离方式，优点是做到了资源之间的隔离，缺点是增加了线程切换成本sentinel 采用的是通过并发线程的数量和响应时间来对资源做限制
3.系统负载保护
当系统负载较高的时候，还持续进行访问，可能导致系统崩溃，无法响应，在集群环境下，会把本应当前机器成灾的流量转发到其他的机器上去，如果其他机器也处于一个边缘状态，sentinel会提供对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围内处理最多的请求
