The more things change, the more they stay the same.
在当下，2022年，「分布式」已经是一个常见的概念了。我们访问的各种网站，各种App的服务端，应该都是基于分布式和云计算来实现的。
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。我们现在设计的软件系统，基本上也是基于分布式、云计算设计。从单机系统到分布式系统，设计和开发常常会犯一些「常识性的错误」。下面就是几个基本的错误假设。
在 1994 年，当时 Sun 公司的研究员 Peter Deutsch 起草了分布式系统架构师和设计师可能做出的 7 个错误假设。1997 年，James Gosling 又添加了一个这样的错误假设。如果在分布式系统设计的时候，做了这些「美好」的假设，会导致设计的系统在运行过程中发生各种「意外」，给团队带来惨痛的代价。
这 8 个错误假设如下：
- 网络是可靠的
- 网络传输的延迟是零
- 网络的带宽是无穷大的
- 网络是安全的
- 网络的拓扑不会改变
- 有一个系统管理员
- 传输数据的成本为零
- 整个网络是同构的
谬误一：网络是可靠的 #
分布式系统的各节点通过网络连接。
网络是复杂的、动态的并且通常是不可预测的。不仅网络本身不可靠，你试图通过网络访问的系统也会失败。网络失败也不是一个二元问题——网络失败会有意想不到的形式。
互联网和数据中心 (通常是以太网) 中的大多数内部网络都是异步分组网络 (asynchronous packet networks)。在这种网络中，一个节点可以向另一个节点发送一个消息 (一个数据包)，但是网络不能保证它什么时候到达，或者是否到达。许多原因可能导致网络故障或网络相关问题：
- 网线被人拔了，或者碰掉了
- 网络超载，导致阻塞或者丢包
- 节点崩溃或者关机，或者节点上的服务不响应
- 交换机或者电源故障
- 交换机配置错误
- 数据中心不可用
- 光缆被切断
- 遭遇 DDoS 攻击
即便说现在我们的系统基于云服务，而各种云服务宣称提供的可用性至少都在99.95%以上，也不能完全保证调用这些服务就一定是不会超时或者出错。前几年因为杭州某个地方的光缆被挖了，导致支付宝出现了一段时间大规模的故障。
系统都是有类似模型的。比如我们人可以类比为一个单机系统，想拿一杯水喝，通过大脑做出判断，“指挥”身体完成这一系列动作就行了，也就几秒钟的事情。
但换成一个“分布式”场景，当你躺在病床上不能动，需要通过另外一个人帮你倒水的时候，就这么一个简单的操作，就可能会出现很多跟之前不一样的问题，比如 (可以对比上面的网络问题)：
- 没人在你身边
- 你按铃打给护士，但是刚好他们去查房了
- 你身边的人正在打电话处理非常紧急的事情，无暇照顾你
- 你身边的人由于多天劳累睡着了
- 你由于身体问题，说不清楚话，传递不了希望喝水的信息
- …
相比于单机系统，分布式系统节点之间可能会隔着各种网络设备，很多是对我们透明的。由于这种复杂性和普遍的不可预测性，网络是不可靠的。
谬误二：网络传输的延迟是零 #
刚工作那会，从单机系统向分布式系统演进，有人引入了一个RPC框架(Thrfit)。然后说这个好，远程过程调用，通过那个框架定义接口，然后访问远程服务，就跟本地函数调用一样。显然这就是做了假设，认为网络传输问题可以忽略。(当然，我这里并不是说 Thrift 有问题，而是说引入理由的问题)
后来，有人要把这个 Thrift 框架换掉，觉得太“重”，把Thrift API换成了 RESTful API，觉得 HTTP 比 TCP 性能要“好”。显然这个理由也是有问题的。也许延迟还会更大了。
从物理学的角度来看，数据在网络中传递，是基于电信号或者光信号传播的，这个肯定是有时间延迟的，相对于在内存和CPU缓存处理有数量级上的差别。这种延迟，特别是在公网环境，会更加明显，距离增加也会导致延迟增加。
具体各种场景的延迟，我这里附了一张图(参考资料1的链接可以查)：
不考虑延迟的问题，设计出来的系统可能在体验上非常糟糕，或者有些场景根本就不能正常跑起来(比如超时等机制可能会被触发)。
还是以上面那个生病的场景为例，拉到现实中来，可能就有点荒诞。你生病了躺在床上，想喝水，需要别人帮你倒。如果不考虑延迟，把一个单区域的设计扩展到多区域，即不是找病床边的人，而是给远在几百公里外的一堆朋友轮流打电话，让他们帮你倒一杯水。估计等他们赶过来的时候，你已经不能喝水了。
谬误三：网络的带宽是无穷大的 #
当然，带宽的发展还是挺好的。十年前，家庭级公网带宽大概是以1Mbps、2Mbps这种程度来使用；到现在，都是使用200Mbps、500Mbps了，费用也就一千多块一年。5G网络据说有1Gbps。
但企业级的贵一点。对于一个企业，一般外网带宽要小于内网；同一个局域网的节点是共用外网出入口的；环境中的网络带宽和传输速率，是服务商提供的公网带宽、机器网卡、交换机、路由器等网络设备所支持的传输速率中的最小值决定的。但即便是千兆万兆，带宽也是有限的。
特别是一些涉及数据传输的产品，更不能忽略带宽这个事情了。比如要跨区域备份一个5TB的数据，这个跟在单机系统上做，带宽限制就是关键因素了。
如果一个私有化部署的产品，在并发能力也会受带宽影响，并不是计算资源无限扩展就能搞定的 (当然，计算资源也不是真的能「无限」扩展)。比如，如果没有考虑一些特别的方案，一个请求按1KB的返回结果来定义，那么1000并发，大约需要8Mbps的流量。如果这些请求里面稍微带一点数据流传输，比如带个文档或者图片啥的，到了1MB级别，那么1000并发，大约需要8Gbps。如果要开放到公网访问，估计一般的企业是没有这么大的公网出口带宽资源的，即便是局域网访问，也需要万兆网卡、万兆交换机了。如果不考虑这个带宽问题，系统运行时得到的结果，可能就是网络阻塞，请求排队，系统体验不佳。
遇到这种场景，你在业务代码上还看不出问题，因为它是一个全局设计问题。假定带宽不受限制，作为外部能力要求，我只能说是一种偷懒和挖坑的行为了。这个在身边也比较常见。
谬误四：网络是安全的 #
网络从来就不是安全的，各种木马、病毒、攻击。安全是一个比较大的话题，这里不做讨论了。
谬误五：网络的拓扑不会改变 #
「网络拓扑不会变」，如果说这个场景确实存在，那就是在测试环境。
这个问题，在之前的架构演进中遇到过。 比如，之前有的服务设计为只访问「本地」的服务，通过硬编码 localhost 来访问。这种设计就是假定了服务部署架构，即「相关联的服务只会部署在同一个节点上」，导致在做容器化改造的时候，变更了一堆坑。
实际上，我们对于网络环境的把控度是很低的。产品部署完成之后，网络环境是无法控制的。运维团队可能会隔一段时间进行网络配置的变更和升级，或者网络设备网络方案的更换，甚至可能对部署形态做变更，比如从物理机迁移虚拟化，或者迁移到云。
假定网络拓扑不会改变，实际上是把业务逻辑跟部署逻辑做了强绑定，在设计上耦合，在环境适应性上会有很大的局限。
谬误六：有一个系统管理员 #
把所有的锅都丢给系统管理员。假定有系统管理员，同时我们可以操控他，约束他按照一定的规则来操作；同时还期待出问题的时候，他能够进行排查和设置。这是不合适的和不现实的。
另外，如果有多个管理员，他们可能会制定相互冲突的策略。如果依赖管理员，这也是一个麻烦。
谬误七：传输数据的成本为零 #
带宽、网络设备、网络管理这些都是需要成本的。
在「谬误三」里面已经在带宽这块做了部分讨论。
在微服务架构的流行趋势下，会考虑把系统做微服务拆分，以提升交付效率和扩展、伸缩能力。一个系统拆分越来越多的微服务，会增加复杂性，会增加故障模式，产生一些新的需要处理的场景。从传输成本这块来看，微服务越小、数量越多，随之而来的传输成本就越大，网络维护的成本也会越大。
系统设计的时候，在考虑引入各种技术和优势的同时，还需要考虑下成本，特别是不能忽视了数据传输成本。
谬误八：整个网络是同构的 #
「同构网络」是指所有节点在网络中具有相同功能的网络，在执行的基本功能中，用户之间可以互相切换。
「异构网络」通常指不同厂家的产品所组成的网络，按功能和效用将节点分为两类或更多类的网络。
当今世界，「同构网络」应该是例外，而不是常态。我们所处的整个全球互联网就是「异构」的。比如装有不同操作系统的服务器、不同的数据库产品、用不同的语言开发的产品等等，有5G、4G这种无线网络，也有光纤。到今天，这个谬误应该很好理解。
以上就是分布式计算的 8 个错误假设：
- 网络是可靠的
- 网络传输的延迟是零
- 网络的带宽是无穷大的
- 网络是安全的
- 网络的拓扑不会改变
- 有一个系统管理员
- 传输数据的成本为零
- 整个网络是同构的
注意，这些都是「错误假设」，在设计分布式系统的过程中绝「不能作为常识来默认」，这些是需要考虑方案来应对的，否则就是坑。