微服务，多服务之间频繁调用导致系统接口超时，怎么优化？

微服务，多服务之间频繁调用导致系统接口超时，怎么优化？-有了

先分析原因，是调用频率不正常，还是接口能力不行？如果业务上就是要求 tpsqps 必须达到 xxx 量，那没什么好说的，提升接口的处理能力！如果没有必要同步调用，那就走消息服务！

我们可以从两方面考虑，一方面是解决超时或者是尽量避免超时，二是超时后的解决方案。所以从这两方面出发，有以下解决方案。

一.避免超时解决方案:
提升接口响应速度的方案
1.优化代码运行效率，是否可用异步，线程等考虑
2.优化 sql，减少关联，索引命中等
3.根据业务看是否可以 cache
削峰的方案
1.看业务场景是否可以使用消息队列慢慢消费
2.可先把数据存下来直接返回，然后慢慢定时任务批量消费
3.以上两种方案可无限方式扩展，异步线程等都能替代，但是这些方式都不能同步返回处理结果，需要异步回调上游

二.超时之后的解决方案
消息队列的形式不需要调用接口所以不存在超时的情况，如果接口调用的形式做了各种优化方案还是超时了，那有以下几种方案
1.上游收到响应超时或者连接超时错误时可尝试再次调用，下游需要做好重复调用的准备做好幂等
2.如果重复调用次数达到阈值要减少调用次数，减少调用频率，防止系统奔溃，记录调用失败的数据尝试等待系统回复正常再次调用或者人工处理数据
3.下游提供查询接口供上游提供查询功能，很多时候下游可能已经处理好数据，只是来不及响应故而返回错误。提供查询接口给上游确认数据是否真的处理成功
4.很多框架有容错，熔断，服务降级等机制，可以做自定义容错处理，扩展性也很好，也很好的解决系统频繁调用奔溃的问题

还有一个比较好用的方案就是设置响应超时和连接超时时间。但是这不能从根本上解决问题，尤其是并发大的时候，会导致服务雪崩。

以上是我工作中遇到超时情况可行的解决方案，仅供参考！