“简单是终极的复杂”——列奥纳多·达·芬奇

“大多数信息是无关紧要的，大多数努力是白费的，但只有专家才知道该忽略什么”——詹姆斯·克利尔，《原子习惯》

您的数据管道很花哨，包含很多不同的系统。表面上看起来非常复杂，但实际上内部却是一团糟。它可能需要大量的连接工作来连接不同的部分，需要持续监控，可能需要一个拥有独特专业知识的大团队来运行、调试和管理它。更不用说，您使用的系统越多，数据重复的位置就越多，数据不同步或过时的可能性也就越大。此外，由于这些子系统都是由不同公司独立开发的，它们的升级或错误修复可能会破坏您的管道和数据层。 

如果您不小心，可能会像下面这个三分钟视频中描述的那样，最终陷入以下境地。我强烈建议您在继续之前观看它。

复杂性之所以产生，是因为尽管每个系统表面上看起来很简单，但它们实际上会将以下变量引入您的管道，并可能增加大量复杂性

1. 协议——系统如何传输数据？(HTTP, TCP, REST, GraphQL, FTP, JDBC)
2. 数据格式——系统支持哪种格式？(Binary, CSV, JSON, Avro)
3. 数据模式和演变——数据如何存储？(tables, Streams, graphs, documents)
4. SDK 和 API——系统是否提供必要的 SDK 和 API？
5. ACID 和 BASE——它提供 ACID 或 BASE 一致性吗？
6. 迁移——系统是否提供一种简单的方法来将所有数据迁移到系统内或从系统中迁移出？
7. 持久性——系统在持久性方面有哪些保证？
8. 可用性——系统在可用性方面有哪些保证？(99.9%, 99.999%)
9. 可扩展性——它如何扩展？
10. 安全性——系统有多安全？
11. 性能——系统处理数据的速度有多快？
12. 托管选项——是仅托管、仅本地部署还是混合？
13. 云——它是否在我的云、区域等上工作？
14. 额外系统——它是否需要额外系统？(例如，Kafka 需要 Zookeeper)

数据格式、模式和协议等变量累积起来，被称为“转换开销”。性能、持久性和可扩展性等其他变量累积起来，被称为“管道开销”。总的来说，这些分类共同构成了所谓的“阻抗不匹配”。如果我们可以衡量它，就可以计算出复杂性，并用它来简化我们的系统。稍后我们将讨论这一点。

现在，您可能会争辩说，您的系统虽然看起来复杂，但实际上是满足您需求的最简单的系统。但您如何证明这一点呢？

换句话说，您如何真正衡量并判断您的数据层是真正简单还是复杂？其次，您如何估计随着添加更多功能，您的系统是否会保持简单？也就是说，如果您的路线图中增加了更多功能，您是否还需要增加更多系统？

这就是“阻抗不匹配测试”的用武之地。但我们先来看看什么是阻抗不匹配，然后再讨论测试本身。

什么是阻抗不匹配？

该术语起源于电气工程，用于解释电抗的失配，当能量从 A 点传输到 B 点时导致能量损失。

简单来说，它意味着您所拥有的与您所需的不匹配。要使用它，您需要将您当前拥有的东西转化为您所需的，然后使用它。因此存在不匹配，以及与修复不匹配相关的开销。

在我们的例子中，您拥有的数据以某种形式或数量存在，并且在我们可以使用它之前需要对其进行转换。这种转换可能会发生多次，甚至可能在中间使用多个系统。

在数据库领域，阻抗不匹配发生有两个原因

1. 转换开销：系统处理或存储数据的方式与数据的实际样子或您对其的思考方式不同。例如：在您的服务器中，您可以灵活地将数据存储在许多数据结构中，例如集合、流、列表、集合、数组等。这有助于您自然地建模数据。但是，您需要将这些数据映射到 RDBMS 中的表或 JSON 文档存储中才能存储它们。然后在读取数据时执行相反的操作。请注意，面向对象语言模型与关系表模型之间的特定不匹配被称为“对象关系阻抗不匹配”。
2. 管道开销：您在服务器中处理的数据量和数据类型与数据库能够处理的数据量不同。例如：如果您正在处理来自移动设备的数百万个事件，您的典型 RDBMS 或文档存储可能无法存储它，或提供 API 轻松聚合或计算这些事件。因此，您需要特殊的流处理系统，例如 Kafka 或 Redis Streams，来处理它，并且可能还需要一个数据仓库来存储它。

阻抗不匹配测试

测试的目标是衡量整个平台的复杂性，以及随着未来添加更多功能，复杂性是增长还是减小。 

测试的工作方式是，使用“阻抗不匹配分数”（IMS）简单计算“转换开销”和“管道开销”。这将告诉您您的系统是否相对于其他系统已经很复杂，以及随着添加更多功能，这种复杂性是否会随着时间增长。

以下是计算 IMS 的公式

该公式简单地将两种类型的开销相加，然后除以功能数量。这样，您将得到总开销/功能（即复杂性分数）。 

为了更好地理解这一点，让我们比较四种不同的简单数据管道并计算它们的得分。其次，我们还设想分两个阶段构建一个简单的应用程序，以便我们可以看到随着时间的推移添加更多功能，IMS 分数如何变化。

阶段 1：构建实时仪表盘

假设您正在从移动设备接收数百万个按钮点击事件，并且需要在出现任何下降或激增时收到警报。此外，您将整个事情视为您更大应用程序的一个功能。 

情况 1：假设您只使用 RDBMS 存储这些事件，尽管表可能不适合。

