Dubbo 压测插件 2.0 —— 基于普通 API 调用

插件已开源,详见 gatling-dubbo【1】 上一篇《Dubbo压测插件的实现——基于Gatling》【2】中,我们介绍了基于 Dubbo 泛化调用实现的 Gatling Dubbo 压测插件,使用泛化调用发起 Dubbo 压测请求,consumer 端不需要拿到 provider 端的 API 包,使用上很便利,…

Read More

有赞全链路压测引擎的设计与实现

一年以前,有赞准备在双十一到来之前对系统进行一次性能摸底,以便提前发现并解决系统潜在性能问题,好让系统在双十一期间可以从容应对剧增的流量。工欲善其事,必先利其器,我们拿什么工具来压测呢?我们做了很多前期调研和论证,最终决定基于 Gatling 开发有赞自己的分布式全链路压测引擎 —— MAXIM。一年多来,我们使用 Maxim 对系统做了很多次的性能压测,在提升系统性能、稳定性的同时,也得益于历次压测的实践经验逐步改进 Maxim。 1、前期调研 1.1、技术选型的核心考量…

Read More

Dubbo压测插件的实现——基于Gatling

Dubbo 压测插件已开源,本文涉及代码详见gatling-dubbo Gatling 是一个开源的基于 Scala、Akka、Netty 实现的高性能压测框架,较之其他基于线程实现的压测框架,Gatling 基于 AKKA Actor 模型实现,请求由事件驱动,在系统资源消耗上低于其他压测框架(如内存、连接池等),使得单台施压机可以模拟更多的用户。此外,Gatling 提供了一套简单高效的 DSL(领域特定语言)…

Read More

混沌工程 - 软件系统高可用、弹性化的必由之路

随着摩尔定律的终结,单机计算性能已达到了极限,然而,我们的软件系统不论是规模还是复杂度一直在增长,所以软件系统都不约而同的朝着分布式化方向发展。近年来,随着云服务、容器的出现,某些分布式系统也更容易微服务化。抛开这些形形色色的分布式技术,我们对系统可靠性的述求却是一致的:分布式系统需要高可用,即使出现了单点或集群故障,也希望系统具备自我恢复或优雅降级的弹性能力、容错能力。我们在合理的架构,高质量的代码,完善的测试等等方面做了很多努力,然而很多分布式系统仍旧达不到高可用、弹性化,为了尽可能发掘系统中存在的弱点,很多大型软件公司都引入了混沌工程,如国外的谷歌、网飞,国内的京东等等。…

Read More

异步系统的两种测试方法

互联网软件系统一直随着需求、用户量上升等等的原因在演进,以求适应更复杂的业务场景,更高的性能要求等等。软件演进方式各种各样,系统异步化即为其中一种。 一般的,对于那些实时性要求不高,但却计算密集或者需要处理大数据量的耗时较长的任务,或是有较慢 I/O 的任务,选择异步化是一个不错的选择。在系统层面,像引入消息中间件来解耦系统,将耗时长的任务放在中间件后异步执行。在方法层面,像把耗时较长的任务放到其他线程中去异步执行。 与测试同步系统或方法不同,当我们测试异步系统(端到端测试、集成测试)或异步方法的时候(单元测试)…

Read More