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