全链路压测:影子库与影子表之争

2643 篇文章 26 订阅
2619 篇文章 14 订阅

01 业界盛传的全链路压测是什么

全链路压测诞生于阿里巴巴双 11 备战过程,如果说双 11 大促是阿里业务的“期末考试”,全链路压测就是大考前的“模拟考试”,诞生后被誉为双 11 稳定性保障的“核武器”。全链路压测通过在生产环境对业务大流量场景进行高仿真模拟,获取最真实的线上实际承载能力、执行精准的容量规划,确保系统可用性。

分布式架构和业务快速发展给业务系统带来了不确定性。分布式环境的任意节点都可能成为瓶颈/短板/问题,同时系统可用性随着业务的快速增长,面临更严峻的挑战和不确定性。比如:

单链路压测缺少外部干扰和各种资源竞争,单链路压测的结果普遍比较乐观,不能反映真实的系统承载能力。
某些问题只有在真正的大流量下才会暴露,比如网络带宽、系统间影响、基础依赖等等。
全链路压测不仅仅是做压测,更多的是进行一次真实的大促预演,预案演练、限流验证、破坏性演练等高可用方案的统一验收。

其中全链路压测的常见问题就是如何做到生产环境的数据隔离:在生产环境进行写压测时,需要保证在压测进行的同时不影响线上业务的正常运行,那么就需要考虑将压测产生的数据与生产的真实数据隔离存储,避免脏数据对线上业务产生影响。阿里云的全链路压测平台除了提供了影子表方案之外,还提供了影子库的数据隔离方案。

在生产环境实施全链路压测的过程中,针对上文谈到的两种方案,又面临着数据隔离方案的选择问题,本文首先针对影子库、影子表两种方案进行介绍和对比,然后针对常见的场景,给出方案的选择建议。

02 全链路压测数据隔离方案的选择

目前全链路压测平台提供了影子库、影子表等解决方案。应该如何选择适合自己的方案呢?本文首先针对两种方案的原理进行阐述,然后从性能、稳定性、成本三个考量指标进行对比。

01 方案一:影子库

如图 1 所示,针对影子库方案,是在同一个实例上建立对应的影子库。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路处理,如果是影子流量,那么会从影子连接池中获取影子连接供业务侧使用,从而将压测流量产生的数据旁路到对应的影子库中,以此达到数据和生产库隔离的效果,从而避免了压测流量产生的数据对生产库造成污染。

图片

图 1:影子库方案基本原理

02 方案二:影子表

如图 2 所示,类似影子库方案,针对影子表方案,是在同一个实例上的同一个数据库上建立对应的影子表。用户服务挂载的全链路压测探针获取到流量标之后进行相应的旁路处理,如果是影子流量,那么,探针会针对本次的 DB 调用进行 SQL 解析和替换,从而将压测流量产生的数据旁路到对应的影子表中。

图片

图 2:影子表方案基本原理

03 方案对比

本文主要从性能、稳定性、成本三个方面来阐述两种方案的优缺点。

图片

图 3:方案对比

01 性能

机器规格:4c8g

并发规格:需同时模拟正常和压测流量两种类型的流量,这里以 2:8 的比例进行划分,以便于模拟业务流量低峰期进行生产环境全链路压测。

  • 正常流量:200 并发
  • 压测流量:800 并发

这里主要从服务所在的主机和所用的数据库实例两方面的监控去分析。其中,应用监控主要以 CPU、内存和平均 RT 三个指标分析。数据库实例监控从连接数、QPS 两个指标的维度进行分析。

图片

从以上两种方案不同维度的指标对比可以看出,影子表方案对 CPU 的消耗略高,这和该方案的实现方式有关。

02 稳定性

谈到稳定性,可以从数据源实例的连接数规格、容量规格、IOPS、网络流量等方面进行分析。

图片

以上指标,这里以连接数为例进行说明,具体如下:

针对影子库方案。由于是在同一个实例上建立不同的数据库,所以如果不考虑数据库实例能够达到最大连接数上限,理论上影子连接和正常连接时相互独立的,执行时互不影响。

针对影子表方案,由于是在同一个实例上的同一个数据库上建立了不同的数据表,那么这里就要考虑业务侧的连接池配置了,因为影子流量涉及到的 DB 操作和正常流量涉及到的 DB 操作,所用的数据库连接,均来源于同一个连接池,所以如果压测量级较大的时候,是比较容易出现连接池连接瓶颈的。

03 成本

图片

根据表格中的内容,这里主要以冗余成本和数据迁移成本进行说明,具体如下:

冗余成本

