12 | 高可用架构:如何让你的系统不掉链子?
系统有哪些故障点?
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了系统高可用架构的重要性以及实现高可用的策略和原则。作者首先强调了系统高可用的重要性,指出系统故障可能导致巨大的经济损失和品牌影响。接着,文章列举了系统可能出现的故障点,包括资源不可用、资源不足和节点功能问题。针对这些故障点,作者提出了高可用的解决思路,包括避免问题发生、故障转移、降低故障影响和快速恢复系统。在具体的架构设计原则方面,文章提出了正面保障和减少损失两个角度。正面保障包括冗余无单点和水平扩展,而减少损失则包括柔性事务和系统可降级。通过这些设计原则,读者可以更好地理解如何实现系统的高可用。文章内容详实,涵盖了系统高可用架构的重要概念和实践原则,对于想要了解系统高可用性的读者具有很高的参考价值。 在实践中,系统的高可用性需要综合考虑多个环节的处理策略。从客户端到接入层、接入层到Web应用、Web应用到内部服务,以及访问基础资源,都需要采取相应的高可用手段,包括网络冗余、负载均衡、水平扩展、自动故障转移和系统可降级等措施。此外,文章还强调了监控的重要性,作为系统高可用的第二条保命措施。通过这些手段和原则,读者可以全面了解系统高可用的处理思路,并在实际工作中灵活应用。 总的来说,本文详细介绍了系统高可用架构的重要性、策略和设计原则,为读者提供了清晰的认识和实践指导。通过实际案例的讲解,读者可以更好地理解如何实现系统的高可用,并在工作中应用这些策略和原则。
《架构实战案例解析》,新⼈⾸单¥59
全部留言(16)
- 最新
- 精选
- Din是 重启、下线、回滚 这三个吗? 感觉这些手段和老师说的「处理线上事故的首要原则是先尽快恢复业务 」是一致的,都是先恢复业务,将业务损失降到最低,然后再定位具体的问题。
作者回复: 差不多,下线和回滚差不多意思,还有一个是加机器。
2020-03-2225 - 洛瑞三板斧:重启、扩容、回滚 以快速止血和恢复业务为目标,然后再定位故障原因
作者回复: 没错,back to normal为首要
2021-11-173 - 洛瑞重启、扩容、回滚
作者回复: 厉害,懂运维精髓
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-172 - j4念勾for数据库主从一般账号不一致,从库账号只有读权限,这种业务场景下,老老师,应该怎么处理?
作者回复: 这很正常,从库只读,你碰到什么问题呢?
2020-04-174 - J.Smile老师,课程看到现在觉得确实都是实际的架构经验,不过更偏重于设计角度,有个疑问,对于有志于成为架构师的开发工程师来说,是需要多花精力在软件本身的使用或者说落地上呢?还是思考架构如何设计上而对软件达到基本能上手使用就行?
作者回复: 工程师到架构师,是一个从实现到设计的过程,设计比实现更难,会设计,实现自然不是问题
2020-03-18