文章目录
前言
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，通常是指通过设计减少系统不能提供服务的时间。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。为了保证系统的高可用，我们可以从事前、事中和事后三个时间阶段，从技术和业务两个层面来解决问题。
事前
技术层面
分布式架构和负载均衡：
采用分布式和冗余架构，避免单点故障。
硬件冗余是指在关键的硬件组件上使用多个备份，以防止单个设备的故障导致整个系统瘫痪。例如，在数据中心中，可能会部署多台服务器、多个网络路径、多个电源供应等，确保任何一个组件的失败都不会影响整体服务。硬件冗余通常包括但不限于服务器、存储设备、网络设备和电源。也就是所谓的多活架构，比如同城双活、两地三中心、异地多活
软件冗余则是通过部署多个软件实例或副本来提高系统的可用性。在一个高可用性的环境中，关键服务将在多个服务器或节点上运行，确保即使某个节点出现故障，其他节点仍能继续提供服务。这种做法在微服务架构中尤其常见，其中每个服务可能有多个实例运行在不同的服务器或容器中。
使用负载均衡器平衡流量，确保各个节点的负载均匀。负载均衡是一种分配网络流量和请求到多个服务器或资源的技术。它的目的是优化资源使用、最大化吞吐量、减少响应时间，并避免任何单一资源过载。负载均衡器可以是软件或硬件设备，它在接收到请求时，根据预设的规则将流量分配到后端的服务器群。这些规则可以基于多种因素，如服务器的当前负载、健康状态或地理位置。通过负载均衡，可以在多个服务器之间分散工作负载，增加系统的可用性和可靠性。
硬件负载：通过硬件来进行分流，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，一般在互联网系统较少使用，主要用于金融行业的核心服务；
软件负载：通过软件实现分流，如Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，费用非常低廉。按所处OSI模型的工作层级，可分为7层负载和4层负载。7层负载，是指工作在网络7层，基于URL等应用层信息的负载均衡，主要代表有Nginx。4层负载，就是基于IP+端口的负载均衡，主要代表有LVS。
数据备份与故障转移：
其核心思想是对分布式系统中的节点进行备份，备份会分为冷备和热备。通常将数据中心分为主备两种，主提供业务服务，备不提供服务仅作备份和故障转移。
冷备也就是定时备份，主推或者备拉去备份数据。
热备，也就是对主数据中心做实时性的备份，以便在主数据中心出现故障时进行转移。这时候主备会有同步和异步两种数据复制方式，但因为同步会造成性能的损失，所以通常使用异步，这种情况下会造成一定程度的数据延迟问题。
故障转移分为两种模式，各有优劣：
主动-被动模式下，一台服务器（或服务实例）作为主动节点运行，处理所有请求，而另一台或多台服务器作为被动节点，处于待命状态。当主动节点发生故障时，系统会自动切换到被动节点，后者接管服务，从而减少系统停机时间。这种模式的优点是简单明了，但缺点是备用资源在大部分时间内处于闲置状态。
主动-主动模式中，所有服务器都处于活动状态并处理请求。这种模式提高了资源的利用率，但同时也增加了管理的复杂性。在这种设置中，如果一个节点失败，其他节点需要能够接管其工作负载，而不影响总体性能。这通常需要更复杂的负载均衡和同步机制。
自动化部署和扩展：
自动化是实现高可用性的关键。这包括自动故障检测和恢复、自动扩展和收缩资源以适应负载变化、自动化部署和配置管理。通过自动化，可以减少人为错误，提高运维效率。
监控和警报系统：
有效的监控系统可以实时跟踪应用程序和基础设施的健康状况。这包括监控服务器的性能指标（如CPU使用率、内存使用、网络流量）和应用级指标（如响应时间、错误率）。监控可以帮助及时发现问题并采取措施，防止小问题演变成大问题。
收集和分析应用日志，及时发现潜在问题，快速响应和解决。
设置自动化的警报系统，及时通知团队关于潜在的问题。
业务层面
灾难恢复计划：
制定灾难恢复计划，包括备份恢复、系统迁移和紧急操作步骤，也包括、团队的紧急联系人和步骤，以迅速应对突发事件。
定期对团队成员进行培训及测试灾难恢复计划，确保在实际情况中有效。
安全性措施：
实施严格的身份验证和授权机制，确保只有授权用户能够访问敏感信息以及变更实例。
事中
技术层面
自动化故障检测和恢复：
检查事前配置的自动故障转移策略是否生效，如果不生效启用灾备恢复计划。常规情况下通常需要实施快速版本回滚，最大限度降低损失。
实时监控和日志分析：
实时监控系统的性能，追踪实时指标，避免后续持续发生问题。
通过实时警报系统，及时通知团队关于潜在问题，以便快速响应。
事后
技术层面
事故分析和改进：
进行事故分析，深入了解故障原因。
采取措施，防止类似问题再次发生，进行系统改进。
业务层面
用户通知和沟通：
向用户提供详细的事故报告，解释发生的问题和采取的措施。
收集用户反馈，用于改进系统的用户体验。
培训和知识共享：
将事后的教训纳入培训计划，确保团队学到经验教训。
实施知识共享机制，使团队能够从彼此的经验中学习。
口语化总结
对于保证系统的高可用，我们可以通过事前、事中和事后三个时间阶段以及技术和业务两个层面综合进行处理。事前的准备是最多的，因为我们要尽最大努力去保证不出现问题。技术层面有几点可以做，一是我们可以采用分布式架构，做好冗余，软件方面做好集群部署，硬件方面做好多活策略。二是做好数据备份和自动故障转移。三是做好自动化部署和弹性伸缩，我现在公司是自研了一个DevOps平台，实现了自动化的CICD，暂时没有资源弹性的伸缩，可以手动修改应用节点数量，异地多活策略是在北京福州还有新加坡搭建了服务器。四是监控和告警，我现在公司是用的prometheus+grafana，通过K8s提供的探针来监控服务器或者部分应用的关键指标，配合告警及时通知相关负责人处理。业务层面有两点，一是组建一个紧急响应团队，或者对每个项目的负责人进行专门的灾备培训，定期测试灾备计划的有效性。二是严控操作权限和外部依赖，我现在公司基于自研的开发服务平台，控制权限只有部分角色允许进行服务变更，对于MySQLRedis一类的中间件也只提供固定配置的申请资源。
事中的时候自然是能进行自动故障转移最好，不行的话立刻启动灾备计划。如果是服务变更引起的问题，立刻回滚版本，先保证服务稳定运行。同时也要关注监控指标，避免问题反复。事后技术层面上自然是进行事故分析，对故障原因进行复盘，采取一些技术上的措施进行系统改进。业务层面上就是做好经验教训的培训和知识共享，同时对受影响的用户提供详细的事故报告，做好公关，提供补偿，收集用户的反馈，优化用户体验。
写在最后
一个常见的高可用总结，偏理论，在最后的总结部分加上了具体的实践。如果有机会参与或者在某个完善的架构里，我会结合真实的企业级案例进行讲解。