1、背景在微服务架构中，我们将业务拆分成一个个服务，服务之间可以相互调用，但是由于网络原因或者自身原因，服务不保证服务的100%可用性。如果单个服务出现问题，调用该服务时会出现网络延迟。如果此时有大量网络涌入，就会形成任务堆积。最终，服务瘫痪。2、为什么会有容错？服务容错是高并发带来的问题。在微服务架构中，服务可以相互调用，但由于网络或自身相关原因，我们无法保证服务一直可用。所以当一个服务出现问题的时候，我们调用这个服务的时候，线程就会被阻塞。如果此时有大量请求涌入，就会出现多线程阻塞等待，导致服务器瘫痪。依赖，故障会向上传播，最终导致整个服务器崩溃。这就是“雪崩效应”。三、常见的容错解决方案1、设置requesttimeouttimeout超时时间，这样请求线程在等待一定时间后会判断为请求失败，释放请求线程。在某些场景下，如果线程释放的足够快，就不会因为连续创建线程导致资源耗尽而导致Service崩溃。2.限流经过测试，我们发现某个请求能够承受的最大QPS（每秒查询速率）为1000，那么我们将这个请求的QPS阈值设置为800，如果超过这个阈值，则请求返回直接到限流错误。3、舱壁模式（设置独立的线程池，空间相对隔离）。舱壁模式实际上是根据现实生活中的舱室结构设计的。一艘船要想不那么容易沉没，就需要有一定的“容错性”。但是，由于早期舰船的设计欠缺，只要有一个地方进水，水就会逐渐扩散到整个船舱。这种结构的船几乎没有“容错性”，所以更容易沉没。所以这时候有人想到了把原本连体的舱室分割成独立的舱室，舱室之间用钢板焊接在一起。这些钢板就是所谓的舱壁。采用这种设计后，即使两个舱室中的一个舱室进水，也不会影响其他舱室，船舶仍能正常行驶。在软件层面借鉴这个思路，我们可以让每个服务运行在自己独立的线程池中。线程池不会相互干扰。服务A的线程池资源耗尽不会影响服务B，此时线程池就像是舱壁的舱壁，隔离不同的服务资源，使得某个服务的失败不会影响其他服务的运行.4、断路器模式检测一定时间内的错误率和错误数，如5秒内的错误率和错误数。当达到一定的阈值时，就认为B服务调用的A服务挂了，跳闸（打开断路器），不会有那么多线程等待的堆积，然后经过10秒（称为断路器时间窗口），断路器变为半开状态，该状态仅向A再次发送一个请求。如果失败，会再次跳闸（断路器打开），默认等待10秒（断路器时间窗口，不一定是10秒，这个值可以自定义），断路器再次变为半开，并且再次向A发送请求，如果这次请求成功，则断路器完全恢复，闸门完全关闭。4.什么是哨兵？Sentinel的官方名称是：TrafficGuardsforDistributedSystems。看名字很容易猜到是用来保证服务稳定性的。对于服务稳定性保障组件，如果熟悉SpringCloud的用户，第一反应肯定是Hystrix。但遗憾的是，Netflix已经宣布停止更新Hystrix。那么，未来我们需要什么更好的选择呢？除了SpringCloud官方推荐的resilience4j，目前SpringCloudAlibaba下集成的Sentinel也是用户重点考察和选择的对象。Sentinel的功能和细节很多，很难用一篇完整的文章来介绍。本文只是让我们对Sentinel有一个整体的了解，后面会详细介绍如何将Sentinel集成到SpringCloud应用中。随着微服务的普及，服务与服务之间的稳定性变得越来越重要。Sentinel以流量为切入点，从流量控制、断路器降级、系统负载保护等多个维度保障服务的稳定性。Sentinel有以下应用场景，功能丰富：Sentinel承接了近10年阿里巴巴双十一流量大促的核心场景，如秒杀（即突发流量控制在系统容量可以承受的范围内）、消息调峰、天谷、Cluster流控、下游不可用应用的实时熔断等。完备的实时监控：Sentinel也提供了实时监控功能。在控制台可以看到应用连接的单机秒级数据，甚至可以看到500以下规模集群的聚合运行状态。-box与其他开源框架/库的集成模块，例如与SpringCloud、Dubbo和gRPC的集成。您只需要引入相应的依赖，进行简单的配置，即可快速接入Sentinel。完整的SPI扩展点：Sentinel提供了一个简单易用的完整SPI扩展接口。您可以通过实现扩展接口来快速自定义逻辑。比如自定义规则管理，动态数据源的适配等。Sentinel的主要特点：Sentinel的开源生态：5.开始吧。首先引入pom文件
