微服务近年来很火很热，相关的文章汗牛充栋，关于架构设计本文就不作叙述了，只谈谈在分布式服务的容错方面怎么做。
1 什么是微服务
对于微服务，我们可以简单的理解成对一个服务解耦，以降低业务系统的复杂性，将服务系统中的功能进行拆分成多个轻量的子服务，各个自服务间通过RPC实现服务间的关联，这样做的好处是将业务简单化，每个子服务可以有自己独立的编程语言，模式等且能够独立维护，独立部署，功能复用。
2 为什么需要做服务隔离与熔断
由于微服务间通过RPC来进行数据交换，所以我们可以做一个假设：在IO型服务中，假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其他的服务，继续下去会使得调用链路过长，技术上称1->N扇出。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住，堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃，又称：雪崩效应。
1->N扇形
雪崩效应
3 服务雪崩的原因
（1）某几个机器故障：例如机器的硬驱动引起的错误，或者一些特定的机器上出现一些的bug（如，内存中断或者死锁）。
（2）服务器负载发生变化：某些时候服务会因为用户行为造成请求无法及时处理从而导致雪崩，例如阿里的双十一活动，若没有提前增加机器预估流量则会造服务器压力会骤然增大二挂掉。
（3）人为因素：比如代码中的路径在某个时候出现bug
4 解决或缓解服务雪崩的方案
一般情况对于服务依赖的保护主要有3中解决方案：
（1）熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
（2）隔离模式：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。
（3）限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。
5 熔断设计
在熔断的设计主要参考了hystrix的做法。其中最重要的是三个模块：熔断请求判断算法、熔断恢复机制、熔断报警
（1）熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
（2）熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
（3）熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警
6 隔离设计
隔离的方式一般使用两种
（1）线程池隔离模式：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）
（2）信号量隔离模式：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）
7 超时机制设计
超时分两种，一种是请求的等待超时，一种是请求运行超时。
等待超时：在任务入队列时设置任务入队列时间，并判断队头的任务入队列时间是否大于超时时间，超过则丢弃任务。
运行超时：直接可使用线程池提供的get方法
8 隔离与熔断代码实现
后续会放到github上
9 性能损耗测试
由于存在计数统计和线程切换等的开销，所以对每个请求会有一定的性能损耗，测试结果表明在线程池隔离模式中，平均一个请求的损耗在0.5ms以内。
测试方法：顺序请求，记录业务运行时间和隔离器运行业务的时间，请求数量500次。
变量解释：
单个请求耗时：为业务的运行时间（使用Thread.sleep()模拟）;
隔离消耗=请求总用时-业务用时;
隔离评价消耗=隔离消耗/请求次数/
测试时间统计（单位ms）：
|
单个请求耗时 |
请求总用时 |
业务用时 |
隔离消耗 |
隔离平均消耗 |
|
1 |
586 |
510 |
76 |
0.152 |
|
5 |
2637 |
2514 |
124 |
0.248 |
|
10 |
5248 |
5136 |
112 |
0.024 |
|
50 |
25261 |
25111 |
150 |
0.3 |
|
100 |
50265 |
50130 |
135 |
0.27 |
|
200 |
100657 |
100284 |
373 |
0.746 |
10 参考
在设计和实现的过程中参考了一些现有的设计和一些文章：
1、Hystrix官方文档：https://github.com/Netflix/Hystrix/wiki
2、Hystrix使用与分析：http://hot66hot.iteye.com/blog/2155036
3、Facebook文章：http://queue.acm.org/detail.cfm?id=2839461
4、Facebook文章：http://queue.acm.org/detail.cfm?id=2209336
4、分布式服务容错模式和实践：http://www.atatech.org/articles/31559