赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

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

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

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

首先,看一下我们当前所面对的极端业务场景,我把它大致分为两类。
1.可预测性场景
什么是可预测性?简单来说,就像电商每年的大促,如 618、双 11、双 12 等等。这类业务场景是可预测的,业务峰值和系统压力峰值会出现在某几个固定的时间点,我们所做的所有准备工作和稳定性应对措施,都是针对这些固定时间点的,比如零点时刻。
峰值压力可预测,就意味着可以提前评估用户访问模型,并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容,调整完成之后,继续压测,继续调整,直至系统容量达到原来设定的目标。由此可见,在可预测的场景下,与后面的不可预测场景相对比,从准备过程上来说会更加从容。
但是,我们的优化或扩容是有限度的,也就是不会无限度地投入成本,来满足零点这个峰值时刻,让所有用户都能够正常访问。从成本和收益角度来说,这样做是不现实的。
所以,在峰值那个时间点上,当用户流量远远大于系统容量时,我们所采取的措施绝不是再去扩容或优化,因为无论是从时效性、系统稳定性还是成本收益上看,这样做都已经无法满足要求了。
那我们该采取什么策略呢?这里我们采取的策略是在系统承诺容量内,保证系统的核心功能能够正常运行。以电商为例,就是要确保整个交易链路是正常的,用户可以正常登陆,访问商品,下单并最终支付。对于非核心功能,就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流,并确保在某些异常状况下能够熔断或旁路,比如缓存故障,就要马上限流并将请求降级到数据库上。
所以,我们在 618,双 11 和双 12 的零点峰值时刻去访问各大电商网站,很大概率上都会提示系统正忙,请稍后再试,短则 2~3 分钟,长则 5~10 分钟,再去访问,网站功能就一切正常了。这并不代表各大电商网站宕机了,而是其在瞬时超大流量访问压力下采取的一种保护措施,这一点反而说明这些电商网站的大促预案非常完善。
2.不可预测性场景
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(2)

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

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

    后面文章还会介绍到,可以关注下

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