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。

相关文章

golang程序打包成脚本部署到Linux系统方式

golang程序打包成脚本部署到Linux系统方式

《golang程序打包成脚本部署到Linux系统方式》Golang程序通过本地编译（设置GOOS为linux生成无后缀二进制文件）,上传至Linux服务器后赋权执行,使用nohup命令实现后台运行,完... 目录本地编译golang程序上传Golang二进制文件到linux服务器总结本地编译Golang程序
阅读更多...
Linux系统性能检测命令详解

Linux系统性能检测命令详解

《Linux系统性能检测命令详解》本文介绍了Linux系统常用的监控命令（如top、vmstat、iostat、htop等）及其参数功能,涵盖进程状态、内存使用、磁盘I/O、系统负载等多维度资源监控,... 目录toppsuptimevmstatIOStatiotopslabtophtopdstatnmon
阅读更多...
linux重启命令有哪些? 7个实用的Linux系统重启命令汇总

linux重启命令有哪些? 7个实用的Linux系统重启命令汇总

《linux重启命令有哪些?7个实用的Linux系统重启命令汇总》Linux系统提供了多种重启命令，常用的包括shutdown-r、reboot、init6等，不同命令适用于不同场景，本文将详细... 在管理和维护 linux 服务器时，完成系统更新、故障排查或日常维护后，重启系统往往是必不可少的步骤。本文
阅读更多...
使用Python进行GRPC和Dubbo协议的高级测试

使用Python进行GRPC和Dubbo协议的高级测试

《使用Python进行GRPC和Dubbo协议的高级测试》GRPC（GoogleRemoteProcedureCall）是一种高性能、开源的远程过程调用（RPC）框架,Dubbo是一种高性能的分布式服... 目录01 GRPC测试安装gRPC编写.proto文件实现服务02 Dubbo测试1. 安装Dubb
阅读更多...
Python的端到端测试框架SeleniumBase使用解读

Python的端到端测试框架SeleniumBase使用解读

《Python的端到端测试框架SeleniumBase使用解读》：本文主要介绍Python的端到端测试框架SeleniumBase使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全... 目录SeleniumBase详细介绍及用法指南什么是 SeleniumBase？SeleniumBase
阅读更多...
Mac系统下卸载JAVA和JDK的步骤

Mac系统下卸载JAVA和JDK的步骤

《Mac系统下卸载JAVA和JDK的步骤》JDK是Java语言的软件开发工具包,它提供了开发和运行Java应用程序所需的工具、库和资源,：本文主要介绍Mac系统下卸载JAVA和JDK的相关资料,需... 目录1. 卸载系统自带的 Java 版本检查当前 Java 版本通过命令卸载系统 Java2. 卸载自定
阅读更多...
基于Python实现一个简单的题库与在线考试系统

基于Python实现一个简单的题库与在线考试系统

《基于Python实现一个简单的题库与在线考试系统》在当今信息化教育时代,在线学习与考试系统已成为教育技术领域的重要组成部分,本文就来介绍一下如何使用Python和PyQt5框架开发一个名为白泽题库系... 目录概述功能特点界面展示系统架构设计类结构图Excel题库填写格式模板题库题目填写格式表核心数据结构
阅读更多...
Linux系统中的firewall-offline-cmd详解(收藏版)

Linux系统中的firewall-offline-cmd详解(收藏版)

《Linux系统中的firewall-offline-cmd详解(收藏版)》firewall-offline-cmd是firewalld的一个命令行工具,专门设计用于在没有运行firewalld服务的... 目录主要用途基本语法选项1. 状态管理2. 区域管理3. 服务管理4. 端口管理5. ICMP 阻断
阅读更多...
Windows 系统下 Nginx 的配置步骤详解

Windows 系统下 Nginx 的配置步骤详解

《Windows系统下Nginx的配置步骤详解》Nginx是一款功能强大的软件,在互联网领域有广泛应用,简单来说,它就像一个聪明的交通指挥员,能让网站运行得更高效、更稳定,：本文主要介绍W... 目录一、为什么要用 Nginx二、Windows 系统下 Nginx 的配置步骤1. 下载 Nginx2. 解压
阅读更多...
如何确定哪些软件是Mac系统自带的? Mac系统内置应用查看技巧

如何确定哪些软件是Mac系统自带的? Mac系统内置应用查看技巧

《如何确定哪些软件是Mac系统自带的?Mac系统内置应用查看技巧》如何确定哪些软件是Mac系统自带的？mac系统中有很多自带的应用，想要看看哪些是系统自带，该怎么查看呢？下面我们就来看看Mac系统内... 在MAC电脑上，可以使用以下方法来确定哪些软件是系统自带的：1.应用程序文件夹打开应用程序文件夹
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2