关于分布式计算有八大谬论，这是20 世纪90 年代在Sun MicroSystem 中被首次提出的，但在此之前就已经为人所熟知了。随着时间的推移，这些谬论已经被IT 从业人员所遗忘了，所以有必要提醒一下大家。它们分别是：
- 网络是可靠的
- 延迟为零
- 带宽是无限的
- 网络是安全的
- 拓扑不会改变
- 只存在一个管理员
- 传输代价为零
- 网络是同质的
我个人经历过一些大型项目，一些高级管理层会做出以上错误的假设，最终导致了灾难性的后果。许多应用设计者对他们使用的网络充满信心，但现实却往往很打脸
某些人可能认为现在的网络比他们很久之前首次接触分布式系统的时候要更快速、更便宜，所以他们认为上面的这些假设不再是一种谬论，因为技术已经把这些假设实现了。但是，尽管有市场的营销宣传，网络的现实仍然困扰着基于以上谬论设计分布式系统的人
分布式系统可以在专门设计和指定的网络中很好的工作，并受到严格的控制和监控，但分布式系统真实运行所在的生产环境可能无法满足这些要求！为什么呢？请继续看！
网络是可靠的
在局域网中，网络可能看起来坚如磐石。毕竟，现在哪还有一个网络组件经常宕机呢？而且即使一个单一的组件出现故障，还会有很多的冗余，确实是这样吗？随着网络环境越来越复杂，网络管理员很有可能犯错，尤其是在配置上。某些情况下，多达1/3 的网络更改会导致网络的可靠性故障。软件和硬件都可能出现故障，尤其是路由器，它占到所有故障的1/4 左右。“不可中断”的电源供应有可能出现断电、管理员可能进行不明智的网络设备配置更改、可能出现网络阻塞、可能遇到拒绝服务攻击，以及软件和防火墙的更新或布丁失败。网络会因为自然的和非自然的因素导致故障，设计一个能应对这些情况的网络需要很高的技巧。广域网在你的可控范围之外，很容易出错
最近几个月的Azure 事件真的是令人头疼，而且这种故障概率是主要的云服务提供商的典型特征。对于移动应用，所有的环节都可能出现问题：请求将以不可预测的间隔失败、目标不可达、请求到达目的地但返回应答失败、数据在传输过程中损坏或者不完整。移动应用必须在网络的可靠范围内具有弹性，但所有分布式应用程序必须能够应对所有这些可能性，并且网络节点必须能够应对服务器故障
延迟为零
延迟和带宽不同，延迟是指花费在等待应答上的时间，原因是什么？除了明显的服务器处理延迟，还有网络延迟，包括传输延迟、节点延迟和阻塞延迟。传输延迟随着距离的增加而增加：在美国和欧洲之间的传输延迟在30ms 左右。传输路径中的节点数（译者注：路由器、网管、代理服务器等）决定了节点延迟
通常开发人员在内网中构建分布式系统，而内网中的延迟并不明显，因此频繁地进行细粒度的网络远程调用几乎不会有什么损失。这种设计错误只有在投入到真实的生产环境中才会暴露出来
高延迟的一个令人不安的影响就是它不是固定的。在一个糟糕的网络中，偶尔会是几秒。就其性质而言，无法保证网络服务单个数据包的顺序，甚至不能保证请求进程仍然存在。延迟会让事情变得更糟。此外，在应用程序通过发送多个同时请求进行补偿的情况下，可以通过对其的响应来加剧暂时高延迟
带宽是无限的
虽然大多数现代电缆可以应对无限带宽，但我们还没有找到如何构建足够快的互联设备（集线器、交换机、路由器等）以保证所有连接用户的带宽，典型的企业内部网仍将具有限制带宽的区域
随着公共网络带宽的快速增加，使用网络进行视频和音频服务（而视频和音频服务所使用的是广播技术）的速度也在增加。社交媒体等新用途往往会吸收不断增加的带宽。此外，主要城市以外的许多地方存在“最后一英里”的限制，以及包丢失的可能性越来越大
所以总的来说，我们在假设高带宽是一种通用体验的时候需要谨慎。无论网络带宽如何令人印象深刻，它都无法接近共同托管进程可以通信的速度
网络是安全的
奇怪的是，仍然会遇到基于网络的系统，它们具有基本的安全弱点。网络攻击逐年增加，已经远远超出了其原本的好奇心、恶意和犯罪根源，成为国际冲突和政治“行动”的一部分。网络攻击是IT 生活的一部分：对开发人员来说很无聊，但必须要防御。部分问题是网络入侵检测往往是低优先级的，所以我们只是不总是知道成功的网络入侵
传统上，漏洞通常是配置不当的防火墙的结果。大多数防火墙弱点都会经常被检测出来，因为如果你愚蠢地禁用了一个就会立即发现。然而，这只是破坏网络和防火墙的一种方式，只是防御的一部分。Wi-Fi 通常是一个弱点，使用自己的设备（BYOD）可以允许通过受损设备进行入侵，虚拟化和软件定义网络（SDN）也是如此。越来越多的DevOps 对快速变化的基础设施的需求使得更难以保持必要的控制措施。企业网络中的僵尸网络是一个持续存在的问题，以及通过业务合作伙伴的入侵也是如此
你需要假设网络是敌对的，并且安全性必须深入。这意味着要将安全性构建到分布式应用程序及其主机的基本设计中
通过纵深防御，分布式系统的任何部分都需要具有访问其他网络资源的安全方式
安全带来了自身的复杂性。这将来自维护不同用户帐户、权限、证书、帐户等的管理开销。一个主要的云网络故障是由于许可在续签之前过期
拓扑不会改变
网络拓扑不断变化，速度非常快。由于“网络敏捷性”的压力越来越大，这是不可避免的，以便与快速变化的业务需求保持同步
无论你在何处部署应用程序，都必须假设大部分网络拓扑都可能无法控制。网络管理员将一次进行更改，原因可能不符合你的利益。他们将移动服务器并更改网络拓扑以获得性能或安全性，并在服务器和网络故障的情况下进行路由更改
因此，依赖特定端点或路由的持久性是错误的。必须始终从任何分布式设计中抽象出网络的物理结构
只存在一个管理员
除非系统完全存在于小型LAN 中，否则将有不同的管理员与网络的各种组件相关联。他们将拥有不同程度的专业知识，不同的职责和优先事项
如果出现导致服务失败的问题，这将很重要。你的服务级别协议将要求在一定时间内做出响应。第一阶段将是确定问题。除非有问题的网络部分的管理员是你的开发团队的一部分，否则这可能并不容易。不幸的是，这不太可能。在许多网络中，问题可能完全是另一个组织的责任。如果云组件是应用程序的重要组成部分，而云出现中断，那么在确定优先级时就无能为力了。你所能做的就是等待
如果网络中有许多管理员，那么协调升级到网络或应用程序就更加困难，特别是当涉及到几个忙碌的人时。升级和部署必须协调完成，涉及的人数越多，这就变得越困难！
传输代价为零
传输成本是指通过网络传输数据的总体成本。我们可以参考时间和计算机资源，或者我们可以参考财务成本
将数据从应用程序层传输到传输层需要CPU和其他资源。需要对结构化信息进行序列化（编组）或解析以将数据传输到线路上。这种性能影响可能大于带宽和延迟时间，XML 冗长和复杂性导致其需要的时间是JSON 的两倍
金融运输成本不仅包括创建网络的硬件和安装成本，还包括监控和维护网络服务器，服务和基础设施的成本，以及如果发现带宽不足，或者你的服务器实际上无法处理足够的并发请求。我们还需要考虑租用线路和云服务的成本，这些成本由所使用的带宽支付
网络都是同质的
今天的同质网络是罕见的，甚至比首次发现谬论时更为罕见！网络可能连接计算机和其他设备，每个设备具有不同的操作系统，不同的数据传输协议，并且所有设备都与来自各种供应商的网络组件相连
但是，异构网络没有什么特别的错误，除非它涉及需要专门支持，设备或驱动程序的专有数据传输协议。从应用程序的角度来看，如果数据以开放标准格式（如CSV，XML或JSON）传输，并且使用行业标准的查询数据（如ODBC）的方法，则会有很大帮助
如果所有组件都来自一个供应商，则可靠性更高，因为测试覆盖范围可能更大，但实际情况是组件的丰富组合。这意味着互操作性应该从任何分布式系统的设计开始就内置
总结
即使有现代的千兆网络，数据在服务器外的传输速度也较慢，而且不那么可靠。这就是为什么我们传统上更喜欢扩展硬件而不是扩展基于网络的商品硬件。问题是，这种偏好僵化成了一条黄金法则。当它被证明可以控制网络到八种谬误更接近现实的程度时，“最佳实践”就可以被推翻，然后分布式模型就变得更有吸引力了。问题是，分布式系统、面向服务的体系结构和微服务只有在网络被驯服了所有的缺点时才有效。即使在今天，云服务的故障或“停机”发生的频率也惊人地高。当你计划或开发分布式应用程序时，在你的网络中假定那些不一定存在的属性和质量是一个坏主意：在计划时，最好假定你的网络将是昂贵的，并且偶尔会是不可靠和不安全的。假设你将面临高延迟、带宽不足和拓扑变化。当你需要更改时，你可能需要与许多管理员联系，以及各种令人眼花缭乱的网络服务器和协议。你可能会感到惊喜，但不要指望它！