Hystrix 实战经验分享

一、背景 Hystrix是Netlifx开源的一款容错框架，防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控(Hystrix Dashboard)等功能。 尽管说Hystrix官方已不再维护，且有Alibaba Sentinel等新框架选择，但从组件成熟度和应用案例等方面看，其实还是有很多项目在继续使用Hystrix中，本人所参与的项目就是其一。故结合个人的Hystrix实战经验与大家分享交流。 二、经验总结 2.1 隔离策略的选择 Hystrix提供两种资源隔离策略，线程池和信号量。它们之间的异同点如下： 而在使用缓存(本地内存缓存更适合该场景，Redis等网络缓存需要评估)时，我们可以使用信号量隔离策略，因为这类服务响应快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了服务效率。 具体使用哪种策略，需根据业务场景综合评估。一般情况下，推荐使用线程池隔离。 2.2 线程池大小与超时时间设置 在线程池隔离策略下，线程池大小及超时时间的设置至关重要，直接影响着系统服务的响应能力。如线程池大小若设置的太大会造成资源浪费及线程切换等开销；若设置的太小又支撑不了用户请求，造成请求排队。而超时时间设置的太长会出现部分长耗时请求阻塞线程，造成其它正常请求排队等待；若设置的太短又会造成太多正常请求被熔断。 对此Hystrix官方给的建议如图： 即转换为以下计算公式： 线程池大小 = 服务TP99响应时长（单位秒） * 每秒请求量 + 冗余缓冲值 超时时间（单位毫秒） = 1000（毫秒） / 每秒请求量 例如某服务TP99情况下每秒钟会接收30个请求，然后每个请求的响应时长是200ms，按如上公式计算可得：线程池大小 = 0.2 * 30 + 4（冗余缓冲值）= 10，超时时间 = 300ms 2.3 注解叠加 在实际开发中可能会遇到某外部调用方法有Hystrix注解与其它注解一起使用的情况，例如查询方法加上缓存注解。此时需特别注意注解间的执行顺序，避免出现非预期的结果： 缓存注解未生效 此时Hystrix注解切面的执行是在最外层，由于Hystrix内部执行是通过ProceedingJoinPoint.getTarget()获取目标对象，使用反射调用的方式直接执行到目标对象方法上，从而造成中间其它注解逻辑丢失。可通过指定注解执行顺序@Order解决保证Hystrix注解执行在最里层。 因缓存异常造成该查询方法被熔断 如果Hystrix注解切面的执行是在最外层，此时Hystrix熔断管理的方法逻辑除了第三方服务远程调用，也包括了缓存调用逻辑。如果缓存调用出现异常就会算作整个方法异常，从而引起整个方法被熔断。 2.4 服务的异常处理 先给大家时间看如下代码，检查是否存在问题： @HystrixCommand(fallbackMethod="queryUserByIdFallback") public User queryUserById(String userId) { if(StringUtils.isEmpty(userId)) { throw new BizException("参数不合法"); } Result