共计 4439 个字符，预计需要花费 12 分钟才能阅读完成。
引言
Apache Flink 是面向数据流处理和批处理的分布式开源计算框架，2016 年阿里巴巴引入 Flink 框架，改造为 Blink。2017 年，阿里整合了所有流计算产品，决定以 Blink 引擎为基础，打造一款全球领先的实时计算引擎。当年双 11，Blink 支持了二十多个事业部/群，同时运行了上千个实时计算 job，每秒处理的日志数峰值达到惊人的 4.7 亿。因此 Blink 的可靠性和稳定性保障变得极其重要，搜索事业部的质量团队为此专门成立了 Blink 测试小组，通过一年多的努力，建立了从代码质量到持续集成再到预发测试的全面的测试体系，帮助 Blink 的质量取得大幅提高。
Blink 测试平台介绍
Blink 测试团队为 Blink 质量量身打造 Blink 测试平台，内容如下图所示：
Blink 测试平台包含了三个测试阶段：代码质量校验阶段，主要进行静态代码扫描、单元测试和基于 minicluster 的测试；集成测试阶段，主要是进行功能测试、性能测试和带有破坏性的稳定性测试；而预发测试阶段，主要是利用用户的 job 进行仿真测试，并在版本发布之前做最后的版本兼容性测试。
平台选取部分测试集合纳入到 precommit 的验证中，可尽早发现代码中问题，而大规模的功能、性能、稳定性测试，通常作为 dailybuild 的集合。另外，Blink 测试平台建立了较为完善的质量度量体系，除去对代码覆盖率的统计及变化的分析，还可一键生成测试报告，并对不同版本的质量进行横向对比。
代码质量校验阶段
代码质量校验阶段是整个 Blink 质量保障的基础。主要包含单元测试，利用 aone 提供的 ” 集团代码规约扫描 ” 工具对代码进行规范扫描，单机运行的基于 minicluster 的集成测试，只有这三个阶段都测试通过后才允许 Blink 代码提交到项目 git。
功能测试
Blink 功能测试框架使用 defender，该框架是由 pytest[1] 改造而来，很好地支持了 BlinkSql 测试的特性，并支持第三方插件的引入。在测试集群中可以端到端的对某一场景进行精准测试。具体流程如下图所示，支持 IDE 和 Jenkins 两种触发模式，yarn_job、yarn_session 和 local 三种 case 运行调度模式。执行结束后通过 web 页面或邮件的形式对结果进行展示，并对运行结果进行持久化。具有如下优势：
1、case 的统一调度与精细化管理：现在 Blink 在 defender 上有 12 个场景 4000 多个 case，可以每天定时进行 dailyrun，如果某一类别的 case 出现问题可单独执行，并可在页面上显示详情。
2、case 的三种运行模式满足了不同场景的测试需求：其中 yarn_session 模式对一个模块中存在 sqlCase 的场景较为适用，可大大减少与 Yarn 交互的时间。
3、case 灵活配置：不仅可以支持系统配置，对每个 case 集所需资源（slot，memory 等）或集群其他配置的不同进行单独配置。
4、一个 case 可同时支持批和流两种运行类型。
5、client 类型灵活扩展：可对现有数据存储和服务进行集成和扩展。现已支持多类型 data store 读写服务，yarn_session 的启动，Blink job 交互等。
性能测试
Blink 作为实时大数据处理引擎，其对单位时间内的数据处理能力和数据处理的实时性提出了非常严苛的要求。因此，性能测试是整个 Blink 测试中非常重要的一环，是衡量 Blink 新版本能否发布的核心标准之一。
Blink 的性能测试主要包含 Operator 性能测试、SQL 性能测试和 runtime 性能测试：
Operator 指构成 SQL 语义的一个原子操作，例如 Sum，Aggregate 等，是一个不能再分割的算子。Operator 的性能测试主要用于监控单个算子在整个开发过程中的性能变化，以保证局部处理的优化和提高。目前，Operator 的测试分成两个部分：单个算子的性能测试和算子组合的性能测试。Operator 测试以 Daily Run 的方式反馈性能的变化。
SQL 性能测试主要用于监控版本开发过程中单个 SQL 的性能变化。TPCH 和 TPCDS 是业界 SQL 标准性能测试集，分别有 22 和 103 个测试用例。测试平台将其引入到 Blink 性能测试中，以更全面地衡量 Blink 的性能变化。
Runtime 性能测试主要为了保障 runtime 层面性能不回退，主要包含端到端性能测试和模块性能测试。端到端性能测试首先根据梳理出测试场景，关注各场景 job 在指定数据量下的 job 运行时间，模块性能测试主要包含网络层性能测试，调度层性能测试，failover 性能测试等，更关注在特定场景下 job 的处理时间。
性能测试未来规划是将 E2E 性能测试、模块级别性能测试和参数调整整体联动起来，使其能够更好协助开发定位性能问题 root cause 和查看参数调优效果。
稳定性测试
对于支持高并发、多节点，集群物理环境复杂的分布式系统来说，类似磁盘打满、网络延迟等物理节点的异常很难避免。Blink 作为一个高可用的分布式系统，必然要做到在异常情况下也能保证系统的稳定运行及数据的正常产出。“避免失败的最好方法就是不断地失败”，因此，在 Blink 任务运行期间将可能发生的异常模拟出来，就能够验证 Blink 的稳定性。
我们把异常场景分为两类：一类是 ” 黑猴子 ”，该类场景与运行环境相关，包括机器重启、网络异常、磁盘异常、cpu 异常等，这部分异常主要用 shell 命令来模拟；另一类异常是 ” 白猴子 ”，此类场景与 Blink job 相关，包括 rpc 消息超时，task 异常，heart beat 消息超时等，主要通过 byteman[2] 软件注入的方式来实现。在稳定性测试中，monkey 作为调度会随机选取上述异常场景进行组合，以模拟线上可能出现的所有异常场景。
考虑到 Blink 支持任务 failover 的特性和稳定性测试的自动运行，我们把稳定性测试设定为一轮轮的迭代循环，每一轮迭代都包含释放出 monkey，提交任务，等待 job 恢复，校验四个阶段，校验主要包含 checkpoint，container 及 slot 资源等是否符合预期，校验失败就报警，校验成功后通过后进入下一轮迭代，以验证任务在长时间运行下的任务稳定性。
稳定性测试架构分为四层：组件层主要包含测试 Blink job，monkeys 和 dumper；action 层包含 job 启动，状态校验，输出校验等；执行层包含 service，monkey 操作等，monkey 操作时会根据 ssh 到具体机器，执行 monkey 操作；最上层是 WebUI。详情如下图所示：
预发测试
Blink 预发测试阶段主要通过克隆线上的真实任务和数据来进行复杂业务逻辑和大数据量的测试。因此，Blink 预发测试是对代码质量校验和集成测试的补充以及整个测试流程的完善，是 Blink 版本发布的最后一道关卡。
Blink 预发测试主要分为两个部分：仿真测试和兼容性测试。
仿真测试
仿真测试对 Blink 的功能、性能和稳定性等基础测试指标进行进一步地衡量，并将开发中的版本与当前的线上版本进行横向比较。因此，仿真测试能够尽早发现各种功能、性能退化和稳定性问题，从而提高上线版本的质量。
仿真测试主要分为环境克隆，环境适配和测试运行三个阶段：
环境克隆
环境克隆是实现整个仿真测试的基础，包括线上任务的挑选、克隆和测试数据的采样。
Blink 的线上任务分散在多个不同的工程中，数量较多。虽然，每一个线上任务都有其内在的业务逻辑，但是，不同的任务可以根据其主要的处理逻辑进行归类，例如，以 Agg 操作为主的任务集合，以 Sum 操作为主的任务集合等，因此，Blink 仿真测试需要对线上任务进行甄别，挑选出其中最具有代表性的任务。
仿真测试的测试数据集是当前线上任务输入数据的采样，仅在数据规模上有差异，并且，可以根据测试需求的不同进行动态地调节，从而实现对测试目标的精确衡量。
环境适配
环境适配是仿真测试过程中的初始化阶段，主要进行测试用例的修改，使其能够正常运行。该过程主要包括两个步骤：更改测试数据输入源和测试结果输出地址和更新任务的资源配置。
测试运行
测试运行是仿真测试流程中的实际执行模块，包括测试用例的运行和结果反馈两个部分。
Blink 仿真测试包括功能测试、性能测试和稳定性测试等模块，不同的测试模块具有不同的衡量标准和反馈方式。这些测试模块的测试结果与代码质量校验和集成测试的结果一起构成 Blink 测试的结果集。
性能测试和功能测试以仿真任务和采样数据作为输入，对比和分析任务在不同执行引擎上的执行过程和产出。其中，性能测试重点考察执行过程中不同执行引擎对资源的利用率、吞吐量等性能指标。功能测试则将执行的最终结果进行对比。需要特别指出的是，在功能测试中，线上版本的运行结果被假定为真，即当线上版本的执行结果与开发版本的执行结果不同时，认为开发版本的执行存在错误，需要修复开发中引入的错误。
稳定性测试重点关注仿真测试任务在线上克隆环境、大数据量和长时间运行条件下的稳定性。其以 Blink 开发版本作为唯一的执行引擎，通过收集执行过程中的资源利用情况、吞吐量、failover 等指标来进行度量。
兼容性测试
Blink 兼容性测试主要用于发现 Blink 新、旧版本之间的兼容性问题，从而为线上任务升级 Blink 执行引擎的版本提供依据。目前，兼容性测试主要分为静态检查和动态运行两个阶段，其中，静态检查是整个兼容性测试的基础。
静态检查
静态检查主要用于分析线上任务在不同执行引擎下生成执行计划的不同，包括两个方面的内容：
新的执行引擎生成执行计划的正确性及生成执行计划的时间长短。
新、旧版本的执行引擎生成的执行计划是否兼容。
在静态检查中，若新的执行引擎不能正确地生成执行计划，或者生成执行计划的时间超出预期，都可以认为静态检查失败，Blink 新版本中存在异常或者缺陷，需要查找原因。当新版本能够正确地生成执行计划时，若新、旧版本的执行引擎生成的执行计划不兼容，那么，需要将对比结果反馈给开发人员以判断该执行计划的更改是否符合预期；若执行计划兼容或者执行计划的更改符合预期，则可以直接进行运行时测试。
动态运行测试
Blink 动态运行测试利用仿真测试中的功能测试模块来进行任务的运行，是升级 Blink 新版本之前的最后一轮测试。若任务能够正常启动且测试结果符合预期，则认为该任务可以自动升级，反之，则需要人工介入进行手动升级。
展望
通过一年多的努力，Blink 整体质量已经有很大幅度的提高，Blink 的测试方法和工具也越来越成熟，Blink 回馈社区之际，我们会逐步将测试工具一起输出，回馈更多的社区开发测试者，与此同时，随着 Blink 用户群的壮大，Blink 业务开发者对于业务任务的质量保证需要日渐高涨，Blink 测试团队未来会提供更多质量保证和开发效率工具，进一步提升 Blink 开发者工程效率。
本文作者：溶月
阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。
