答复。

问题的历史

随着微服务架构和分布式系统的转变，在服务之间交互时发生错误的概率急剧增加，同时它们的处理复杂性也随之提升。早期的方法通常未考虑网络交互的不稳定性，导致在生产环境中出现大规模事件。

问题

关键问题在于，复杂的故障、服务退化和集成错误的场景在要求中未得到充分形式化。因此，开发人员不得不自行决定错误处理方案，这导致案例的多样性和测试的困难。

解决方案

有效的错误处理描述应包括：

• 确定错误类型（网络故障、超时、第三方服务失败、业务逻辑错误、数据不一致）。
• 为每种错误类型编写反应选项：重试、事务回滚、功能降级、警报、用户消息。
• 引入明确的故障测试场景（故障切换、优雅降级），包括非特定和链式事件。
• 文档化错误的合同和格式（例如，标准的错误响应JSON合同）。

关键特点：

• 在服务之间标准化错误处理模板。
• 验证降级场景并与业务达成一致。
• 确保错误追踪和日志记录以供后续事件分析。

设问。

在要求中是否必须描述技术错误的处理——难道这不是开发者的任务？

必须必须。未反映的错误处理政策经常导致工作中的错误和误解。系统分析师有责任讨论错误情况下的行为。

是否需要描述极少发生的情况（例如，服务之间部分失去联系）？

是的，因为极少发生的错误往往导致最复杂的事件。其后果可能对业务至关重要。

是否需要与业务协调展示给用户的错误消息？

是的。需要与业务协调准确、信息丰富但不冗余或恐怖的消息，否则会影响用户体验和忠诚度。

常见错误和反模式

• 仅描述成功路径，忽视故障场景。
• 忽视系统退化（备份场景未被描述）。
• 用户错误消息未达成一致或技术上复杂。

实际案例

负案例：项目中未描述服务之间超时的处理场景。结果，由于不稳定的网络，服务“挂起”无响应。优点：快速执行基本场景。缺点：生产中的大量故障，客户的不满，“手动”关闭事件。

正案例：分析师描述了降级、重启、重试和正确消息的场景。优点：在故障时服务的高稳定性，减少事故数量。缺点：在场景架构的处理上需要更多时间。