稳定性思考-强弱依赖

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 淘宝系统依赖关系比较复杂。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. 两种方式相结合使用最佳
相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
3月前
|
测试技术
单元测试策略问题之行覆盖率和分支覆盖率之间的问题如何解决
单元测试策略问题之行覆盖率和分支覆盖率之间的问题如何解决
|
3月前
软件复用问题之度量组件的可靠性,如何解决
软件复用问题之度量组件的可靠性,如何解决
|
3月前
|
传感器 数据采集 测试技术
工程结构健康状况评估是保持建筑物和桥梁等基础设施安全性和稳定性的重要工作
工程结构健康状况评估是保持建筑物和桥梁等基础设施安全性和稳定性的重要工作
工程结构健康状况评估是保持建筑物和桥梁等基础设施安全性和稳定性的重要工作
|
2月前
|
测试技术
软件交付质量问题之对于处理质量与成本的平衡该如何实现
软件交付质量问题之对于处理质量与成本的平衡该如何实现
|
3月前
|
设计模式 存储 Java
代码优化设计问题之解耦策略路由和策略实现的依赖问题如何解决
代码优化设计问题之解耦策略路由和策略实现的依赖问题如何解决
|
5月前
|
算法
【核心复现】同时考虑考虑孤岛与重构的配电网故障恢复运行策略
【核心复现】同时考虑考虑孤岛与重构的配电网故障恢复运行策略
|
5月前
|
SQL 运维 监控
老系统重构系列--稳定性摸排灵魂三问
该文主要讨论了老系统改造的过程和方法,特别是针对版权资产管理-财资系统的重构。作者强调了系统稳定性的重要性,并分享了他们团队在重构过程中采取的策略。他们通过确定目标、制定方法论和实施步骤来确保问题的全面摸排,包括核心链路图、流程时序图和问题路由图的绘制,以识别可能的问题和需要加强监控的部分。此外,文章还提到了数据对账监控和系统级统一监控的重要性,以及技术改造和预案的制定。作者提供了相关文章链接以供进一步阅读,并分享了他们在摸排和整改过程中的实际成果。
|
5月前
软件体系结构 - 可靠性指标
软件体系结构 - 可靠性指标
212 0
软件体系结构 - 可靠性指标
|
5月前
|
消息中间件 Cloud Native Java
项目环境稳定性指标建设之路
这篇文章讨论了项目环境在集团研发中的重要性,它是一个灵活的平台工具,用于支持联调测试和不同阶段的环境隔离。早期的项目环境管理存在任务重复运行、单机处理瓶颈和任务猝死等问题。为了解决这些问题,文章介绍了通过引入领域驱动设计(DDD)来重构流程引擎,创建了统一的异常处理和任务执行接口,增强了异常处理能力,并通过分布式分片任务、工厂模式和责任链模式实现了任务的分布式运行。此外,还使用分布式锁解决了多机忙等和任务重复执行的问题,提高了任务执行效率。优化后,环境创建成功率提升至99%以上,创建时间降低至100秒以下,系统异常率低于1%,并且能够应对更高的并发量。
|
12月前
|
运维 程序员 测试技术
如何保证项目质量?层层卡点,一次把事情做对!
如何保证项目质量?层层卡点,一次把事情做对!
174 0