导致系统不可用的原因有哪些?保障系统稳定高可用的方案有哪些?请分别列举并简述。
原因:
- 硬件故障
- 系统 bug
- 系统维护升级发布时短时不可用
- 用户访问量大导致并发压力过高,超过系统承载上限
- 遭受网络攻击等,导致系统负载过高崩溃
- 自然灾害等外部因素
高可用架构:
使用服务集群
假设只有一台服务器执行所有应用,只要有人不小心踩到了电源插头,就可以导致整个服务宕机。通常系统设计时通常会将应用部署到不同的服务器上,降低故障发生时系统不可用的概率
无状态组件
部署服务集群是保证高可用的最基本需求:确保任何一个节点都可以断连、关机、升级,但是剩余的服务依旧正常工作。应用集群一般设计为无状态服务,通过 Session、cache 或是数据库共享信息。
Load Balancing
负载均衡既是应对网络并发压力的解决方案,也可以在检测到某实例故障时,无缝切换流量,提高系统容错能力。
数据备份、恢复
数据库奔溃比服务器宕机危害更大,因为用户的数据很可能会就此丢失,后果不堪设想。数据库冗余备份是系统设计时必须的考量。每个数据中心都应该具有完整的备份,并事先计划好数据丢失和恢复的策略。
故障转移
失效转移指的是当主要组件异常时,其功能转移到备份组件。其要点在于有主有备,且主故障时备可启用并设置为主。通常的实现手段有:主从复制、主主复制,也可以结合数据分片等等技术。
异地多活
服务集群、数据库扩展后,有些安全隐患依旧不可避免,比如地震、火灾这类自然灾害很可能导致整个机房遭遇重大破坏。为了避免这类事故,一般会在多地部署机房,实现异地容灾容错。
故障自动恢复计划
如上的架构设计仅仅能提高系统的可用性,但依旧不可能完全避免故障产生。因而恢复故障也是一套很复杂的系统流程:能及时地隔离故障设备,确保剩余系统功能正常;建立故障历史记录,并追踪问题根源;通过监控系统收集负载数据并分析趋势;建立一系列恢复手册,并定期测试其实用性;员工培训,以提高设计、部署、运维的能力;还应制定安全策略,抑制安全漏洞……
本文由 biezhi 创作,采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
最后编辑时间为:
2020/08/27 23:29