SRE 实践:服务可靠性案例课
白园
前百度资深运维专家,前快手资深 SRE 专家
1189 人已学习
新⼈⾸单¥59
SRE 实践:服务可靠性案例课
15
15
1.0x
00:00/00:00
登录|注册

10|容量场景(三):一条让新浪工程师们通宵加班的微博

你好,我是白园。
今天,我们来看容量部分的第三个案例,在之前两个案例中我跟你分享了流量控制、服务上云、雪崩、热点等场景。资源通常是有限的,因此不可能对所有服务进行扩容。我们应优先将资源扩容到那些最需要资源的关键链路。如果扩容速度不够快,未能在流量高峰到来之前完成,可能会导致系统故障或业务损失。
这节课我们就来探讨一下,在资源有限的条件下,如何做快速精准地扩容。
我们先看一个案例。时间回到 2017 年 10 月 8 日的这一天,也是国庆与中秋长假的尾声。在这个特别的日子里,一个事件吸引了近 7000 万人的目光,那就是鹿晗公开了他和关晓彤的恋情。这一消息的公布,迅速引起了公众的广泛关注,也因此导致了微博平台的短暂瘫痪。因为其访问量激增,超出了服务器的承载能力。新浪工程师们通过通宵的努力,最终才把这个问题解决。

难点分析

面对微博热点事件,最直接的应对策略是系统扩容,以适应突发的流量高峰,但是微博相关的服务扩容是非常困难的事情,扩容难点如下:
难点一:不可预测性。与抢票事件相比,微博热点事件往往伴随着许多不确定因素,因为公众人物发布新闻的时间和内容是无法控制的。
难点二:层次复杂性。系统架构中存在多个层次,包括网络入口层、四层(传输层)和七层(应用层)的网络协议处理、服务层的业务逻辑处理以及数据层的存储管理。不同系统层次的扩容难易度和维持高冗余度的成本存在显著差异。接入层维持高冗余的成本相对比较低。相比之下,服务层由于服务器规模庞大,维持高冗余度的成本比较高。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
  • 解释
  • 总结

1. 微博平台在面对热点事件时,需要快速扩容以适应突发的流量高峰,但微博相关的服务扩容是非常困难的事情,因为扩容难点包括不可预测性、层次复杂性、链路多样性和资源限制。 2. 针对微博热点事件,需要通过应急响应机制确认需要扩容的链路,并采取相应的响应措施,如扩容、功能降级等,以确保平台的稳定运行和维护良好的用户体验。 3. 在扩容过程中,需要分析涉及的应用和服务,采用动态服务架构图和追踪工具来迅速确定相关服务,并明确标注服务之间的依赖关系,区分它们的重要性和依赖强度。 4. 对于接入层的快速扩容,建议采取提前扩容的策略,并预留一定的冗余空间,同时加强演练,以确保能够有效应对突发流量。 5. 面对热点事件,需要对每个链路进行细致的流量分析和压力测试,以预测和应对不同的流量模式。 6. 数据库(DB)扩容是一个耗时的过程,特别是在紧急情况下,很难迅速完成,因为扩容涉及到数据的同步操作,必须在同步完成后才能进行。 7. 在数据层应对热点最好的方案就是多级缓存,比如用CDN来缓存一些静态图片和视频,比如利用Redis/Memcached来缓解一些热点查询压力。 8. 针对写分片,应提前进行扩容,以避免在流量高峰时措手不及。 9. 对于一个高可用的服务,很重要的一个设计就是降级开关,其目的是抛弃非重要服务,保障主要或核心业务能够正常提供服务。 10. 选择水平扩容还是垂直扩容,需要根据实际业务需求、成本预算、系统架构和未来扩容计划来综合考虑。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实践:服务可靠性案例课》
新⼈⾸单¥59
立即购买
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部