构建分布式系统是一项复杂的工作。架构，设计，编码和测试对分布式系统的成功都至关重要。任何一点的失败都可能导致性能下降，故障频发，费用超标以及最终导致客户流失。在20世纪90年代Sun Microsystems的Peter Deutsch，James Gosling和其他人总结出了分布式计算的八个谬论。随着时间的推移，IT人员对这些谬论的认识可能已经消退，所以想要提醒下大家。
八大谬论是：
- 网络可靠。 The network is reliable.
- 延迟为零。 Latency is zero.
- 带宽是无限的。 Bandwidth is infinite.
- 网络是安全的。 The network is secure.
- 拓扑不会改变。 Topology doesn’t change.
- 只有一个管理员。 There is one administrator.
- 运输成本为零。 Transport cost is zero.
- 网络是同质的。The network is homogeneous.
在局域内，网络可能看起来坚如磐石。毕竟，现在网络组件多久失败一次？即使单个组件发生故障，也确实存在大量冗余？那么，随着网络变得越来越复杂，网络管理就越容易出错，大多数都是配置错误。在某些情况下，多达三分之一的网络更改会导致影响网络可靠性的错误。软件和硬件都可能出现故障，尤其是路由器，它们占所有故障的四分之一左右。“不间断”电源也可能会中断，人们可能会发生不明智的设备配置更改，并且可能存在网络拥塞，拒绝服务（DoS）攻击以及软件和固件升级或修补程序失败。网络遭受自然灾害和非自然灾害，设计一个对这类东西具有弹性的网络需要技巧。广域链接超出您的控制范围，很容易出错。
最近几个月，Azure上的事件令人痛苦，而且这种失败率是主要云服务提供商的典型特征。对于移动应用程序，各种各样的事情都可能会出错：网络请求将以不可预测的间隔失败，目标将不可用，数据将到达目的地但无法发回确认，数据将在传输中损坏或到达不完整。移动应用程序必须在网络可靠性范围的可怕范围内具有弹性，但所有分布式应用程序必须能够应对所有这些可能性，并且网络节点必须能够应对服务器故障。
延迟为零延迟与带宽不同。延迟是等待响应所花费的时间。除了明显的处理延迟外，还有网络延迟，包括传播延迟，节点延迟和拥塞延迟。传播延迟随距离增加：约为30 ms。欧洲和美国之间。路径中的节点数决定了节点延迟。
通常，开发人员在内部网中构建分布式系统，这些系统具有无关紧要的延迟，因此进行频繁的细粒度网络调用几乎不会受到惩罚。这种设计错误只有在投入实时系统时才会变得明显。
高延迟的一个令人不安的影响是它不是恒定的。在糟糕的网络上，偶尔可以在几秒钟内计算出来。就其性质而言，无法保证网络服务单个数据包的顺序，甚至不能保证请求进程仍然存在。延迟会让事情变得更糟。此外，在应用程序通过发送多个同时请求进行补偿的情况下，可以通过对其的响应来加剧暂时高延迟。
带宽是无限的虽然大多数现代电缆可以处理几乎无限的带宽，但我们还没有找到如何构建足够快的互连设备（集线器，交换机，路由器等）以保证所有连接用户的高带宽。典型的企业内部网仍将具有限制带宽的区域。
随着公共网络带宽的增加，网络对使用视频和音频的服务的使用也一样快，而视频和音频曾经使用过广播技术。诸如社交媒体之类的新用途往往会吸收不断增加的带宽。此外，主要城市以外的许多地方都存在“最后一英里”的限制，并且丢包的可能性也在增加。
一般而言，我们需要谨慎地假设高带宽是一种普遍的体验。无论网络带宽如何令人印象深刻，它都无法接近共同托管进程可以通信的速度。
网络是安全的令人遗憾的是仍然遇到具有基本安全漏洞的基于网络的系统。网络攻击逐年增加，并且在好奇心，恶意和犯罪方面已经超越了它们的原始根源，成为国际冲突和政治“行动”的一部分。网络攻击是IT生活的一部分：对开发人员来说很无聊，但却是必不可少的。部分问题是网络入侵检测往往是低优先级，因此我们并不总是意识到成功的网络攻击。
传统上，漏洞通常是配置不当的防火墙的结果。大多数防火墙都会经常被检测出来，因为你会立即发现你是否愚蠢地禁用它们。然而，这只是破坏网络和防火墙的一种方式中的一种，只是防御的一部分。Wi-Fi通常是一个弱点，使用自己的设备（BYOD）可以允许通过受损设备进行入侵，虚拟化和软件定义网络（SDN）也是如此。越来越多的DevOps对快速变化的基础设施的需求使得更难以保持必要的控制措施。企业网络中的僵尸网络是一个持续存在的问题，以及通过业务合作伙伴的入侵。
您需要假设网络是敌对的，并且安全性必须深入。这意味着将安全性构建到分布式应用程序及其主机的基本设计中。
通过纵深防御，分布式系统的任何部分都需要具有访问其他网络资源的安全方式。
安全带来了自身的复杂性。这将来自维护不同用户帐户，权限，证书，帐户等的管理开销。一个主要的云网络中断是由于权限在更新之前到期而导致的。
拓扑不会改变网络拓扑不断变化，速度非常快。由于“网络敏捷性”的压力越来越大，这是不可避免的，以便与快速变化的业务需求保持同步。
无论您在何处部署应用程序，都必须假设大部分网络拓扑都可能无法控制。网络管理员将一次进行更改，原因可能不符合您的利益。他们将移动服务器并更改网络拓扑以获得性能或安全性，并在服务器和网络故障的情况下进行路由更改。
因此，依赖特定端点或路由的持久性是错误的。必须始终从任何分布式设计中抽象出网络的物理结构。
只有一个管理员除非系统完全存在于小型LAN中，否则将有不同的管理员与网络的各种组件相关联。他们将拥有不同程度的专业知识，不同的职责和优先事项。
如果出现导致服务失败的问题，这将很重要。您的服务级别协议将要求在一定时间内做出响应。第一阶段将是确定问题。除非有问题的网络部分的管理员是您的开发团队的一部分，否则这可能并不容易。不幸的是，这不太可能。在许多网络中，问题可能完全是另一个组织的责任。如果云组件是应用程序的重要组成部分，并且云中断，则无法确定优先级。你所能做的就是等待。
如果网络中有许多管理员，那么协调升级到网络或应用程序就更加困难，特别是当涉及到几个忙碌的人时。升级和部署必须协调完成，涉及的人数越多，这就变得越困难！
运输成本为零运输成本是指通过网络传输数据的总体成本。我们可以参考时间和计算机资源，或者我们可以参考财务成本。
将数据从应用程序层传输到传输层需要CPU和其他资源。需要对结构化信息进行序列化（编组）或解析以将数据传输到线路上。这种性能影响可能大于带宽和延迟时间，因为XML的冗长和复杂性使得XML占用JSON的两倍。
金融运输成本不仅包括创建网络的硬件和安装成本，还包括监控和维护网络服务器，服务和基础设施的成本，以及如果发现带宽不足，或者您的服务器实际上无法处理足够的并发请求。我们还需要考虑租用线路和云服务的成本，这些成本由所使用的带宽支付
网络是同质的今天的同质网络是罕见的，甚至比首次发现谬论时更为罕见！网络可能连接计算机和其他设备，每个设备具有不同的操作系统，不同的数据传输协议，并且所有设备都与来自各种供应商的网络组件相连。
但是，异构网络没有什么特别的错误，除非它涉及需要专门支持，设备或驱动程序的专有数据传输协议。从应用程序的角度来看，如果数据以开放标准格式（如CSV，XML或JSON）传输，并且使用行业标准的查询数据（如ODBC）的方法，则会有很大帮助。
如果所有组件都来自一个供应商，则可靠性更高，因为测试覆盖范围可能更大，但实际情况是组件的丰富组合。这意味着互操作性应该从任何分布式系统的设计开始就内置。
结论虽然这个指导是在二十年前制定的，但我们今天仍在犯这些错误。这些错误显示为不安全的端点，由于大型对象的序列化导致的超时，丢失的事务，性能降低等等。避免这些错误意味着在每次设计和代码审查中需要考虑这些谬论。
