架构师第十一周作业及总结

导致系统不可用的原因有哪些？保障系统稳定高可用的方案有哪些？请分别列举并简述。

1、导致系统不可用的原因：

• 硬件故障

主要包括磁盘、网卡等使用相当频繁的设备，还有就是散热系统故障

• 网络故障

主要由于光纤/网线被人为或自然灾害破坏导致

• 软件故障

如果系统架构比较复杂，中间件/模块太多，其中的任一关键链路出现故障都会导致整个系统不可用

由于触发系统bug造成系统不可用

由于前期没有做相关的压力测试，凭经验估计硬件配置，造成系统上线后高峰期服务器扛不住而宕机

架构设计不合理，在关键链路上存在性能瓶颈造成系统整体不可用



2、保障系统稳定高可用的方案

• 前端应用负载均衡

对前端应用程序通过部署K8S集群进行弹性伸缩，通过设置最低运行容器数量，动态弹性伸缩，保障业务高峰期的流量压力。对于静态资源采用CDN缓存策略，减轻对应用服务器的压力

• 中间层采用消息机制、内存数据库缓存数据

在应用服务器与后台数据库之间采用memcached/redis等内存数据库，缓存非关键业务数据/热点数据，减轻对后端数据库的直接数据读取压力。同时采用消息中间件的异步方式，减轻对后端数据库的写入压力。让数据库的读写整体保持均衡

• 数据库采用集群部署

后端数据库采用mysql，则可以做PXC或MGR集群，同时进行读写分离。一来分散IO请求，二来保证数据的多副本数，同时可以再做一层主从同步/异步复制。用于数据的备份/延迟备份。用于数据出错时的回滚机制。

后端数据库采用oracle，则做成rac集群，同时做DG，保障多副本，同时如果RAC集群故障后，可以自动切换到备用数据库，继续提供数据服务。

另外还可以在数据库端前面再放一个数据库中间件产品，比如Mycat，用于数据请求的自动路由、负载均衡、读写分离等。后端数据库则可以做成多个集群，集群之间通过主从同步机制，保证集群之间数据的一致性

• 在软件层面的高可用方案

在软件层面可以做的有：限流、熔断、降级等

• 异地多活

在不同城市或不同地域部署系统，这样在面对大的灾害时能保证还能继续对外提供服务，但此种方案的实施成本相当高，对技术的要求也比较高，