AutoMQ 系统测试体系揭秘

2024-04-30 16:20
文章标签 系统 测试 体系 揭秘 automq

本文主要是介绍AutoMQ 系统测试体系揭秘，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

01 前言

Apache Kafka 有着比较完备的自测体系。除了常规的单元测试和集成测试以外，Apache Kafka 还有着 1000+ 的“系统集成和性能测试”（以下简称系统测试）。系统测试会拉起一套真实的 Kafka 集群，并模拟用户使用 Kafka 集群的方式，进行消息的收发，并验证测试结果是否符合预期。整个流程可以实现自动化运行。

AutoMQ 继承了 Apache Kafka 的系统测试框架，并利用该框架保障代码的健壮性，以及对 Apache Kafka 的 100% 兼容性。本文将简要介绍系统测试的原理、演示系统测试过程，并给出 AutoMQ 对系统测试的实践。

02 系统测试框架介绍

2.1 基本信息

系统测试基于 ducktape[1] 框架，该框架旨在让开发者可以像使用单元测试一样编写系统测试的 case。ducktape 框架并不仅仅支持 Kafka 的系统测试。理论上，任意分布式系统都可以基于 ducktape 框架，搭建自己的系统测试体系。
Ducktape 提供如下特性：
ꔷ 保障测试隔离；
ꔷ 多种环境下（Docker、k8s、云厂商 VM）Service 的拉起和销毁；
ꔷ 自定义事件的触发（例如 Kafka node 的强制关机）；
ꔷ 测试结果的收集和总结；
Apache Kafka 目前支持以下三种集成测试环境：
ꔷ Docker;
ꔷ 虚拟机;
ꔷ AWS EC2;

AutoMQ 主要使用的是 Docker 环境下的系统测试。在后续的内容中，我们默认系统测试的使用环境为 Docker，默认工程为 AutoMQ[2] 而非 Apache Kafka。

2.2 目录结构

系统测试的基本目录为工程主目录下的 tests 子目录。

主要的子目录包括：
ꔷ Docker：系统测试运行在 Docker 环境时，镜像的打包逻辑、测试的触发脚本等；
ꔷ kafkatest：系统测试的主目录，包含 Kafka 对 ducktape 框架的适配 Service、系统测试 case 等；
ꔷ spec：trogdor 的一些简单负载 example；
ꔷ unit：一些极简的测试，目前基本没有使用；

注：trogdor 是 Kafka 工程中定义的一个测试框架，系统测试中会利用该框架跑一些复杂的负载场景。

进一步地，kafkatest 的子目录包括：

ꔷ benchmarks：性能测试的 case；
ꔷ sanity_checks：较为基础的 case，主要验证简单生产消费、Kafka node 重启等基本场景；
ꔷ services：ducktape 的基本测试资源为 Service，本目录下是 Kafka 集群中各种测试资源对 Service 的实现，其中最重要的就是 KafkaService （对应的是 Kafka 集群）；
ꔷ tests：Kafka 工程中各个模块的系统测试，包括 Kafka Client、Kafka Connect、Kakfa Core、Kafka Streams 和 Kafka Tools 等；

2.3 运行系统测试

Talk is cheap. 本小结将以“sanity_checks/test_verifiable_producer.py”中的“test_multiple_kraft_security_protocols” 测试 case 为例，实际跑一下系统测试。

在 AutoMQ 工程的主目录下，输入以下命令触发上述系统测试：

TC_GENERAL_MIRROR_URL="mirrors.ustc.edu.cn" TC_PATHS="tests/kafkatest/sanity_checks/test_verifiable_producer.py::TestVerifiableProducer.test_multiple_kraft_security_protocols" bash tests/Docker/run_tests.sh

其中 TC_GENERAL_MIRROR_URL 的设置是为了在国内环境下加速 Docker image 的打包，TC_PATHS 指定系统测试 case。

如果你此前没有打包过系统测试的 Docker image，上述命令会自动触发打包逻辑。之后自动触发指定的系统测试，测试的输出类似于：

