从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

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

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

超时

首先你要知道的是,单体应用被改造成微服务架构后,一次用户调用可能会被拆分成多个系统之间的服务调用,任何一次服务调用如果发生问题都可能会导致最后用户调用失败。而且在微服务架构下,一个系统的问题会影响所有调用这个系统所提供服务的服务消费者,如果不加以控制,严重的话会引起整个系统雪崩。
所以在实际项目中,针对服务调用都要设置一个超时时间,以避免依赖的服务迟迟没有返回调用结果,把服务消费者拖死。这其中,超时时间的设定也是有讲究的,不是越短越好,因为太短可能会导致有些服务调用还没有来得及执行完就被丢弃了;当然时间也不能太长,太长有可能导致服务消费者被拖垮。根据我的经验,找到比较合适的超时时间需要根据正常情况下,服务提供者的服务水平来决定。具体来说,就是按照服务提供者线上真实的服务水平,取 P999 或者 P9999 的值,也就是以 99.9% 或者 99.99% 的调用都在多少毫秒内返回为准。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 波波安
    (1)线程池隔离模式:使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
    (2)信号量隔离模式:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)
    2018-10-14
    13
  • 有铭
    双发策略完全没想明白,当遇到慢请求的时候,你就算新发一个请求,也应该是大概率的慢请求,而且你并不能保证新请求的响应时间会比之前请求短。也就是双发请求大部分时间实际只是做了两次请求而已,这两次请求中有一次被浪费掉了。双发策略的意义到底在哪里呢,我看不出有实际可应用的场景
    2018-10-09
    7
  • feimeng0532
    服务熔断和降级区别?

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

    2018-11-14
    3
  • 公号-代码荣耀
    线程池隔离可以实现故障隔离,避免雪崩
    但是由于由于线程频烦上下文切换,开销较大
    2018-10-09
    3
  • Douglas
    重试的前提是不是请求是幂等的?客户端还没拿到返回的情况下

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

    2018-10-11
    2
  • 陈华应
    hystrix会对每个服务请求都封装成一个hystrix command吗?如果是的话,服务请求量非常多的时候,会创建非常多的command对象吗?

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

    2018-10-10
    2
  • 盘木
    线程池隔离啥意思?
    2018-10-09
    2
  • andyXH
    优点:可以防止某个服务占满可以使用的线程,影响其他服务

    缺点:如果运行线程特别多,线程上下文切换成本较高。
    2018-10-18
    1
  • 蔡呆呆
    线程池隔离也就是每个服务对应一个线程池,好处是各个服务隔离的很干净,不会相互影响。坏处在于对资源的需求量比较大,利用率会比较低。
    2018-10-09
    1
  • 拉欧
    线程池隔离可以确保不同接口的问题不相互影响,但是会增加应用的线程数量,即资源消耗会增加
    2018-10-09
    1
  • echo_陈
    我们编写API网关时,使用了Hystrix,作为熔断实现,为了不使得ThreadLocal编程变得困难,使用了信号量隔离,直接复用工作线程。但是发现了问题,就是,如果使用信号量隔离,请求超时无法做到立即返回。
    2018-10-09
    1
  • 哦山丘
    P999是啥意思
    2019-10-08
  • godtrue
    不是很精彩呀😄
    来个比喻:
    张三喊李四一起出去玩
    1:超时,喊一嗓子,等五分钟,不去就算啦
    2:重试,喊一嗓子,不出来,就再喊一嗓子
    3:双发,喊一嗓子,不出来,就喊王五
    4:熔断,喊一嗓子,不出来,不喊了
    2019-06-15
  • 张小男
    “聪明的双发”这个思路太神奇了啊!
    我们的服务就是不知道什么原因导致服务超时,还有这种连续5秒没有日志的情况,正常每秒都要上千行的日志,感觉是cpu不工作了…
    我们平均响应也就几十毫秒,超时设置的500毫秒!但是只能达到99.88左右,qps 2000
    问下motan可以设置重试超时时间吗?
    2019-04-16
  • 滚键盘
    双发是减少因为网络I/O 或者抖动引起的请求失败 降低本来所需要的等待重试时延
    2019-03-06
  • 刘炳乾
    Hystrix已经不再更新了,有其他比较优秀替代框架么?

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

    2018-11-30
  • 莲花
    dubbo中怎么判断服务调用成功或超时了?
    2018-10-10
  • 三木子
    “P999 由于长尾请求时间较长的缘故“ 这句话没看明白,可以解释下吗?
    2018-10-09
    1
收起评论
18
返回
顶部