零点之战—阿里双11高可用架构演 进之路

双11技术挑战的本质是用有限成本去实现最大化的用户体验和集群整体吞吐能力,用最合理的代价解决零点峰值,支持好业务的狂欢不确定性来自于技术实现链条中变量的叠加,如峰值的增量和系统架构的变化,交易创建峰值的组成、拆单比、每个业务入口的访问量、CPU利用率等,并实现引导和控制。本文介绍阿里巴巴支持双十一网站构架的扩展性,容量规划(包括如何对这些规划容量进行压测),成本优化,运行控制及稳定性治理的话题,包括他们的出发点及相关目标。
展开查看详情

1.零点之战—阿里双11高可用架构演 进之路 Alibaba – 丁宇(叔同)

2.个人介绍 § 丁宇(叔同) § 阿里巴巴中间件技术部-资深技术专家 § 2010年加入阿里,10余年技术研发和系统架构经验 § 目前负责高可用架构、电商交易运维和基础中间件几个团队 § 2015年作为共享平台双11负责人,2016年作为集团双11稳定性负责人 § 推动了电商交易从可用性到正确性、容量确定性到资源确定性的升级 § 建设了大量高可用性技术产品,参与电商交易较大的技术演进工作 § 构建了全球最大的混合云弹性架构支撑双11 § 联系方式:shutong.dy@alibaba-inc.com 18657182390

3.双11的技术挑战 § 交易额增长200倍,交易峰值增长400多倍,系统复杂度和大促支撑难度以指数级攀升 § 双11技术挑战的本质是用有限成本去实现最大化的用户体验和集群整体吞吐能力,用最合理 的代价解决零点峰值,支持好业务的狂欢 § 双11的不确定性来自于技术实现链条中变量的叠加,如峰值的增量和系统架构的变化,交易 创建峰值的组成、拆单比、每个业务入口的访问量、CPU利用率等,并实现引导和控制 § 零点之战峰值的意义: 对技术实现能力的推动,对架构优化的推动,加速技术演进和沉淀

4.议程 § 扩展性 § 容量规划 § 成本优化 § 运行控制 § 稳定性治理

5.扩展性—3.0分布式架构 存储 集群

6.扩展性—背景挑战 50% 50% § 背景 - 3.0分布式架构 机房1 机房2 - 去IOE可水平伸缩 - 同城容灾、异地备份 应用 应用 § 挑战 - 系统可用性、故障恢复能力 主库 备库 - 超级机房应用层水平伸缩瓶颈,数据库链接等 - IDC资源限制,一个城市不足以支撑我们的规模增长 - 容灾问题,单地域IDC单点,网络、台风等导致高风险 - 国际化部署需求,可扩展性再次成为瓶颈

7.扩展性—异地多活方案 § 建设异地单元机房 § 流量按用户维度切分 § 单元内封闭减少远程调用 § 数据层实时同步最终一致

8.扩展性—异地多活架构 cdn1 cdn2 cdnN 按UserId路由 中心 单元1 单元2 单元3 web 服务调用 web web web center service service service service 异步消息 cache cache cache cache storage storage storage storage 数据同步

9.扩展性—异地多活的意义 § 异地多活消除了IDC资源单点和容量瓶颈 § 解决了异地容灾问题,业务可以秒级快速切换 § 简化了容量规划,提升了伸缩性和可运维性 § 可扩展性问题的解决为后续架构演进打下坚实基础

10.容量规划—线上压测 http_load 压测模型 § 评估应用线上单机极限能力 Nginx 引流、代理 HSF分流 § 建立性能基线,驱动性能优化 Apache TcpCopy Notify分流 引流、代理 BTrace § 给容量规划和弹性伸缩提供数据 Web层 服务层 存储层 支撑 面向单机压测 面向单机 § 根据公式和经验推演容量规划 面向集群读压测 接口配比压测 线上 应用 阈值监控 异常监控 压测控制 系统 Cpu 配置异常 手动 自动 Load 登录异常 RT 连接异常 压测报告 性能基线 性能优化 系统数据 性能数据 容量规划 弹性伸缩 业务数据 历史数据

11.容量规划—挑战 § 容量规划的目的,是从用户登录到完成购 应用层 买的整个链条中,整体资源如何合理分配 APP1 APP2 APP3 APP4 APP5 § 500+的核心系统,整个技术链条长、业务 入口多、逻辑复杂 服务层 Service1 Service2 Service3 Service4 § 链路瓶颈点较多,每年大促峰值都会出现 一些问题,无法提前发现 Service5 Service6 Service7 § 堆积木的容量规划方法,前面失之毫厘后 存储层 面谬以千里 Cache DB1 DB2 § 在能力评估时应该考虑的是一个处理链路 而不仅仅是单一的应用 § 缺乏验证核心页面和交易创建链条实际承 载能力的手段