206 actionable tasks: 206 up-to-date
Docker exec ducker01 bash -c "cd /opt/Kafka-dev && ducktape --cluster-file /opt/Kafka-dev/tests/Docker/build/cluster.json  ./tests/kafkatest/sanity_checks/test_verifiable_producer.py::TestVerifiableProducer.test_multiple_kraft_security_protocols "
/usr/local/lib/python3.9/dist-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated and will be removed in a future release"class": algorithms.Blowfish,
[INFO:2024-04-25 08:13:03,399]: starting test run with session id 2024-04-25--002...
[INFO:2024-04-25 08:13:03,400]: running 4 tests...
[INFO:2024-04-25 08:13:03,400]: Triggering test 1 of 4...
[INFO:2024-04-25 08:13:03,418]: RunnerClient: Loading test {'directory': '/opt/Kafka-dev/tests/kafkatest/sanity_checks', 'file_name': 'test_verifiable_producer.py', 'cls_name': 'TestVerifiableProducer', 'method_name': 'test_multiple_kraft_security_protocols', 'injected_args': {'inter_broker_security_protocol': 'PLAINTEXT', 'metadata_quorum': 'ISOLATED_KRAFT'}}
[INFO:2024-04-25 08:13:03,422]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: on run 1/1
[INFO:2024-04-25 08:13:03,425]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: Setting up...
[INFO:2024-04-25 08:13:03,426]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: Running...
[INFO:2024-04-25 08:13:37,574]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: Tearing down...
[INFO:2024-04-25 08:13:59,432]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: PASS
[INFO:2024-04-25 08:13:59,434]: RunnerClient: kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT: Data: None
[INFO:2024-04-25 08:13:59,447]: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
================================================================================
SESSION REPORT (ALL TESTS)
ducktape version: 0.11.4
session_id:       2024-04-25--002
run time:         3 minutes 50.640 seconds
tests run:        4
passed:           4
flaky:            0
failed:           0
ignored:          0
================================================================================
test_id:    kafkatest.sanity_checks.test_verifiable_producer.TestVerifiableProducer.test_multiple_kraft_security_protocols.inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT
status:     PASS
run time:   56.010 seconds
--------------------------------------------------------------------------------
...

可以看到成功触发了 4 个系统测试，测试全部成功。
在工程的主目录下的 results 目录下，可以看到测试的详细产物：

.
├── TestVerifiableProducer #测试类
│   └── test_multiple_kraft_security_protocols # 测试类中的方法
│       ├── inter_broker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT # 测试方法的参数信息
│       │   └── 1
│       │       ├── KafkaService-0-281473792730304 # controller节点群
│       │       │   └── ducker02
│       │       │       ├── info # 日志信息
│       │       │       │   ├── controller.log
│       │       │       │   ├── Kafka-authorizer.log
│       │       │       │   ├── Kafka-request.log
│       │       │       │   ├── log-cleaner.log
│       │       │       │   ├── server.log
│       │       │       │   └── state-change.log
│       │       │       └── server-start-stdout-stderr.log
│       │       ├── KafkaService-1-281473792730160 # broker节点群
│       │       │   └── ducker03
│       │       │       ├── info
│       │       │       │   ├── controller.log
│       │       │       │   ├── Kafka-authorizer.log
│       │       │       │   ├── Kafka-request.log
│       │       │       │   ├── log-cleaner.log
│       │       │       │   ├── server.log
│       │       │       │   └── state-change.log
│       │       │       └── server-start-stdout-stderr.log
│       │       ├── MiniKdc-0-281473793298144
│       │       │   └── ducker05
│       │       │       └── minikdc.log
│       │       ├── VerifiableProducer-0-281473792730400 # 消费者日志
│       │       │   └── ducker04
│       │       │       └── verifiable_producer.log
│       │       ├── report.json
│       │       ├── report.txt
│       │       ├── test_log.debug
│       │       └── test_log.info # 测试过程的 std 信息
├── report.css
├── report.html # 测试的整体结果报告
├── report.json
├── report.txt
├── report.xml
├── session_log.debug
└── session_log.info

对于成功的测试，只会保留 info 级别日志；对于失败的测试，还会保留 debug 级别的日志。

使用以下命令销毁测试容器：

./tests/Docker/ducker-ak down

2.4 细节信息

