云原生高可用技术体系的构建

本文涉及的产品
性能测试 PTS,5000VUM额度
注册配置 MSE Nacos/ZooKeeper,118元/月
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: 原来单一的技术环境开始走向分布式、分层的多组件技术架构,越来越多的组件使得保障业务稳定运行的工作也越来越艰巨。本文从容灾、容量、线上防护、演练四个维度全方位讲解如何构建一个真正的高可用体系。

QzpcVXNlcnNc576O5LmfXEFwcERhdGFcUm9hbWluZ1xEaW5nVGFsa1wzODk0MTg4MTBfdjJcSW1hZ2VGaWxlc1wxNTk1MjEzNTY3MzkxXzg3MDA1MjdGLTE0MjItNDVlMy05ODE5LUI5NjVDMjJBODc3Ny5wbmc=.png
伴随着互联网业务的高速发展,越来越多的线下场景需要转移到线上,而线上业务的量级也在飞速增长,给互联网业务的技术架构带来了严峻的挑战,原来的“一体机+数据库”的方式已经不适用于当前的主流业务,越来越来的业务开始向分布式架构和云原生架构演进。同时,原来单一的技术环境开始走向分布式、分层的多组件技术架构,越来越多的组件使得保障业务稳定运行的工作也越来越艰巨。

一、容灾

航空系统的容灾体系做得非常优秀。航空系统的容灾体系从人、飞机和环境三个维度来考虑,才能构建一套优秀的容灾方案。

从人的维度,以防万分之一的紧急情况出现的可能,每年要进行多次的模拟机训练或者实景演练。一架飞机上都会配备至少两名飞行员,二者相互合作的同时也要相互监督。

从飞机的维度,每一个航段前,光是一个绕机检查可能就有几十个项目需要检查。机检查是由地面机务人员和飞行机组分别完成,同样也是为了更仔细的检查,降低错误率。每架飞机还有短期全面检查和长期全面检查,飞机上的每一个设备都是独立的双系统在工作。

从环境的维度,气象雷达可以让飞行员感知到几十甚至几百海里范围内的天气情况。飞机防撞系统可以让飞行导航显示仪上显示正在接近的可能存在威胁的飞机。盲降系统是由地面发射的两束无线电信号实现航向道和下滑道指引,飞机通过机载接收设备,进行降落。

从航空业的容灾体系构建中我们可以发现,容灾的核心思想是基于隔离的冗余。在系统设计中,其实也经常用到冗余的机制,比如机器经常是多台、数据是多备份等。容灾的评价指标主要有两个:
一是RPO(Recovery Point Objective),即数据恢复点目标,以时间为单位,即在灾难发生时,系统和数据必须恢复的时间点要求。
二是RTO(Recovery Time Objective),即恢复时间目标,以时间为单位,即在灾难发生后,信息系统或业务功能从停止到必须恢复的时间要求。RTO标志着系统能够容忍的服务停止的最长时间,系统服务的紧迫性要求越高,RTO的值越小。

1. 业界主流容灾方案

如下图所示,业内主流的容灾方案最早是异地冷备的方式,后来演进到同城双活方式,最后发展成为“两地三中心”。
image.png

业界主流容灾方案

2. 阿里AHAS

阿里AHAS容灾方案使用的是比“两地三中心”更前沿的“异地多活”方案,在所有的数据中心都能提供服务的同时,RPO和RTO能做到分钟级甚至秒级。下图是阿里AHAS的产品形态。AHAS在2013年之后就开始大规模在阿里内部使用,并且作为高可用平台的一个核心模块,开始服务外部客户。AHAS通过异地多活,能够真正做到对于宏观架构的容灾,并抵御大规模的失败场景。比如一个城市的机房出了故障,可以很轻易地把流量实时切换到另外一个机房。
image.png

AHAS异地多活的产品形态

二、容量

在互联网业务下,流量的不确定性非常明显,经常会出现流量高峰事件,比如微博的热点、阿里的双11、12306的火车票放购等事件。在这种场景下,如何做好容量规划就变得至关重要。

1. 压测

传统的压力测试通常关注的是性能的好坏,这是一个相对模糊的概念,不需要很精准。但是在互联网的情况下, 我们需要精准地获取到一个系统的实时吞吐量,以便更好地应对突发事件。在这种情况下,压测要尽可能地模拟一个真实的环境,而不能像以往一样,在一个额外的环境去测试。压测时在流量规模、流量模型、系统环境上都需要一个尽可能真实的环境,这样才能精准做好容量规划。

传统的压测工具虽然仍在发挥作用,但是随着互联网的发展,已经越来越不能去适应互联网技术的迭代。互联网的压测有几个明显的特点:
强调流量的真实性;
压测规模要足够大;
必须简单易用,交互式压测。

