关于云原生:Milvus-20-质量保障系统详解

编者按：本文具体介绍了 Milvus 2.0 品质保障系统的工作流程、执行细节，以及提高效率的优化计划。

内容纲要：

品质保障总体介绍
测试内容的关注点
开发团队与品质保障团队如何协同
Issue 的治理流程
公布规范
测试模块介绍
总体介绍
单元测试
功能测试
部署测试
可靠性测试
稳定性和性能测试
提效办法和工具
Github Action
性能测试工具
品质保障总体介绍

架构设计图对于品质保障同样重要，只有充沛理解被测对象，能力制订出更正当和高效的测试计划。Milvus 2.0 是一个云原生、分布式的架构，次要的入口通过 SDK 进入，外部有很多分层的逻辑。因此对于用户来说，SDK 这一端是十分值得关注的一部分，对 Milvus 测试时，首先会对 SDK 这一端进行功能测试，并通过 SDK 去发现 Milvus 外部可能存在的问题。同时 Milvus 也是一个数据库，因而对于数据库的各种零碎测试也会波及到。

云原生、分布式的架构，既会给测试带来益处，也会引入各种挑战。益处在于，区别于传统的本地部署运行，在 k8s 集群中部署和运行能尽可能保障软件在开发和测试时环境统一。挑战则是分布式的零碎变得复杂，引入了更多的不确定性，测试工作量和难度的减少。例如微服务化后服务数量减少、机器的节点会变多，两头阶段越多，出错的可能性越大，测试时就须要思考各个状况。

依据产品的性质、用户的需要，Milvus 测试的内容与优先级如下图所示。

首先在性能（Function）上，关注接口是否与设计的预期合乎。

其次在部署（Deployment）上，关注 standalone 或者 cluster 模式下重启和降级是否能胜利。

第三在性能（Performance）上，因为是流批一体的实时剖析数据库，所以对于速度会更器重，会更关注插入、建设索引、查问的性能。

第四在稳定性（Stability）上，关注 Milvus 在失常的负载下的失常运行工夫，预期指标是 5 – 10 天。

第五在可靠性（Reliability）上，关注谬误产生时 Milvus 的体现，以及谬误打消是否还能失常工作。

第六是配置问题（Configuration），须要验证每个凋谢进去的配置项是否失常工作，变更是否失效。

最初是兼容性问题（Compatibility），次要是体现在硬件上和软件配置上。

由图可知，性能和部署是放在最高等级的，性能、稳定性、可靠性放在第二等级，最初将配置和兼容性放在第三的地位。不过，这个等级重要性也是相对而言的。

个别用户会认为质量保证的工作是仅仅调配给质量保证团队的，然而软件开发过程中，品质须要多方团队单干以失去保障。

最开始的阶段由开发设计文档，品质保障团队依据设计文档写测试计划。这两个文档须要测试和开发独特参加以缩小了解误差。公布前会制订这一版本的指标，包含性能、稳定性、bug 数须要收敛到什么水平等。在开发过程中，开发侧重于编码性能的实现，性能实现之后品质保障团队会进行测试和验证。这两个阶段会轮巡很多遍，品质保障团队和开发团队须要每天放弃信息同步。此外，除了自身性能的开发验证，开源的产品还会收到很多来自于社区的问题，也会依据优先级进行解决。

在最初阶段，如果产品达到了公布规范，团队就会选定一个工夫节点，公布一个新的镜像。在公布前须要筹备一个 release tag 和 release note，关注这个版本实现了什么性能，修复了什么 issue，前期品质保障团队也会针对这个版本出一个测试报告。

品质保障团队更多地关注于产品开发中的 issue。Issue 的作者除了品质保障团队的成员，还有大量的内部用户，因而须要标准每个 issue 的填写信息。每个 issue 都有一个模板，要求作者提供一些信息，例如以后应用的版本，机器配置信息，而后你的预期是什么？理论的返回后果是什么？如何去复现这个 issue，而后品质团队和开发团队会持续去跟进。

