一次 Logback 发现的隐患
一、现象描述 近期我们在线下环境进行了核心链路单接口的性能摸底,在使用我厂基于 Gatling 自研的 gatling-dubbo框架(详见Dubbo 压测插件 2.0 —— 基于普通 API 调用)对 ic 应用的 getActivityList 这个 Dubbo 接口进行压测的时候,在 RPS 接近 100…
Read More一、现象描述 近期我们在线下环境进行了核心链路单接口的性能摸底,在使用我厂基于 Gatling 自研的 gatling-dubbo框架(详见Dubbo 压测插件 2.0 —— 基于普通 API 调用)对 ic 应用的 getActivityList 这个 Dubbo 接口进行压测的时候,在 RPS 接近 100…
Read More背景介绍 有赞早期业务跑在一个单体php工程上,随着业务发展,性能拓展性已经满足不了需求,为了后续发展,底层开始微服务化,整体转向dubbo框架。从单体转向分布式框架,测试也面临着一系列问题,如下: 对于分布式系统中的绝大部分应用,随着业务发展,自身应用代码复杂度会不断增加,如何准确、全面判定代码修改影响范围会越来越重要; 一些领域设计不太合理的业务架构,会发现任一应用接口变动会使多个应用受影响。测试过程中会发现只是自身应用代码一个修改,会导致对外暴露的接口逻辑发生很大变动,此时测试人员需要判定出这个对外暴露的接口对上层应用到底有多大影响; 业务快速迭代导致测试时间不断压缩,全量回归是一个很困难的事情,那么测试范围需要开发测试人员根据代码和业务熟悉程度精确把控,风险容易失控; 基于上述背景,…
Read More一、背景介绍 有赞 PaaS 团队自17年7月份开始投入测试资源,测试人员的加入意味着与测试相关的一系列东西产生,比如测试环境、测试工程、测试流程等等,这次分享的内容主要与测试环境有关,刚开始我们把测试环境部署在虚拟机上,从18年7月份开始,我们决定把测试环境从虚拟机迁移到 K8S 上,做这个决定主要出于以下几个方面考虑。 1、公司持续交付系统不支持 PaaS 产品 目前公司的持续交付系统只支持业务产品,不支持 PaaS 产品,由于…
Read More背景 随着业务增长, 随之而来的前端需求激增, 如何在有限的时间内保证前端代码的质量. 通过测试同学单方面的保障, 还是免不了前端线上问题, 存在回归不到位或者测试遗漏的地方, 同时测试质量的高低没有客观数据可量化. 通过单测方法补充, 可以提前发现一部分问题, 减少问题解决的成本, 但是由于业务形态的原因, 需求变更频繁, 功能迭代快, 补充和维护单测的成本比较高, 在业务方的大部分前端工程中暂时没有单测方法, 因此开发在自测时, 感知比较薄弱, 无量化数据, 在项目提测前也没有统一指标可以把关, 测试对开发的自测状况也不了解; 同时前端缺少像jacoco这样的集成测试覆盖率统计框架, 无法通过集成测试收集覆盖率, 对于测试阶段的质量仍然没有数据量化 结合上面说的几点,…
Read More插件已开源,详见 gatling-dubbo【1】 上一篇《Dubbo压测插件的实现——基于Gatling》【2】中,我们介绍了基于 Dubbo 泛化调用实现的 Gatling Dubbo 压测插件,使用泛化调用发起 Dubbo 压测请求,consumer 端不需要拿到 provider 端的 API 包,使用上很便利,…
Read More