架构实战案例解析
王庆友
前 1 号店首席架构师
18817 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 23 讲
架构实战案例解析
15
15
1.0x
00:00/00:00
登录|注册

12 | 高可用架构:如何让你的系统不掉链子?

你好,我是王庆友。今天我和你聊一聊,如何实现系统的高可用。
在实际工作中,我们平常更关注系统业务功能的实现,而对于系统是否会出故障,总觉得那是小概率事件,一开始不会考虑得太多。然而系统上线后,我们会发现系统其实很脆弱,每个地方都可能会出问题,处理线上事故的时间往往超过了开发功能的时间。
所以,对于系统的高可用,我想你经常会有这样的疑问:系统的高可用真的很重要吗?如何实现系统的高可用,具体都有哪些手段呢?
十年前,我还在 eBay,那时候,我们有几个数据来说明系统宕机对公司的影响,我记得其中一个是系统每宕掉 1 秒,公司将损失三千美金的收入;现在的大型外卖平台也是如此,如果就餐高峰期宕掉 1 小时,平台至少损失几个亿的直接收入,更加不用说对公司品牌的影响。
但是我们知道,系统中包含了大量的软硬件设备,要保证所有的节点都可用,不是一件容易的事。所以今天这一讲,我会从系统高可用的角度出发,和你介绍如何才能做到让系统不掉链子。

系统有哪些故障点?

那么一个系统,它在运行的过程中,都可能会出现哪些故障呢?我们来看一个简化的系统处理过程。
首先,客户端在远程发起请求,经过接入系统处理后,请求被转发给应用系统;应用系统调用服务完成具体的功能;在这个过程中,应用和服务还会访问各种资源,比如数据库和缓存。这里,我用红色部分,标识出了整个处理过程中可能出现的故障点,如下图所示:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了系统高可用架构的重要性以及实现高可用的策略和原则。作者首先强调了系统高可用的重要性,指出系统故障可能导致巨大的经济损失和品牌影响。接着,文章列举了系统可能出现的故障点,包括资源不可用、资源不足和节点功能问题。针对这些故障点,作者提出了高可用的解决思路,包括避免问题发生、故障转移、降低故障影响和快速恢复系统。在具体的架构设计原则方面,文章提出了正面保障和减少损失两个角度。正面保障包括冗余无单点和水平扩展,而减少损失则包括柔性事务和系统可降级。通过这些设计原则,读者可以更好地理解如何实现系统的高可用。文章内容详实,涵盖了系统高可用架构的重要概念和实践原则,对于想要了解系统高可用性的读者具有很高的参考价值。 在实践中,系统的高可用性需要综合考虑多个环节的处理策略。从客户端到接入层、接入层到Web应用、Web应用到内部服务,以及访问基础资源,都需要采取相应的高可用手段,包括网络冗余、负载均衡、水平扩展、自动故障转移和系统可降级等措施。此外,文章还强调了监控的重要性,作为系统高可用的第二条保命措施。通过这些手段和原则,读者可以全面了解系统高可用的处理思路,并在实际工作中灵活应用。 总的来说,本文详细介绍了系统高可用架构的重要性、策略和设计原则,为读者提供了清晰的认识和实践指导。通过实际案例的讲解,读者可以更好地理解如何实现系统的高可用,并在工作中应用这些策略和原则。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《架构实战案例解析》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • Din
    是 重启、下线、回滚 这三个吗? 感觉这些手段和老师说的「处理线上事故的首要原则是先尽快恢复业务 」是一致的,都是先恢复业务,将业务损失降到最低,然后再定位具体的问题。

    作者回复: 差不多,下线和回滚差不多意思,还有一个是加机器。

    2020-03-22
    2
    5
  • 洛瑞
    三板斧:重启、扩容、回滚 以快速止血和恢复业务为目标,然后再定位故障原因

    作者回复: 没错,back to normal为首要

    2021-11-17
    3
  • 洛瑞
    重启、扩容、回滚

    作者回复: 厉害,懂运维精髓

    2021-11-17
  • 寒光
    功能开关这个方案,老师是否有更具体的案例可以分享下呢? 另外,对于2B的服务,熔断、降级好像都没法落地,这个有没有最佳实践呢?

    作者回复: 功能开关很常见,就是一个配置项,可以存储在数据库里或者使用类似apollo的配置系统,然后应用系统读取配置信息,根据配置值的不同执行不同逻辑分支。

    2021-01-05
  • jian
    "比如说,你可以选择 Nginx、HAProxy、LVS 等负载均衡软件,它们都能很好地支持双节点 +Keepalived 部署。". 请问老师这里的“双节点 +Keepalived 部署”是什么意思? 特别是Keepalived 部署,不太明白。恳请指点!

    作者回复: 两个节点提供同样的功能,Keepalived机制保证一个节点出问题,另一个节点顶上去,这个机制很常用,你百度下,有深入的介绍。

    2020-06-10
  • Robin康F
    处理事故三板斧:快速回复 根源定位 复盘总结

    作者回复: 这样事故处理起来有点慢了

    2020-04-24
  • 陈政璋
    老师你好,数据库之间使用主从异步复制是有延迟的,这样可能导致数据不一致问题,这种有什么好的方式解决吗?

    作者回复: 没有特别好的技术上解决办法,只能尽量保证网络良好,另外对时间敏感性高的度操作还是要访问主库。

    2020-04-23
  • j4念勾for
    老师您好,“支持主库故障时,能够自动实现主从切换,应用可以通过 VIP 访问数据库,因此这个切换过程对应用也是透明的。”从库只读,主从账号不一致的场景下应该怎么处理?

    作者回复: mha机制会自动把从库只读变成读写,账号不一致,那就把它设成一致啊,不然就不符合mha部署。

    2020-04-17
    2
  • j4念勾for
    数据库主从一般账号不一致,从库账号只有读权限,这种业务场景下,老老师,应该怎么处理?

    作者回复: 这很正常,从库只读,你碰到什么问题呢?

    2020-04-17
    4
  • J.Smile
    老师,课程看到现在觉得确实都是实际的架构经验,不过更偏重于设计角度,有个疑问,对于有志于成为架构师的开发工程师来说,是需要多花精力在软件本身的使用或者说落地上呢?还是思考架构如何设计上而对软件达到基本能上手使用就行?

    作者回复: 工程师到架构师,是一个从实现到设计的过程,设计比实现更难,会设计,实现自然不是问题

    2020-03-18
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部