SpringCloud学习

SpringCloud

Spring Cloud 5大组件有哪些？

服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？

注册中心的核心作用是：服务注册和发现，常见的注册中心：eureka、nocas、zookeeper

1. 服务提供者需要把自己的数据，比如ip和端口注册到注册中心

2. 服务消费者需要从注册中心中拉去所需要调用的服务提供者的信息
3. 服务消费者在获得服务提供者的信息后，采用负载均衡的方式进行远程调用

4. 为了防止服务器宕机导致注册中心存储错误的数据，服务提供者需要的每个微服务需要定期向注册中心发送心跳，如果一个服务在一段时间内持续没有发送心跳，那么注册中心就认为当前某个实例挂机，并从服务列表中移除。

eureka作为注册中心，这个也是spring cloud体系中的一个核心组件

服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等

服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用

服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

nacos与eureka的区别

1. Nacos与eureka的共同点（注册中心）

   1. 都支持服务注册和服务拉取
   2. 都支持服务提供者心跳方式做健康检测

2. Nacos与Eureka的区别（注册中心）

   1. Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
   2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
   3. Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
   4. Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
   5. Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

项目负载均衡如何实现的 ?

1. 负载均衡 Ribbon，发起远程调用feign就会使用Ribbon

2. Ribbon负载均衡策略有哪些 ?

• RoundRobinRule：简单轮询服务列表来选择服务器
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
• RandomRule：随机选择一个可用的服务器
• BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
• RetryRule：重试机制的选择逻辑
• AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
• ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询

3. 如果想自定义负载均衡策略如何实现 ?
   1. 创建类实现IRule接口，可以指定负载均衡策略（全局，对所有的原成功调用都起作用）
   2. 在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）

什么是服务雪崩，怎么解决这个问题？

• 服务雪崩：一个服务失败，导致整条链路的服务都失败的情形

• 服务雪崩的预防：服务降级是服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃。当被调用服务宕机时，自动执行fallback策略，返回相应提示信息。一般在实际开发中与feign接口整合，编写降级逻辑

• 服务雪崩的解决：Hystrix 熔断机制，用于监控微服务调用情况， 默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker。如果检测到 10 秒内请求的失败率（也就是服务降级的次数）超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。
  

微服务是怎么监控的？

由于一个项目中存在大量微服务，如果一个服务出现问题，会导致整个接口的调用也出现问题，那么如何定位问题服务就尤为重要。

• skywalking：一个分布式系统的应用程序性能监控工具（ Application Performance Managment ），提供了完善的链路追踪能力， apache的顶级项目。

项目中采用的skywalking进行监控的

1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。

2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复

为什么要做限流 ? 怎么做的 ?

1. 并发的确大（突发流量）；防止用户恶意刷接口

2. 限流的实现方式：

   • Tomcat：可以设置最大连接数

   • Nginx，漏桶算法

     控制速率（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量

   

   ​ 控制并发数，限制单个ip的链接数和并发链接的总数

   ​

   • 网关，令牌桶算法：令牌桶算法可以应对突发的大量请求

   

   • 自定义拦截器

CAP定理

分布式系统有三个指标：Consistency（一致性）、Availability（可用性）、Partition tolerance （分区容错性）

• Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致

• Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

• Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

  Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

• 分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的

• 如果保证访问的高可用性（A）,可以持续对外提供服务，但不能保证数据的强一致性–> AP

• 如果保证访问的数据强一致性（C）,就要放弃高可用性 --> CP

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

•Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

•Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。

•Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

上图中，各个服务可以在事务提交前发送相应的执行情况给事务协调者，事务协调者来判断各个事务的状态从而决定是否提交。此时的服务就处于以一种软状态。

解决分布式事务的思想和模型：

1. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）

2. 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚（CP）

分布式事务解决方案有哪些

只要是发生了多个服务之间的写操作，都需要进行分布式事务控制

1. Seata框架(XA、AT、TCC)

Seata事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - **事务协调者：**维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - **事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - **资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

• XA模式，CP，需要互相等待各个分支事务提交，可以保证强一致性，性能差

• AT模式，AP，底层使用undo log 实现，性能好

• TCC模式，AP，性能较好，不过需要人工编码实现

2. MQ模式实现分布式事务，在A服务写数据的时候，需要在同一个事务内发送消息到另外一个事务，异步，性能最好

分布式服务的接口幂等性如何设计？

幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。

需要幂等场景：

1. 用户重复点击(网络波动)
2. MQ消息重复
3. 应用使用失败或超时重试机制

接口幂等以及解决方式：基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析

1. 数据库唯一索引（新增）
2. token+redis（新增，修改）

3. 分布式锁（新增，修改）

public void saveOrder(Item item) throws InterruptedException {    
    //获取锁（重入锁），执行锁的名称
    RLock lock = redissonClient.getLock("heimalock");
    //尝试获取锁，参数分别是：获取锁的最大等待时间（期间会重试），锁自动释放时间，时间单位  
    boolean isLock = lock.tryLock(10, TimeUnit.SECONDS);    
    	try {
            //判断是否获取成功    
            if (!isLock) {
                log.info("下单操作获取锁失败,order:{}",item);           
                throw new RuntimeException("新增或修改失败");       
            } 
            //下单操作    
        } finally {        
            //释放锁
            lock.unlock();
        }
}

• 快速失败（抢不到锁的线程）

• 控制锁的粒度

分布式任务调度（XXL-Job）

xxl-job解决的问题：

1. 解决集群任务的重复执行问题

2. cron表达式定义灵活

3. 定时任务失败了，重试和统计

4. 任务量大，分片执行

• xxl-job路由策略有哪些？

1.FIRST（第一个）：固定选择第一个机器；

2.LAST（最后一个）：固定选择最后一个机器；

3.ROUND（轮询）

4.RANDOM（随机）：随机选择在线的机器；

5.CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。

6.LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举；

7.LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举；

8.FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度；

9.BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度；

10.SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

• xxl-job任务执行失败怎么解决？

故障转移（上面的路由策略）+失败重试（设置重试次数），查看日志分析----> 邮件告警

• 如果有大数据量的任务同时都需要执行，怎么解决？

执行器集群部署时，任务路由策略选择分片广播情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务。l在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行