默认情况下，系统测试会启动 14 个 ducker 容器 ducker01 ~ ducker14(前文中打包的测试镜像的实例) + 1 个 S3 服务容器。所有 ducker 容器只负责一个职能，即作为 Kafka 节点、 producer、consumer 等。其中 ducker01 为管控容器，负责拉起关闭 Kafka 节点、拷贝日志之类的操作。S3 服务容器使用了 localstack[3] 在本地模拟 S3 存储。

每个 ducker 容器会将宿主机上的工程主目录映射到容器的 /opt/Kafka-dev 下，默认测试的都是开发版本的 Kafka 代码。在 ducker 容器的 /opt 目录下，还可以看到其他版本的 Kafka 产物：

ducker@ducker01:/opt$ ls
kafka-0.10.0.1  kafka-0.10.2.2  kafka-0.8.2.2  kafka-1.0.2  kafka-2.0.1  kafka-2.2.2  kafka-2.4.1  kafka-2.6.3  kafka-2.8.2  kafka-3.1.2  kafka-3.3.2  kafka-3.5.2  kafka-3.7.0  kibosh
kafka-0.10.1.1  kafka-0.11.0.3  kafka-0.9.0.1  kafka-1.1.1  kafka-2.1.1  kafka-2.3.1  kafka-2.5.1  kafka-2.7.2  kafka-3.0.2  kafka-3.2.3  kafka-3.4.1  kafka-3.6.1  kafka-dev

在某些系统测试中，这些产物会用来验证 Kafka 各个版本的客户端和服务端能够互相兼容。

系统测试的过程大致可以分为以下步骤：

  1. 测试扫描：统计本次运行涉及的所有 case；

  2. 节点分配：从 14 个 ducker 容器中分配节点，这些节点将负责执行 Service 的实现（KafkaService、 VerifiableProducer、MiniKdc 等）；

  3. Service 的启动：为了保证幂等性，一般是先做现场的清理（stop service、日志删除等），然后按照系统测试的配置启动 Service。

  4. 执行测试：所有 Service ready 以后，执行系统测试的详细逻辑；

  5. 收尾：一次测试结束后，记录测试的结果、拷贝测试过程中的日志，并清理现场（stop service、日志删除等）

需要注意的是，上述过程均由 ducker01 容器管控，管控的方式是 SSH 免密登录到目标容器，然后执行命令。集成测试的验证逻辑，例如生产消息的数目是否预期，也是基于 SSH 远程查询、解析来实现的。

另外，所有测试是串行执行的，会复用这 14 个 ducker 容器 + 1 个 S3 服务容器。

2.5 参数化测试

在软件测试中，参数化测试是一种常见的策略，它允许开发者使用不同的输入数据来执行相同的测试用例，从而实现更全面的覆盖。这种方法非常适合于需要测试多种输入组合的情况。Kafka的系统测试采用了这种优秀的测试参数注入设计。以其系统测试背后的一个例子为例，我们可以看到测试方法上有两种注解：
ꔷ @cluster：指定测试涉及的最大节点数；
ꔷ @matrix：测试参数注入；

@cluster(num_nodes=4)
@matrix(inter_broker_security_protocol=['PLAINTEXT', 'SSL'], metadata_quorum=[quorum.isolated_kraft])
@matrix(inter_broker_security_protocol=['SASL_SSL'], inter_broker_sasl_mechanism=['PLAIN', 'GSSAPI'],metadata_quorum=[quorum.isolated_kraft])
def test_multiple_kraft_security_protocols(self, inter_broker_security_protocol, inter_broker_sasl_mechanism='GSSAPI', metadata_quorum=quorum.isolated_kraft)

@matrix注解用于定义参数的可能值，它可以看作是一个参数的集合。例如，@matrix(inter_broker_security_protocol=[‘PLAINTEXT’, ‘SSL’], metadata_quorum=[quorum.isolated_kraft]) 这个注解表示方法参数 inter_broker_security_protocol 可以分别取值 ‘PLAINTEXT’ 和 ‘SSL’，而 metadata_quorum 取值为 quorum.isolated_kraft。这样，就形成了一个2 * 1的测试矩阵，即两种可能的测试场景。

