云上高可用架构
业务的持续稳定可服务,决定着企业对客户的服务质量,是企业发展的基础。然而系统总会面临各种故障风险,高可用性(High Availability, HA) 设计的核心,就是通过消除单点故障,确保系统在局部受损时仍能持续提供服务。本方案从企业上云最基础的需求出发,介绍如何在云端逐层构建稳健的高可用架构,帮助你建立系统性的高可用设计认知。
适用客户
有处理高并发请求的业务场景
需要实现业务的快速扩展和灵活管理
对服务连续性和数据完整性有高要求
业务面临的稳定性挑战
企业在业务发展初期,单点架构是一种常见的部署架构,满足业务基本需要,通常是由一台服务器、一个单节点数据库组成,但是这样的简单架构,面临着一些隐患:
可靠性与稳定性
单一节点故障,整个业务系统将不可用。这是单节点架构中最明显、最致命的风险。缺乏业务服务的冗余、故障转移等容灾能力。
性能与弹性
应用系统的服务能力受限于单一节点的性能,存在性能瓶颈。扩容时可能面临成本高、周期长、服务中断等多重问题。
运维与管理
当对单节点进行维护或升级时,可能面临停机停服问题。每台独立机器保持独立的公网入口,安全策略统一管理困难。
如何提升业务稳定性
应对上述挑战的核心思路,是通过冗余消除单点依赖,让系统的任何一个局部故障都不会导致整体不可用。实现这一目标需要以下关键机制:
冗余
关键组件不能只有一份,任何单点都可能成为故障点
健康检测
系统需要持续感知每个组件的状态,才能及时发现故障
自动故障转移
发现故障后必须能自动切换,依赖人工响应会大幅延长中断时间
方案优势
架构方案对比
相比传统自建架构在成本、运维、稳定性上的固有局限,阿里云高可用架构通过弹性伸缩、自动容灾、跨可用区部署等能力,全面降低企业上云门槛与风险。
传统自建架构
阿里云高可用架构
硬件需要一次性投入大量设备与建设成本
异地容灾成本高昂,无弹性扩容能力,性能与可靠性依赖硬件,架构扩展或升级困难,维护成本高。
成本
支持弹性伸缩和按需扩展
基于业务用量变化自动弹性,无需人工介入,增强安全、性能、管理等方面能力。
软件技术方案复杂,维护成本高
需要专业的开发、测试、运维团队来保持架构的更新迭代。
运维
支持跨可用区容灾和产品自动更新
故障自动恢复,无需人工介入;自带多种监控管理,运维专家 7*24 小时在线服务。
可靠性不足
应用系统的服务能力受限于单一节点的性能,存在性能瓶颈。单一节点故障,整个业务系统将不可用。
稳定性
稳定性高
ECS 多可用区多实例可用性可达 99.995%,云数据库 RDS MySql 高可用系列可用性可达 99.95%。
可用区级高可用:应用层
应对单台服务器故障、单个机房(可用区)整体不可用等情况,这是绝大多数业务必须达到的基础高可用级别。
![]()
多实例冗余与负载均衡
通过“多实例冗余 + ALB 负载均衡 + 跨可用区部署”的组合,在应用层实现自动化的故障隔离和流量切换,详见本方案的部署实践
![]()
应用无状态化
将所有可变状态从应用服务器中剥离,存入外部独立的、可被所有实例共享的存储服务中
![]()
弹性伸缩
弹性伸缩让系统既能在高峰期保证服务质量,又能在低谷期节约成本,是高可用与成本优化的结合点
可用区级高可用:数据层
应用层实现冗余后,数据层的高可用同样不可忽视——数据是业务的核心,一旦丢失或不可访问,比应用宕机更加致命。数据通常分为两类,需要针对性地选择存储方案。
![]()
结构化数据
用户信息、订单记录等结构化数据,存储在云数据库 RDS 中,通过主备架构实现高可用:主节点发生不可恢复故障时,系统自动触发主备切换,无需人工干预,对应用透明
![]()
非结构化数据
图片、视频、文档等非结构化数据,在应用无状态化改造中将其迁移至 OSS,通过多重副本机制保证数据持久性,同时选择同城冗余存储获得可用区级高可用保障
![]()
缓存层
将用户会话迁移到高性能分布式缓存 Tair,任何一台 ECS 处理请求时都通过访问同一个 Tair 实例获取或更新用户状态
方案优势
地域级容灾与高可用
![]()
主备容灾
在生产地域部署生产环境,在灾备地域部署备用环境。正常情况下,备用环境只接收数据同步(数据传输服务DTS同步结构化数据,OSS跨区域复制实现非结构化数据的跨地域冗余),不处理任何业务请求。灾难发生时,将备用系统激活,手动修改 DNS 记录,或通过全局流量管理 GTM 自动触发切换,在分钟至小时级别内恢复业务。
![]()
两地三中心
金融等对稳定性要求极高的行业中常见的增强型架构,本质上是将同城高可用与异地主备容灾分层叠加。生产地域:业务系统同时部署在两个不同可用区,构成能自动抵御单机房故障的同城高可用集群(两中心);灾备地域:部署一套与上海生产环境保持数据同步的异地灾备中心(一中心)。
![]()
异地多活
多地域同时部署完整的生产环境,并同时处理真实业务请求,不再有主备之分。GTM 根据用户地理位置和网络延迟,将请求路由到最优地域。当某个地域发生故障时,GTM 自动将其从地址池中移除,用户流量自然流向其他健康地域,整个过程对用户无感知,从而实现地域级故障的自动切换。
可观测的高可用架构
构建了冗余架构,并不意味着高可用就万事大吉。设想这样一个场景:所有实例都在运行,ALB 健康检查全部通过,但数据库连接池已悄悄耗尽,99% 的用户请求正在超时失败——而你对此一无所知。可观测性是高可用体系不可缺少的组成部分,它让你在故障演变为用户可感知的中断之前提前告警,在故障发生时快速定位问题所在层级与组件,并通过历史数据持续识别系统薄弱环节,有针对性地优化。
![]()
指标(Metrics)与告警
在应用层(ALB 请求成功率、响应时间、ECS CPU/内存)、数据层(RDS 连接数、慢查询、主备同步延迟,Tair 内存使用率、命中率)和业务层(订单量、支付成功率等核心指标)分别采集关键指标并设置告警阈值,实现全链路监控覆盖。
![]()
链路追踪(Tracing)
当一个请求需要经过 ALB → ECS → Tair → RDS 多个组件时,ARMS 应用性能监控能够将这条请求的完整调用链路可视化,精准定位是哪个环节耗时过长或发生了错误,将故障定位时间从小时级缩短到分钟级。
![]()
日志(Logs)
将所有实例的应用日志、访问日志集中采集到日志服务(SLS),避免实例故障后日志丢失,同时支持跨实例的日志搜索和分析,为故障复盘和安全审计提供完整的现场记录。
架构与部署
云上高可用架构部署实践
2785364
用户访问应用时,DNS 会将访问请求解析至负载均衡 SLB (本文使用 ALB )的服务地址。负载均衡作为应用的统一入口,会基于对 ECS 的健康检查和负载策略,将请求分发至后端服务器组内的 ECS 。当一台 ECS 宕机或故障时,负载均衡会检测到其不可用状态,并将流量转发至另一台处于可用状态的 ECS ,保障业务可以正常访问,实现了服务的高可用。
35 分钟
20 元(假设您选择的云资源与建议规格一致,为按量付费,开通 CDT 获得公网流量免费额度,方案过程中产生流量在 20GB 以内。且体验时长不超过 24 小时。域名、证书、备案费用不包含在内。实际产生费用因规格、版本不同可能产生变化,以控制台显示为准)
负载均衡云服务器 ECS云数据库 RDS MySQL 版
应用场景
技术方案的广泛应用场景

企业关键应用
如 ERP(企业资源规划)、CRM(客户关系管理)和 BI(商业智能)系统,这些是企业运营的核心,需要高可用性保障。

电子商务平台
电网平台往往要求 24/7 不间断运行,以处理用户的订单、支付和查询等,高可用性至关重要。
免费试用
阿里云为您提供云产品免费试用
986754
10000011871
10000009092
推荐解决方案