阿里高可用架构建设实践经验

简介： 阿里巴巴在多年双11高并发、高可用和高客户体验要求背景下积累了相应的技术体系，本文将依据高并发用户、突发高流量场景下的真实案例，分享阿里在高可用架构建设过程中的经验总结，以期待帮助更多企业做好业务高可用建设。

本文始发于：云栖社区
时间：2020-06-02
原文链接：https://yq.aliyun.com/articles/763336

1 背景

随着业务在线化互联网化的高速发展，企业对核心业务系统的稳定性、可靠性、有效性、业务连续性等有了更高的要求。采用高可用系统架构支持重要系统、为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。但如何从海量实践中提炼出值得借鉴复制的高可用架构之道，实现适合自身的高可用系统架构，是需要企业深思熟虑的问题。阿里巴巴在多年双11高并发、高可用和高客户体验要求背景下积累了相应的技术体系，本文将依据高并发用户、突发高流量场景下的真实案例，分享阿里在高可用架构建设过程中的经验总结，以期待帮助更多企业做好业务高可用建设。

2 存在的问题

2.1 非常复杂的服务端

通常从客户端到达服务端会涉及到的关键节点有CDN、动态加速、高防、应用防火墙、4/7层负载均衡、前后端服务集、缓存、数据库存储、中间件、基础设施层等等，整个链路都面临着不确定性。后端服务的服务规模化问题更是复杂和难以评估检验，这其中任何一个节点出现问题都会导致服务不可用。如何能有效地全面检验服务端吞吐能力、发现所有问题甚至是做好容量规划，具备对峰值的流控调度能力是所有企业都需要思考和应对的。

2.2 缺乏提前规划的服务能力

如果企业没有对自己的服务能力进行提前规划，没有提前做好关键节点的规划，对线上的应急措施如弹性扩容、线上防护、熔断降级等都不具备，那么在面对突发问题时，就很难保证核心接口能够稳定对外服务。一旦出现问题，很多企业无法采取正确的手段，匆匆扩容非但不能解决问题，反而带来更多不可预期的问题，导致问题进一步的恶化。此外，运维侧的隐患问题如故障影响面、配置一致性、监控和根因分析相关工具、复杂人员组织的高可用程度等，如果没有足够的演练和验证方案，同样会在关键时刻出现问题。

3 高可用架构建设

3.1 架构设计

首先要实现架构可视化。服务器、存储、网络是现代云平台的基础设施。随着上云战略的推进，越来越多的企业将业务、服务、系统构建在云平台上。利用阿里AHAS的架构感知可以全面了解云上系统架构，以可视化的方式直观呈现云资源、容器和应用间分层依赖关系。

开源软件和云服务的多样性、开发语言的异构性，以及企业IT团队的组织和能力差异，都提高了标准化的复杂性。架构感知功能应运而生，通过采集和分析操作系统及第三方标准接口，捕捉进程级的调用关系，并使用特征库算法识别进程所使用的技术组件，最后在服务器、容器和进程这三个维度上以可视化的方式展示应用架构，给用户一张全面清晰的云上架构地图。围绕这张基础的视图，会持续衍生出云资源、容器和应用架构多维度的架构视图，还有搬站、重构梳理和资产管理等场景化的视图，真正做到CMDB可视化，驱动问题发现助推业务增长，释放云上的更多维度的红利。

而关于强弱依赖治理，因为强依赖本身意味着一荣俱荣，一损俱损。结合AHAS SDK的引入和预埋，一旦当平台最大吞吐能力到达瓶颈时，除了入口或者web类应用的业务峰值流量限流可以起到第一层的保护作用外，还可以将预先标记为弱依赖的服务平滑下线，从而达到节省更多资源保障核心计算能力的目的，同时还可以去除非核心对核心服务的影响，最终通过合理高效的服务降级最大程度获得业务和成本的平衡。而使用了AHAS SDK之后在编码时，只需要关心如何定义资源，即哪些方法/代码块需要保护，而不需要关注如何保护这个资源。然后通过添加规则来保护资源，规则添加即时生效。

图1：AHAS架构感知及可视化

3.2 容量规划

外网仿真压测：首先可以通过PTS高效快速构建同模型和量级的业务流量，对于开源主流的JMeter脚本可以直接100%兼容，对于没有现成脚本的情况可以使用PTS自研的可视化交互进行0编码编排，编排完成后从公网的各地域运营商发起，真实模拟特定业务场景下的外网流量，从而全面验证和探测云上或云下整体架构（从网络接入到应用服务内再到存储层和基础设施）的瓶颈和问题。

全链路压测：更进一步的，如果在生产环境想直接精准衡量业务容量，可以通过PTS相关解决方案使生产环境具备压测流量识别和路由到指定影子存储区域的能力，结合相关影子存储区域的准备，然后做到同样规模基础数据上的业务流量压测同样的生产环境，最终达到精准衡量线上生产环境的能力。当然，对于压测流水数据由于已经隔离开，所以可以方便安全地清理和维护。