如果存在多个 @matrix 注解，那么会生成一个包含所有可能组合的测试矩阵。例如，在这个例子中，test_multiple_kraft_security_protocols 方法使用一份代码构造了21 + 12*1 = 4种测试场景。

这种矩阵式的测试参数方法有一个显著的优点，那就是它可以大大减少重复的代码。通过使用参数化测试，开发者可以用一份代码来测试许多不同的场景，从而提高代码的可重用性，同时也提高了测试的效率和覆盖率。

03 AutoMQ系统测试现状

AutoMQ 完全适配并继承了 Apache Kafka 的系统测试。由于 AutoMQ 使用 S3 作为主要存储， 所以系统测试中引入了 S3 服务容器，并在测试之间清理 S3 的数据（以保证测试隔离）。

系统测试很好地监督了 AutoMQ 的代码改动，确保其对 Apache Kafka 保证100%的兼容性。例如，ISSUE-751[4] 中，QuotaTest 及时发现了此前 AutoMQ 对网络层模型的修改带来的衍生问题。

AutoMQ 目前只支持 KRaft 模式下启动 Kafka 集群，因此我们更关注 KRaft 模式下的系统测试。除了适配已有的系统测试 case，在 2024 年 1 月，我们还全量改造了所有 case 以支持 KRaft 模式的测试：由于 Kafka 早期是基于 zk 集群运行的，大量系统测试还是仅限 zk 模式下运行的，我们梳理并改造了相关测试，以支持 KRaft 模式下的验证。

截止到 2024 年 4 月，AutoMQ 共有 543 个系统测试案例（其余基本都是 zk 模式的测试，或者已经废弃的测试）。自 2023 年以来，系统测试每日由 github action 触发，并自动报告测试的结果：

注：上图是 Kafka Connect 模块中系统测试概览报告，并不是全量的报告。你也可以通过 [5] 和 [6] 查看 AutoMQ main 分支下的代码每天全量系统测试的结果。

利用系统测试，AutoMQ 可以确保 0.9.x 版本以来的 Kafka 客户端与 AutoMQ 的兼容性，以及 Kafka Connect 等衍生产品与 AutoMQ 的兼容性。此外还可以验证真实用户场景（事务消息、消费者动态平衡）、灾难场景（Kafka node 宕机、 进程卡死）下 AutoMQ 服务的健壮性。

04 总结

本文主要介绍了 Kafka 的系统测试框架，并简要介绍了系统测试的原理。AutoMQ 完全继承了 Apache Kafka 丰富的系统测试案例，模拟真实用户使用 Kafka 集群的行为，并验证行为的结果是否符合预期。500+ 系统测试案例在一定程度上保证了 AutoMQ 代码的健壮性，同时能够保证 AutoMQ 对 Apache Kafka 的 100% 兼容性。

引用

[1]ducktape: https://ducktape.readthedocs.io/en/latest/ 
[2] AutoMQ: https://github.com/AutoMQ/AutoMQ 
[3] localstack: https://github.com/localstack/localstack 
[4] ISSUE-751: https://github.com/AutoMQ/automq/issues/751 
[5] main E2E tests：Nightly Main E2E tests · Workflow runs · AutoMQ/AutoMQ 
[6] extra E2E tests: Nightly Main E2E tests · Workflow runs · AutoMQ/AutoMQ

关于我们

我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队，曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念，重新设计并实现了 Apache Kafka 和 Apache RocketMQ，带来高达 10 倍的成本优势和百倍的弹性效率提升。
🌟 GitHub 地址：https://github.com/AutoMQ/automq
💻 官网：https://www.automq.com
👀 B站：AutoMQ官方账号
🔍 视频号：AutoMQ

这篇关于AutoMQ 系统测试体系揭秘的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/949342。

相关文章

JWT + 拦截器实现无状态登录系统

JWT + 拦截器实现无状态登录系统

《JWT+拦截器实现无状态登录系统》JWT（JSONWebToken）提供了一种无状态的解决方案：用户登录后,服务器返回一个Token,后续请求携带该Token即可完成身份验证,无需服务器存储会话... 目录✅ 引言 一、JWT 是什么？ 二、技术选型 三、项目结构 四、核心代码实现4.1 添加依赖（pom
阅读更多...
基于Python实现自动化邮件发送系统的完整指南