1. 转换开销 = 1
   1. 您需要将事件流转换为表。
2. 管道开销 = 1
   1. 您的管道中只有一个数据库。
3. 功能数量 = 1

情况 2：假设您使用 Kafka 处理这些事件，然后将它们存储到 RDBMS 中。

1. 转换开销 = 1
   1. Kafka 可以轻松处理点击流；然而，Kafka 到 RDBMS 是一个开销。
2. 管道开销 = 2
   1. 您有两个系统（RDBMS 和 Kafka）。请注意，我们忽略了 Zookeeper。
3. 功能数量 = 1

情况 3：假设您使用 Kafka 处理这些事件，然后将它们存储到 KsqlDB 中。

1. 转换开销 = 0
   1. Kafka 可以轻松处理点击流
2. 管道开销 = 1
   1. 您只有一个系统（Kafka + KSqlDB）。请注意，我们忽略了 Zookeeper。
3. 功能数量 = 1

情况 4：假设您使用 Redis Streams 处理这些事件，然后将它们存储到 RedisTimeseries 中（两者都是 Redis 的一部分，并且与 Redis 本地协同工作）。

1. 转换开销 = 0
   1. Redis Streams 可以轻松处理点击流
2. 管道开销 = 1
   1. 您只有一个系统（Redis Streams + RedisTimeSeries）
3. 功能数量 = 1

阶段 1 结论： 

在此示例中，我们比较了四种系统，发现“情况 3”或“情况 4”最简单，IMS 均为 1。此时，它们是相同的，但当我们添加更多功能时，它们还会保持相同吗？

让我们向系统中添加更多功能，看看 IMS 如何变化。

阶段 2：构建带有 IP 白名单的实时仪表盘

假设您正在构建同一个应用程序，但希望确保它们仅来自白名单 IP 地址。现在您正在添加一个新功能。

情况 1：假设您只使用 RDBMS 存储这些事件，尽管表可能不适合，并且他们使用 Redis 或 MemCached 进行 IP 白名单。 

1. 转换开销 = 1
   1. 对于 IP 白名单，您不需要任何转换。但是，您需要将事件流转换为表
2. 管道开销 = 2
   1. 您有 Redis + RDBMS
3. 功能数量 = 2

情况 2：假设您正在使用 Redis + Kafka + RDBMS。 

1. 转换开销 = 1
   1. 对于 IP 白名单，您不需要任何转换。此外，Kafka 可以轻松处理流。
2. 管道开销 = 3
   1. 您有 Redis + Kafka + RDBMS。注意：我们忽略了 Kafka 也需要 Zookeeper。如果您添加它，数字会进一步下降。
3. 功能数量 = 2

情况 3：假设您正在使用 Redis + Kafka + KsqlDB。 

1. 转换开销 = 0
   1. 对于 IP 白名单，您不需要任何转换。此外，Kafka 和 KsqlDB 可以轻松处理流。 
2. 管道开销 = 2
   1. 您有 Redis + (Kafka + KsqlDB)。注意：在本例中，我们将 Kafka + KsqlDB 视为同一系统的一部分。
3. 功能数量 = 2

情况 4：假设您正在使用 Redis + Redis Streams + RedisTimeSeries。 

1. 转换开销 = 0
   1. 对于 IP 白名单，您不需要任何转换。此外，Redis Streams 和 RedisTimeseries 可以轻松处理流和警报。
2. 管道开销 = 1
   1. 您有 Redis +  Redis Streams + Redis TimeSeries。注意：在本例中，这三个都是同一系统的一部分。
3. 功能数量 = 2

阶段 2 结论： 

当我们添加一个额外功能时， 

• 情况 1 在阶段 1 时为 2，降至 1.5。 
• 情况 2 在阶段 1 时为 3，降至 2
• 情况 3 在阶段 1 时为 1，保持为 1
• 情况 4 在阶段 1 时为 1，降至 0.5（最佳）

因此在我们的例子中，情况 4 的 IMS 分数最低，为 1，随着我们添加新功能，它实际上变得更好，最终达到 0.5。  

请注意：如果您添加更多或不同的功能，情况 4 可能不会保持最简单。但这正是 IMS 分数的意义所在。只需列出所有功能，比较不同的架构，然后查看哪一个最适合您的用例。

为了使其更容易使用，我们为您提供了一个计算器，您可以在一个简单的电子表格中实现它来计算 IMS 分数。

IMS 计算器

以下是使用方法

1. 对于每个数据层或数据管道，只需列出
   1. 您当前拥有的功能。 
   2. 路线图中的功能。这很重要，因为您要确保您的数据层能够继续支持即将推出的功能，而不会产生任何额外开销。
2. 然后映射每个功能的转换开销和管道开销。
3. 最后，将所有开销的总和除以功能数量。
4. 重复步骤 2 和 3，对不同系统的管道进行比较和对照。

数据管道 1

数据管道 2

总结

很容易被冲昏头脑，构建一个复杂的数据层，而不考虑后果。创建 IMS 分数是为了帮助您做出明智的决定。 

您可以使用 IMS 分数轻松比较和对照适用于您的用例的多个系统，并查看哪一个最适合您的功能集。您还可以验证您的系统是否能够应对功能扩展，并尽可能保持简单。 

永远记住

“简单是终极的复杂”  — 列奥纳多·达·芬奇

“大多数信息是无关紧要的，大多数努力是白费的，但只有专家才知道该忽略什么” — 詹姆斯·克利尔，《原子习惯》