赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37829 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

21 | 极端业务场景下,我们应该如何做好稳定性保障?

突发热点事件
社交类业务的复杂性
功能降级和流量限流
保证核心功能正常运行
压测调优
预估用户访问模型
业务峰值和系统压力峰值
技术与业务的关系
复杂的业务模型
用户的业务访问模型
监控体系
故障模拟
开关预案
限流降级
容量评估和压测
运维自动化
不可预测性场景
可预测性场景
不确定因素
技术挑战
极端业务场景
稳定性保障

该思维导图由 AI 生成,仅供参考

从今天开始,和你分享我对微服务和分布式架构下的稳定性保障的理解。
稳定性保障需要一定的架构设计能力,又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏,以及杨波老师的“微服务架构核心 20 讲”专栏都有非常详细的介绍。所以在我的专栏里,我会结合特定的场景,并着重从运维和技术运营的角度来分享。

我们所面对的极端业务场景

首先,看一下我们当前所面对的极端业务场景,我把它大致分为两类。
1.可预测性场景
什么是可预测性?简单来说,就像电商每年的大促,如 618、双 11、双 12 等等。这类业务场景是可预测的,业务峰值和系统压力峰值会出现在某几个固定的时间点,我们所做的所有准备工作和稳定性应对措施,都是针对这些固定时间点的,比如零点时刻。
峰值压力可预测,就意味着可以提前评估用户访问模型,并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容,调整完成之后,继续压测,继续调整,直至系统容量达到原来设定的目标。由此可见,在可预测的场景下,与后面的不可预测场景相对比,从准备过程上来说会更加从容。
但是,我们的优化或扩容是有限度的,也就是不会无限度地投入成本,来满足零点这个峰值时刻,让所有用户都能够正常访问。从成本和收益角度来说,这样做是不现实的。
所以,在峰值那个时间点上,当用户流量远远大于系统容量时,我们所采取的措施绝不是再去扩容或优化,因为无论是从时效性、系统稳定性还是成本收益上看,这样做都已经无法满足要求了。
那我们该采取什么策略呢?这里我们采取的策略是在系统承诺容量内,保证系统的核心功能能够正常运行。以电商为例,就是要确保整个交易链路是正常的,用户可以正常登陆,访问商品,下单并最终支付。对于非核心功能,就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流,并确保在某些异常状况下能够熔断或旁路,比如缓存故障,就要马上限流并将请求降级到数据库上。
所以,我们在 618,双 11 和双 12 的零点峰值时刻去访问各大电商网站,很大概率上都会提示系统正忙,请稍后再试,短则 2~3 分钟,长则 5~10 分钟,再去访问,网站功能就一切正常了。这并不代表各大电商网站宕机了,而是其在瞬时超大流量访问压力下采取的一种保护措施,这一点反而说明这些电商网站的大促预案非常完善。
2.不可预测性场景
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文讨论了在极端业务场景下,稳定性保障对于微服务和分布式架构的重要性。作者从可预测性和不可预测性两类业务场景出发,探讨了面对这些场景时的挑战和应对策略。在可预测性场景下,系统可以通过评估用户访问模型并进行压测调优来提前应对挑战。而在不可预测性场景下,社交类业务面临更大的挑战,需要解决运维自动化、容量评估和压测、限流降级、开关预案、故障模拟和监控体系等技术挑战。稳定性保障需要综合考虑技术和运维等多方面因素,以确保系统在压力下依然能够稳定运行。文章强调了用户的业务访问模型在稳定性保障中的关键作用,指出了业务层面的不确定因素对技术层面的挑战。作者以电商为例,详细描述了用户下单逻辑中的多种不确定因素,强调了对用户访问模型的深入理解和业务的重要性。最后,文章呼吁读者不要脱离业务谈架构和技术,强调了技术与业务的紧密联系。整体而言,本文通过深入的业务案例和技术挑战,强调了在极端业务场景下稳定性保障的重要性,为读者提供了深入思考的空间。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • feie22
    对于熔断和降级实现方式,应该是研发主导吧,能举个具体的例子说明下吗

    作者回复: 技术实现上研发主导,但是场景梳理,产品设计上,还是会依赖运维,运维离线上环境是最近的,这个优势并不是所有开发都具备的。 后面文章还会介绍到,可以关注下

    2018-02-28
    2
    4
  • 老衲只吃肉
    老师,我们目前在容量预估上出现问题,请教一下你 (1) 压测是否需要独立的压测环境?如果放到你说的beta环境或者预发布环境,是否会对线上环境的数据库造成影响,因为你的预发布环境和beta环境都是和生产公用一个库。 (2)如果需要独立的压测环境,如何部署?单应用接口压测部署还简单。如果全链路压测部署怎么部署?部署生产一样的?还是把对应链路的都找出来【其实测试人员和运维人员都可能找不出来,因为对业务不熟,还是公司的培训体制问题】,全链路压测,还涉及到多个库,线上都是分开部署的。是否为了达到目的,尽量和线上相同? 其实整个工程是很复杂的。 是否能给一些建议,目前在这一块遇到了思路上的瓶颈。
    2019-07-23
    1
    4
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部