基于Python实现自动化邮件发送系统的完整指南

《基于Python实现自动化邮件发送系统的完整指南》在现代软件开发和自动化流程中,邮件通知是一个常见且实用的功能,无论是用于发送报告、告警信息还是用户提醒,通过Python实现自动化的邮件发送功能都能... 目录一、前言：二、项目概述三、配置文件 `.env` 解析四、代码结构解析1. 导入模块2. 加载环
阅读更多...
linux系统上安装JDK8全过程

linux系统上安装JDK8全过程

《linux系统上安装JDK8全过程》文章介绍安装JDK的必要性及Linux下JDK8的安装步骤,包括卸载旧版本、下载解压、配置环境变量等,强调开发需JDK,运行可选JRE,现JDK已集成JRE... 目录为什么要安装jdk？1.查看linux系统是否有自带的jdk：2.下载jdk压缩包2.解压3.配置环境
阅读更多...
Linux查询服务器系统版本号的多种方法

Linux查询服务器系统版本号的多种方法

《Linux查询服务器系统版本号的多种方法》在Linux系统管理和维护工作中,了解当前操作系统的版本信息是最基础也是最重要的操作之一,系统版本不仅关系到软件兼容性、安全更新策略,还直接影响到故障排查和... 目录一、引言：系统版本查询的重要性二、基础命令解析：cat /etc/Centos-release详
阅读更多...
更改linux系统的默认Python版本方式

更改linux系统的默认Python版本方式

《更改linux系统的默认Python版本方式》通过删除原Python软链接并创建指向python3.6的新链接,可切换系统默认Python版本,需注意版本冲突、环境混乱及维护问题,建议使用pyenv... 目录更改系统的默认python版本软链接软链接的特点创建软链接的命令使用场景注意事项总结更改系统的默
阅读更多...
基于Python Playwright进行前端性能测试的脚本实现

基于Python Playwright进行前端性能测试的脚本实现

《基于PythonPlaywright进行前端性能测试的脚本实现》在当今Web应用开发中,性能优化是提升用户体验的关键因素之一,本文将介绍如何使用Playwright构建一个自动化性能测试工具,希望... 目录引言工具概述整体架构核心实现解析1. 浏览器初始化2. 性能数据收集3. 资源分析4. 关键性能指
阅读更多...
在Linux系统上连接GitHub的方法步骤(适用2025年)

在Linux系统上连接GitHub的方法步骤(适用2025年)

《在Linux系统上连接GitHub的方法步骤(适用2025年)》在2025年,使用Linux系统连接GitHub的推荐方式是通过SSH(SecureShell)协议进行身份验证,这种方式不仅安全,还... 目录步骤一：检查并安装 Git步骤二：生成 SSH 密钥步骤三：将 SSH 公钥添加到 github
阅读更多...
Linux系统中查询JDK安装目录的几种常用方法

Linux系统中查询JDK安装目录的几种常用方法

《Linux系统中查询JDK安装目录的几种常用方法》：本文主要介绍Linux系统中查询JDK安装目录的几种常用方法,方法分别是通过update-alternatives、Java命令、环境变量及目... 目录方法 1：通过update-alternatives查询（推荐）方法 2：检查所有已安装的 JDK方
阅读更多...
Linux系统之lvcreate命令使用解读

Linux系统之lvcreate命令使用解读

《Linux系统之lvcreate命令使用解读》lvcreate是LVM中创建逻辑卷的核心命令,支持线性、条带化、RAID、镜像、快照、瘦池和缓存池等多种类型,实现灵活存储资源管理,需注意空间分配、R... 目录lvcreate命令详解一、命令概述二、语法格式三、核心功能四、选项详解五、使用示例1. 创建逻
阅读更多...
使用Python构建一个高效的日志处理系统

使用Python构建一个高效的日志处理系统

《使用Python构建一个高效的日志处理系统》这篇文章主要为大家详细讲解了如何使用Python开发一个专业的日志分析工具,能够自动化处理、分析和可视化各类日志文件,大幅提升运维效率,需要的可以了解下... 目录环境准备工具功能概述完整代码实现代码深度解析1. 类设计与初始化2. 日志解析核心逻辑3. 文件处
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2