当下互联网压测已经变成了一个实时的产品,方便进行实时的调控。基于这样的背景,阿里构建了基于PTS的流量引擎,大家可以在阿里云上直接使用,其特点如下:
流量真实。流量来源于全国上百城市,覆盖各运营商(可拓展至海外),真实模拟最终用户的流量来源,相应的报表、数据更接近用户真实体感;发现端到端更多更全面的问题,压测即是模拟考。
压测规模强大,可支持3kW QPS。
简单易用,门槛低。复杂场景的全可视化编排,支持自定义编排能力、指令、控制、函数等相关能力,覆盖95%以上的HTTP压测场景,和JMeter构建能力不相伯仲,同时免去复杂的理解学习成本;除了自身丰富的客户侧监控数据,还可集成云监控和ARMS监控。压测过程提供日志明细查询,配套有请求瀑布模型,压测之后的报告和问题定位更方便。结合AHAS可额外提供流量吞吐控制能力、容量水位管理、熔断降级保护功能。除了强大的自研功能,对于开源JMeter的支持也很友好,支持JMeter脚本转化为PTS压测,同样支持原生JMeter引擎进行压测。

2. 全链路压测

在实践中发现,单系统单应用的压测与真实场景之间的误差非常大,因为在压测的时候无法验证整个系统的方方面面,而且很多问题只有在真正的大流量场景下才会暴露,所以要进行全链路压测,其核心是希望未来的事件能够提前到在当前时间内发生,能够用最真实的场景来端对端的验证系统的能力和稳定性。

为了实现更好地进行全链路压测,阿里云提出了基于PTS的全链路压测解决方案,其架构如下图所示。
image.png

基于PTS的全链路压测

从压测环境、压测基础数据、压测流量(模型、数据)、流量发起和问题定位对基于PTS的全链路压测解决方案总结如下:
压测环境:对应真实的线上环境,压测结果和问题暴露都是最真实的情况,可通过压测流量全局识别、透传(影子表),或者等比隔离环境,或复用生产库(压测使用测试数据),业务挡板。
压测基础数据:构造满足大促场景的核心基础相关数据(如买家、卖家、商品信息),以线上数据为数据源,进行采样、过滤和脱敏,保持和线上一个量级。
压测流量(模型、数据):链路范围、访问量级、参数集合、基础数据的特性一起构造压测的业务模型,和真实业务情况保持一致。
流量发起:模拟全国各地真实的用户请求访问,探测站点能力。
问题定位:发起侧多维度的监控和报表,服务端可通过其他生态产品协助定位。

三、线上防护

线上防护对于系统高可用来说是一个非常重要的环节。随着分布式技术的应用,节点越来越多,技术越来越复杂,出错的机会也相对增大。同时,在互联网的条件下,业务的发布也越来越频繁。在互联网的环境下,系统随时面临一些不确定事件、流量冲击等,不能奢望每次出现故障的时候都有人工来干预,而是需要系统自身有一定的防护能力,能够让自身在任何环境下都能有最佳的工作状态。

1. AHAS流量防护

阿里云将流量防护广泛应用于各种场景,比如双11峰值流量、秒杀活动、物流、订单处理、商品查询、付款等。同时,阿里云也成功地将流量防护能力融合到了云产品AHAS(Application High Availability Service,应用高可用服务)中。AHAS涵盖了阿里巴巴多年来在应用高可用服务领域的技术沉淀,包括架构感知、流量防护、故障演练和功能开关四大独立的功能模块。如下图所示,AHAS构建了一个从入口到最后端的一个完整的防护体系。
image.png

AHAS经典流量防护布局

2. AHAS针对大流量场景的保护措施

流量防护首先需要考虑的是对大流量场景的保护,比如url、服务提供方、重点业务等,突然出现超乎预期的大流量,基于AHAS可以做如下防护措施:
(1)如果有性能压测,可以精准设置QPS阈值。有了QPS阈值,可以用来限流,避免出现超负载的流量。
(2)如果没有性能压测,也可以通过秒级监控,实时设置阈值。
(3)支持高阶功能:流控模式支持直接、关联、链路,流控方式支持快速失败、Warm UP、排队等待。

3. AHAS针对不同场景的措施——异常隔离

在特定未知的场景下,可能出现不稳定的因素,如慢SQL,甚至死锁,导致整个应用越来越慢,甚至整个应用没有响应,这时候要对异常流量进行隔离,以免影响到正常的流量。

4. AHAS针对不同场景的措施——系统防护

