微服务，多服务之间频繁调用导致系统接口超时，怎么优化？
回答·41
最热
最新
- 1.频繁调用从接口设计上解决，尽量提高 RPC 接口的响应速度，亦或加 cache 减少频繁调用 2.增加熔断降级限流等措施，保证服务高可用，防止服务雪崩 3.使用异步方式例如 MQ 进行削峰 4. 加机器，加配置 5.如果以上都不能解决，删库跑路吧。
- 这是啥问题？时间上的问题无非时间与空间转换、要不缩短调用链路、要么延长响应时间呗
- 都已经知道频繁调用导致的超时，基本是服务被做烂了，优化分几个步骤: 1.从性能上优化，检查调用次数是否可以通过封装处理减少，还有接口的代码性能是否可以优化 2.从服务结构优化，有些是业务结构拆分问题导致的业务复杂度引起的频繁调用，需要优化业务机构 3.从微服务框架上优化，这时候主要就是微服务框架选型，以及实现解决方案需要优化，比如异步解耦等问题等，解决高并发问题
- 先分析原因，是调用频率不正常，还是接口能力不行？如果业务上就是要求 tps qps 必须达到 xxx 量，那没什么好说的，提升接口的处理能力！如果没有必要同步调用，那就走消息服务！
- 意思应该是请求链路太长，导致超时吧？ 1.首先考虑是否是中间层太多，是否可以将没有用的中间层去掉？直接调用真实服务。或者并行的调用几个没有依赖关系的服务 2.如果每层都有业务处理，那可以考虑改变接口调用方式，从同步改成异步回调，可以参考支付宝付款回调 3.督促各个业务方进行接口优化（比较慢） 4.根据实际工作情况，链路太长导致的超时几乎不存在，我遇到的两种情况是: 数据量太大&数据处理耗时太多 对于第一种，考虑分布式的存储数据，一个大数据拆成多个小数据块，并行获取&存储 对于第二种，对各部分处理耗时进行统计分析，按照从小到大的顺序依次优化 暂时能想到这些了。 暂时能想到这些
- 调用接口内需要优化 加大调用时间
- 通过 freemarker 进行页面静态化，降低服务器数据库访问压力
- 看是什么原因导致的超时嘛，逻辑处理不够好就代码优化，sql 查询太慢，那就 sql 优化
- 比较直观的做法是增加超时时间限制，但是不建议。拆分微服务的宗旨是服务的职责专一化，功能细化，这样就要求微服务的业务接口响应速度要够快，只要够快，即使大量请求过来也不会有很高的并发。所以，专业的做法是首先考虑微服务业务的优化 ，监控接口慢在哪里，调整业务算法和 SQL 调优，考虑优化缓存，将接口响应时间降下来。做到这个前提后，争对大量请求，考虑水平扩展更多的微服务节点，采取相应的算法路由将请求打到不同节点。
- 做负载，做集群，对于非紧急事务丢进消息队列里调用，做对于超时做熔断降级
相似问题
推荐关注
正在加载中...