分布式系统的谬误(Fallacies of distributed systems)是由L Peter Deutsch和Sun公司的其他人一起提出的一系列论断,这些论断描述了刚接触分布式应用程序的程序员总是会做出的错误假设。
微服务的大规模采用迫使更多的工程师理解这一架构决定对他们系统设计的影响。在讨论基于微服务的分布式系统设计时,经常能看到这8个被忽略的谬误:
- 1、网络是可靠的;
- 2、网络延迟是0;
- 3、带宽是无限的;
- 4、网络是安全的;
- 5、网络拓扑是不变的;
- 6、总是有一个管理员;
- 7、网络传输成本是0;
- 8、网络是同质化的。
1、网络是可靠的
在软件应用程序开发时很少对网络错误进行处理。在网络中断期间,此类应用程序可能会暂停或无限地等待应答包,永久地消耗内存或其他资源。当故障网络可用时,这些应用程序也可能无法重试任何停止的操作或需要(手动)重新启动。
为了建立一个可靠的系统,你必须理解并接受这样一个事实:任何特定的通信都有可能失败;因此,我们需要为系统提供一种方法来处理这种潜在的通信错误。所以最终,这归结为重新发送,它可以以多种形式出现。
其中一种模式是存储并转发模式。我们将数据存储在本地或其他地方,而不是直接将数据发送到下游服务器。这样还可以在发生灾难性的情况下进行数据恢复,而简单的重试循环将缺乏此类保证。
有许多技术符合这个的模式,如Kafka、RabbitMQ、ActiveMQ等消息中间件都可以解决此问题。
2、网络延迟是0
忽视网络延迟以及它可能导致的数据包丢失,导致应用程序层和传输层开发人员允许无限制的流量,大大增加了丢失的数据包并浪费带宽。
我们应该将延迟视为完成任何请求的严格必须开销。消息可以很大,也可以很小,延迟是不变的。与带宽不同,延迟通常与光速和通信距离(或路径)有关。所以两个系统之间的距离在这里起着重要的作用。
延迟无处不在。它发生在所有的通信中。
理想情况下,这种开销应该尽可能小。延迟与从汽车上卸下杂货非常相似。你从厨房到汽车所花费的时间就是延迟。你是想在一次往返中拿走尽可能多的东西,还是想单独带着这些东西,往返几百次才能把车卸完?
3、带宽是无限的
假设你可以无限制地增加通道上的数据大小,这可能是个很大的错误。这个问题只有规模达到一定程度,且通信通道达到了上限才会出现。
现在你可能会想,上面刚刚说的在每次往返中尽可能多地携带数据,以减少延迟的影响。这是事实,但它也有局限性。这在很大程度上取决于你的系统设计和各自的优先级,但意识到如何权衡两者是至关重要的。
4、网络是安全的
假设你可以信任你所在的网络或你正在为其构建系统的人,这可能是一个严重的错误。
如今,随着众包漏洞赏金计划的出现以及每天新闻中的重大漏洞,这一点变得更加明显。
在设计系统时采取安全第一的立场将会在未来获得好处。甚至花时间评估当前系统的安全漏洞也是一个很好的开始,这将很快产生一个简短的改进清单。
5、网络拓扑是不变的
网络结构并不总是一样的。网络拓扑的变化会对带宽和延迟问题产生影响。例如,如果基础设施的关键部分出现故障,流量能否继续流向适当的目的地?我们会有单点失败的故障吗?
随着Docker和Kubernetes的出现,改变网络拓扑结构的便利性,几乎让我们认为这是理所应当的,这种想法是危险的。
像Zookeeper和Consul这样的工具确实有助于解决服务发现方面的问题,并允许应用程序对布局和组成系统发生变化时做出反应。
构建能够对这些拓扑变化做出反应的系统可能很棘手,但最终会产生更具弹性的系统。
6、总是有一个管理员
这个谬误本质上说是你不能控制一切。
随着系统的发展,它们将依赖于你无法控制的其他系统。花点时间想想所有的依赖关系;你拥有从代码到运行它们的服务器的一切。
有一种清晰的方式来管理你的系统及其各自的配置是非常重要的。随着具有各种配置的系统数量的增加,管理和跟踪变得越来越困难。基础设施即代码(IaC)可以帮助对系统中的这些配置变化进行编码。
当问题出现时,有一个诊断问题的好方法,监控和可观察性将是可以节省时间的关键工具。
另外,适当的解耦还可以帮助确保整体系统的弹性和正常运行时间。
7、网络传输成本是0
我们经常认为用于在系统之间发送数据的资源是一种简单的业务成本。当数据很小的时候,这些开销和成本是可以忽略不计。
尽管如此,随着系统的增长,与 gRPC 或 MessagePack 等传输优化格式相比,优化 JSON 等消息格式的成本可能有点重(双关语意)。
尽管如此,随着系统的增长,与gRPC或MessagePack等传输优化格式相比,优化JSON这类有点重的消息格式的成本是值得的。
了解这些成本是必要的;但是,它也有它的权衡。在短期内,过早优化可能会带来更多的麻烦。
8、网络是同质化的
我们肯定曾经写过不少转换程序,将一种格式的数据转换成另一种格式。
我们喜欢一切都干净整洁,但现实世界远非如此。互操作是必不可少的。
这种灵活性确保我们的系统在 "新的热门框架 "出现时,或者当你需要在原本未考虑过的环境中运行你的新系统时,能够继续发挥作用。
知道所有的系统都不一样,并且不将您的解决方案耦合到特定方面技术,可以节省您的时间和麻烦。
结语
在我们广泛的应用微服务架构时,我们要意识到微服务架构本质上是一种分布式系统的架构。
作为分布式系统架构,我们就要面临很多分布式系统面临的挑战。了解“分布式系统的谬误”可以很好的规避我们在使用微服务架构所必要考虑的问题,而不是当这些问题不存在!
参考资料:
https://architecturenotes.co/fallacies-of-distributed-systems/
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
文章出自:爱科学的卫斯理,如有转载本文请联系爱科学的卫斯理今日头条号。