本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
了解工作量
要应用该框架,首先要了解要分析的工作负载。系统架构图为记录系统最相关的细节提供了一个起点。但是,尝试分析整个工作负载可能很复杂,因为许多系统都有许多组件和交互作用。相反,我们建议您集中精力用户故事
每个用户故事都包含四个常见组件:代码和配置、基础架构、数据存储和外部依赖关系。您的图表应包括所有这些组件,并反映各组件之间的相互作用。例如,如果您的 Amazon API Gateway 终端节点负载过大,请考虑该负载如何级联到系统中的其他组件,例如您的AWS Lambda函数或亚马逊 DynamoDB 表。跟踪这些互动有助于你了解故障模式会如何影响用户故事。如上图所示,您可以使用数据流图或在架构图中使用简单的流程箭头直观地捕获此流。对于每个组件,请考虑捕获详细信息,例如正在传输的信息类型、接收的信息、通信是同步还是异步通信以及跨越了哪些故障边界。在示例中,DynamoDB 表在两个用户故事中共享,您可以从箭头中看到,该箭头表示应用内退款故事中的 Lambda 组件访问了应用内购买故事中的 DynamoDB 表。这意味着,由于共同的命运,由应用内购买用户故事引起的失败可能会级联到应用内退款用户故事。
此外,了解每个组件的基准配置也很重要。基准配置确定了约束条件,例如每秒的平均和最大事务数、有效负载的最大大小、客户端超时以及资源的默认或当前服务配额。如果您要对新设计进行建模,我们建议您记录设计的功能要求并考虑限制。这可以帮助你了解故障模式在组件中是如何表现出来的。
最后,你应该根据用户故事提供的商业价值来确定其优先级。这种优先级排序可帮助您首先专注于工作负载中最关键的功能。然后,您可以将分析重点放在作为该功能关键路径一部分的工作负载组件上,并更快地利用该框架实现价值。在迭代该过程时,您可以按不同的优先级检查其他用户故事。