谈谈服务限流和熔断的设计与实现

限流/熔断的目的

• 微服务化之后，系统分布式部署，系统之间通过rpc框架通信，整个系统发生故障的概率随着系统规模的增长而增长，一个小的故障经过链路传导放大，有可能造成更大的故障。
• 业务方系统在调用服务时，在一些非关键路径服务发生服务质量下降的情况下，选择尽肯恩恶搞屏蔽所造成的影响。

业务限流和熔断需求

• 大部分熔断返回默认值(null),也可定制，RPC client原生支持最好，业务方少改代码。
• 进入熔断时，打印熔断日志，同时能够返回Exception（业务方定制了熔断方法）
• 服务治理平台可以看到服务的状态，是否降级，是否熔断，可以实时下发阙值配置，可以报警，最好加上异常信息
• 调用方粒度的确定，接口粒度。

image

服务治理平台可以对服务的一些配置包括限流，降级，阙值等等进行管理。

image

业界方案

• Netflex OSS Hystrix(这个观法宣布不再更新了)

  • 手动写 Hystrix command 或者有maven插件生成command，在fall back method里面返回null。
  • 业务侵入性大。
  • 加入jar包
    • 额外引入Hystrix jar包
    • 放入rpc框架内
  • 非平台化
    • 客户端直接引用、重启代价
    • 需要做成服务治理平台(而不是jar包，不然调用方还需要关注jar包版本)

• 优雅的方案

  • RPC Client(实现在这里) + 服务治理平台(具体策略配置所在，实现控制一些函数的熔断，如下图)

    • 基于RPC Client 实现熔断
    • RPC Client 修改创建的proxy，在prxy内部由本地计算统计决定是否熔断
    • 服务治理平台存储降级相关的配置，以及提供上报数据的可视化，报警，配置变更下推等

image

有图有选项:
是否开启熔断机制
是否强制开启熔断
是否强制关闭熔断
滑动窗口时间

交互流程

image
image

自定义fallback

• 约定fallback的类名

  • 通过注解的形式

• 约定方法上加了

  fallbackCommand注解才能生效（没加注解的方法不是fallback method）

实现

image

Hystrix方案参考

image