通过接受挑战并将其纳入您的设计中，您可以获得分布式系统的真正好处。让我们一一看看这些挑战。

如今，分布式系统风靡一时。

每当我访问 Internet 上的技术出版物时，我通常会发现一大堆关于分布式系统的好处的帖子。每个人似乎都对分布式系统的一般概念及其带来的表面优势着迷。

虽然创建可以帮助人们学习的信息内容没有坏处，但我发现很多时候分布式应用程序被设计为易于构建的东西。

然而，现实却大不相同。

构建和运行分布式系统很困难。否则不要让别人告诉你。

创建分布式系统的任务充满挑战。具有讽刺意味的是，许多挑战源于使这些系统首先具有吸引力的好处。在尝试构建分布式系统时，您不应忽视这些挑战。如果你这样做，你最终会陷入麻烦的世界。

但是，如果您接受这些挑战并将它们纳入您的设计中，您就可以获得分布式系统的真正好处。让我们一一看看这些挑战。

沟通

分布式系统是分布式的。

多个节点。可能是地理上分开的。

没有其各个节点之间的通信，任何分布式系统都无法运行。

即使是在 Web 浏览器中浏览网站这一看似简单的任务，也需要不同进程之间进行大量通信。

当我们访问一个 URL 时，我们的浏览器会联系 DNS 来解析该 URL 的服务器地址。一旦获得地址，它就会通过网络向服务器发送 HTTP 请求。服务器处理请求并发回响应。

系统设计者应该问几个关于通信方面的重要问题：

• 请求和响应消息是如何通过网络表示的?
• 在网络中断的情况下会发生什么?
• 我们如何保证安全免受窥探?

我们可以通过退回到 TCP 和 HTTPS 等抽象来应对其中的许多通信挑战。

但是，抽象可能会泄漏。例如，TCP 试图提供底层不可靠网络的完整抽象。但如果网络电缆被切断或过载，TCP 将无能为力。当这种情况发生时，挑战就落到了系统设计者身上。

协调

想象一下，有两位将军和他们各自的军队。他们需要相互配合才能同时进攻一座城市。只有同时进攻，才能攻下城池。为此，他们需要就攻击时间达成一致。

由于军队在地理上是分开的，将军们只能通过派遣使者来进行交流。不幸的是，信使必须穿过敌人的领土并可能被俘虏。

两位将军怎么能就进攻时间达成一致呢?

他们中的一个可以通过发送信使并等待响应来向另一个建议时间。但是，如果没有响应怎么办?会不会是信使被抓了?信使会不会受伤并且需要比预期更长的时间?将军应该再派一个使者吗?

这个问题不是微不足道的。

无论派出多少使者，两位将军都不能确定对方军队会在正确的时间攻城。派遣更多的使者可以增加协调成功的机会，但机会永远不会达到 100%。

在分布式系统的上下文中，这个问题被称为二一般问题。将军就像分布式系统中的节点。为了使系统工作，节点应该相互协调。但是，节点随时可能因故障而失效。

在开始时，每个开发人员都觉得他们将构建一个无故障的系统。我以前也是这么想的。当然，这是一种天真的追求，注定要失败。您无法构建一个完全没有错误的系统。分布式系统越大，出现故障的概率就越高。尽管存在一个或多个故障，容错系统仍可以继续运行。诀窍是使系统中的节点在出现故障时相互协调。

可扩展性

在构建分布式系统时，可伸缩性通常会引起系统设计人员的最大关注。

在基本层面上，可伸缩性是衡量系统性能随负载增加的指标。

但是我们如何衡量分布式系统的性能和负载呢?

• 对于性能，我们可以使用两个优秀的参数：吞吐量和响应时间。吞吐量表示每秒处理的操作数。响应时间是客户端请求和响应之间经过的总时间。
• 系统负载的测量更具体到系统用例。例如，系统负载可以通过并发用户数、通信链路或写入与读取的比率来衡量。

性能和负载本质上是相互关联的。随着负载的增加，最终会达到系统的容量。容量可能取决于系统的物理限制，例如：

• 节点的内存大小或时钟周期
• 网络链路的带宽和延迟

当负载达到容量时，系统的性能要么停滞不前，要么恶化。

如果系统上的负载继续增长超过容量，它最终会达到大多数操作失败或超时的程度。吞吐量下降，响应时间猛增。此时，系统不再具有可扩展性。请参见下图，该图显示了这种情况。

我们如何使系统具有可扩展性?

如果负载超出容量是导致性能下降的原因，我们可以通过增加容量来使系统具有可扩展性。增加容量的一种快速简便的方法是购买具有更好性能指标的更昂贵的硬件。这种方法称为放大。

尽管在纸面上听起来不错，但这种方法迟早会碰壁。

更可持续的方法是通过向系统添加更多机器来进行扩展。

如果您有兴趣，我还对分布式系统中的可扩展性有更详细的了解。

弹性

故障在分布式系统中很常见。有几个原因：

• 首先，向外扩展会增加失败的可能性。由于系统中的每个组件都有发生故障的内在概率，因此添加更多部件会增加总体故障概率。
• 其次，更多的组件意味着更多的操作。这增加了系统中故障的绝对数量。
• 最后，失败不是独立的。一个组件的故障会增加其他组件发生故障的可能性。

当系统大规模运行时，任何可能发生的故障最终都会发生。理想的分布式系统必须接受故障并以弹性方式运行。当一个系统即使在发生故障时也能继续工作时，就被认为是有弹性的。

我们可以使用多种技术(例如冗余和自我修复机制)来提高系统的弹性。然而，这不是零和游戏。没有分布式系统可以 100% 有弹性。在某些时候，故障会削弱系统的可用性。

可用性是一个重要指标。它是应用程序可以为请求提供服务的时间除以测量的持续时间。

组织通常使用 9 的概念以百分比形式推销其系统的可用性。三个九 (99.9%) 通常被认为对大量系统来说是可以接受的。任何超过四个九 (99.99%) 的东西都是高可用的。关键任务系统可能需要更多的 9。

这是一个方便的图表，它展示了实际停机时间的可用性百分比。

操作

在所有其他挑战中，操作分布式系统可能是最困难的。但我也看到了这一领域发生的最重要的创新。就像任何其他软件系统一样，分布式系统也需要经历开发、测试、部署和运行的软件开发生命周期。

然而，过去由两个独立的团队或部门来开发和操作软件的日子已经一去不复返了。分布式系统的复杂性催生了DevOps。现在，设计和开发系统的同一个团队有望在生产环境中运行它。这给开发团队带来了一些他们之前忽略的困难。

• 需要以安全的方式不断推出新的部署。
• 系统需要是可观察的。
• 当服务水平目标有被破坏的风险时，需要发出警报。

这种变化也有积极的一面。对于开发人员来说，没有比提供随叫随到的支持更好的方法来找出系统的不足之处了。只要确保为破坏你的周末而得到适当的报酬!

结论

构建分布式系统并非易事。它充满了围绕通信、协调、可扩展性、弹性和 运营领域的多重挑战。但解决这些挑战是有益的。当分布式系统按计划工作时，它会创造出一种特殊的组件舞蹈，令人赏心悦目。