首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

分布式计算的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

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/sc7FlVUvb2NgQuD7IcjP
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券
http://www.vxiaotou.com