限流/熔断的目的
- 微服务化之后，系统分布式部署，系统之间通过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
