从 0 开始学微服务
胡忠想
微博技术专家
63927 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
开篇词 (1讲)
结束语 (1讲)
从 0 开始学微服务
15
15
1.0x
00:00/00:00
登录|注册

21 | 服务调用失败时有哪些处理手段?

通过前面的学习你应该可以理解,微服务相比于单体应用最大的不同之处在于,服务的调用从同一台机器内部的本地调用变成了不同机器之间的远程方法调用,但是这个过程也引入了两个不确定的因素。
一个是调用的执行是在服务提供者一端,即使服务消费者本身是正常的,服务提供者也可能由于诸如 CPU、网络 I/O、磁盘、内存、网卡等硬件原因导致调用失败,还有可能由于本身程序执行问题比如 GC 暂停导致调用失败。
另一个不确定因素是调用发生在两台机器之间,所以要经过网络传输,而网络的复杂性是不可控的,网络丢包、延迟以及随时可能发生的瞬间抖动都有可能造成调用失败。
所以,单体应用改造为微服务架构后,要针对服务调用失败进行特殊处理。那具体来说有哪些处理手段呢?下面我就结合自己的实战经验,一起来聊聊服务调用失败都有哪些处理手段。

超时

首先你要知道的是,单体应用被改造成微服务架构后,一次用户调用可能会被拆分成多个系统之间的服务调用,任何一次服务调用如果发生问题都可能会导致最后用户调用失败。而且在微服务架构下,一个系统的问题会影响所有调用这个系统所提供服务的服务消费者,如果不加以控制,严重的话会引起整个系统雪崩。
所以在实际项目中,针对服务调用都要设置一个超时时间,以避免依赖的服务迟迟没有返回调用结果,把服务消费者拖死。这其中,超时时间的设定也是有讲究的,不是越短越好,因为太短可能会导致有些服务调用还没有来得及执行完就被丢弃了;当然时间也不能太长,太长有可能导致服务消费者被拖垮。根据我的经验,找到比较合适的超时时间需要根据正常情况下,服务提供者的服务水平来决定。具体来说,就是按照服务提供者线上真实的服务水平,取 P999 或者 P9999 的值,也就是以 99.9% 或者 99.99% 的调用都在多少毫秒内返回为准。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(21)

  • 最新
  • 精选
  • feimeng0532
    服务熔断和降级区别?

    作者回复: 熔断可以理解为间歇性的降级,之后会探测服务是否恢复自动恢复降级,而降级一般指的是一次性的中断对服务的调用,需要人为再主动恢复降级

    2
    7
  • Douglas
    重试的前提是不是请求是幂等的?客户端还没拿到返回的情况下

    作者回复: 对,必须是幂等的调用才可以重试

    5
  • 南山
    hystrix会对每个服务请求都封装成一个hystrix command吗?如果是的话,服务请求量非常多的时候,会创建非常多的command对象吗?

    作者回复: 这里指的是每一种服务调用,如果提供了三个服务,每一种服务有各自的command对象和对应的线程池。

    3
  • 刘炳乾
    Hystrix已经不再更新了,有其他比较优秀替代框架么?

    作者回复: 目前功能足够稳定了吧,如果需要持续更新,可以关注下netflix用于替代hystrix的框架resillience4j

    1
  • 波波安
    (1)线程池隔离模式:使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理) (2)信号量隔离模式:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)
    28
  • 不是很精彩呀😄 来个比喻: 张三喊李四一起出去玩 1:超时,喊一嗓子,等五分钟,不去就算啦 2:重试,喊一嗓子,不出来,就再喊一嗓子 3:双发,喊一嗓子,不出来,就喊王五 4:熔断,喊一嗓子,不出来,不喊了
    3
    16
  • 有铭
    双发策略完全没想明白,当遇到慢请求的时候,你就算新发一个请求,也应该是大概率的慢请求,而且你并不能保证新请求的响应时间会比之前请求短。也就是双发请求大部分时间实际只是做了两次请求而已,这两次请求中有一次被浪费掉了。双发策略的意义到底在哪里呢,我看不出有实际可应用的场景
    4
    9
  • 公号-技术夜未眠
    线程池隔离可以实现故障隔离,避免雪崩 但是由于由于线程频烦上下文切换,开销较大
    4
  • 滚键盘
    双发是减少因为网络I/O 或者抖动引起的请求失败 降低本来所需要的等待重试时延
    3
  • 楼下小黑哥
    优点:可以防止某个服务占满可以使用的线程,影响其他服务 缺点:如果运行线程特别多,线程上下文切换成本较高。
    3
收起评论
显示
设置
留言
21
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部