针对影子库方案,为了保证全链路压测评估结果的精准度,我们需要在同一个实例上做全量的库迁移操作,包括表结构和表数据,这会带来一个比较明显的问题,成本比较高,所有的基础只读表(此类型的表不会有写操作)均要冗余一份,无法达到复用的目的,所以对于中大型企业来说,是难以接受的。

针对影子表方案,是在同一个实例上的同一个数据库上建立影子表。那么就可以复用生产库中的基础只读表,只需对写表进行建立影子表即可。影子表方案在一定程度上降低了数据冗余所带来的成本消耗。

数据迁移成本

从压测的主流程来说,分为压测前、压测中、压测后。其中,数据准备是处于压测前这一阶段的,压测成功与否,和数据准备这一环节密切相关。数据迁移的过程需要将某张数据表所关联的其他表字段同时做迁移,这一过程是比较复杂和耗费精力的。所以,具体选择哪种方案,需要结合业务数据的复杂程度来评估。

04 总结

综上,具体选择以上两种方案中的哪一种,其实仅靠一个指标判断是不够的,要结合以上多个指标以及具体的业务场景来进行综合评估的。下面针对两种典型的场景来说明应该如何选择适合自己方案,以下意见仅供参考。

场景 1:在涉及到的读表比例高于写表、并且整库迁移成本较高的情况下,推荐选择影子表方案,在一定程度上可以减少复杂的数据迁移带来的成本。

场景 2:在涉及到的写表比例高于读表,同时生产库实例容量较为充足的情况下,推荐选择影子库方案,在一定程度上降低了梳理、配置的成本。

在这里插入图片描述

喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一 键三连哦!
在这里插入图片描述

第1章 阿里技术架构演进 1 双11是阿里技术发展的强大驱动力,双11业务的快速发展造就了阿里具备高度水平伸缩能力、低成本的电商架构体系。这个架构体系是如何一步一步形成的呢?在形成过程中阿里遇到了哪些问题,做了哪些尝试,最终用什么样的思路、方法和技术解决了问题? 1.1 五彩石,电商架构新起点 3 1.2 异地多活,解除单地域部署限制 的新型双11扩容方式 9 1.3混合云,利用阿里云弹性大幅降低双11成本 17 1.4 OceanBase,云时代的关系数据库 23 1.5 手机淘宝,移动互联网电商新时代 30 1.6 蚂蚁技术架构演进 36 第2章 稳定,双11的生命线 43 双11最大的困难在于零点峰值的稳定性保障。面对这种世界级的场景、独一无二的挑战,阿里建设了大量高可用技术产品,形成了链路一体化的解决方案,用更加逼真和自动化的方式,去评估、优化和保护整个技术链条,最大化地为用户提供稳定可靠的服务。 2.1 容量规划,资源分配的指南针 45 2.2 链路压测,大促备战的核武器 51 2.3 链路功能,提前开始的狂欢盛宴 58 2.4 自动化备战,喝着咖啡搞大促 65 2.5 实时业务审计,从系统可用到业务正确 70 2.6 故障演练,系统健壮性的探测仪 75 2.7 系统自我保护,稳定性的最后一道屏障 82 第3章 技术拓展商业边界 89 双11业务驱动技术发展的同时,技术的创新与发展也不断推动着商业模式的升级与变革,实践着技术拓展商业的边界。 3.1 招商报名,活动基础设施建设 91 3.2 会场,小二与商家共同打造的购物清单 99 3.3 搜索,大促场景下智能化演进之路 107 3.4 个性化推荐,大数据和智能时代的新航路 114 3.5 供应链,从飞速增长到精耕细作 120 3.6 蚂蚁花呗,无忧支付的完美体验 127 第4章 移动端的技术创新之路 133 从2010年开始,国内爆发了从PC向移动端技术和业务的持续迁移,移动深刻地改变着人们的衣食住行和人际交往。阿里的双11始于2009年,正好经历了移动互联网崛起的程,双11在移动端的主要创新有哪些呢? 4.1 Weex,让双11更流畅 135 4.2 互动,让购物变成狂欢 143 4.3 VR&AR;,移动端创新体验 153 4.4 奥创&TMF;,让双11多端业务腾飞 163 第5章 繁荣生态,赋能商家 171 双11从阿里内部员工的一个点子到球购物狂欢节,其背后支撑是服务、物流、大数据、云计算、金融服务等,是商家自身业务结构的调整、消费者消费习惯的转变、第三方开发者的大量入驻,以及整个生态的变迁。 5.1 聚石塔,开放的电商云工作台 173 5.2 菜鸟电子面单,大数据改变物流 179 5.3 生意参谋,数据赋能商家的“黑科技” 184 5.4 阿里小蜜,用智能重新定义服务 191 5.5 阿里中间件,让传统企业插上互联网的翅膀 198 5.6 蚂蚁金服,金融机构间协同运维的探索和实践 205
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值