远方的灯塔 - 专注于服务端技术分享 远方的灯塔 - 专注于服务端技术分享
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)

Terwer Green

一个后端老菜鸟
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)
  • JavaSE

  • 开源框架

  • Linux

  • Struts2

  • Hibernate

  • Webservice

  • 分布式

    • RPC架构设计及IO模型
    • NIO编程及其三大核心原理
    • NIO三大核心之缓冲区(Buffer)
    • NIO三大核心之通道(Channel)
    • NIO三大核心之选择器(Selector)
    • Netty核心原理
    • 线程模型以及传统IO阻塞模型
    • Reactor模型
    • Netty线程模型
    • Netty核心API介绍
    • Netty入门与异步模型
    • Netty高级进阶之Netty编解码器
    • Netty高级进阶之基于Netty的群聊天室案例
    • Netty高级进阶之基于Netty的HTTP服务器开发
    • Netty高级进阶之基于Netty的Websocket开发网页聊天室
    • Netty高级进阶之Netty中的粘包和拆包的解决方案
    • Nety源码剖析
    • 自定义RPC框架之分布式架构网络通信理论
    • 自定义RPC框架之基于Netty实现RPC框架
    • 分布式架构理论
    • 分布式理论之数据一致性
    • 分布式理论之CAP定理
    • 分布式理论之BASE定理
    • 分布式一致性协议之两阶段提交协议(2PC)
    • 分布式一致性协议之三阶段提交协议(3PC)
    • 分布式一致性协议之NWR协议
    • 分布式一致性协议之Gossip协议
    • 分布式一致性协议之Paxos协议
    • 分布式一致性协议之Raft协议
    • 分布式一致性协议之Lease机制
    • 分布式系统设计策略之心跳检测
    • 分布式系统设计策略之高可用
    • 分布式系统设计策略之容错性
    • 分布式系统设计策略之负载均衡
    • 分布式架构服务调用
    • 分布式服务治理之服务协调
    • 分布式服务治理之服务削峰
    • 分布式服务治理之服务降级
    • 分布式服务治理之服务限流
    • 分布式服务治理之服务熔断
      • 分布式服务治理之服务链路追踪
      • 架构设计基本原则之开闭原则(OCP)
      • 架构设计基本原则之单一职责原则(SRP)
      • 架构设计基本原则之接口隔离原则(ISP)
      • 架构设计基本原则之里式替换原则(LSP)
      • 架构设计基本原则之依赖倒置原则(DIP)
      • 架构设计基本原则知识扩展
      • 分布式架构知识拓展与总结
    • 分布式框架

    • 后端开发
    • 分布式
    terwer
    2022-05-04
    目录

    分布式服务治理之服务熔断

    # 服务熔断

    # 什么是服务熔断

    牺牲局部,保存整体的措施叫做熔断。

    不采取熔断的后果,例子:

    image-20220412134933476

    一旦下游服务C变的不可用,积压了大量请求,服务B的请求也会随之阻塞。

    线程资源逐渐耗尽,使得服务B也变的不可用。紧接着,服务A也会变得不可用,整个服务链路被拖垮。

    image-20220412135224506

    这种调用链路的连锁故障,叫做雪崩。

    # 熔断机制

    可以采用熔断机制来解决上面的问题。

    image-20220412135744686

    需要注意两点:

    1. 开启熔断

    在固定时间窗口内,接口调用超时比例达到一个阈值,会开启熔断。

    进入熔断状态后,后续对该服务的调用,不再经过网络,而是调用本地的默认方法,达到服务降级的效果。

    1. 熔断恢复

    熔断不是永久的,经过了熔断超时时间之后,服务将从熔断状态恢复,再次接受调用方的远程调用。

    # 熔断机制的实现
    1. Spring Cloud Hystrix

    Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现的,该框架实现了服务熔断、线程隔离等一系列服务保护功能。

    对熔断机制的实现,Hystrix设计了三种状态: - 熔断关闭状态(Closed)

      服务没有故障时,熔断器所处的状态,对调用方的调用不作任何限制。
    - 熔断开启状态(Open)
      
      在固定时间内,Hystrix默认是10s,接口调用出错比例达到一个阈值,Hystrix默认是50%,就会进入熔断状态。
      
      进入熔断状态后,后续对该服务接口的调用,不再经过网络,而是调用本地的fallback方法。
    - 半熔断状态(Half-Open)
      
      在进入熔断开启状态一段时间后,Hystrix默认是5s,容器会进入半熔断状态。
      
      半熔断状态尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,说明服务已经恢复,提前进入熔断关闭状态。如果成功率依然很低,则重新进入熔断开启状态。
      
         三个状态的转化关系如下:
      
         ![image-20220412143208192](https://img1.terwer.space/image-20220412143208192.png)
      
      2. Sentinel
      
         [https://github.com/alibaba/Sentinel](https://github.com/alibaba/Sentinel)
      
         Sentinel和Hystrix的原则是一致的:当调用链路中,某个资源出现不稳定,例如,表现为timeout,异常比例升高的时候,则对这个资源的的调用进行限制,并让请求快速失败,避免影响到其他资源,导致最终产生雪崩。
      
         Sentinel的熔断手段:
    - 通过并发线程数进行限制
    - 通过响应时间对资源进行降级
    - 系统负载保护
    编辑 (opens new window)
    #rpc#service#fusing
    上次更新: 2023/02/22, 13:47:25
    分布式服务治理之服务限流
    分布式服务治理之服务链路追踪

    ← 分布式服务治理之服务限流 分布式服务治理之服务链路追踪→

    最近更新
    01
    解决css部分border被圆角切掉之后圆角的边框消失问题
    03-18
    02
    使用TypeScript开发一个自定义的Node-js前端开发脚手架
    03-08
    03
    Github-Actions使用release-please实现自动发版
    03-06
    更多文章>
    Theme by Vdoing | Copyright © 2011-2023 Terwer Green | MIT License | 粤ICP备2022020721号-1 | 百度统计
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式