服务限流、熔断的设计与实践

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内部由本地计算统计决定是否熔断

                  服务治理平台存储降级相关的配置，以及提供上报的可视化，报警配置变更下推等