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