1.限流、熔断的目的
微服务化之后,系统分布式部署,系统之间通过RPC框架通信,整个系统发生故障的概率随着系统规模的增长而增长。一个小的故障经过链路传导放大,有可能造成更大的故障。
业务方希望在调用服务时,在一些非关键路径服务发生服务质量下降的情况下,选择尽可能地屏蔽所造成的影响。
2.业务限流、熔断需求
2.1.大部分熔断返回默认值(null)也可定制,RPC client原生支持最好,业务方少改代码。
2.2.进入熔断时,打印熔断日志,同时能够返回Exception(业务方定制了熔断方法)
2.3.服务治理平台可以看到服务的状态,是否降级,是否熔断,可以实时下发阀值 配置。
2.4.可以报警,最好加上异常信息
2.5.调用方粒度的确定,接口粒度
3.服务管理平台本质
服务可视化治理: RPC客户端 -》 RPC服务端 这里的客户端与服务端都需要上报信息给服务管理平台
熔断主要是放在RPC客户端实施,熔断配置放在服务管理平台,
4.限流、熔断业界方案
4.1.Netflix OSS Hystrix
缺点:1)、手动写Hystrix command,或者是由maven插件生成command,在fall back method里面返回NULL
2)、业务侵入大: 每个方法都要加注解
3)、引入jar包:额外引入Hystrix Jar包,我们希望是直接放入RPC框架内
4)、非平台 化, 客户端直接引用当熔断配置改变需要重启代价,我们希望将配置做到服务治理平台中而不是一个jar 包。
4.2.优雅的设计方案
1)、平台化思路实践
2)、RPC Client、服务治理平台,
基于RPC Client实现熔断,RPC Client修改创建的proxy,在proxy内部由本地计算统计决定是否熔断
服务治理平台存储降级相关的配置,以及提供上报的可视化,报警配置变更下推等