在创立这个 issue 之后，首先会 assign 给品质保障团队的负责人，而后负责人会对这个 issue 进行一些状态流转。如果 issue 成立且有足够多的信息，后续会有若干种状态，如：是否解决了；是否能复现；是否与之前有反复；呈现概率大小；优先级大小。如果确认存在缺点，开发团队会提交 PR，关联上这个 issue，进行批改。在失去验证后，这个 issue 会被敞开，如果之后发现仍然存在问题，还能够 reopen。此外，为了进步 issue 的管理效率，还会引入标签和机器人，用于对 issue 分类和状态流转。

是否公布次要指以后这个版本是否达到预期要求。例如上图是一个大抵的状况，RC6 到 RC7，RC8 和 GA 的规范。随着版本的推动，对 Milvus 的品质提出更高的要求：

从原先 50M 的数量级，逐步演进到 1B 的数量级
在稳定性的工作运行中，由单任务变成混合工作，时长逐步由小时级变成天级
对于代码而言，也在逐步进步它的代码覆盖率
……
此外，随着版本的更替，也会退出其余的测试项。例如在 RC7 的时候，提出了要有一个兼容项，降级的时候要有兼容；在 GA 的时候，引入更多对于混沌工程的测试

第二局部是对于每个测试模块的一些具体细节。

业界有写代码就是写 bug 的戏谑，从下图能够看到，85% 的 bug 是由 coding 阶段引入的。

从测试的角度来看，代码编写到版本公布这个过程中，顺次能够通过 Unit Test / Functional Test / System Test 去发现 bug；然而随着阶段的推移，修复 bug 的老本也会递增，所以往往偏向于早发现早修复。不过，每个阶段的测试有本人的侧重点，不可能只通过一种测试伎俩就发现所有的 bug。

开发从编写代码到代码合并到主分支这个阶段别离会从 UT、code coverage 和 code review 去保障代码品质，这几项也体现在 CI 中。在提交 PR 到代码合并的过程中，须要通过动态代码查看、单元测试、代码覆盖率规范以及 reviewer 的代码审核。

在合并代码时，同样须要通过集成测试。为了保障整个 CI 的工夫不会太长，在这个集成测试外面，次要运行 L0 和 L1 这些具备高优先级标签的 case。通过所有查看后，就能够到 milvusdb/milvus-dev 仓库中公布这个 PR 构建的镜像。在镜像公布之后，会设置定时工作对最新的镜像进行前文提到的多种测试：全量的原有功能测试，新个性的功能测试，部署测试，性能测试，稳定性测试，混沌测试等。

单元测试能够在尽可能早的阶段发现软件存在的 bug，同时也能够为代码重构提供验证规范。在 Milvus 的 PR 准入规范中，设定了代码的单元测试 80% 覆盖率指标。

https://app.codecov.io/gh/mil…

对 Milvus 的功能测试，次要是通过 pymilvus 这个 SDK 作为切入点。

功能测试次要关注于接口是否依照预期工作。

输出失常的参数或采纳失常的操作时，SDK 是否能返回预期的后果
当参数或操作是异样的时候，SDK 是否能 handle 住这些谬误，同时可能返回一些正当的错误信息

下图是以后的功能测试框架，整体而言是基于目前支流的测试框架 pytest，并对 pymilvus 进行了一次封装，提供了接口自动化测试能力。

采纳上述测试框架，而不是间接用 pymilvus 原生的接口，是因为在测试过程中须要提取出一些公共办法，复用一些罕用的函数。同时也会封装一个 check 的模块，能更不便地去校验一些预期和实在值。

以后 tests/python_client/testcases 目录下的性能测试用例曾经有 2700+，基本上笼罩了 pymilvus 的所有接口，且蕴含侧面用例和背面用例。功能测试作为 Milvus 的基本功能保障，通过自动化和继续集成，严格把控每一个提交的 PR 品质。

部署测试中，反对 Milvus 部署状态有 standalone 和 cluster，部署的形式有 docker 或者 helm。部署实现之后，须要对系统执行 restart 和 upgrade 的操作。

重启测试，次要是验证数据的长久化，即重启前的数据在重启后是否持续应用；降级测试，次要是验证数据的兼容性，避免在不知情的状况下引入了不兼容的数据格式。

重启测试和降级测试能够对立为如下的测试流程：

