服务治理利器Hystrix-理论篇

引言    

如今的大中型应用，不少都在朝着服务化、分布式的方向发展。这有多方面的考虑，好比说，方便治理、便于扩展、服务隔离等等。不过在带来如此多利好的同时，不可避免的也会带来麻烦，好比系统架构复杂、服务依赖关系繁杂。总体来讲，仍是利大于弊，而咱们须要思考的，就是怎么在获得这些利的同时，解决弊端。从本篇开始，将会用两到三篇来探讨这方面的心得。

 正文

    这类应用，每每会依赖几个甚至几十个服务，而服务发生故障又是不可避免的事情，即便你说本身的服务达到了四个9的高标准，那么借用网上的一个算式，若是应用A依赖了30个服务，那么出错的概率也是99.99%^30=99.70%每一年大约有24个小时是不稳定的。一亿次请求*0.3%=30w次失败。有没有细思极恐的赶脚？

 

    不少时候，咱们还不得不面临，只有一个服务延迟或者挂掉，结果整个应用都受到影响。在高QPS的场景下，很快整个服务器上的资源就会被耗尽。来个图感觉下（注：图片来自于网络）：

    服务I出问题，站在其余服务的角度看，这就是坑队友了啊。若是再有级联的依赖，简直就是噩梦。

        

    那么怎么办呢？继续提高每一个服务的可用率？固然，这是咱们永远的追求，如星辰大海通常，没有止境。但也正是所以认识到，想达到100%的可用率，几乎不可能，只要有那么点缺憾的存在，那么，一旦量级起来了，刺耳的报警短信之音仍是会在夜深人静的时候响起。

    

    既然这条路走不通，或者说只能部分走通，那么还有没有其余路呢？固然有，办法总比问题多。

 

    最经常使用的就是降级策略。所谓降级，无非就是愿意承担必定限度的成本，保证总体可用。举几个例子来讲：

 

• 牺牲一小部分流量（其实深究起来就是用户的请求），来保证服务总体不被压垮。

• 再也不强求一小部分服务的返回值，保证绝大多数服务可用。

• 固然还有缓存，牺牲数据的时效性，保证可用性。

    

    方向性的指导原则有了，不会南辕北辙了，那么剩下的就是具体实践了，正所谓工欲善其事必先利其器。本篇，将重点研究业界流行的一件神兵利器：Hystrix。

 

    Hystrix是经过什么手段来实现的服务降级呢？在小端看来，最核心的就是如下三点，其余的都是锦上添花的东西：

1. 配置线程池，来控制并发量

2. 配置超时时间，加快返回速度

3. 配置熔断器，直接拒绝请求（舍小我保你们）   

    

   下面，详细说明：

 

隔离：

        为每个服务，注意，是每个，都维护一个独立的线程池（或者信号量），当线程池满时，使用相应策略处理，好比拒绝服务，好比排队（要看配置的是哪一种线程池了）。这样，就控制了并发量。不会由于忽然而至的请求骤增，压垮服务。这样就实现了服务间相互隔离，彼此不受影响的效果。以下图（图片来自网络）：

 

命令模式：

        这个真没什么高深的，就是咱们的业务逻辑类，要继承HystrixCommand或者HystrixObservableCommand，重写他们的run()或construct()方法。在该方法里，实现对外部服务的调用。而在使用时，就像下命令同样，对业务逻辑类实例化的对象，下达“命令”（即调用提供的统一的execute、queue等方法），而不需关心内部的具体调用逻辑，便可自动执行咱们重写的run()或者construct()。

 

超时：

        设置超时时间，那么在每一个请求执行过程当中，一旦发生响应超时，便可有所动做，对的，就是转而去执行getFallBack()方法，快速返回结果，释放系统资源。固然，执行失败的，也是如此处置。

 

熔断器：

        这个词看起来高大上，知道这个词，是前几年A股里的那次事件。在这里思路其实差很少，就是我要统计一个时间窗口内，服务的成功、失败、超时等的数据，而后依据配置的策略，好比失败率达到80%时，切断服务一段时间，这时，任何请求，都拒绝服务！拒绝服务！拒绝服务！直接执行getFallBack()逻辑。比较牛的设计是，提供了自动恢复能力。能够配置一个时间阈值，在拒绝服务超过这个时长后，接受一个请求，尝试调用服务。若是成功，则服务恢复，若是失败，则继续进入熔断状态。

 下篇预告

基本原理性的东西，先写这么多，下篇继续从使用层面分析。

若是对你有帮助，能够关注个人公众号，第一时间看到更多原创内容：

搜索：小端有话说

扫码：