应用为什么需要高可用？随着计算机科学及互联网技术的蓬勃发展，互联网电商、金融、云计算、地图导航等逐步成为了社会的基础设施。这类业务的线上生产事故除了危害业务自身的稳定运行要求，同时也会影响广大用户的正常使用，及特殊情况下可能会对用户和商业伙伴造成难以挽回的损失。因此高可用性是现代系统设计中的一个重要目标，它能够保障业务连续性、提高用户体验、确保数据安全性，并增强企业的品牌声誉和用户的信任。在竞争激烈的市场中，高可用性对于现代应用系统的重要性不可忽视。
应用的高可用如何衡量？应用的高可用是通过可用性指标来衡量的。可用性指标用来衡量系统能够正常运行并提供服务的程度。常用的可用性指标是系统的正常运行时间与总运行时间的比例（通常以百分比表示），例如，99.99%的可用性表示系统每年只有不到1小时的停机时间。
可用性的计算公式为 [ MTBF/（MTBF + MTTR）] * 100。
MTBF 是 Mean Time Between Failure，平均故障前的时间，即系统的正常运行时间，或者可以理解为系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTBF 越长。
MTTR 是 Mean Time To Recovery，平均修复时间，即从故障出现到故障修复的这段时间，这段时间越短越好。
高可用和容灾的区别是什么？应用的高可用性（High Availability, HA）和容灾（Disaster Recovery, DR）是确保业务连续性的两个重要概念，在功能和目的上它们既有联系也有区别。
高可用性关注的是减少应用系统停机时间，确保业务服务能够在正常情况或轻微故障情况下持续运行。高可用性通常通过在应用系统设计中实现冗余来达到，包括硬件冗余、软件冗余、负载均衡、故障转移等技术。其目标是在发生故障时能够迅速恢复服务，通常在几秒钟到几分钟内。
高可用性系统的核心特征包括：
最小化单点故障：通过设计多个冗余组件来避免单个组件的故障导致整个系统的不可用。
快速故障恢复：在检测到故障时，系统能够快速自动切换到备用系统或组件，以保证服务不间断。
实时性和透明性：故障转移和恢复对用户来说应尽可能的无感知。
系统发生故障其实是不可避免的，尤其是规模越大的系统，发生问题的概率也越大。这些故障一般体现在 3 个方面：
硬件故障：CPU、内存、磁盘、网卡、交换机、路由器
软件问题：代码 Bug、版本迭代
不可抗力：地震、水灾、火灾等
这些风险随时都有可能发生。所以，在面对故障时，我们的系统能否以最快的速度恢复，就成为了可用性的关键。而容灾则正是指在硬件问题、软件问题或是灾难发生而引发故障时，我们业务快速恢复并继续运行的能力。
容灾的目的是保证应用系统的连续性和稳定性，减少因系统故障或灾难造成的损失。设计容灾系统时的基本假设是发生故障的机房无法立即恢复，需要将数据和服务转移到另一个机房。容灾系统一般在较远的异地，建立多套功能相同的系统，系统间可以进行切换，某一处因意外发生故障时，可以快速切换实现恢复。容灾能力的两个评价指标为：
RTO（Recovery Time Objective）：即恢复时间目标。在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求，以时间为单位。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。
RPO（Recovery Point Objective）：即数据恢复点目标。在灾难发生时，系统和数据必须恢复的时间点要求，以时间为单位。RPO标志系统能够容忍的最大数据丢失量。系统容忍丢失的数据量越小，RPO的值越小。
如何实现应用高可用？应用实现高可用的关键是最大程度上降低故障发生概率，降低故障发生后的影响面。高可用建设追求的是要通过故障管理手段与技术架构设计手段的持续提升做好风险的防范。
故障管理故障管理可以从事前故障预防、事中故障处置、事后故障复盘三个维度实现。
事前故障预防
执行线上变更时（包括新功能发布），需要满足可观测、可灰度、可回滚的要求，旨在快速识别风险，降低风险转换成故障的可能性。如果已经发生故障，可以有效地控制故障影响面。
事中故障处置
通过1（1分钟发现）、5（5分钟响应）、10（10分钟处置）指标作为牵引，可快速发现并恢复故障，有效降低故障发生后的影响面。
事后故障复盘
故障复盘需要从流程机制层面、质量检验层面、产品业务层面、系统设计层面提出5个为什么？即：为什么会发生？为什么没有验证发现？有没有防御机制？如何避免再次发生？有没有改进点？并提出改进点，制定对应策略与解决方案，旨在避免已发生的同类型故障重复发生。
技术架构应用的技术架构可以从容量管理、容错管理、容灾管理三个维度实现。
容量管理
全链路压测：全链路压测通过在生产环境对业务大流量场景进行高仿真模拟，获取最真实的线上实际承载能力、执行精准的容量规划，确保系统可用性。
流量控制：流量是非常随机性的、不可预测的。前一秒可能还非常平稳，后一秒可能就会出现流量洪峰（例如双十一零点的场景）。然而我们系统的容量总是有限的，如果突然而来的流量超过了系统的承受能力，就可能会导致请求处理不过来，堆积的请求处理缓慢，CPU/Load 飙高，最后导致系统崩溃。因此，我们需要针对这种突发的流量来进行限制，在尽可能处理请求的同时来保障服务不被打垮。
容错管理
负载均衡：负载均衡是一种常用的故障转移技术。它通过将请求分发到多个服务器上，以均衡系统的负载。当某个服务器发生故障时，负载均衡器会自动将请求重定向到其他可用服务器上，确保服务的连续性和可用性。
熔断&降级：一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。例如，支付的时候，可能需要远程调用银联提供的 API；查询某个商品的价格，可能需要进行数据库查询。然而这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长，线程会产生堆积，最终可能耗尽业务自身的线程池，服务本身也变得不可用。对不稳定调用熔断可以暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩，对于一些弱依赖的服务（非关键链路依赖），可以在活动前或资源紧张时进行动态降级，以优先保障重要服务的稳定性。
开关&预案：各种有风险的业务或者模块上线的时候可以加上开关，关键时刻可以手工关闭功能。
超时设置：设置恰当的网络超时时间，可以有效地保障系统调用者不被临时性故障拖垮。
依赖治理：减少系统间的强依赖，如对实时性要求不高的高并发业务，可尝试使用异步消息解耦系统间的强依赖。在系统设计阶段要避免核心系统强依赖非核心系统，针对弱依赖系统注解捕获异常。
容灾管理
容灾是指在系统发生故障或灾难时，能够及时恢复系统的能力。容灾的目的是保证系统的连续性和稳定性，减少因系统故障或灾难造成的损失。
主流容灾架构对比如下表。
名称
主要特征
优势
劣势
同城主备
备机房不接收业务流量
数据库单点写，同城备份
部署简单。
业务侵入极少。
冷备资源浪费。
由于冷备机房平时不接收业务流量，无法确认冷备机房部署的应用数量与应用部署的代码版本是否和主机房一致，所以在主机房出现故障后，无法切流到冷备机房来保证业务的连续性。
同城多活(DB主备)
应用机房级多活
数据库单点写，同城备份
部署简单、业务侵入极少。
可以实现同城机房级容灾。
存在数据资源瓶颈。
无法抵御地域级灾难。
异地灾备
备数据中心不接收业务流量
数据库单点写，异地备份
部署简单、业务侵入少。
异地数据容灾。
冷备资源浪费。
由于冷备机房平时不接收业务流量，无法确认冷备机房部署的应用数量与应用部署的代码版本是否和主机房一致，所以在地域级机房出现故障后，无法切流到冷备机房来保证业务的连续性。
两地三中心
同城多活(DB主备)和异地灾备结合的方案
应用机房级多活
备数据中心不接收业务流量
数据库单点写，异地备份
部署简单，业务侵入少。
同城机房容灾，异地数据容灾。
冷备资源浪费。
由于冷备机房平时不接收业务流量，无法确认冷备机房部署的应用数量与应用部署的代码版本是否和主机房一致，所以在地域级机房出现故障后，无法切流到冷备机房来保证业务的连续性。
异地多活
应用地域级多活
数据库多点写，地域级多活，无单点瓶颈
多数据中心同时对外提供服务
异地业务级容灾，常态化切流。
容量水平扩展。
部署复杂。
业务侵入高。
阿里云如何帮助您实现应用高可用？产品和服务阿里云产品
应用场景
描述
微服务治理
全链路灰度
无损上下线
熔断降级
微服务治理可以帮助企业消除变更过程中的风险，消除偶发问题引发的风险和低成本实现微服务敏捷开发，全面增强微服务线上稳定性和提升研发效率。
云原生网关
负载均衡
故障转移
重试
安全防护
超时设置
云原生网关是兼容K8s Ingress标准的下一代网关产品，将传统的流量网、微服务网关和安全网关的功能合并，降低50%资源开销，支持ACK容器服务和Nacos等多种服务发现方式，支持多种负载均衡策略，支持主动健康检查实现故障转移、支持多种认证登录方式快速构建安全防线。
微服务配置中心
开关&预案管理
微服务配置中心提供微服务运行时的动态配置能力。动态配置可以让用户以中心化、外部化和动态化的方式管理所有环境的应用配置，消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
应用实时监控服务 ARMS
Java 应用监控
Web 应用、小程序监控
告警管理
作为云原生可观测平台，应用实时监控服务 ARMS 轻松实现全栈性能监控告警与端到端追踪诊断，能够覆盖浏览器、小程序、APP 等客户端环境及分布式、微服务等应用架构，容器、Serverless 等部署环境，实现全栈应用性能与用户体验的洞察与优化。
可观测监控 Prometheus 版
容器监控
云服务监控
多云监控
作为云原生指标监控平台， 可观测监控 Prometheus 版完整兼容 Prometheus 生态，满足业务、应用组件、云服务、容器、基础设施等场景的监控告警需求。
性能测试 PTS
容量规划
服务验证
性能测试
性能测试 PTS 作为一款集性能压测、监控与分析于一体的一站式服务平台，模拟百万规模并发用户访问，对各类应用程序、网站、API 等进行深度性能评估和优化。它提供一站式操作界面与流程管理，降低性能测试的复杂性和门槛，通过提供智能化分析功能，能够自动识别和诊断性能问题，更轻松全面地评估系统负载承受能力与响应速度。
最佳实践实践场景简述
具体描述
相关文档
云原生网关实现同城多活最佳实践
云原生网关默认采用多可用区部署，提供了地域级的、跨可用区的全局流量管理能力。在同城多活的场景下，能够确保对跨可用区的多个业务集群的请求实现高效负载均衡分配，在单个可用区内的业务集群发生故障时，可在1秒内完成故障节点的自动摘除从而实现故障转移，有效的保障服务连续性和高可用性。
基于MSE云原生网关实现同城多活
15分钟完成服务治理能力快速体验
通过DEMO，提供服务治理的全链路灰度、无损上下线、流量防护等核心功能的手把手快速体验。
15分钟完成服务治理能力快速体验
Java 应用监控
尝试分布式、微服务化，缺乏 Java 应用性能监控、Trace 调用链分析
希望对错、慢、异常等进行分析排查，重现调用参数、发现系统瓶颈，且能够持续性能剖析，查找代码热点。
接入 Java 应用监控
.NET、Go、PHP、C++等多语言应用监控
在缺乏多语言应用性能监控的情况下，开始希望对错、慢、异常等进行分析排查，重现调用参数、发现系统瓶颈。
接入多语言应用监控
容器监控、云服务监控
基于应用服务进行容器化改造，需对容器服务进行监控。
购买了各种云服务，不想来回切换控制台进行日常巡检，想要进行统一的云产品监控。
自建 Prometheus 受到日常维护、资源消耗、系统性能等问题困扰。
接入 Prometheus 监控
性能测试
互娱、游戏、社交的用户活动、电商促销、秒杀活动需要实时监测服务运行状况，保障业务稳定性。为了应对未知规模流量，或新系统上线未充分规划、经常宕机，配合性能测试 PTS 压测，想要定位系统瓶颈，为产品优化提供依据。
快速创建压测