忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 七 ) 【51CTO.com原创稿件】面试的时候

完美，下单的流程开发完毕了，可以让 QA 接入。 ^?_?^
等等，微服务的保护措施做了吗?
熔断限流隔离降级
微服务分布式依赖关系错综复杂，比方说前端的一个请求，这来到后端会被转为为很多个请求。
这个时候后台的服务出现不稳定或者延迟，如果没有好的限流熔断措施，可能会造成用户体验的下降，严重的时候会出现雪崩效应，把整个网站给搞垮。
如果像阿里巴巴在双 11 等活动中，如果没有一套好的限流熔断措施，这是不可想象的，可能是根本无法支撑那么大的并发容量。
Netflix 在 2012 年前也没有设计好的限流容错，当时也是饱受着系统稳定性的困扰，好几次网站因为没有好的熔断措施把网站搞垮。
在 2012 年 Netflix 启动了弹性工程项目，其中有一个产品叫 Hystrix ，这个产品主要用来解决微服务的可靠性。
有了这个系统之后， Netflix 在系统稳定性上上了一个大的台阶，在此之后就没有出现过大规模的雪崩事故。
下面使用 Hystrix 例子来讲解一下限流熔断。
几个概念：熔断，隔离，限流，降级，这几个概念是分布式容错最重要的概念和模式。
①熔断：如果说房子里面安装了电路熔断器，当你使用超大功率的电路时，有熔断设备帮你保护不至于出问题的时候把问题扩大化。
②隔离：我们知道计算资源都是有限的， CPU ，内存，队列，线程池都是资源。
他们都是限定的资源数，如果不进行隔离，一个服务的调用可能要消耗很多的线程资源，把其他服务的资源都给占用了，那么可能出现因为一个服务的问题连带效应造成其他服务不能进行访问。
③限流：让大流量的访问冲进去我们的服务时，我们需要一定的限流措施，比方说我们规则一定时间内只允许一定的访问数从我们的资源过，如果再大的话系统会出现问题，那么就需要限流保护。
④降级：如果说系统后台无法提供足够的支撑能力，那么需要一个降级能力，保护系统不会被进一步恶化，而且可以对用户提供比较友好的柔性方案，例如告知用户暂时无法访问，请在一段时候后重试等等。
Hystrix
Hystrix 就把上面说的熔断，隔离，限流，降级封装在这么一个组件里面，下图是 Hystrix 内部设计和调用流程：
大致的工作流如下：

构建一个 HystrixCommand 对象，用于封装请求，并在构造方法配置请求被执行需要的参数。
执行命令， Hystrix 提供了几种执行命令的方法，比较常用到的是 Synchrous 和 Asynchrous 。
判断电路是否被打开，如果被打开，直接进入 Fallback 方法。
判断线程池/队列/信号量是否已经满，如果满了，直接进入 Fallback 方法。
执行 Run 方法，一般是 HystrixCommand.run() ，进入实际的业务调用，执行超时或者执行失败抛出未提前预计的异常时，直接进入 Fallback 方法。
无论中间走到哪一步都会进行上报 Metrics ，统计出熔断器的监控指标。
Fallback 方法也分实现和备用的环节。
最后是返回请求响应。

完美，把 Hystrix 加入我们系统吧，这样突然有洪峰流量也不至于我们的系统一下就冲垮。 ^?_?^