在某些场景下,比如系统的负载CPU飙升,系统没有反应,无法确认具体哪个接口导致问题的出现,这时AHAS提供了一个终极大招:系统保护。系统保护就是当系统负载比较高的时候,会自动根据入口流量和系统的负载取得一个动态的平衡,保证系统不会恶化的同时,也能处理最大的入口请求。在这种情况下,系统对各种流量都是平等的,无法设置流量的优先级。

四、演练

很多故障是一个小概率事件,但是一旦发生,所造成的损失是不可估量的,比如巴黎圣母院的火灾。互联网业务也是一样,小概率的故障也可能带来不可挽回的经济损失,甚至是法律风险。因此,故障演练是一个完备的容灾体系所必需进行的一步。

1. 企业为什么需要做故障演练?

如果一个业务系统的流量很小且趋于稳定,就没有必要进行故障演练。但是如果一个企业处于高速发展中,业务发展快,有大量的稳定性技术债,其业务系统不断的变化,甚至今天的形态跟昨天的形态都不一致,架构也日益复杂,那么故障演练就是十分必要且必需的。因为每个环节的不确定因子都是累积的,如果不进行故障演练,最后一旦发生故障,极大可能会对系统造成严重破坏。故障演练还可以培养企业人员的故障处理经验,增强人员的应急能力。

2. 企业引入故障演练遇到的常见问题

在企业进行故障演练的时候,经常会遇到一些问题,比如如何设计组织架构,如何选择技术方案,如何落地演练实践等。如果业务牵涉到资金,就要做一个清晰化的深层评估,不要因为演练导致出现资金上的亏损,比如在演练中用到的收费内容(例如短信等)要考虑周全。

3. 阿里的故障演练方案

如下图所示,阿里有一套完整的故障演练方案。一开始是通过一些工具或者脚本,在2016年之后才开始将通用的故障模式沉淀为系统。2018年阿里将内部沉淀多年的实践正式在阿里云商用,2019年将沉淀多年的故障注入场景正式开源,成为国内首个混沌工程开源产品。
image.png

阿里故障演练历程

4. AHAS故障演练

AHAS故障演练的产品架构如下图所示,其定位是一款简单、安全、低成本的故障演练工具,能够帮助用户快速实施演练并发现问题。

相关文章
|
1月前
|
消息中间件 存储 Cloud Native
云消息队列 Kafka 版 V3 系列荣获信通院“云原生技术创新标杆案例”
2024 年 12 月 24 日,由中国信息通信研究院(以下简称“中国信通院”)主办的“2025 中国信通院深度观察报告会:算力互联网分论坛”,在北京隆重召开。本次论坛以“算力互联网 新质生产力”为主题,全面展示中国信通院在算力互联网产业领域的研究、实践与业界共识,与产业先行者共同探索算力互联网产业未来发展的方向。会议公布了“2024 年度云原生与应用现代化标杆案例”评选结果,“云消息队列 Kafka 版 V3 系列”荣获“云原生技术创新标杆案例”。
|
2月前
|
Cloud Native
邀您参加云原生高可用技术沙龙丨云上高可用体系构建:从理论到实践
云原生高可用技术专场,邀您从理论到实践一起交流,探索云上高可用体系构建!
|
2月前
|
运维 Cloud Native Serverless
Serverless Argo Workflows大规模计算工作流平台荣获信通院“云原生技术创新标杆案例”
2024年12月24日,阿里云Serverless Argo Workflows大规模计算工作流平台荣获由中国信息通信研究院颁发的「云原生技术创新案例」奖。
|
2月前
|
人工智能 Cloud Native 大数据
DataWorks深度技术解读:构建开放的云原生数据开发平台
Dateworks是一款阿里云推出的云原生数据处理产品,旨在解决数据治理和数仓管理中的挑战。它强调数据的准确性与一致性,确保商业决策的有效性。然而,严格的治理模式限制了开发者的灵活性,尤其是在面对多模态数据和AI应用时。为应对这些挑战,Dateworks进行了重大革新,包括云原生化、开放性增强及面向开发者的改进。通过Kubernetes作为资源底座,Dateworks实现了更灵活的任务调度和容器化支持,连接更多云产品,并提供开源Flowspec和Open API,提升用户体验。
|
2月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
2月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
82 3
|
3月前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。
|
2月前
|
Cloud Native 持续交付 云计算
云原生架构的崛起:企业数字化转型的加速器
在当今快速发展的技术环境中,企业正面临着前所未有的变革压力。本文深入探讨了云原生架构如何成为推动企业数字化转型的关键力量。通过分析其核心概念、优势以及实施策略,本文旨在为读者提供对云原生技术的全面理解,展示其在现代企业中不可或缺的作用。
60 19
|
2月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####