找公司做网站多少钱,番禺人才网站,python企业网站开发,网站服务器崩溃1. 引言
软件系统有三个追求#xff1a;高性能、高并发、高可用#xff0c;俗称三高。三者既有区别也有联系#xff0c;门门道道很多#xff0c;本篇讨论高可用
高可用技术的重要性在于保证系统的连续可用性#xff0c;提高系统的稳定性和可靠性。它可以应对高并发和大规…1. 引言
软件系统有三个追求高性能、高并发、高可用俗称三高。三者既有区别也有联系门门道道很多本篇讨论高可用
高可用技术的重要性在于保证系统的连续可用性提高系统的稳定性和可靠性。它可以应对高并发和大规模负载支持持续交付和快速迭代。实际应用场景涵盖了各个行业和领域关乎到企业的业务运营和发展。
2. 高可用性概述
2.1. 定义
高可用性是指系统能够在面对故障、意外事件或负载增加时保持稳定运行持续提供可用的服务的能力是现代系统设计和架构中的一个重要目标。
2.2. 重要性
高可用性是现代系统设计中的一个重要目标它能够保障业务连续性、提高用户体验、确保数据安全性并增强企业的品牌声誉和用户的信任。在竞争激烈的市场中高可用性对于现代系统的重要性不可忽视。
举个例子用户面对2个系统一个全年不停机、无故障另一个隔三差五出线上事故、宕机用户肯定选择前者
3. 衡量指标
3.1.1. 系统可用性Availability
可用性是衡量系统能够正常运行并提供服务的程度。常用的可用性指标是系统的正常运行时间与总运行时间的比例通常以百分比表示例如99.99%的可用性表示系统每年只有不到1小时的停机时间 其中
MTTF 是 Mean Time To Failure平均故障前的时间即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高MTTF 越长。注意从字面上来说看上去有 Failure 的字样但其实是正常运行的时间。
MTTR 是 Mean Time To Recovery平均修复时间即从故障出现到故障修复的这段时间这段时间越短越好。 业界衡量系统可用性的方式主要有2种
时间纬度的系统可用性。请求纬度的系统可用性。
3.1.1.1. 时间纬度的系统可用性常用
Availability 程序正常运行时间 / (程序正常运行时间 系统故障时间)
时间维度的系统可用性就是我们经常提起的X个9
X个9表示以年/月/日等为单位在指定的时间范围内系统可以正常使用时间与总时间之比。 例如我们以1年为时间单位可以得出
3个9(1-99.9%)365248.76小时表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。4个9(1-99.99%)365240.876小时52.6分钟表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。5个9(1-99.999%)36524*605.26分钟表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
根据如上的定义我们可以总结出一张表格 可用性等级 故障时间以年为单位 故障时间以月为单位 故障时间以日为单位 90% (1-90%)*365天 36.5天 (1-90%)*30天 * 24小时 72小时 (1-90%)*24小时 2.4小时 99% (1-99%)*365天 3.65天 (1-99%)*30天 * 24小时 7.2小时 (1-99%)*24小时 * 60分钟 14.4分钟 99.9% (1-99.9%)*365天 * 24小时 8.76小时 (1-99.9%)*30天 * 24小时 * 60分钟 43.8分钟 (1-99.9%)*24小时 * 60分钟 1.44分钟 99.99% 以此类推 ... ... 99.999% ... ... ...
3.1.1.2. 请求纬度的系统可用性
Availability 成功请求数量 / 请求总数量
3.1.2. 容错性Fault Tolerance
容错性是指系统能够在出现组件故障或异常情况时继续正常运行的能力。评估容错性的指标可以是系统的恢复时间Recovery Time ObjectiveRTO即系统从故障到完全恢复正常运行所需的时间
3.1.3. 可恢复性Recoverability
可恢复性是指系统能够在故障后迅速恢复到正常运行状态的能力。评估可恢复性的指标可以是系统的恢复点目标Recovery Point ObjectiveRPO即系统从故障点到数据和服务完全恢复的时间和数据损失程度。
4. 考虑的因素
4.1. 成本
系统可用性越高对你的系统要求也越高那么你付出的成本和代价也会越高。对于可用性越高的系统那么对于你服务器的存储、网络、软件等要求也就越高。而对于一些服务并不需要达到那么高的可用性因此就可以为这些服务设置较低的可用性目标。
4.2. 业务容忍度
系统可用性也需要考虑业务的容忍度。
对于金融行业服务来说任何一个请求的失败都有可能带来资金的损失因此对于这类的服务对于错误的容忍度是比较低的也就要求系统可用性较高。
对于常用的社交软件而言例如我们使用的评论区功能/弹幕功能对于这些应用来说即使请求一次失败也是 可以接受的下次再请求成功就可以了。因此对于这些业务来说业务容忍度较高系统可用性不要求一定要很高。 高可用架构设计需要在成本和业务容忍度中取得一个平衡
5. 核心设计思想
做好研发规范系统都是研发人员设计和编码写出来的因此首先要对研发层面有一个规范和标准做好容量规划和评估主要是让开发人员对系统要扛住的量级有一个基本认知方便进行合理的架构设计和演进。做好服务层面的高可用主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。做好存储层面的高可用主要是冗余备份热备、冷备、故障转移确认转移恢复等。做好运维层面的高可用主要是发布测试、监控告警、容灾、故障演练等。做好产品层面的高可用主要是兜底策略。做好应急预案主要是在出现问题后怎么快速恢复不至于让我们的异常事态扩大。
6. 常见技术手段介绍
常见的实技术手段包括负载均衡、冗余备份、故障转移、监控和告警和容错设计
6.1. 负载均衡
6.1.1. 简介
将系统的流量均匀地分散到多个服务器或节点上确保每个服务器的负载均衡避免单一节点过载提高系统的性能和可靠性
6.1.2. 负载均衡算法 算法名称 描述 适用场景 轮询 (Round Robin) 请求依次分发给每个服务器按照顺序循环轮询 服务器性能相近、请求量均匀分布 加权轮询 (Weighted Round Robin) 根据权重比例分发请求给服务器 服务器性能不均衡、某些服务器处理能力更强 最少连接 (Least Connection) 将请求发送到当前连接数最少的服务器上确保请求在服务器上的分布均衡 每个连接的处理时间不同 IP哈希 (IP Hash) 根据客户端的IP地址将请求分发给特定的服务器保持会话的连续性 需要保持会话状态或会话一致性的应用程序 最短响应时间 (Least Response Time) 将请求发送到响应时间最短的服务器上根据服务器的平均响应时间选择最快的服务器处理请求 服务器处理能力不同、响应时间差异较大 随机 (Random) 随机选择一个服务器处理请求 请求分布均匀不需要考虑服务器负载差异 哈希 (Hash) 根据请求的特定属性如URL、Cookie等进行哈希计算将相同哈希值的请求分发给同一台服务器保持请求的一致性 需要特定请求的一致性如会话保持 加权最小连接 (Weighted Least Connection) 结合权重和连接数选择连接数最少且权重最高的服务器处理请求 服务器性能不均衡且每个连接的处理时间不同 最短预测延迟 (Least Predicted Delay) 根据服务器的预测延迟选择最快的服务器处理请求 服务器响应时间具有预测性可以根据历史数据进行预测
这些负载均衡算法根据不同的需求和条件提供了各种选择。在设计高可用架构时需要根据系统的特点和负载分布选择合适的负载均衡算法以实现负载的均衡和优化系统的性能。
6.1.3. 常见负载均衡技术
基于硬件的负载均衡这种技术使用专门的硬件设备如负载均衡器来分发流量。负载均衡器通常位于网络前端通过监控服务器的负载情况和性能指标在多个服务器之间均匀地分配请求。硬件负载均衡器具有高性能、高可靠性和高并发处理能力适用于大型系统和高流量环境。基于软件的负载均衡这种技术使用软件来实现负载均衡功能。常见的软件负载均衡器包括Nginx、HAProxy和Apache等。软件负载均衡器可以在应用层或传输层进行负载均衡根据不同的算法如轮询、最少连接数或响应时间来分配请求。它们通常具有灵活的配置选项和易于扩展的特点。基于DNS的负载均衡这种技术通过DNS来实现负载均衡。当客户端发起请求时DNS服务器返回一个与请求相对应的服务器IP地址。通过将多个IP地址与同一域名关联DNS负载均衡可以将请求分发到不同的服务器上。DNS负载均衡具有简单和易于实现的优点但缺点是无法动态调整负载分配。内容分发网络CDNCDN是一种分布式的负载均衡解决方案通过将静态和动态内容缓存在全球各地的边缘节点上来分发流量。当用户请求内容时CDN会根据用户的位置选择最近的边缘节点来提供内容。CDN可以大大减少延迟和带宽使用提高系统的性能和可用性。
6.2. 数据备份
6.2.1. 简介
采用备份服务器、热备份或冷备份等方法将系统的数据和功能复制到备份系统当主系统发生故障时可以快速切换到备份系统保证系统的连续性和可用性
6.2.2. 具体方案
在高可用性架构中常见的数据备份方式包括热备份和冷备份
热备份Hot Backup 热备份是在系统正常运行期间进行的数据备份。它基于实时或定期的备份策略将数据实时复制到备用存储设备中确保数据的冗余性和可靠性。在系统故障或灾难发生时可以快速切换到备份设备并迅速恢复数据减少系统的停机时间和数据丢失风险。冷备份Cold Backup 冷备份是在系统停机或处于非活动状态时进行的数据备份。它涉及到备份整个系统或关键数据通常在系统维护窗口期间进行。冷备份能够提供完整和一致的备份数据但恢复时间较长需要系统重启和数据导入。 相对于热备份而言冷备份的备份过程对正常的数据源操作有较小的影响。当主要数据源发生故障时需要将备份数据还原到备用设备上然后再将服务切换到备用设备上因此冷备份的恢复过程可能需要一些时间。
6.3. 故障转移
6.3.1. 简介
在高可用架构设计中故障转移技术起着至关重要的作用。它可以帮助系统实现快速的故障检测和转移从而减少系统停机时间提高系统的可用性和可靠性
6.3.2. 常见的故障转移技术
心跳监测心跳监测是一种基本的故障检测和转移机制。它通过周期性发送心跳信号来监测主节点的可用性。备用节点会监听这些心跳信号一旦检测到主节点失效就会接管主节点的工作负载。这种机制通常用于主备模式的故障转移。故障切换故障切换是一种手动或自动触发的故障转移机制。当主节点发生故障时管理员可以手动切换到备用节点。自动故障切换则是通过监控和自动化工具实现的当监测到主节点故障时自动将工作负载迁移到备用节点上。负载均衡器负载均衡器是一种常用的故障转移技术。它通过将请求分发到多个服务器上以均衡系统的负载。当某个服务器发生故障时负载均衡器会自动将请求重定向到其他可用服务器上确保服务的连续性和可用性。数据复制和同步数据复制和同步是一种常见的故障转移技术特别适用于数据库和存储系统。通过将数据实时或定期复制到备用设备上并保持同步一旦主节点发生故障备用节点可以接管数据服务保证数据的可用性和一致性。容器编排技术容器编排技术如Kubernetes提供了故障转移和容灾功能。它可以自动监测和管理容器集群中的节点和服务一旦发现节点故障或服务失效会自动转移工作负载到其他健康节点确保应用的连续运行。
6.4. 监控和告警
6.4.1. 简介
监控和告警是保障高可用性的守护者它们可以无时无刻地监测系统的脉搏发现潜在的问题和异常情况并在关键时刻发出警报以便及时采取行动确保系统始终保持稳定和可用。
6.4.2. 具体方案
定义关键指标和阈值确定系统的关键指标和性能指标如服务器负载、响应时间等并为每个指标设置适当的阈值。阈值应该根据系统需求和性能标准进行定义超过阈值时触发告警。选择合适的监控工具和系统根据系统的特点和需求选择适合的监控工具和系统。常见的监控工具包括Prometheus、Nagios、Zabbix等。确保监控工具能够实时收集和展示关键指标的数据并提供告警功能。配置监控项和告警规则在监控工具中配置监控项和告警规则。设置监控项以收集系统指标和性能数据同时设置告警规则根据阈值和异常条件触发相应的告警通知。设置告警通知方式选择适当的告警通知方式确保相关人员能够及时收到告警信息。常见的告警通知方式包括电子邮件、短信、即时通讯工具等。确保告警通知能够及时传达给相关人员以便他们能够快速响应和处理问题。告警响应和故障处理设立明确的告警响应流程确保接收到告警后能够及时响应和处理。指定责任人和相应的行动计划确保故障能够在最短的时间内得到处理和解决。持续优化和演进定期回顾和评估监控和告警系统的效果并根据实际情况进行调整和优化。根据系统的演化和需求变化不断改进监控策略和配置以确保系统的高可用性和稳定性。
6.5. 容错设计
6.5.1. 简介
任何服务一定会存在失败的情况不可能有 100% 的可用服务在线上运行过程中总会遇到各种各样意想不到的问题会让你的服务出现状况。为此我们的设计建议遵循design for failure的设计原则设计出一套可容错的系统需要做到尽早返回、自动修复
6.5.2. 核心思想
遵循 fail fast 原则 Fail fast 原则是说当我们的主流程的任何一步出现问题的时候应该快速合理地结束整个流程尽快返回错误而不是等到出现负面影响才处理。具备自我保护的能力 当我们依赖的其他服务出现问题的时候要尽快的进行降级、兜底等各种异常保护措施要避免出现连锁反应导致整个服务完全不可用。比如当我们依赖的数据存储出现问题我们不能一直重试从而导致数据完全不可用
6.6. 其他
相关技术很多诸如 限流、降级、熔断、预案、回滚、超时与重试...在此不在展开 7. 总结
高可用架构设计需要综合运用多种技术和策略以实现系统的高可用性和可靠性。根据具体的需求和场景选择和结合合适的技术能够有效地提升系统的性能、可用性和容错性确保持续的业务运行。