如果是重启测试，两次部署应用雷同镜像；如果是降级测试，第一次部署应用旧版本镜像，第二次部署应用新版本镜像。第二次部署时，无论是重启还是降级，均会保留第一次部署后的测试数据（Volumes 文件夹或者 PVC）。在 Run first test 这个步骤中，会创立多个 collection，并对每个 collection 执行不同的操作，使其处于不同的状态，例如：

create collection
create collection –> insert data
create collection –> insert data –>load
create collection –> insert data –>flush
create collection –> insert data –>flush –>load
create collection –> insert data –>flush –> create index
create collection –> insert data –>flush –> create index –> load
……

在 Run second test 这个步骤中会进行两种验证：

之前创立的 collection 各种性能仍然可用
能够创立新的 collection，同样各种性能仍然可用

以后针对云原生，分布式产品的可靠性，大部分的公司都会通过混沌工程的办法进行测试。混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们辨认进去。通过被动制作故障，测试零碎在各种压力下的行为，辨认并修复故障问题，防止造成严重后果。

在执行 chaos test 时，抉择了 Chaos Mesh 作为故障注入工具。Chaos Mesh 是 PingCAP 公司在测试 TiDB 可靠性的过程中孵化进去的，非常适合用于云原生分布式数据库的可靠性测试。

在故障类型中，实现了以下几种故障类型：

首先就是 pod kill，测试范畴是所有的组件，模仿节点宕机的状况
其次 pod failure，次要是关注于 work node 的多正本状况下，有一个 pod 不能工作，整个零碎还能失常运作
第三个是 memory stress，偏重内存和 CPU 的压力，次要注入到 work node 的节点
最初一个 network partition，即 pod 与 pod 之间的一个通信隔离。Milvus 是一个存储计算拆散，工作节点和协调节点拆散的多层架构，不同组件之间的通信十分多，须要通过 network partition 测试它们之间的相互依赖关系

通过建构一套框架，较为自动化地实现 Chaos Test。

流程：

通过读取部署配置，初始化一个 Milvus 集群
集群状态 ready 后，首先会运行一个 e2e 测试，验证 Milvus 的性能可用
运行 hello_milvus.py，次要用于验证数据的可长久化，会在故障注入前创立一个 hello_milvus 的 collection，进行数据插入，flush，create index，load，search，query。留神，不会将 collection release 和 drop
创立一个监测对象，该对象次要是开启 6 个线程，别离一直执行 create，insert，flush，index，search，query 操作

checkers = {Op.create: CreateChecker(),
    Op.insert: InsertFlushChecker(),
    Op.flush: InsertFlushChecker(flush=True),
    Op.index: IndexChecker(),
    Op.search: SearchChecker(),
    Op.query: QueryChecker()}

故障注入前进行第一次断言：所有操作预期胜利
注入故障：解析定义故障的 yaml 文件，通过 Chaos Mesh，向 Milvus 零碎中注入故障，例如使 query node 每 5s 被 kill 一次
故障注入期间进行第二次断言：判断针对故障期间的 Milvus 执行的各个操作返回的后果与预期是否统一
删除故障：通过 Chaos Mesh 删除之前注入的故障
故障删除，Milvus 复原服务后（所有 pod 都 ready），进行第三次断言：所有操作预期胜利
运行一个 e2e 测试，验证 Milvus 的性能可用，因为第三次断言，有些操作会在 chaos 注入期间被阻塞，即便故障打消后，仍然被阻塞，导致第三次断言不能如预期一样全副胜利。因而减少这个步骤辅助第三次断言的判断，并临时将这次 e2e 测试作为 Milus 是否复原的规范
运行 hello_milvus.py，加载之前创立的 collection，并对该 collection 执行一系列操作，判断故障前的数据在故障复原后，是否仍然可用
日志收集

稳定性测试的目标：

Milvus 能够在失常程度的压力负载下，安稳运行设定的时长
在运行过程中，零碎应用的资源放弃安稳，Milvus 的服务失常

次要思考两种负载场景：

读密集：search 申请 90%，insert 申请 5%，其余 5%。这种场景次要是离线场景，数据导入之后，根本不更新，次要提供查问服务
写密集：insert 申请 50%，search 申请 40%，其余 10%。这种场景次要是在线场景，须要提供边插入边查问的服务

查看项：

内存使用量平滑
CPU 使用量平滑
IO 延时平滑
Milvus 的 pod 状态失常
Milvus 服务响应工夫平滑

