背景

一般在微服架构中，我们的独立服务是比较多的，每个独立服务之间划分责任边界，并通过约定协议接口来进行通信。当我们的调用链路复杂依赖多时，很可能会发生雪崩效应。为了保证服务高可用，我们都会使用熔断、降级等措施。

线上问题分析

查看了错误日志后分析可能的原因：

• 服务调用超时导致熔断
• Hystrix线程池/信号量满了导致熔断

验证

首先在熔断方法里加上异常栈的打印

查看异常栈打印信息

好家伙 根据异常信息可知应该是线程池满了，默认线程池执行线程大小才10个

解决方案

查看查Hystrix文档

默认采用的是THREAD方式，而对于用户信息查询RPC接口，虽有缓存但显然QPS很高

果断改成SEMAPHORE方式，再去Redis监控台查下这个服务当前的QPS数据

由于此接口是用户的RPC接口 调用会有几分钟的cache 所以读QPS并不高 设置一个合理并发值

过了12小时后查看错误日志，未发现有熔断异常出现，至此问题解决

总结

1. 针对新引入的中间件/组件需要细看API文档
2. 熔断接口也需要打印异常栈信息
3. 并发、性能测试不能少