写点什么

分布式计算的 8 大谬误

2021 年 9 月 14 日

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

2021 年 9 月 14 日 15:07239

评论

发布
暂无评论
发现更多内容

架构实战营 模块一作业

netspecial

架构实战营

话说 ReentrantLock_源码

木子的昼夜

话说 Lock condition

木子的昼夜

用 JavaScript 实现时间轴与动画 - 前端组件化

三钻

JavaScript 前端 动画 组件化 时间轴

PCB如何拼版

不脱发的程序猿

嵌入式 电路设计 硬件设计 4月日更 PCB打样

一文读懂区块链领域最新发展方向 NFT经济将成未来发展方向

CECBC区块链专委会

艺术品

踩坑 MySQL 索引,看看你真的会用么?

架构精进之路

MySQL 4月日更

架构实战营——作业一:微信架构及学生管理架构

开拓纪

架构实战营 作业一

话说 线程切换&线程数设置

木子的昼夜

话说 ReadWriteLock 第二篇

木子的昼夜

面试题 : 一个单调递增的数组 随机拿出一个数 你怎么找到这个数

木子的昼夜

面试题: 合并两个有序链表

木子的昼夜

面试题: String "123" 转 int类型

木子的昼夜

区块链的环保实验,助全球提高垃圾回收

CECBC区块链专委会

环保

Linux grep 命令

一个大红包

4月日更

怎么画出专业的架构图?

秋天

架构师 架构·

极客架构module 1 作业

Geek_649372

架构实战营

Wireshark数据包分析学习笔记Day25

穿过生命散发芬芳

Wireshark 数据包分析 4月日更

自研规则/流程引擎-ice简介

迟到的月亮

规则引擎

话说 ReadWriteLock

木子的昼夜

架构实战营 - 模块 1- 作业

请弄脏我的身体

架构实战营

C++ sort 排序及自定义排序

玄兴梦影

如何做Nginx安全日志分析可视化

运维研习社

nginx 4月日更 waf

为什么数据库字段要使用NOT NULL?

艾小仙

重磅官宣:Nacos2.0发布,性能提升10倍

xcbeyond

Java 微服务 nacos 微服务发现 4月日更

go每日一库 [go-rate] 速率限制器

happlyfox

golang 学习 4月日更

机器学习和大数据的区别和联系

大数据技术指南

机器学习 大数据 4月日更

话说 LockSupport

木子的昼夜

聪明人的训练(五)

Changing Lin

4月日更

什么是架构?怎么来理解?

秋天

架构师 架构·

高承实:绘一幅区块链社会画像

CECBC区块链专委会

区块链

分布式计算的8大谬误-InfoQ