为停机设计：理解“易怒路径”

有关更多信息，请访问 developer.intuit.com。

作为一名自学成才、多年的 应用程序开发人员，我学到了许多惨痛的教训。大多数教训对我们来说都很普遍：删除表之前备份数据库，在处理服务器主板之前接地，检查可能向 CEO 发送垃圾邮件的无限循环等等。最近，我再次体会到了一个最难吸取的教训：网络调用总会在最糟糕的时候失败。无论是与重要客户视频聊天，还是调用数据库写入新客户记录，亦或是调用第三方服务的 API，准备应对瞬时错误和停机至关重要。我发现，让客户保持满意并最终使用我们辛勤工作和优美代码的应用程序的最佳方法，就是从用户体验的角度进行设计，以应对停机。在本文中，我将描述一些设计策略，以在处理潜在的网络连接问题时提供更好的用户体验。

理解“糟糕路径”

在为停机进行设计时，第一步是完全理解用户体验。我喜欢从“顺畅路径”（happy path）的角度来思考用户体验的每一步，在这种情况下，一切都很顺利；用户点击正确的按钮（按正确的顺序），最终会到达一个祝贺页面，庆祝他们愉快的体验。令人遗憾的是，顺畅路径很容易。而设计“糟糕路径”（cranky path）可以保护我们的用户免于遭受挫败的体验。沮丧的用户会忽略应用程序的更大好处，并最终放弃我们无数小时的工作和整洁的代码。

理解糟糕路径为应用程序的技术设计带来了许多显著的好处

• 我可以根据应用程序修复对糟糕路径的影响来确定修复的优先级
• 我可以设置重试策略，以更好地影响用户体验
• 设定用户期望并制定周到的消息传递，以保持我的应用程序用户的满意度。

以下是我使用的一些方法，它们将帮助您为糟糕路径设计应用程序，并让您的客户满意。

幂等请求

幂等听起来令人生畏，但却非常重要，尤其是在管理会计数据时。幂等的简要定义是，相同的操作，相同的输入，总是会产生相同的输出。“请求幂等性”可确保重复调用 QuickBooks Online 服务不会导致重复交易并创建不准确的数据。调用服务时，您必须考虑到在底层服务已成功执行后可能会发生失败。在这些情况下，您需要重试执行服务调用，而幂等服务应能处理您的请求并每次都提供相同的输出。

没有请求幂等性，应用程序就无法保证数据准确性，并存在重复或被放弃交易的风险。试想一下，如果银行或会计师在 10 次处理 100 美元的存款，可能会出现什么问题。

• 在幂等服务中，我们的账户余额会因一次 100 美元的存款而增加 100 美元，并且新余额会被报告 10 次，每次都相同。
• 在非幂等服务中，我们的账户余额会在 10 次存款中每次都增加 100 美元，并且新余额报告为每次增加 100 美元，总共增加 1000 美元。

有关幂等请求的更详细描述，Sridhar Kalaga 最近撰写了一篇 关于幂等 API 的精彩博文。将幂等性视为所有重试策略的前提条件。

重试策略

重试策略是一种机制，允许您的应用程序在预定的时间表或围绕您的应用程序的其他条件失败时重新执行操作。重试策略中可以使用三种常见的重试算法。

• 固定 — 如果用户正在执行一项操作并期望立即响应，那么一次固定重试（或不重试）可能是提供用户期望行为的合适尝试。
• 增量 — 如果用户正在运行一个长时间或无人值守的操作，更长的重试间隔可能是可以接受的，以增加操作成功重试的可能性。
• 指数 — 如果无人值守的操作可以容忍，那么重试之间的持续时间（称为回退间隔）可以呈指数级增加，以便在操作继续失败时有更多的时间流逝。

在这三种策略算法中，目标都是从用户的角度成功完成目标操作。如果重试策略失败，向用户呈现一个周到的错误消息可能会对用户体验产生重大影响。

如果您正在利用应用程序中成熟的库，例如 .NET 和 Java QuickBooks SDK，它们内置了固定、增量和指数策略，您可以对这些策略进行调整以满足您的应用程序需求。

在实现重试策略时，同样重要的是要考虑何时“短路”或阻止重试操作。如果任何服务完全中断，您花哨的指数回退算法将变得毫无用处。一旦应用程序尝试达到预定的最大次数，您就必须短路并等待一段较长的时间才能重试。我建议考虑使用轻量级的 API 作为健康检查，然后再恢复处理，以节约资源、时间，并防止日志被错误填满。

原子操作

原子操作是在您的应用程序中执行的操作，它将始终在没有其他进程或操作能够中断它并更改正在操作的底层状态的情况下执行。关系数据库事务有助于使与我们数据的交互具有原子性。在审查应用程序的服务调用时，请考虑哪些操作组必须是原子的。当您考虑销售或其他直接影响受监管信息（如会计数据）的交易时，这一点非常重要。

例如，如果用户期望收到一张附有已关联付款的发票，但应用程序只能写入发票，那么至关重要的是要提醒用户并重试付款操作，直到发票被正确标记为已付款。在这种情况下，我建议将发票和付款操作设为原子操作，以避免需要重试策略和通知机制。

引入混沌

在应用程序中引入混沌是理解糟糕路径、测试应用程序重试策略以及充分理解用户在服务失败时的感受的另一种好方法。Netflix 在其系统中引入了一个名为“混沌猴”的工具，故意制造不同的故障，并验证其应用程序能否在这些故障中继续生存。在测试期间，您的应用程序可以使用 WireMock、MockServer，甚至您自己的存根服务等工具来模拟 Web 服务异常。

测试混沌模式的有限实验计划

为了帮助您开始测试您的流程，我们正在为开发人员提供一个有限可用、实验性的计划。这使您能够直接在我们的 QuickBooks SDK 之一中测试内置的混沌模式。启用混沌模式后，SDK 将在可配置的容忍级别引入模拟服务错误。我们希望这项功能能帮助开发人员在服务可能不合作的情况下，继续提供令人愉快的客户体验。 申请参加我们的实验计划，并开始使用启用了混沌模式的服务进行测试。