分布式计算的 8 大谬误

在 Ably 博客最近的一篇文章中，Alex Diaconu 回顾了分布式计算的 8 大谬误，并提供了一些应对建议。InfoQ 借此机会与 Diaconu 进行了交流，以了解更多关于 Ably 工程师如何处理这些谬误的信息。

在 Ably 博客最近的一篇文章中，Alex Diaconu回顾了分布式计算的 8 大谬误，并提供了一些应对建议。InfoQ 借此机会与 Diaconu 进行了交流，以了解更多关于 Ably 工程师如何处理这些谬误的信息。

这8大谬误是关于分布式计算的一组假设，这些假设可能会导致软件开发的失败：网络是可靠的；延迟为 0；带宽是无限的；网络是安全的；拓扑结构是不变的；只有一名管理员；传输成本为 0；网络是同构的。

这些谬误可以视为分布式系统设计时需要考虑的架构需求。InfoQ 与 Diaconu 进行了交流，以了解更多关于 Ably 工程师如何处理这些谬误的信息。

InfoQ：关于分布式计算的谬误，自从最初提出以来，已经过去了近三十年，但现在它们仍然很有意义。在 Ably，它们的作用是什么？

Alex Diaconu： 所有这些谬误指向的都是分布式系统设计的陷阱，它们今天依然很有意义。它们的影响不尽相同，其中有一些更容易处理。对于 Ably 来说，下面这几个谬误的影响最为普遍：

网络是可靠的。 自然，这是所有服务设计和运营都需要考虑的一个方面。不仅网络本身不可靠，你试图通过网络访问的系统也会失败。网络失败也不是一个二元问题——网络失败会有意想不到的形式。预测节点或互连故障是系统设计固有的工作。在 Ably 的博客上，我们已经对我们的处理方法做了广泛的探讨，比如通过容错机制。

拓扑结构是不变的。 这条谬误对于我们的架构而言也很重要。Ably 平台被设计成具有实时弹性的平台，因此，其拓扑结构会不断变化。我们的系统必须把拓扑结构变化作为一个常规问题来处理，而且，处理这个问题是系统复杂性的一个重要来源。其他系统服务使用发现层来构造系统拓扑的公共视图。服务间请求路由全都是根据那个拓扑结构图来完成的：发现层的可扩展性和性能是一项不小的工程挑战，我们已经在扩展 Ably 服务的过程中解决了这个问题。

带宽是无限的 &传输成本为 0。 在实践中，系统内的网络成本——在跨多个地区的全球性系统中——在运营成本中占了相当一部分。因此，我们要知道，在设计系统时，要保证我们的流量可以随着用户负载线性扩展，并且要监控流量，确保它在设计参数之内。我们偶尔也会遇到网络状况退化的问题，因此，我们需要通过监控来发现这种退化。

InfoQ：在分布式系统过去 30 年的发展历程中，是否出了其他需要注意的谬误？

Diaconu： 我觉得，过去 30 年最大的变化是我们对如何处理这些谬误的理解更成熟了。这不是说问题更简单了，而是我们对它们有了更好的理解。我们知道什么方法好，什么方法不好，以及某种特定的方法有什么局限。关于这些问题，现在已经有了完善的科学理论和工程实践。计算机科学专业的学生都会学习这些问题及其现状。

当然，重要的是要知道，这些谬误是长久存在的技术挑战，而不要把它们想成是可以轻松躲开的陷阱。事实上，我觉得你可以说有这样一种新谬误——“避免分布式计算的谬误很简单”。

InfoQ：有些谬误已经是老生常谈，例如，“云不安全”的观点已被广泛接受。不过，这些谬误中也有一些复杂难解之处，应对起来并不是那么简单。

Diaconu： 就像前面提到的那样，分布式系统的挑战，以及与分布式系统构建技术和机制相关的广泛的科学领域，已经得到了很好的研究。然而，当你在现实世界中应对这些挑战时就会发现，学术理解只能带你走这么远。

构建分布式系统要遵循工程实用主义进行权衡，最好的解决方案来自于经验以及试验。例如，“网络是可靠的”这一谬误是你要解决的最基本的问题。已知的解决方案有具有重试机制的协议、共识形成协议或冗余容错，使用哪种方案，取决于你所关注的特定的故障模式。不过，工程上的现实情况是，多重故障可能会同时发生。这样，理想的解决方案应该基于故障分布分析或是故障预算分析，以及某些故障对具体业务的影响。恢复机制本身可能会因为系统不可靠而失败，而此类失败发生的概率可能会影响解决方案。当然，也有复杂性风险：解决方案理论上很可靠，但也很复杂，与理论上不那么完善但更简单的机制相比，当事件发生时，处理或理解的难度都要大很多。

InfoQ：过去几年，微服务已经变得非常流行，它们似乎并不把“传输成本为 0”当成谬误。事实上，微服务越小，其数量和随之而来的传输成本就越大。关于这一点，您怎么看？

Diaconu： 也许这是另一个谬误“微服务简化了系统推理”。有时候，将事情分解成表面积较小的组件可以简化推理。但是，有时候，这些边界会增加复杂性，会增加故障模式，产生一些新的需要推断的行为。

和之前的回答一样，具体的设计选择，以及何时何地采用已知的理论解，取决于工程判断和经验。在 Ably，我们运营的系统有多个角色，这些角色可以独立扩展、相互操作及相互发现。然而，我们很少将功能划分成不同的角色，而且只在有特定需求时才会这样做。例如，如果我们希望某些特定的功能能够独立于其他功能进行扩展，这可以证明单独创建一个角色的合理性，即使它带来了额外的复杂性。

Diaconu 的文章不仅帮助我们了解了谬误的来源，而且还就当前解决谬误的技术和方法提供了一些实用的线索，所以如果你对这个问题感兴趣，不妨读一下。

查看英文原文：Reviewing the Eight Fallacies of Distributed Computing