许式伟的架构课
许式伟
七牛云CEO
立即订阅
20066 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (9讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册

53 | 过载保护与容量规划

许式伟 2019-11-01
你好,我是七牛云许式伟。
前面在 “47 | 服务治理的宏观视角” 一讲中,我们大体将故障类型分为以下几种。
软硬件升级与各类配置变更,即发布。
软硬件环境的故障。
终端用户的请求。比较典型的场景是秒杀类,短时间内大量的用户涌入,导致系统的承载能力超过规划,产生服务的过载。当然还有一些场景,比如有针对性的恶意攻击、特定类型的用户请求导致的服务端资源大量消耗等,都可能引发服务故障。
软硬件升级与各类配置变更,主要通过发布与升级系统完成。软硬件环境的故障,可以参考 “51 | 故障域与故障预案”。
今天我们聊的是故障的第三大类:由终端用户请求导致的故障。它最典型的现象是 “过载”。

过载的成因与后果

我们要思考的第一个问题是:过载的原因是什么?
所谓过载,最直白的理解,当然就是因为活跃的用户超过了资源的承载能力范围,导致某类资源耗尽,进而体现出系统过载。
本质上,这是一个容量规划的问题。
资源怎么会不够了?往往有以下这么几个成因:
其一,用户增长太快了,资源规划上的预期没有跟上,导致资源储备不足。
其二,部分资源因为故障而下线,导致线上活跃的资源不足。举个例子,假设我们做了双机房容灾,但是往往这仅仅是架构上的容灾。从资源储备角度来说,我们需要按 2 倍的容量来做资源规划,才有可能在某个机房下线后系统不出问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 小名叫大明
    天呐,这么好的内容怎么没几个人交流呢。

    前一段时间微信支付故障,前端没有关闭微信支付通道,后端其他逻辑因为失败在疯狂重试(不是有节奏的延长重试时间),服务端也没有做限流,差点导致悲剧。

    过载保护确实很重要。

    对于老师说的:基于QPS还是基于资源使用率,我们常规压测是基于QPS。容量规划上可以容忍一半的机器故障。

    作者回复: 目前我看到的的确也是基于qps比较常见一些

    2019-11-12
    1
    2
  • Aaron Cheung
    用量的确很好


    更好的解决方案,是直接基于该服务所依赖的关键资源,如 CPU 和内存等,来衡量服务的可用容量。我们为该服务预留了多少资源,这些资源已经用了多少,预计还能够用多久。
    2019-11-01
    2
  • 诗泽
    负载均衡处的过载保护是怎么做的?

    作者回复: 比如,负载均衡是业务服务的前端,上面介绍的客户端侧能够做的过载保护机制都是可以考虑的。

    2019-11-01
  • Charles
    许老师,这几讲读下来,有一个疑问请教下:
    每个人所处的项目规模有很大的不同,有的没做服务化还在跑负载均衡、有的可能到了七牛云的体量、有的可能是微博那种体量,另外就是人力可能也不允许,那么有什么衡量指标或依据可以判断一个服务端相关的SRE工作是否做到位?以此指导每个阶段应该做哪些最主要的事情?谢谢

    作者回复: 用户量不大的时候,方案简陋些没关系的,毕竟出问题影响面也小,所以怎么平衡每个公司有自己的一杆秤

    2019-11-01
收起评论
4
返回
顶部