通过接受挑战并将其融入您的设计中，您可以获得分布式系统的真正好处。让我们一一看看这些挑战。如今，分布式系统风靡一时。每当我访问Internet上的技术出版物时，我通常会发现一堆关于分布式系统的好处的帖子。每个人似乎都对分布式系统的一般概念及其带来的表面优势着迷。虽然创建有助于人们学习的信息内容没有坏处，但我发现很多时候分布式应用程序被设计成易于构建的东西。然而，现实却大不相同。构建和运行分布式系统很困难。否则不要让任何人告诉你。创建分布式系统的任务具有挑战性。具有讽刺意味的是，许多挑战源于使这些系统首先具有吸引力的好处。在尝试构建分布式系统时，您不应忽视这些挑战。如果你这样做，你将陷入一个充满麻烦的世界。但是，如果您接受这些挑战并将它们纳入您的设计中，您就可以获得分布式系统的真正好处。让我们一一看看这些挑战。通信分布式系统是分布式的。多个节点。可能在地理上是分开的。没有其各个节点之间的通信，任何分布式系统都无法运行。即使是在Web浏览器中浏览网站这一看似简单的任务，也需要不同进程之间进行大量通信。当我们访问一个URL时，我们的浏览器会联系DNS来解析该URL的服务器地址。获得地址后，它会通过网络向服务器发送HTTP请求。服务器处理请求并发回响应。系统设计者应该问几个关于通信的重要问题：请求和响应消息如何在网络中表示？网络中断时会发生什么？我们如何避免被窥视？诸如HTTPS之类的抽象用于解决许多此类通信挑战。但是，抽象可能会泄漏。例如，TCP试图提供底层不可靠网络的完整抽象。但如果网线被切断或过载，TCP将无能为力。当这种情况发生时，挑战就落在了系统设计者身上。协调假设有两位将军和他们各自的军队。他们需要相互配合，同时进攻一座城市。只有同时进攻，才能攻下城池。为此，他们需要就攻击时间达成一致。由于军队在地理上是分开的，将军们只能通过派遣使者来沟通。不幸的是，信使必须穿越敌人的领土并可能被俘虏。两位将军如何商定进攻时间？他们中的一个可以通过发送信使并等待响应来向另一个建议时间。但是如果没有回应怎么办？快递员会不会被抓了？快递员会不会受伤并需要比预期更长的时间？一般要不要再发一个快递？这个问题不是微不足道的。无论他们派出多少使者，两位将军都不能确定对方军队会在适当的时候攻城。派出更多的使者可以增加协调成功的几率，但几率永远不会是100%。在分布式系统的上下文中，这个问题被称为第二个一般问题。将军就像分布式系统中的节点。为了使系统工作，节点应该相互协调。但是，节点随时可能因故障而失效。一开始，每个开发人员都觉得他们要构建一个没有错误的系统。我以前也是这么想的。当然，这是天真的追求，注定要失败。您无法构建一个完全没有错误的系统。分布式系统越大，失败的概率就越高。尽管出现一个或多个故障，容错系统仍会继续运行。诀窍是让系统中的节点在发生故障时相互协调。可扩展性在构建分布式系统时，可扩展性往往是系统设计者最关心的问题。在基本层面上，可伸缩性是衡量随负载增加的系统性能的指标。但是我们如何衡量分布式系统的性能和负载呢？对于性能，我们可以使用两个出色的参数：吞吐量和响应时间。吞吐量表示每秒处理的操作数。响应时间是客户端请求和响应之间经过的总时间。系统负载的测量更具体到系统用例。例如，系统负载可以通过并发用户数、通信链路或写入与读取的比率来衡量。性能和负载本质上是相互关联的。随着负载的增加，最终会达到系统的容量。容量可能取决于系统的物理约束，例如：节点的内存大小或时钟周期带宽和网络链路的延迟当负载达到容量时，系统的性能要么停滞不前，要么恶化。如果系统上的负载继续增长超出容量，它最终将达到大多数操作失败或超时的程度。吞吐量下降，响应时间猛增。此时，系统不再具有可扩展性。参见下图，它显示了这种情况。我们如何使系统具有可扩展性？如果负载超过容量是导致性能下降的原因，我们可以通过增加容量来使系统具有可扩展性。增加容量的一种快速简便的方法是购买具有更好性能指标的更昂贵的硬件。这种方法称为放大。虽然在纸面上听起来不错，但这种方法迟早会碰壁。一种更可持续的方法是通过向系统添加更多机器来进行扩展。如果您有兴趣，我还更详细地介绍了分布式系统中的可伸缩性。弹性故障在分布式系统中很常见。有几个原因：首先，向外扩展会增加失败的可能性。由于系统中的每个组件都有固有的故障概率，因此添加更多部件会增加总体故障概率。其次，更多的组件意味着更多的操作。这增加了系统中故障的绝对数量。最后，失败不是独立的。一个组件的故障会增加其他组件发生故障的可能性。当系统大规模运行时，任何可能的故障最终都会发生。理想的分布式系统必须接受故障并以弹性方式运行。当一个系统即使在发生故障的情况下也能继续运行时，就可以说它是有弹性的。我们可以使用冗余和自我修复机制等各种技术来增加系统的弹性。然而，这不是零和游戏。没有分布式系统可以100%有弹性。在某些时候，故障会损害系统的可用性。可用性是一个重要指标。它是应用程序可以为请求提供服务的时间除以测量的持续时间。组织通常使用9的概念按百分比来推销其系统的可用性。三个九(99.9%)通常被认为对于大量系统来说是可以接受的。任何超过四个九(99.99%)的东西都是高可用的。关键任务系统可能需要更多9.这是一个方便的图表，显示实际停机时间占可用性的百分比。操作在所有其他挑战中，操作分布式系统可能是最困难的。但我也看到了这个领域正在发生的最重要的创新。就像任何其他软件系统一样，分布式系统也需要经历开发、测试、部署和运行的软件开发生命周期。然而，软件由两个独立的团队或部门开发和运营的日子已经一去不复返了。分布式系统的复杂性催生了DevOps。现在，设计和开发该系统的同一个团队有望在生产中运行它。这给开发团队带来了一些他们以前忽略的困难。需要以安全的方式不断推出新的部署。系统需要是可观察的。当服务水平目标有被违反的风险时，需要发出警报。这种变化也有积极的一面。对于开发人员来说，没有比随叫随到的支持更好的方法来找出系统的不足之处。只要确保您因破坏周末而得到适当的报酬！结论构建分布式系统并不容易。它在通信、协调、可扩展性、弹性和操作方面充满了多重挑战。但解决这些挑战是有益的。当分布式系统按计划工作时，它会创建一种令人赏心悦目的特殊组件舞蹈。
