SA实战 ·《SpringCloud Alibaba实战》第9章(二)

发布于 2022-5-31 16:38
浏览
0收藏

 

服务雪崩
系统采用分布式或微服务的架构模式后,由于网络或者服务自身的问题,一般服务是很难做到100%高可用的。如果一个服务出现问题,就可能会导致其他的服务级联出现问题,这种故障性问题会在整个系统中不断扩散,进而导致服务不可用,甚至宕机,最终会对整个系统造成灾难性后果。

这里,小伙伴们可以对比冰河写的《一起进大厂系列》专栏中的《【高并发】面试官:讲讲什么是缓存穿透?击穿?雪崩?如何解决?》一文进行记忆。

为了最大程度的预防服务雪崩,组成整体系统的各个微服务需要支持服务容错的功能。

 

服务容错方案
服务容错在一定程度上就是尽最大努力来兼容错误情况的发生,因为在分布式和微服务环境中,不可避免的会出现一些异常情况,我们在设计分布式和微服务系统时,就要考虑到这些异常情况的发生,使得系统具备服务容错能力。

常见的服务错误方案包含:服务限流、服务隔离、服务超时、服务熔断和服务降级等。

 

服务限流
服务限流就是限制进入系统的流量,以防止进入系统的流量过大而压垮系统。其主要的作用就是保护服务节点或者集群后面的数据节点,防止瞬时流量过大使服务和数据崩溃(如前端缓存大量实效),造成不可用;还可用于平滑请求。

限流算法有两种,一种就是简单的请求总量计数,一种就是时间窗口限流(一般为1s),如令牌桶算法和漏牌桶算法就是时间窗口的限流算法。

 

服务隔离
服务隔离有点类似于系统的垂直拆分,就按照一定的规则将系统划分成多个服务模块,并且每个服务模块之间是互相独立的,不会存在强依赖的关系。如果某个拆分后的服务发生故障后,能够将故障产生的影响限制在某个具体的服务内,不会向其他服务扩散,自然也就不会对整体服务产生致命的影响。

互联网行业常用的服务隔离方式有:线程池隔离和信号量隔离。

 

服务超时
整个系统采用分布式和微服务架构后,系统被拆分成一个个小服务,就会存在服务与服务之间互相调用的现象,从而形成一个个调用链。形成调用链关系的两个服务中,主动调用其他服务接口的服务处于调用链的上游,提供接口供其他服务调用的服务处于调用链的下游。

服务超时就是在上游服务调用下游服务时,设置一个最大响应时间,如果超过这个最大响应时间下游服务还未返回结果,则断开上游服务与下游服务之间的请求连接,释放资源。

 

服务熔断
在分布式与微服务系统中,如果下游服务因为访问压力过大导致响应很慢或者一直调用失败时,上游服务为了保证系统的整体可用性,会暂时断开与下游服务的调用连接。这种方式就是熔断。

服务熔断一般情况下会有三种状态:关闭、开启和半熔断。

  • 关闭状态:服务一切正常,没有故障时,上游服务调用下游服务时,不会有任何限制。
  • 开启状态:上游服务不再调用下游服务的接口,会直接返回上游服务中预定的方法。
  • 半熔断状态:处于开启状态时,上游服务会根据一定的规则,尝试恢复对下游服务的调用。此时,上游服务会以有限的流量来调用下游服务,同时,会监控调用的成功率。如果成功率达到预期,则进入关闭状态。如果未达到预期,会重新进入开启状态。


服务降级
服务降级,说白了就是一种服务托底方案,如果服务无法完成正常的调用流程,就使用默认的托底方案来返回数据。例如,在商品详情页一般都会展示商品的介绍信息,一旦商品详情页系统出现故障无法调用时,会直接获取缓存中的商品介绍信息返回给前端页面。

 

 

文章转自公众号:冰河技术

分类
已于2022-5-31 16:38:32修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