服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和C又调用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统的崩溃，这就是所谓的“雪崩效应”。
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟达到饱和。甚至更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源的紧张，导致整个系统发生更多的级联故障。这些否表示需要对故障和延迟进行隔离管理，以便使单个依赖的失败，不能取消整个应用的系统。
服务降级
例如服务器忙，请稍后再试，不让客户端等待，直接返回一个友好提示，fallback。
哪些情况下会出现服务降级？
程序运行异常
超时
服务熔断触发服务降级
线程池/信号量打满也会导致服务降级
当我们的服务器压力剧增，为了保证核心功能的可用性，选择降低一些功能的可用性，或者直接关闭其他不必要的功能。
一般而言会独立建立降级系统，可以灵活的配置服务器的降级功能。当然也有用代码自动降级，例如接口超时降级，失败多次重试降级。
服务熔断
熔断一般是指依赖的外部接口出现了故障，需要断绝和外部接口的关系。
例如A服务调用B服务，B服务调用C服务,C因为某种原因突然变得不可用或者响应很慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
熔断机制：熔断机制是应对服务雪崩效应的一种微服务链路保护机制。当删除链路的某个微服务出错不可用时或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的相应信息。
当检测到该节点微服务调用恢复正常时，又会自动恢复调用链路。（这就是他的nb之处）
在SpringCloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务之间调用的关系，当失败的次数达到设置的阈值，默认是5秒内20次失败，就会开启熔断机制。熔断机制的注解还是@HystrixCommand。
服务限流
例如在高并发的情况下，秒杀场景，严禁一窝蜂请求全部过来，需要排队。
一般限制的指标有：请求总量或某段时间内请求总量。
超时服务器变慢如何解决？
超时不再等待。
宕机或者程序运行出错：有默认的处理方式
服务提供者超时了，调用者不能一直卡死等待，必须有服务降级；
服务提供方宕机了，调用者不能一直卡死，也必须有服务降级。
对方服务帧长，调用者这时有故障，可以设置自己的等待时间小于服务提供者。
评论