复原设计
 工作负荷必须继续以完整功能或降级的功能运行。 |
|---|
你应该预料到会发生组件故障、平台中断、性能降低和其他故障。 在系统中建立复原能力，使其可以容错并且可以正常降级。
示例场景
Contoso Air 是一家商业航空公司，有一个内部开发部门。 主要的 LOB 应用程序是一个预订解决方案，允许客户直接通过 Contoso Air 预订航班。 该应用内置于 Azure 中，使用 Azure 应用服务、Cosmos DB、Azure Functions、Azure 逻辑应用和 Azure 服务总线。
确定故障风险
识别系统中的潜在故障点（尤其是针对关键组件的），并确定对用户和系统流的影响。
分析每个潜在故障点的故障案例、爆炸半径和故障强度。 故障案例及其强度可能会有一个范围，既可以是影响相对较小的场景（例如后端进程暂时丢失），也可以是因灾难而导致的全面中断。 执行此分析有助于确定组件级别的错误处理功能的设计。
Contoso 的挑战
- LOB 应用程序提供了从营销到商务的许多关键功能。 购票用户流已被确定为最关键的流。 工作负荷团队已确定应实施更多可靠性措施，以确保流针对复原能力进行了优化。
- 团队有时间预算用于分离组件和重新设计流等改进，但希望确保能够将这些时间专用于最高价值的改进。
应用方法和成果
- 团队将外部支付网关确定为潜在的故障点。 网关可用性很高，但用户可能会偶尔遇到因网络问题或请求激增而导致的暂时性故障。 网关在因多个同时发送的请求而过载时可能会拒绝某些请求。
- 团队确认，当用户的初始请求被网关拒绝时，用户必须重新提交请求，从而导致负面的用户体验。
实施自我保护机制
通过正确使用设计模式以及将设计模块化来隔离故障，建立自我保护能力。
通过在系统中建立自我保护能力，你将能够防止问题影响下游组件。 系统将能够缓解暂时性和永久性故障、性能瓶颈以及其他可能影响可靠性的问题。 你还可以将爆炸半径最小化。
Contoso 的挑战
- 团队希望最大限度地降低因暂时性故障而导致用户的请求被支付网关拒绝的风险。 由于某些错误条件的瞬态性，相同的请求在重新提交的情况下很可能会成功。
应用方法和成果
- 团队在流中开发自定义逻辑，以便在检测到可重试的故障时在短暂延迟后重试事务。
- 将修改解决方案设计以纳入“重试模式”，稍微增加重试之间的等待时间，直到成功处理请求或达到最大失败次数。
- 团队还决定使用 Azure 服务总线的事件驱动方法来分离此流的用户交互和后端支付处理功能。 如果在处理消息时发生不可恢复的故障（在最大重试次数之后），后端处理器会放弃处理该请求，将消息留在队列中，以便稍后重新处理它。
构建全面的冗余和复原能力
在各个应用程序层上构建层冗余和复原能力。
目的是实现物理实用工具的冗余和即时数据复制。 另外一个目的是在涵盖服务、运营和人员的功能层中实现冗余。 冗余有助于最大限度地减少单一故障点。 例如，如果发生影响一个或多个组件、一个可用性区域或整个区域的中断，冗余（主动-主动或主动-被动）部署可以让你满足运行时间目标。
添加中介可以防止组件之间的直接依赖并改善缓冲。 这两个好处都增强了系统的复原能力。
Contoso 的挑战
- 使用服务总线实现重试并将支付网关调用与 UI 分离极大地提高了该流的可靠性，但业务利益干系人仍然担心由于主要区域发生灾难性故障而可能发生数据丢失。
应用方法和成果
- 团队决定升级到服务总线高级层。 通过这样做，团队可以利用该层的可用性区域支持功能。 借助此功能，数据的多个副本可以存储在三个物理上独立的设施（可用性区域）中，并且服务具有足够的容量储备，可以立即应对数据中心的彻底的、灾难性的损失。
- 此外，团队还会配置 Azure 服务总线异地灾难恢复，以将数据持续复制到次要区域，该次要区域将在主要区域发生完全故障的极端情况下使用。