稳定性思考-强弱依赖

40 篇文章 0 订阅

系统依赖关系比较复杂情况:

    A系统依赖B系统资源,当B系统发生故障的时候,A系统势必会被拖累,导致A系统也发生故障 。这里的依赖要区分两种情况:

 

1、A强依赖于B     任何强依赖都要尽可能的转化成弱依赖,因为强依赖本身意味着一荣俱荣,一损俱损。   

 对于强依赖B这个场景,从稳定性来说我们还是可以做一些事情:

    当B发生故障,虽然A系统不能正常执行业务,但是A不能挂掉,一旦B系统恢复,A系统也要做到立即恢复。同时A有责任对B要进行流量保护,而不是对B进行摧残。     如果系统没有做特殊的保护,当分流的量大于了单机的容量,持续一段时间后,系统将不能很好的恢复,即便我们把分流进入的量减少到系统容量以下也不能快速恢复。

 

2、A弱依赖于B 此时B如果发生了故障,那么大家都期望A继续能提供正常的服务 。

    场景1:A调用B,A的主流程不需要等待B的返回结果 浏览器弱依赖:A从浏览器上发起异步请求,如果B挂了,那么只会出现页面某一个区域不显示B的内容,如果对于用户交互可以接受,那么系统层面无任何问题,商品详情页面的评论列表和购买记录就是这个情况 异步线程:A调用B的时候只发送消息,然后调用动作由另外的线程来执行,并且不需要即时反馈结果,一般作为消息通知,轨迹记录等场景使用。不过为了防止堆积,也需要控制队列的大小

    场景2:A调用B,A的主流程需要等待B的返回结果 设置超时时间:如果B响应超时,则抛出超时异常,绝对大部分情况下OK;不过两种影响要考虑:1、超时时间设置过长或者过短导致的副作用 2、大量异常抛出 设置最大并发请求数阀值,一旦超过阀值就跳过访问B 两种方式相结合使用最佳。

  • 5
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值