引言
现在的大中型应用，很多都在朝着服务化、分布式的方向发展。这有多方面的考虑，比如说，方便治理、便于扩展、服务隔离等等。不过在带来如此多利好的同时，不可避免的也会带来麻烦，比如系统架构复杂、服务依赖关系繁杂。整体来说，还是利大于弊，而我们需要思考的，就是怎么在得到这些利的同时，解决弊端。从本篇开始，将会用两到三篇来探讨这方面的心得。
正文
这类应用，往往会依赖几个甚至几十个服务，而服务发生故障又是不可避免的事情，即使你说自己的服务达到了四个9的高标准，那么借用网上的一个算式，如果应用A依赖了30个服务，那么出错的几率也是99.99%^30=99.70%每年大约有24个小时是不稳定的。一亿次请求*0.3%=30w次失败。有没有细思极恐的赶脚？
很多时候，我们还不得不面临，只有一个服务延迟或者挂掉，结果整个应用都受到影响。在高QPS的场景下，很快整个服务器上的资源就会被耗尽。来个图感受下（注：图片来自于网络）：
服务I出问题，站在其他服务的角度看，这就是坑队友了啊。如果再有级联的依赖，简直就是噩梦。
那么怎么办呢？继续提升每个服务的可用率？当然，这是我们永远的追求，如星辰大海一般，没有止境。但也正是因此认识到，想达到100%的可用率，几乎不可能，只要有那么点缺憾的存在，那么，一旦量级起来了，刺耳的报警短信之音还是会在夜深人静的时候响起。
既然这条路走不通，或者说只能部分走通，那么还有没有其他路呢？当然有，办法总比问题多。
最常用的就是降级策略。所谓降级，无非就是愿意承担一定限度的成本，保证整体可用。举几个例子来说：
牺牲一小部分流量（其实深究起来就是用户的请求），来保证服务整体不被压垮。
不再强求一小部分服务的返回值，保证绝大多数服务可用。
当然还有缓存，牺牲数据的时效性，保证可用性。
方向性的指导原则有了，不会南辕北辙了，那么剩下的就是具体实践了，正所谓工欲善其事必先利其器。本篇，将重点研究业界流行的一件神兵利器：Hystrix。
Hystrix是通过什么手段来实现的服务降级呢？在小端看来，最核心的就是以下三点，其他的都是锦上添花的东西：
配置线程池，来控制并发量
配置超时时间，加快返回速度
配置熔断器，直接拒绝请求（舍小我保大家）
下面，详细说明：
隔离：
为每一个服务，注意，是每一个，都维护一个独立的线程池（或者信号量），当线程池满时，使用相应策略处理，比如拒绝服务，比如排队（要看配置的是哪种线程池了）。这样，就控制了并发量。不会因为突然而至的请求骤增，压垮服务。这样就实现了服务间相互隔离，彼此不受影响的效果。如下图（图片来自网络）：
命令模式：
这个真没什么高深的，就是我们的业务逻辑类，要继承HystrixCommand或者HystrixObservableCommand，重写他们的run()或construct()方法。在该方法里，实现对外部服务的调用。而在使用时，就像下命令一样，对业务逻辑类实例化的对象，下达“命令”（即调用提供的统一的execute、queue等方法），而不需关心内部的具体调用逻辑，即可自动执行我们重写的run()或者construct()。
超时：
设置超时时间，那么在每个请求执行过程中，一旦发生响应超时，即可有所动作，对的，就是转而去执行getFallBack()方法，快速返回结果，释放系统资源。当然，执行失败的，也是如此处置。
熔断器：
这个词看起来高大上，知道这个词，是前几年A股里的那次事件。在这里思路其实差不多，就是我要统计一个时间窗口内，服务的成功、失败、超时等的数据，然后依据配置的策略，比如失败率达到80%时，切断服务一段时间，这时，任何请求，都拒绝服务！拒绝服务！拒绝服务！直接执行getFallBack()逻辑。比较牛的设计是，提供了自动恢复能力。可以配置一个时间阈值，在拒绝服务超过这个时长后，接受一个请求，尝试调用服务。如果成功，则服务恢复，如果失败，则继续进入熔断状态。
下篇预告
基本原理性的东西，先写这么多，下篇继续从使用层面分析。
如果对你有帮助，可以关注我的公众号，第一时间看到更多原创内容：
搜索：小端有话说
扫码：
