微服务很重要。它们可以为我们的架构和团队带来一些相当大的胜利，但微服务也有很多成本。随着微服务、无服务器和其他分布式系统架构在行业中变得更加普遍，我们将它们的问题和解决它们的策略内化是至关重要的。在本文中，我们将研究网络边界可能引入的许多棘手问题的一个示例：超时。

在你害怕“分布式系统”这个词之前，请记住，即使是一个带有 Node 后端的小型 React 应用程序，或者一个与 AWS Lambda 对话的简单 iOS 客户端，也代表一个分布式系统。当您阅读这篇博文时，您已经参与了一个分布式系统，其中包括您的 Web 浏览器、内容交付网络和文件存储系统。

在背景方面，我将假设您了解如何使用您选择的语言进行 API 调用并处理它们的成功和失败，但这些 API 调用是同步还是异步、HTTP 或不是。如果您遇到不熟悉的术语或想法，请不要担心！我很高兴在 Twitter 或其他地方进行更多讨论，并且我还尝试在适当的地方添加链接。

我们将要探讨的问题是：如果我们遇到一个非常非常慢的 API 调用最终超时，并且我们假设 (a) 它成功或 (b) 它失败，我们就会遇到错误。超时（或更糟糕的是，无限长的等待）是分布式系统的一个基本事实，我们需要知道如何处理它们。

问题

让我们从一个思想实验开始：你有没有给同事发邮件向他们要东西？

• [星期二，上午 9:58] 你：“嘿，你能把我加到我们公司的潜在导师名单中吗？”
  
• 同事：“……”
  
• [星期五，下午 2:30] 你：[?]
  

你该怎么办？

如果您希望您的请求得到满足，您最终需要确定没有回复。你会等更长的时间吗？你想等多久？

那么，一旦你决定等待多长时间，你会采取什么行动？您是否再次尝试发送电子邮件？你尝试不同的传播媒介吗？你认为他们不会这样做吗？

好的，现在这里到底发生了什么？我们希望看到这种请求-响应行为：

但是出了点问题。有几种可能性：

• 他们从来没有得到消息。
  

• 他们收到了邮件，成功处理了邮件，然后给您发回了一个从未收到您的回复（或转到您的垃圾邮件文件夹）。
  

• 他们得到了信息，但他们仍在思考，或者他们失去了它，或者[喘气！]他们忘记了。
  

• 最终，我们只是不知道！
  

正是这个问题出现在分布式系统上的任何通信中。

我们可能会延迟我们的请求、处理或响应，而这些延迟可能是任意长的。因此，与电子邮件示例一样，我们需要确保“我们要等多久？”问题有答案，我们称该持续时间为超时。

如果您只从本文中学到一个教训，那就这样吧：使用超时。否则，您将面临永远等待永远不会完成的操作的风险。

但是一旦我们达到了超时，等待的上限，我们该怎么办？

方法

当人们在远程系统调用中遇到超时时，有几种常见的方法。我并不声称这份清单是详尽无遗的，但它确实涵盖了我见过的许多最常见的场景。

方法#1

当您遇到超时时，假设它成功并继续前进。

请不要这样做。[1]不幸的是，我不得不说这是一个常见的无意识选择，即使在生产应用程序中，也会有一些非常糟糕的用户体验结果。如果我们假设手术成功了，我们可怜的消费者就会合理地假设事情进展顺利——只是后来当他们发现结果时会感到失望和困惑。

任何时候你有一个网络呼叫，寻找成功和失败的案例。例如，如果你在 JavaScript 中通过 Promise.then(...) 使用异步 API，请问问自己对应的 .catch(...) 在哪里。如果它丢失了，你几乎肯定有一个错误。

在一些非常特殊的情况下，您可能理所当然地不在乎请求是成功还是失败。UDP 是具有此属性的非常成功的协议。另外，很多软件坏了，继续赚钱就好了！但请不要让这成为您的默认设置——先用尽您的其他选项。

方法#2

对于读取请求，请使用缓存或默认值。

如果您的请求是读取请求并且不打算对远程端产生任何影响，那么这可能是一个不错的选择。在这种情况下，您可以使用先前成功请求中的缓存值。或者，如果还没有成功的请求或者缓存在您的情况下没有意义，您可以使用默认值。这种方法相对简单：它不会增加太多的性能开销或实现复杂性。但请记住，如果您使用的是通过网络访问的进程外缓存（例如，memcached、Redis 等），那么您将回到类似的情况，即您的请求对缓存本身可能会超时。

方法#3

当您遇到超时时，假设远程操作失败，然后自动重试。

这提出了更多的问题：

• 如果重试不安全怎么办？网络连接另一端的服务获取重复项只是烦人吗？或者你是双重收取信用卡？（！）
  
