网站分析软件,公寓注册公司需要什么条件,提升学历英语翻译,阿树 wordpress背景 信息系统上线后通常会需要迭代升级甚至重构#xff0c;如何确保系统原有业务的正确性非常重要。曾经有一家叫瑞穗证券的证券公司因为一个系统bug导致了数亿美金的损失#xff0c;赔掉了公司一年的利润。这样的极端例子虽然少见#xff0c;但是却像达摩克利斯之剑警示着… 背景 信息系统上线后通常会需要迭代升级甚至重构如何确保系统原有业务的正确性非常重要。曾经有一家叫瑞穗证券的证券公司因为一个系统bug导致了数亿美金的损失赔掉了公司一年的利润。这样的极端例子虽然少见但是却像达摩克利斯之剑警示着我们那么当前系统稳定性都有哪些挑战呢 系统改造升级由于回归测试不全面导致线上故障。自动化脚本的编写和维护需要大量成本枯燥单调且覆盖率很难保证。灰度测试要临近上线才能实施且存在流量小、无有效验证手段、不能消除bug对业务影响等问题。阿里作为一家以电商为核心的公司交易系统和稳定性的重要性不言而喻。整个交易系统在多年的发展过程中经历了很多业务的上下线维护的人员也换了一波又一波几乎没有人能梳理清楚其中的业务和代码。当它不得不面临一次全面升级的时候其回归测试的困难度难以想象。 如何解决 如何实现低成本高效率的自动化测试确保线上稳定性避免一切可能发生的线上故障呢复制线上真实流量来进行自动化回归归测试是一个行之有效的办法。 当前支持复制流量来做自动回归的工具有网易的tcpcopy、twitter的diffy等等但是这些工具均无法用于交易核心系统或者是非幂等接口的测试。原因是引流会导致业务脏数据甚至影响业务的正确性。而天猫内部诞生的doom平台的出现解决了这一难题它通过巧妙的mock机制避免了流量回放对业务数据的影响让复制流量回归测试适用于各种Java前后台业务系统。 效果如何 doom平台在阿里集团内部得到广泛使用。有超过28个部门的400核心应用的接入使用其中一些案例效果如下 订单中心tp的重构项目bug总数数1385个其中80%通过引流回归发现确保了双十一的稳定运行。同时借助回放功能问题排查效率提升50%。日常发布回归时间从40min缩短至15min,覆盖率得到大幅提升。交易TMF2.0重构项目通过引流回归发现有效bug 800 ,无P3以上故障。天猫物流拆分项目一期、二期通过引流回归发现遗漏bug 40零故障上线。优惠融合项目二期、三期通过引流回归遗漏bug 30零故障上线。IC中台化项目通过引流回归发现遗漏bug 40, 零故障上线。天猫优惠平台通过引流回归实现相当长一段时间的系统零故障记录。...引流回归平台介绍 什么是doom平台 doom自动回归平台是一个将一部分线上真实流量复制并用于自动回归测试的平台。 通过创新的自动mock机制不仅支持读接口的回归验证同时支持了写接口例如用户下单接口、付款接口的验证。它最底层借助了java的instrument实现aop因此目前仅支持java应用的接入使用。其原理图如下 它与tcpcopy或者diffy的区别tcpcopy、diffy是在应用外的网络层实现流量录制和回放的它们只能实现一些只读页面的验证。doom是在应用内部通过aop切面编程方式实现的流量录制和回放功能因此可以做到应用内部接口级以及http流量的回归验证通过巧妙创新的mock机制可实现写流量的回归验证。 应用场景 系统重构时复制真实线上环境流量到被测试环境进行回归相当于在不影响业务的情况下提前上线检测系统潜在的问题。可以将录制的流量作为用例管理起来进行日常自动化归回。 优势 doom平台在天猫内部发起经过多年发展逐渐推广阿里内部各个BU、蚂蚁金服。那么它到底有哪些优势呢 低成本 无需编写测试用例 一旦接入完成就可以复制线上真实流量作为用例来进行回归测试这些流量包括用户的一次请求或者是系统间发生的一次rpc调用。一次请求或者一次调用便作为一个用例每一个用例都会记本次请求的入参、返回结果、对外系统调用的入参和返回结果以及自定义录制的一些过程数据因此在回放时可以重现录制执行时的现场并完成回放过程同时通过比对来识别系统bug。 高覆盖 业务覆盖率 通常生产环境会处理大量用户请求只要业务场景被用户使用到该场景的便可以被录制成为一个用例通过一定时间的积累就可以实现很高的覆盖率确保每一个业务都会被覆盖到。也可以通过收藏指定的场景用例作为用例集来实现精确的用例回归提高回放执行效率。 支持中间过程的验证 要验证业务正确性往往仅校验返回结果是不够的例如业务系统和底层业务系统的交互请求是否变化了业务系统写数据库数据内容是否正确业务系统发送的异步消息内容是否正确等等。针对应用的外部请求验证是doom的基础能力doom还支持自定义任意的函数调用过程去进行验证。 支持丰富的全对象对比功能 为了减低服务端压力以及数据的保密性对比过程是在客户端执行。比对的内容是录制的返回结果以及请求后台系统的入参。对比方式是全对象对比也就是对象字段逐个对比。但通常情况下直接全对象对比会导致很多误报例如服务器ip不一样、时间不一样、集合顺序不同等等都会导致对比失败。因此在全对象对比的基础上提供比对排除、无序对比支持、针对字符串的特殊转化对比等等功能来实现对象精确对比。 轻量级 对应用代码侵入少 只需要在工程中初始化doom的一个客户端实例即可如何实现流量拦截都是通过字节码插桩实现。当然也有人会问既然都已经动用字节码工具了为什么更彻底一点做零代码改造。实际上我们完全可以做到零代码改造但是为了安全性考虑并没有这么做。如果是在beta生产环境回放那么如何保证这些字节码修改一定是生效的如何确保数据真正不会落库如何保证消息一定是隔离的我们实现了一套校验机制去识别异常情况一旦出现问题就通过客户端实例去抛出异常避免有问题的回放机器启动从而避免对业务的影响。 零冲突接入免代码修改升级 平台客户端所有依赖都通过独立classloader进行加载应用classloader只需要加载很少量的api类即可因此引入jar依赖不会对应用造成任何jar包冲突。同时也可以实现免代码修改升级,当平台配置的客户端版本升级后客户端在初始化时会去加载最新版本的依赖文件完成版本更新不需要修改任何应用代码。 安全性 经受过阿里大量核心应用的检验 目前阿里内部几乎所有交易核心系统都通过doom去做引流回归测试没有发生过一起因doom使用过程中导致的业务故障。 影响可控 只需要线上少数几台机器开启流量录制流量的录制也支持按百分比去采样因此即便发生问题也不会照成大面积影响。 支持生产环境流量引流到测试环境 测试环境和生产环境数据库独立生产环境的数据在测试环境也无法查询那么是如何支持生产环境流量在测试环境回放的呢原因很简单通过mock机制的存在相当于隔离了整个回放环境对下游依赖所以不在乎下游是否生产环境一切数据都可以mock解决。通过这种方式也解决了下游不稳定导致常规的自动化无法正常执行的问题。 负载及异常感知功能 客户端录制流量的过程会带来一定消耗如果生产机器压力小这种消耗可以无忽略。但是生产机器高峰期要承受巨大压力的时候doom客户端会感知并主动停止流量录制确保线上稳定性。另外再在接入配置过程中也难免会出现各种问题最最要的是配置了不可序列化的对象导致异常客户端也会对这样异常进行监控主动停止有问题的流量的录制。 功能强大 支持应用接口级以及http流量的引流回归测试 一般一个网站会包括前台和后台应用前台应用通常是通过http提供给用户服务因此用户的每次操作都会产生一次http请求通过录制http请求可以完成前台应用的回归验证。而前台应用要实现一些业务功能需要通过rpc调用对后台应用发起请求针对后台应用的验证就可以录制这些rpc请求流量即通过接口级回归验证保证。 支持链路级应用的回归测试 当发生跨应用重构的时候仅仅通过一个应用的接入来验证已经不够了。可以将重构前的应用作为录制链路将重构后的应用作为回放链路来测试可以更好的解决多个应用重构的回归验证。 时间机器功能 有时候录制的流量要过很长时间才能重放或者流量是预先录制好的在重放的时候时间间隔较长。这时对时间敏感的流程将无法正常回放或者业务回放结果和期待的必然不一致。而通过线程级的时间替换机制可以确保回放时读取到的系统时间为录制时的时间解决时间不一致问题。 支持热部署流量拦截配置可立即生效。 在应用刚开始接入的时候往往要进行一些接入配置如果每次配置都需要发布新版本或者重启一次应用这是不可接受的因此支持在测试环境中的一些配置通过热部署方式动态生效。而线上为了稳定性考虑不开放生产环境热部署功能。 支持流量定向指定机器重放方便问题快速定位。 当我们通过doom发现系统bug的时候可以通过重放这一利器来快速复现您只需要设置好断点然后通过一键重放功能将流量在您指定的机器进行重放帮助开发人员快速定位问题当问题修复后也可以快速验证。 支持多项目支持流量复用 对于大一点的平台往往会有很多项目同时进行通过配置平台上的分组管理机制可以实现多个项目同时使用流量录制回放功能也支持一份流量多项目共同使用。 支持丰富的扩展机制用于重构验证。 当应用发生重构的时候整个回放的的执行流程可能和录制时不一致比如重构后可能会减少rpc调用用次数或者增加某些新的rpc调用可以通过扩展自定义处理扩展去解决这种不一致的场景例如基于已有的上下文快照去构造新增的一个rpc调用的结果或者自己构造一个默认的返回结果甚至是允许rpc真正执行调用等等。 支持业务覆盖率分析 这里的业务覆盖率并不是通常意义上的代码覆盖率业务覆盖率关注具体的回放验证过程覆盖到了哪些业务而不是覆盖了多少代码行。其原理是通过指定流量的业务标识字段然后在流量回放时对业务类型进行积累得到一个总的业务类型池当某一次回归执行时会计算本次回归执行到的业务类型占真个业务池类型的占比当达到100%时说明已经回归完成了该接口的所有已经执行过的业务。 平台作为云服务对外开放 初衷 doom的模式可以推广使用因此我们在阿里云的一站式研发协作产品云效上提供了doom的云服务功能也希望开放后借助外部力量共同完善平台。 它能帮助企业在研发测试过程解决如下问题 业务快速发展、项目时间紧迫自动化脚本来不及维护导致覆盖率不高。重构或者基础组件升级影响范围很难评估测试工作很难展开。测试环境经常受下游不稳定影响导致自动化脚本无法正常运行。测试资源不足重复回归测试单调重复。无法构造线上真实数据场景测试效果不佳。很多校验点无法验证例如通过中间件发送消息的内容程序执行的中间过程数据等等。平台文档原理接入使用指南 云服务部署方式 如图上所示云服务提供配置管理功能而在用户机房可以直接使用阿里云oss存储产品来实现用例或者流量的存储也可以扩展实现自定义数据存储。 图中A企业完全使用平台功能如果平台功能不满足需求也可以像图中企业B一样基于平台提供的录制、回放等等能力去实现自己的稳定性/回归测试平台。 展望 一种高效率的研发测试方式 试想一下当研发人员提交一次代码集成系统会自动引入线上真实流量或者使用历史存储的流量进行回归测试并以报告的形式告诉他是否存在bug本次代码提交带来的性能提升有多少并且通过调用链路上的分析给他指出一些可优化提示这让他能专注于新业务的研发和系统优化不必为修改了一行老的代码而担心触发线上故障。对于测试同学只需要关注新上线的功能是否正确而不是关注那些一遍又一遍测了无数次的旧功能也不用维护那些沉甸甸的脚本。这样的研发测试方式将是多么惬意的事。 要实现这样愿望还有很多事情要做也希望有更多志之士一起来完成。 应用接入自动化目前需要用户手动去做一些应用变更、手动去配置流量入口人工去分析失败用例对于对这套机制不熟悉以及对代码不熟悉的同学来说成本较高。这样的的接入过程实际上是有规可寻因此做到自动化接入不是不可能。如何解决mock数据库后针对数据库相关逻辑的验证是否可以实现一个快照式的数据库可以将回放写入数据库的影响消除或者写入另外一个相同的影子库进行数据写入验证。将doom作为一个基础组件融入到集成发布系统中用户不需要感知doom接入过程当用户提交集成时系统自动会把代码部署到对应的回归环境中并且分析代码变更去触发相关流量的回归最终将分析报表给到用户同时在发布时会检查是否已完成自动回归否则自动触发引流回归并等待验证无误后才允许发布上线。其他应用场景 doom能记录系统业务执行过程的全部上下文信息基于这些数据能够拓展出很多应用场景例如线上问题排查时的现场还原。以及是否能利用这些丰富的数据作为基础数据仓库提供给上层做离线或者实时数据挖掘分析以及决策等等。
