（1）现象：在某段时间内无法请求到微服务A，连接服务超时，20分钟左右服务又恢复可用
（2）服务请求链路：客户端——nginx——微服务网关——微服务A
排查过程：查看故障时间段经过nginx和微服务网关对微服务A的请求，在微服务A中没有请求日志，也就是说故障时间段请求并没有到达微服务。
（3）故障原因分析：这种现象的原因一般有两种可能，一种是是微服务处理请求时间超过服务熔断时间，导致服务被熔断，在熔断时间内微服务是不可用的。另外一种，微服处理请求时间超过服务的负载均衡配置的请求读取超时时间，然后请求被负载到微服务其它节点，结果还是请求处理超过请求读取超时时间，负载均衡机制会A服务的其它节点求挨个负载一遍，若处理时间都超过请求读取超时时间。那么，网关会告诉客户端服务不可用。查看故障时间段前的微服务A的系统日志发现有需要长时间处理的可疑请求。例如，下载请求，或者请求接口本身就存在严重的性能问题处理的慢。所以，这种业务处理场景一旦发生，若超过服务熔断时间或服务负载均衡配置的请求读取超时时间，那么微服务将启动保护机制，修改服务的健康状态为不可用，使得所有对此微服务发起的请求都无法到达，以此来保护服务。这个保护时间不是永久的，是短时间的，20分钟左右，也可通过配置修改。
（4）优化方案：1.修改服务熔断时间与负载均衡请求读取超时时间，使其大于最长的请求处理时间，配置公式为：最长的请求处理时间<服务熔断时间<负载均衡请求读取超时时间（负载均衡请求读取超时时间=负载混很请求连接超时时间）
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds #服务熔断时间
ribbon.ReadTimeout #负载均衡服务请求读取超时时间
ribbon.ConnectTimeout #负载均衡服务连接超时时间
2、将耗时长、慢的接口处理时间优化到合理的处理时间范围内
3、将耗时长、慢的接口移植到单独的微服务中来来避免这类接口的可用性而影响同服务中其它接口的可用性
如果有足够的故障修复时间，采用优化方案中的1、2、3点进行系统优化是最彻底解决故障的方法。