• 您应该同步重试还是异步重试？
  
• 如果您同步重试，从消费者的角度来看，这些重试会减慢您的速度——您是否有可能无法满足他们的期望？这在服务中尤其重要，而不是最终用户应用程序。
  
• 如果你异步重试，你告诉你的消费者关于操作成功的什么？您是一次尝试一个，还是在一段时间内分批重试？
  
• 您应该重试多少次？（一次？两次？10次？直到成功？）
  
• 您应该如何在重试之间延迟？（指数退避[例如，1s、2s、4s、8s、16s，...] 以最大等待时间为界？使用抖动？）
  
• 如果远程服务器由于过载而出现性能问题，重试是否会使他们的情况变得更糟？
  

如果远程 API 可以安全地重试，我们称之为幂等。如果没有幂等属性，您可能会创建重复数据（如信用卡费用的情况）或导致竞争条件（即，如果您尝试更改您的电子邮件地址两次，并且第一个在第二个完成后重试）。

在许多情况下，使自动重试安全可能需要大量的架构工作。但是，如果您可以安全地重试（例如，通过发送请求 UUID，并让远程端跟踪这些），事情就会变得非常非常简单。查看 Stripe API 以了解实际情况的一个很好的示例。

方法#4

检查请求是否成功，如果安全再试一次。

这里的想法是，在某些情况下，我们可以在超时请求之后跟上另一个请求，询问我们原始请求的状态。这种方法显然需要存在一个端点，可以为我们提供我们想要的信息。给定这样一个端点，如果端点说我们的请求成功，我们可以明确地说我们不需要重试。

但是这里有一个严重的问题，我们无法真正知道重试是否安全。因为通常我们的远程服务可以接收到请求，但仍在处理中，因此我们正在检查的查询端点将无法确认成功。当然，检查本身可能会超时！远程服务器可能由于与初始故障相同的原因而完全无法访问，但即使这是真的，我们仍然无法知道问题是在处理初始请求之前还是之后发生的。

方法#5

放弃并让用户弄清楚。

这需要最少的努力，并且可以说可以防止我们做出错误的决定，因此在许多情况下这可能是最佳选择。我们还需要问自己：我们的用户能找出正确的做法吗？他们是否有足够的信息和对其他系统的洞察力来确定如何前进？

在某些情况下，让我们的消费者知道这个问题可能是最好的选择。对于任何涉及重试的方法，如果我们不想允许无限次数的重试，我们最终可能仍会退回到这条路径！

结论

所以在这一点上，事情可能看起来很黯淡。分布式系统很难，看来我们不能只选择其中一种解决方案作为灵丹妙药。如果您感到失败，请振作起来，不要让完美成为美好的敌人。

使用超时。

即使超时时间很长，比如 5 秒、10 秒或 [gulp!] 甚至更多，每个网络请求都应该有一些超时时间。选择超时可能很棘手——当请求最终成功时，您不希望有太多失败（误报），也不希望浪费太多时间并冒着不健康的应用程序的风险。您可以通过查看历史请求的分布和趋势以及您的应用程序自身的性能保证或风险概况来确定好的值。

在任何情况下，我们都不希望我们的应用服务器的队列、连接池、环形缓冲区或任何瓶颈被将永远等待的东西堵塞。您绝对可以根据您的生产需求研究并添加更高级的东西，例如断路器和隔板，但是超时很便宜并且库很好地支持。使用它们！

默认使重试安全。

除了让你的代码更简单、更安全之外，你还会说“幂等性”，这很有趣。

考虑以不同的方式委派工作。

异步消息传递在这里有一些吸引人的特性，因为您的远程服务不再需要保持快速和可用；只有您的消息代理可以。但是，消息传递/异步性并不是灵丹妙药——您仍然需要确保代理收到消息。不幸的是，这可能很难！消息代理也有权衡。您的用户对于何时需要重试会有自己的想法。例如，如果消息处理延迟，他们可能会决定重新提交，因为他们的订单尚未显示在订单历史记录中。分布式日志/流媒体平台也可能出现类似问题。如果您正在考虑消息传递路线（实际上，即使没有！），请仔细查看 Enterprise Integration Patterns — 尽管它年代久远，但其中的模式与当今的架构极为相关。

并且冒着成为派对大便的风险，不要忘记您可能能够完全移动或删除该网络边界！把一个难题变成一个简单的问题并没有什么可耻的。因此，也许您可以使用一个网络请求而不是五个，或者您可以将两个服务内联在一起。或者，也许您采用上述方法之一以可靠和安全的方式处理超时。无论您选择哪种方式，请记住，您的用户并不关心您是否使用微服务——他们只是想让事情正常工作。