服务容错与保护方案 — Hystrix.docxVIP

服务容错与爱护方案 — Hystrix 在通过第三方客户端访问（通常是通过网络）依靠服务消灭高延迟或者失败时，为系统供应爱护和把握 在分布式系统中防止级联失败 快速失败（Fail fast）同时能快速恢复 供应失败回退（Fallback）和优雅的服务降级机制 供应近实时的监控、报警和运维把握手段 2、Hystrix设计准绳 防止单个依靠耗尽容器（例如 Tomcat）内全部用户线程 降低系统负载，对无法准时处理的恳求快速失败（fail fast）而不是排队 供应失败回退，以在必要时让失效对用户透亮?????化 使用隔离机制（例如『舱壁』/『泳道』模式，熔断器模式等）降低依靠服务对整个系统的影响 针对系统服务的度量、监控和报警，供应优化以满足近实时性的要求 在 Hystrix 绝大部分需要动态调整配置并快速部署到全部应用方面，供应优化以满足快速恢复的要求 能爱护应用不受依靠服务的整个执行过程中失败的影响，而不只仅是网络恳求 3、Hystrix如何实现这些目标 Hystrix 通过如下几个方式实现了设计目标: 3.1、命令模式 将全部恳求外部系统（或者叫依靠服务）的规律封装到 HystrixCommand 或者 HystrixObservableCommand 对象中 Run()方法为实现业务规律，这些规律将会在独立的线程中被执行当恳求依靠服务时消灭拒绝服务、超时或者短路（多个依靠服务挨次恳求，前面的依靠服务恳求失败，则后面的恳求不会发出）时，执行该依靠服务的失败回退规律(Fallback) 3.2、隔离策略 Hystrix 为每个依靠项维护一个小线程池（或信号量）;假如它们达到设定值（触发隔离），则发往该依靠项的恳求将马上被拒绝，执行失败回退规律（Fallback），而不是排队。 隔离策略分线程隔离和信号隔离。 线程隔离 第三方客户端（执行Hystrix的run()方法）会在单独的线程执行，会与调用的该任务的线程进行隔离，以此来防止调用者调用依靠所消耗的时间过长而堵塞调用者的线程。 使用线程隔离的好处： 应用程序可以不受失控的第三方客户端的威逼，假如第三方客户端消灭问题，可以通过降级来隔离依靠。 当失败的客户端服务恢复时，线程池将会被清除，应用程序也会恢复，而不至于使整个Tomcat容器消灭毛病。 假如一个客户端库的配置错误，线程池可以很快的感知这一错误（通过添加错误比例，延迟，超时，拒绝等），并可以在不影响应用程序的功能情况下来处理这些问题（可以通过动态配置来进行实时的转变）。 假如一个客户端服务的功能变差，可以通过转变线程池的目标（错误、延迟、超时、拒绝）来进行属性的调整，并且这些调整可以不影响其他的客户端恳求。 简而言之，由线程供的隔离功能可以使客户端和应用程序优雅的处理各种变化，而不会形成中缀。 线程池的缺点 线程最次要的缺点就是添加了CPU的计算开销，每个command都会在单独的线程上执行，这样的执行方式会涉及到命令的排队、调度和上下文切换。 Netflix在设计这个系统时，打算接受这个开销的代价，来换取它所供应的好处，并且认为这个开销是足够小的，不会有严重的成本或者是功能影响。 信号隔离 信号隔离是通过限制依靠服务的并发恳求数，来把握隔离开关。信号隔离方式下，业务恳求线程和执行依靠服务的线程是同一个线程（例如Tomcat容器线程）。 线程池隔离与信号量隔离对比 对比项 线程池隔离 信号量隔离 线程池 与调用线程非相同线程 与调用线程相同（jetty线程） 开销 排队、调度、上下文开销等 无线程切换，开销低 异步 支持 不支持 并发 支持（最大线程池大小） 支持（最大信号量上限） 应用场景 第三方应用或者接口、并发量大 内部应用或者两头件、并发需求不大 留意：假如不涉及近程RPC调用（没有网络开销）则使用信号量来隔离，更为轻量，开销更小。假如是缓存调用，响应快，不会占用容器线程太长时间，也可以使用信号量来隔离 3.3、观看者模式 Hystrix通过观看者模式对服务进行形态监听 每个任务都包含有一个对应的Metrics，全部Metrics都由一个ConcurrentHashMap来进行维护，Key是CommandKey.name() 在任务的不同阶段会往Metrics中写入不同的信息，Metrics会对统计到的历史信息进行统计汇总，供熔断器以及Dashboard监控时使用 Metrics Metrics内部又包含了很多内部用来管理各种形态的类，全部的形态都是由这些类管理的 各种形态的内部也是用ConcurrentHashMap来进行维护的 Metrics在统计各种形态时，时运用滑动窗口思想进行统计的，在一个滑动窗口时间中又划分了若干个Bucket（滑动窗口时间与Bucket成整数倍关系），滑动窗口的移动是以Bucke