选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

了解工作量 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

了解工作量

要应用该框架,首先要了解要分析的工作负载。系统架构图为记录系统最相关的细节提供了一个起点。但是,尝试分析整个工作负载可能很复杂,因为许多系统都有许多组件和交互作用。相反,我们建议您集中精力用户故事,它们是从最终用户的角度对软件功能进行非正式、一般性的解释。他们的目的是阐明软件功能如何为客户提供价值。然后,您可以使用架构图和数据流程图对这些用户故事进行建模,以便更轻松地评估提供所述业务功能的技术组件。例如,应用内手机游戏购买解决方案可能包含两个用户故事,“购买应用内积分” 和 “获得应用内退款”,如下图所示。(此示例架构重点介绍了如何将系统分解为用户故事;它并不打算代表具有高弹性的应用程序。)

包含两个用户故事的应用内购买系统

每个用户故事都包含四个常见组件:代码和配置、基础架构、数据存储和外部依赖关系。您的图表应包括所有这些组件,并反映各组件之间的相互作用。例如,如果您的 Amazon API Gateway 终端节点负载过大,请考虑该负载如何级联到系统中的其他组件,例如您的AWS Lambda函数或亚马逊 DynamoDB 表。跟踪这些互动有助于你了解故障模式会如何影响用户故事。如上图所示,您可以使用数据流图或在架构图中使用简单的流程箭头直观地捕获此流。对于每个组件,请考虑捕获详细信息,例如正在传输的信息类型、接收的信息、通信是同步还是异步通信以及跨越了哪些故障边界。在示例中,DynamoDB 表在两个用户故事中共享,您可以从箭头中看到,该箭头表示应用内退款故事中的 Lambda 组件访问了应用内购买故事中的 DynamoDB 表。这意味着,由于共同的命运,由应用内购买用户故事引起的失败可能会级联到应用内退款用户故事。

此外,了解每个组件的基准配置也很重要。基准配置确定了约束条件,例如每秒的平均和最大事务数、有效负载的最大大小、客户端超时以及资源的默认或当前服务配额。如果您要对新设计进行建模,我们建议您记录设计的功能要求并考虑限制。这可以帮助你了解故障模式在组件中是如何表现出来的。

最后,你应该根据用户故事提供的商业价值来确定其优先级。这种优先级排序可帮助您首先专注于工作负载中最关键的功能。然后,您可以将分析重点放在作为该功能关键路径一部分的工作负载组件上,并更快地利用该框架实现价值。在迭代该过程时,您可以按不同的优先级检查其他用户故事。

下一主题:

应用框架

上一主题:

框架概述
隐私网站条款Cookie 首选项
© 2024, Amazon Web Services, Inc. 或其附属公司。保留所有权利。