图2：全链路压测核心流程

3.3 业务监控

面对复杂的应用环境和高速增长的业务，ARMS能帮助用户快速构建各种环境下完整的监控体系，实现从页面到数据库、从应用性能到基础架构资源、从IT到业务的端到端监控。减少故障排查时间，降低跨部门沟通成本，最终降低因为故障和体验差给企业带来的损失。

图3：ARMS业务监控体系

3.4 线上管控

对于运行态或已有应用可以通过AHAS探针形态（除AHAS SDK外更轻的方案）在不修改代码的情况下进行业务洪峰的流量强力控制、消息场景的削峰填谷，而对于结构复杂的可以将系统内或外不稳定的因素迅速降级让业务保持稳定，同时还有单机过载保护（根据RT动态调节入口流量）的兜底能力，甚至很多时候系统来不及压测或者不知道配置什么规则的时候单机智能过载保护是个很好的功能和方法。以上都在运行态和运维侧即可完成引入和控制。对于线上配置项和业务属性值通过AHAS开关模块的轻量级方案进行安全和统一管控，这部分能力即将开放，敬请期待。

图4：线上高可用防护布局

3.5 日常巡检

风险的提前暴露，通过Advisor智能顾问对云上主要云资源进行全面的巡检和风险识别，规则都来自于阿里云一线运维同学面向客户的技术体3系积累及阿里生态内SRE最佳实践的融合。基于前述的架构地图和用户的输入，可进行更深层次的应用/业务架构层面的巡检和建议。

3.6 常态化演练

AHAS的故障演练模块遵循混沌工程实验原理并融合了阿里巴巴内部实践的经验，基于此用户可以建立流程完整且可视化程度很高的故障演练体系，可方便地对基础资源、应用服务、容器服务和云平台4层进行超多维度的编排和定制，同时产品还提供了丰富的成熟故障经验库。从而帮助用户实现包括架构、业务、人员的全面高可用提升。故障演练在依赖治理、业务连续性提升和故障修复验证等场景中都有巨大作用。

图5：故障演练体系

4 阿里高可用工具

4.1 应用高可用服务AHAS

专注于提高应用高可用能力的云工具产品，提供应用架构自动探测，故障注入式高可用能力评测和一键流控降级等功能，可以快速低成本地提升应用可用性。
https://www.aliyun.com/product/ahas

4.2 性能测试PTS

面向所有技术背景人员的云化测试工具。有别于传统工具的繁复，PTS以互联网化的交互，提供性能测试、API调试和监测等多种能力。自研和适配开源的功能都可以轻松模拟任意体量的用户访问业务的场景，任务随时发起，免去繁琐的搭建和维护成本。更是紧密结合监控、流控等兄弟产品提供一站式高可用能力，高效检验和管理业务性能。
https://www.aliyun.com/product/pts

4.3 智能顾问Advisor

智能顾问Advisor根据用户情况，结合阿里云长期以来的客户侧最佳实践，基于TAM（Technical Account Management）服务体系的核心基础能力，全方位地为用户提供云资源、应用架构、业务性能及安全上的诊断和优化建议。现在，越来越多的阿里云云原生客户可以通过Advisor便捷地享受专业的TAM基础服务，更好地用好云。同时，我们也会围绕Advisor为有相关需求的客户提供专项深度的TAM服务。
https://www.aliyun.com/product/advisor

4.4 企业级高可用架构解决方案

脱胎于阿里巴巴电商业务下的高可用技术体系，经过所有的双11流量洪峰考验、日常稳定性考验，已经服务于阿里全生态并开始服务外部的企业客户，为企业提供包括营销活动支撑、整体成本控制（全链路压测、容量规划、流量控制、调度）、应急应对能力（开关和预案）、容灾逃逸能力（架构感知、故障演练、异地多活、单元化）等在内的解决方案。
https://www.aliyun.com/solution/ehasl

4.5 混沌测试工具ChaosBlade

ChaosBlade是一款遵循混沌工程实验原理，建立在阿里巴巴近十年故障测试和演练实践基础上，并结合了集团各业务的最佳创意和实践，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具。
https://github.com/chaosblade-io/chaosblade

4.6 轻量级流量控制框架sentinel

以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助客户保护服务的稳定性。
https://github.com/alibaba/Sentinel/wiki

5 总结

以上便是阿里高可用架构建设的实践经验分享。一个好的高可用架构可以以最低的成本、更灵活的方式满足企业的相关需求。而在各种各样、纷繁复杂的技术中构建最适合企业的高可用技术架构，是需要逐渐摸索和持续积累的。

作者：丁杰

阿里云智能GTS-SRE团队解决方案架构师

阿里云智能GTS-SRE团队架构师，长年负责阿里生态内支付宝、钉钉、旺旺和阿里音乐的SRE工作，近几年专注于阿里云应用高可用技术体系的产品化工作和解决方案体系构建事宜。