性能测试的目标：

对 Milvus 各个接口进行性能摸底
通过性能比照，找到接口最佳的参数配置
作为性能基准，避免之后的版本呈现性能降落
找到性能瓶颈点，为性能调优提供参考

次要思考的性能场景：

数据插入性能
性能指标：吞吐量
变量：每批次插入向量数，……
索引构建性能
性能指标：索引构建工夫
变量：索引类型，index node 数量，……
向量查问性能
性能指标：响应工夫，每秒查问向量数，每秒申请数，召回率
变量：nq，topK，数据集规模大小，数据集类型，索引类型，query node 数量，部署模式，……
……

解析并更新配置，定义指标
server-configmap 对应的是 Milvus 单机或者集群的配置
client-configmap 对应的是测试用例配置
配置服务端和客户端
数据筹备
客户端与服务端之间的申请交互
指标数据的上报与展现

由前文可知，测试中很多步骤流程是雷同的，次要是批改 Milvus server 端的配置，client 端的配置，接口的传入参数。在多项配置下，通过排列组合，须要执行很屡次试验能力比拟全面地笼罩各种测试场景，因而代码复用、流程复用、测试效率就是十分重要的问题。

对原有办法进行一个 api_request 的装璜器封装，设置成相似于一个 API gateway，对立去接管所有的 API 申请，发送给 Milvus 而后对立接管响应，再返回给 client。这样更容易去捕获一些日志信息，比方传的参数、返回的后果。同时返回的后果能够通过 checker 模块去校验，便于将所有的查看办法定义在同一个 checker 模块
设置默认参数，将多个必要的初始化步骤封装成一个函数，原先须要大量代码实现的性能就能够通过一个接口实现。这种设定可能缩小大量冗余反复的代码，使每个测试用例更简略清晰
每个测试用例都是关联独有的 collection 进行测试，保障了测试用例之间的数据隔离性。在每个测试用例的的执行起始步骤，创立新的 collection 用于测试，在测试完结后也会删除对应的 collection
因为每个测试用例都是相互独立的，在执行测试用例的时候，能够通过 pytest 的插件 pytest -xdist 并发执行，进步执行效率

GitHub Action 的长处：

与 GitHub 深度集成，原生的 CI/CD 工具
对立配置的机器环境，同时预装了丰盛的常用软件开发工具
反对多种操作系统和版本：Ubuntu, Mac 和 Windows-server
领有丰盛的插件市场，提供了各种开箱即用的性能
通过 matrxi 进行排列组合，复用同一套测试流程，反对并发的 job，从而提高效率

部署测试和可靠性测试都须要独立隔离的环境，非常适合在 GitHub Action 上进行小规模数据量的测试。通过每日定时运行，测试最新的 master 镜像，起到日常巡检的性能。

Argo workflow：通过创立 workflow，实现工作的调度，将各个流程串联起来。从右图能够看出，通过 Argo 能够实现多个工作同时运行
Kubernetes Dashboard：可视化 server-configmap 和 client-configmap
NAS：挂载罕用的 ann-benchmark 数据集
InfluxDB 和 MongoDB: 保留性能指标后果
Grafana：服务端资源指标监控，客户端性能指标监控
Redash: 性能图表展现

完整版视频解说请戳：
https://www.bilibili.com/vide…

如果你在应用的过程中，对 Milvus 有任何改良或倡议，欢送在 GitHub 或者各种官网渠道和咱们保持联系～

Zilliz 以从新定义数据迷信为愿景，致力于打造一家寰球当先的开源技术创新公司，并通过开源和云原生解决方案为企业解锁非结构化数据的暗藏价值。

Zilliz 构建了 Milvus 向量数据库，以放慢下一代数据平台的倒退。Milvus 数据库是 LF AI & Data 基金会的毕业我的项目，可能治理大量非结构化数据集，在新药发现、举荐零碎、聊天机器人等方面具备宽泛的利用。

品质保障总体介绍

测试内容的关注点

开发团队与品质保障团队如何协同

Issue 的治理流程

公布规范

测试模块介绍

总体介绍

单元测试

功能测试

部署测试

可靠性测试

稳定性和性能测试

稳定性测试

性能测试

测试框架和流程

提效办法和工具

Github Action

性能测试工具