Apache Kafka被用于很多的公司，包括全球最苛刻的，大规模的和关键的系统。其最大的用户在数千台机器上运行Kafka，每天处理数万亿条消息。它是银行和金融交易等关键市场数据系统的骨干。它是许多科技公司的计费管道的一部分。它还被用作几个分布式数据库（包括运行Linkedin的主数据库）的提交日志。在所有这些环境中，最根本的问题是保持正确性和性能：我们如何确保系统保持不变，不会丢失数据。你如何为这种类型的严苛需求用途的系统编写软件？

当然，现实是非常困难的，没有“银弹”。分布式系统因其精细的环境而令人头疼，也是追踪和复验问题的难点。试图消除它们需要在整个软件开发生命周期中的一套实践，从设计到生产。大多数项目都很好地记录了他们的API和功能集，但很少记录他们采取的做法和策略，以确保这些功能的正确性。本文目的是让人们深入了解Confluent和更大的Apache Kafka社区如何处理以确保质量的测试和其他做法。

从设计开始：Kafka改进提案

软件的趋势远离了前期的设计流程和更灵活的方法，这对于应用程序开发来说可能是一件好事，但是对于分布式系统，我们认为制作好的软件必须以良好的设计开始。什么是核心要素，确保和API？新功能或模块如何与其他子系统进行交互？如果你不能用少量的编码来清楚地解释这些东西，那么很难测试你是否在一个大的代码库中正确地实现了这些。更重要的是，设计讨论的目的是确保全面开发团队对特征的意图有所了解，以便代码审查和未来开发在代码基础发展的过程中保持正确性。

为了确保我们已经考虑过这些问题，Kafka要求任何主要的新功能或子系统都附带一个名为Kafka Improvement Proposal（KIP）的设计文档。这允许改变进行广泛而公开的讨论。例如，关于KIP-98提出的一次性交付语义的讨论，一个非常大的功能，花费了几个月，但最终大大改善了原始设计。设计讨论经常缓慢，但实际情况是，设计可以比实现功能所需的时间快得多，因为认识到方法的局限性，然后重新设计和重新实现。

KIP文档：

KIP98：

代码审查

Kafka团队具有深入和广泛的代码审查的分为，试图主动发现正确性和性能问题。代码审查当然是软件工程中相当普遍的做法，但它通常是对风格和高级设计的粗略检查。我们发现在代码审查中更深入的时间投入真的是值得的。

分布式系统中的故障通常与错误条件有关，通常是在有针对性的测试中难以触发的组合和状态。这可不是一个偏执的个人通过逐行检查新的代码，花费大量的时间尝试思考可能出错的一切所能替代的。代码审查通常有助于找到难以在测试中触发的罕见问题。

测试与平衡

软件工程师通常主张单元测试优于集成测试。我们发现，需要的是测试方法的层次结构。单元测试运行速度快，易于调试，但你需要将其与更为完整的测试相结合，在更现实的环境中运行更完整集成的软件版本。

单元测试

Kafka拥有超过6800个单元测试，用于隔离单独组件或小套组件。这些测试运行速度快，容易调试，因为它们的范围很小。但是由于它们不测试模块之间的相互作用，而且只能在人为环境中运行，因此它们对整个系统的正确性没有提供太多保证。

除了单元测试，我们还使用其他预提交检查，例如findbugs（静态分析工具）和checkstyle（样式检查来保持代码美观）。

集成测试

Kafka拥有超过600个集成测试，可以验证在单个进程中运行的多个组件的交互。典型的集成测试可能会设置Kafka代理和客户端，并验证客户端是否可以向代理发送消息。

这些测试比单元测试慢，因为它们涉及更多的设置工作，但是在没有负载或环境故障（如硬碰撞或网络问题）的情况下，可以很好地检查正确性。

分布式系统测试

许多软件项目仅限于单一和单一过程集成测试；然而，我们发现这不足够，因为它们不涵盖分布式数据系统困扰的全部问题：并发问题只发生在负载，机器故障，网络故障，缓慢的进程，版本之间的兼容性，微妙的性能回归等等。要检测这些问题，必须在现实环境中测试分布式系统的实际部署。我们将这些多机测试系统测试称为单进程/机器集成测试。

构建分布式测试对于像Kafka这样的系统来说并不困难：它具有明确的正规保证和性能特征，可以被验证，并不难写出测试来检查它们。困难的是使这种测试自动化，可维护和可复验。这需要Kafka管理员，轻松部署流处理器和其他组件的不同分布式拓扑，然后协调安装程序的测试和故障。更难的是使这种类型的测试可调试：如果你在引入故障的同时通过负载分布式环境运行一千万条消息，并且你检测到一条消息丢失，知道从哪开始寻找问题？

为了帮助我们这样做，我们创建了一个名为ducktape的框架。Ducktape在创建分布式环境，胜任设置集群和索引故障方面的工作。它有助于脚本化测试场景，并收集测试结果。也许最重要的是它也有助于聚合所有运行的测试的日志和指标，以便可以调试失败任务。

Ducktape框架库：

系统测试框架允许我们构建不可能的测试类型：

应力测试：这些测试在重载下运行，并检查负载下的正确性。

性能测试：一次性基准测试非常好，但需要检查性能回归。

故障注入测试：这些测试会导致故障，如磁盘错误，网络故障，进程暂停（模拟GC或I/O）

兼容性测试：这些测试检查旧版本的Kafka与新版本的兼容性，或对外部系统（如Kafka Connect连接器）进行测试。

我们每天运行超过310个系统测试场景，每天超过350个机器小时。可以在这里看到的结果和测试场景。

结果和测试场景：

Ducktape是开源的，所以如果你面临类似的问题，可能值得一试。

社区测试

没有什么比生产环境找到问题重要了。幸运的是，Kafka拥有一大群资深用户，可以在发布之前在类似生产环境中帮助测试Kafka，通常是通过镜像生产负载并对新版本的软件进行运行，以确保其在使用模式下在其环境中工作。

由于我们所有的测试都是自动化的，因此代码库尽可能地接近可持续释放的状态。这允许Linkedin和其他几个企业在官方发布之前运行中继版本。这些企业的理念是，更频繁的升级意味着更低的风险和更小的变化来寻找任何问题。

来自运行Kafka规模的人们以及撰写代码的工程师的紧密反馈循环，一直是开发的重要组成部分。在Confluent和Confluent云中，我们托管Kafka产品使我们能够在非常重的环境中观察各种生产工作负载。这个反馈循环是确保大规模操作的工具，配置，指标和实践真正有效的。毕竟，在生产中运行软件是最终的考验。