稳定性思考-强弱依赖

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,182元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 淘宝系统依赖关系比较复杂。A系统依赖B系统资源,当B系统发生故障的时候,A系统势必会被拖累,导致A系统也发生故障                                  图:[ A]--依赖-->[B] 这里的依赖要区分两种情况 1、A强依赖于B     任何强依赖都要尽可能的转化

淘宝系统依赖关系比较复杂。A系统依赖B系统资源,当B系统发生故障的时候,A系统势必会被拖累,导致A系统也发生故障

                                 图:[ A]--依赖-->[B]
这里的依赖要区分两种情况
1、A强依赖于B
    任何强依赖都要尽可能的转化成弱依赖,因为强依赖本身意味着一荣俱荣,一损俱损。老婆管账,但是老公又没有私房钱,对老公来说强依赖于老婆,也许是很幸福的事情。在系统角度来说这并不是好事情,比如支付系统强依赖银行的支付,一旦银行支付出现问题,那么只能干等着。所以需要尽量的扩展银行的支付通道,让单个节点影响到最小。
    对于强依赖B这个场景,从稳定性来说我们还是可以做一些事情:当B发生故障,虽然A系统不能正常执行业务,但是A不能挂掉,一旦B系统恢复,A系统也要做到立即恢复。同时A有责任对B要进行流量保护,而不是对B进行摧残。
    我和小赌对淘宝某一前台系统做过一次分流压测(和ab,httpload等压测不同,是直接将正常的用户请求不断引入的压测方式,本质区别是分流压测方式用户数会持续不断的增加,ab等则是固定用户数):A系统单机的容量是4,当前的进入的流量是1。进行分流压测,不断增加单机的流量,直到该单机的流量到4,此时一切正常,流量增加到5,此时响应时间突增,减少流量到4,响应时间还是很长,持续一段时间不能自己恢复,再减少到3,系统还是没有恢复,直到减少到2之后,系统恢复。原因是系统被压垮之后,其容量发生了变化,原来容量是4,压垮之后容量变成了2.5。
    此时系统会有比较频繁的fullgc产生,做个简单的分析,因为用户不断增加,而容量有不够只能堆积,导致线程数量大增,直到max-limit值,并且由于强资源,导致每个线程完成工作的时间变长,minagc发生的时候大量的eden区对象不能被回收,拷贝到s0 or s1又放不下或者超过交换次数后被拷贝到了old区。

    所以摧残一个系统不好,同时也说明如果系统没有做特殊的保护,当分流的量大于了单机的容量,持续一段时间后,系统将不能很好的恢复,即便我们把分流进入的量减少到系统容量以下也不能快速恢复。
2、A弱依赖于B
此时B如果发生了故障,那么大家都期望A继续能提供正常的服务
场景1:A调用B,A的主流程不需要等待B的返回结果
  1. 浏览器弱依赖:A从浏览器上发起异步请求,如果B挂了,那么只会出现页面某一个区域不显示B的内容,如果对于用户交互可以接受,那么系统层面无任何问题,商品详情页面的评论列表和购买记录就是这个情况
  2. 异步线程:A调用B的时候只发送消息,然后调用动作由另外的线程来执行,并且不需要即时反馈结果,一般作为消息通知,轨迹记录等场景使用。不过为了防止堆积,也需要控制队列的大小
场景2:A调用B,A的主流程需要等待B的返回结果
  1. 设置超时时间:如果B响应超时,则抛出超时异常,绝对大部分情况下OK;不过两种影响要考虑:1、超时时间设置过长或者过短导致的副作用 2、大量异常抛出
  2. 设置最大并发请求数阀值,一旦超过阀值就跳过访问B
  3. 两种方式相结合使用最佳
相关文章
|
运维 监控 算法
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
|
消息中间件 缓存 监控
系统稳定性建设实践总结
2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。
系统稳定性建设实践总结
|
应用服务中间件 nginx
403 Forbidden nginx/1.20.1
403 Forbidden nginx/1.20.1
1431 0
403 Forbidden nginx/1.20.1
|
6月前
|
运维 Kubernetes 监控
Log/Trace/Metric 完成 APIServer 可观测覆盖
12 月 11 日,OpenAI 出现了全球范围的故障,影响了 ChatGPT/API/Sora/Playground/Labs 等服务,持续时间超过四个小时。究其背后原因,主要是新部署的服务产生大量的对 K8s APIServer 的请求,导致 APIServer 负载升高,最终导致 DNS 解析不能工作,影响了数据面业务的功能。面对 APIServer 这类公用基础组件,如何通过 Log/Trace/Metric 完成一套立体的覆盖体系,快速预警、定位根因,降低不可用时间变得非常重要。
229 95
Log/Trace/Metric 完成 APIServer 可观测覆盖
|
7月前
|
监控 容灾 Java
系统稳定性建设三件事
本文分享了作者学习稳定性工作、构建思路、落实方案,面对问题不断反思再推进的经验总结。
系统稳定性建设三件事
|
SQL 缓存 运维
使用篇丨链路追踪(Tracing)很简单:链路拓扑
使用篇丨链路追踪(Tracing)很简单:链路拓扑
31816 99
|
编解码 算法 前端开发
聊聊我从底层算法到业务算法转型的这一年
聊聊我从底层算法到业务算法转型的这一年
530 0
|
安全 网络安全 数据安全/隐私保护
`certifi`是一个Python包,它提供了一个包含Mozilla证书颁发机构(CA)Bundle的PEM文件。
`certifi`是一个Python包,它提供了一个包含Mozilla证书颁发机构(CA)Bundle的PEM文件。
|
存储 消息中间件 Cloud Native
饿了么EMonitor演进史
可观测性作为技术体系的核心环节之一,跟随饿了么技术的飞速发展,不断自我革新。
7933 112
饿了么EMonitor演进史
|
消息中间件 缓存 Cloud Native
大促场景系统稳定性保障实践经验总结
11月11日0点刚过26秒,天猫双11的订单创建峰值就达到58.3万笔/秒,阿里云又一次扛住全球最大规模流量洪峰!58.3万笔/秒,这一数字是2009年第一次天猫双11的1457倍。
13000 111
大促场景系统稳定性保障实践经验总结

热门文章

最新文章