：什么是雪崩效应？
服务业 服务心 服务 服务 务n 服务 时 服务 商服务6 服务 轴 服卡 服务c 服务 身服务 服务C 服务点 业务场景，高井发调用 ①：正常情况下，微服务ABCD都是正常的 ②：随着时间推移，在某一个时间点微服务A突然挂了，此时的微服务B还在疯狂的调用微服务A，由于 A已经挂了，所以B调用A必须等待服务调用超时.
而我们知道每次B->A的时候B都会去创建线程（而 线程由是计算机的资源比如cpu内存等）.
由于是高并发场景B就会阻塞大量的线程.
那么B所在的 机器就会去创建线程，但是计算机资源是有限的，最后B的服务器就会宕机（说白了微服务B活生生 的被猪队友微服务A给拖死的） ③：由于微服务A这个猪队友活生生的把微服务B给拖死，导致微服务B也宕机了，然后也会导致微服务 CD出现类是的情况，最终我们的猪队友A成功的把微服务BCD都拖死了.
这种情况也叫做服务雪 崩.
也有一个专业术语（cascadingfailures）级联故障 二：容错三板斧 2.1)超时：超时机制你懂的，配置一下超时时间，例如1秒--每次请求在1秒内必须返回，否则到点 就把线程掐死，释放资源！
思路：一旦超时，就释放资源.
由于释放资源速度较快，应用就不会那么容易被拖死 代码演示：（针对调用方处理） 2/** 第一步：设置RestTenplate的超时时间 5@Configuration 6public class WebConfig( @Bean public RestTenplate restTenplate(){ 10 //设置restTenplate的超时时间 11 SinpleClientHttpRequestFactory requestFactory = new SimpleClientHttpRequestFactory(); 12 requestFactory.setReadTineout (1eee); 13 requestFactory. setConnectTimeout(1eee); 14 RestTenplate restTemplate = new RestTenplate(requestFactory);
15 return restTenplate; 16 17} 18/** 19第二步：进行超时异常处理 20*f 21 try( 22 ResponseEntity responseEntity- restTemplate.getFarEntity(uriorderInfo.getProduct No() ProductInfo.class); 23 productInfo -responseEntity-getBody(); 24}catch（Exception e）( 25 throu new RuntimeException("调用超时"); 26 27 2/** 29 设置全局异常处理 30*/ 31 @Contro1lerAdvice 32public classTulingExceptionHandler ( 33 34 @ExceptionHandler(value -(RuntimeException.class)) 35 @ResponseBody 36 public Object dealBizException() ( 37 OrderVo orderVo - new OrderVa(); 38 orderVo.setOrderNo(*-1"); 39 orderVo.setUserNane（“容错用户"）; 10 return orderVo; 41 42 13 2.2）舱壁隔离模式 有兴趣的可以先了解一下船舱构造-一般来说，现代的轮船都会分很多舱室，舱室之间用钢板焊 死，彼此隔离.
这样即使有某个/某些船舱进水，也不会影响其他舱室，浮力够，船不会沉.
2.2.1）代码中的舱壁隔离（线程池隔离模式）
M类使用线程池1，N类使用线程池2，彼此的线程池不同，并且为每个类分配的线程池大小，例如coreSize=10.举 个例子：M类调用B服务，N类调用C服务，如果M类和N类使用相同的线程池，那么如果B服务挂了，M类调用B服务 的接口并发又很高，你又没有任何保护措施，你的服务就很可能被M类拖死.
而如果M类有自己的线程池，N类也有 自己的线程池，如果B服务挂了，M类顶多是将自己的线程池占满，不会影响N类的线程池一于是N类依然能正常工 作， 思路：不把鸡蛋放在一个篮子里.
你有你的线程池，我有我的线程池，你的线程池满了和我没关系，你挂了也和我没 关系.
Order微服务 线程池 用积分服务 的controller 积分微服务 调用库存服务 的controller 库存服务 Order微服务 线程池-0 调用积分服务 的eontroller 线程池-1 调用积分服务 的controller 库存服务 2.3）断路器模式 现实世界的断路器大家肯定都很了解，每个人家里都会有断路器.
断路器实时监控电路的情况，如果 发现电路电流异常，就会跳闸，从而防止电路被烧毁.
软件世界的断路器可以这样理解：实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阅 值，就“跳闸”，断路器打开一一此时，请求直接返回，而不去调用原本调用的逻辑.
跳闸一段时间后（例如15秒），断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该 调的逻辑，如果成功，则断路器关闭，应用正常调用：如果调用依然不成功，断路器继续回到打开状 态，过段时间再进入半开状态尝试一-通过“跳闸”，应用可以保护自己，而且避免浪费资源；而通过半 开的设计，可实现应用的自我修复”
服务调用成功 服务调用失败 断路器关闭 服务调用失败 （低于开关闯值） （达到开关阅值） 断路器打开 服务调用失败 时间窗口结束 服务调用成功 断路器半开 三：Sentinel流量控制，容错，降级（Hystrix在Sentinel面前就是弟弟） 3.1）什么是Sentinel? A lightweight powerful flow control ponent enabling reliability and monitoring for microservices.（轻量级的流量控制、熔断降级Java库） github官网地址:github./alibaba/Sentinel wiki:qithub./alibaba/Sentinel/wiki/ 3.1.1）Sentinel的初体验 tulingvip04-ms-alibaba-sentinel-helloworld V1版本 ③：添加依赖包 con.alibaba.csp sentinel-core 1.7.1 5 ②:编写测试 controller 1@S1f4j 2 public class SentinelHelloController ( @Automired private BusiServiceImpl busiService; /** 初始化流控规则 */ @PostConstruct 10 public void init(）{ 11 12 List flowRules = new ArrayList(); 13 14 //创建流控规则对象 15 FlowRule flowRule = new FlowRule(); 16 //设置流控规则QPS 17 flowRule.setGrade (RuleConstant.FLOw_GRADE_QPS) ; 18 //设置受保护的资源 19 flowRule.setResource(*HelloSentinel°); 20 //设置受保护的资源的调值 21 flowRule.setCount(1);
22 23 flowRules.add(flowRule); 24 25 //加载配置好的规则 26 FlowRuleManager . loadRules(flowRules); 27 28 29 1** 30 频繁请求接口1ocalhost：8e8e/helloSentinelV1 31 这种做法的缺点： 32 1）业务侵入性很大，需要在你的cantrooler中写入非业务代码 3 2）配置不灵活若需要添加新的受保护资源需要手动添加init方法来添加流控规则 34 *@return 35 36 @RequestMapping(*/hellaSentinelv1") public String testHelloSentinelV1(){ 38 39 Entry entity =null; 40 //关联受保护的资源 11 try( 12 83 7/开始执行自己的业务方法 busiService doBusi(); 45 //结束执行自己的业务方法 96 }catch（BlockException e）{ 47 log.info（“testHelloSentinelv1方法被流控了"); 48 return"testHelloSentinelv1方法被流控了"; 49 }finally ( 50 if(entityl=null)( 51 entity-exit(); 3 53 54 return "oK"; 55} 56 57 测试效果：localhost:8080/helloSentinelV1 v1版本的缺陷：如下 业务侵入性很大需要在你的controoler中写入非业务代码 配置不灵活若需要添加新的受保护资源需要手动添加init方法来添加流控规则