12.容量规划—压测方案 § 在线上集群模拟真实业务流量的读写压测 应用层 ,完成从网络、IDC、集群、应用、缓存 APP1 APP2 APP3 APP4 APP5 、DB,以及业务系统上下游依赖链条的容 量、性能压力测试 服务层 § 自定义压测工具,大流量来自机房外部 Service1 Service2 Service3 Service4 § 构造线上测试数据,业务模型接近真实 Service5 Service6 Service7 § 测试数据和正常数据隔离,不互相影响 存储层 § 压测时对用户体验无感知、无影响 Cache DB1 DB2

13.容量规划—全链路压测 流量控制中心 压测数据 数据平台 电信CDN节点 联通CDN节点 移动CDN节点 教育网CDN节点 压测引擎 压测引擎 压测引擎 压测引擎 流量引擎集群 阿里业务集群 § 超大规模的集群压测能力,每秒千万QPS § 真实数据与测试数据结合,数据模型与双11极其接近 § 流量真实模拟用户行为,从全国各地CDN发出,技术链条覆盖更长 § 线程级隔离,无脏数据,压力测试直接作用于线上集群,暴露问题更精准

14.容量规划—全链路压测的意义 § 打破不可预知技术风险的限制,加速技术进化 § 为新技术的尝试和突破做好保底和验收的工作 § 做到主动发现问题而不是被动等待、应急处理 § 新的线上演练,为稳定性的确定性打下坚实基础

15.成本优化—混合云弹性架构 § 双11只有一天,过后资源利用率不高, 隔年会形成较长时间的低效运行 § 全面使用阿里云弹性基础设施,降低资源保有时间,降低单笔交易成本 § 构建全球最大的混合云弹性架构支撑双11,大幅降低大促成本 § 一键建站8小时搭建单元,弹性伸缩3小时完成容量调整 § 全面Docker化拉平异构平台运维的成本,几十万的镜像

16.运行控制—限流降级 服务端限流 资源 客户端限流 调用方A 分应用 应用 接口 链路限流 限流依赖D 不分应用 url 参数 直接限流 限 调用方B 关联限流 自定义资源 关联限流 流 正常调用依赖F 调用方C限流 线程数 负载 QPS 应用 重要调用方A 资源 自动降级弱依 服务 客户 赖D 应用 接口 端降 端降 降 重要调用方B 级 自定义资源 级 级 正常调用依赖F 自动降级不重 阈值熔断 要调用方C 应用

17.运行控制—流量调度 流量调度平台 局部用户体验受阻 始终流畅的用户体验 前台系统 实时 前台系统 后台系统 后台系统 自动 后台系统 后台系统 智能 正常机器 问题机器 正常机器 问题机器不分配流量或少分配 § 实时探测与监控分布式环境,使用流量调度策略和负载均衡机制 § 使分布式服务具备自我隔离能力和自我修复能力 § 关注局部用户请求和用户体验,提升整体可用性

18.运行控制—开关预案 预案管理 操作管理 § 开关是让系统切换不同功能表现的标准技术 预案录入 预案执行 批量导入 分布式调用 § 可以无需变更代码只推送配置控制系统行为 执行日志 预案开放 权限控制 开关 配置中心 ,让系统的后门标准化 预案流转 预案验证 预案导出 直接 URL § 开关中心配置变更可以实时下发到集群,操 作行为对业务来说是原子的 限流 关联 应急预案 定时预案 § 预案整合一批业务开关、限流等操作,将多系统的后台操作组装批量执行 § 预案推送是有顺序性的,保证业务切换的一致性和完整性

19.稳定性治理 § 通过中间件通道能力跟踪分布式调用链路,完成系统架构梳理 § 对海量调用链进行统计,得到链路各个依赖系统的稳定性指标 § 结合业务用例识别强弱依赖,弱依赖可自动降级提供有损服务

20.未来的挑战 § 精细化、数据化、智能化的双11 § 容量确定性到资源确定性 - 从每个实例部署在哪里最佳、精确到每个内核如何分配最佳 § 更加精准的分析、预测流量模型和业务模型 - 实现预测、引导相结合,逼近真实、增加确定性 § 技术变量的采集、分析、预测,数据分析驱动,自主决策处理 - 关键技术指标的预估错误系统做到自适应,弹性处理 § 体验、成本和最大吞吐能力找到新的平衡点

21.Q&A