练习 - 构建分层运行状况结构
在本练习中，你的任务是为示例应用程序设计分层运行状况模型。 首先查看应用程序体系结构、应用程序使用的关键 Azure 服务，以及 Azure 服务对整体用户体验的贡献。
示例应用程序
本练习的示例是 Contoso Shoes 使用的 Web 应用程序。 该应用程序支持员工浏览产品目录、更新目录中的各个项，并通过在应用程序中创建注释与其他用户交互。
Contoso Shoes 的运营团队确定了此应用程序的两个关键业务需求。 员工必须能够：
- 通过显示项列表和浏览项来与目录交互。
- 为各个项创建注释，以供其他用户查看。
运行状况模型至少应包括以下两个关键操作。
体系结构
组件
前端 Web 应用程序：此工作负载的用户界面，在 Azure Web 应用上运行。
- 读取自：目录 API、Azure Blob 存储
- 写入到：目录 API
目录 API：前端 Web 应用程序用于对目录项和注释执行数据操作的 API 层。 它不会写入数据库。 而是将消息发送到事件中心进行异步处理。 此组件托管在 Azure Functions 上。
- 读取自：Azure Cosmos DB
- 写入到：Azure 事件中心
后台处理器：异步处理数据库更新的组件。 处理器没有公共终结点。 此组件托管在 Azure Functions 上。
- 读取自：Azure 事件中心
- 写入到：Azure Cosmos DB
消息中转站：消息处理器使用 Azure 事件中心在目录 API 和后台处理器之间传递消息。
数据库：数据保存在 Azure Cosmos DB 中。 目录 API 直接从数据库读取。 后台处理器处理写入。 映像存储在 Azure Blob 存储中。
机密：此工作负载的应用程序组件使用机密授予访问权限。 机密存储在 Azure Key Vault 中。 目录 API 和后台处理器使用连接字符串访问数据库和 Azure 事件中心。 前端 Web 应用程序使用 API 密钥来调用目录 API。
监视：应用程序组件将所有数据度量发送到 Application Insights，由 Log Analytics 工作区提供支持。 使用同一工作区收集此工作负载的其他日志和指标。
将体系结构分层
如上一单元所述，运行状况模型应该是分层结构。 为运行状况建模的过程是一个体系结构练习，用于定义所有用户流、映射功能组件和逻辑组件之间的依赖关系以及 Azure 资源之间的依赖关系。
在此阶段，识别用户流并构建运行状况模型是一项概念性练习。 使用纸笔或空白文档记录各个层并绘制结构。
对于本练习，我们的运行状况模型有三层：用户流、应用程序组件和 Azure 资源。
用户流
从体系结构的顶部开始，根据预期的应用程序功能考虑可能的用户流。 尝试抽象化技术详细信息和 Azure 服务，并从用户的角度评估流。
- 哪些过程至关重要？
- 员工如何使用应用程序实现业务目标？
根据运营团队确定的要求，顶层应至少有两个用户流：“列出目录项”和“添加注释”。
如果你能想到更多内容，请将它们包含在运行状况模型中。
应用程序组件
向下移动一层并评估应用程序组件。 首先提出问题，例如：
- “应用程序的哪一部分使此流正常工作？”
- “哪些微服务或组件参与此流？”
- “如果此部分失败，此流是否仍然正常工作？”
目的是识别在技术层面对每个用户流有贡献的应用程序组件。 这些组件可以是 API、后台工作线程、微服务等。
此工作负载至少有三个应用程序组件参与这两个识别的用户流：前端、目录 API 和后台处理器。
Azure 资源
底包含各个应用程序组件使用的 Azure 资源。 对于本练习，组件部分介绍了组件和资源。
注意
实际方案可能有更多服务，并且服务之间的关系更为复杂。 构建成功的运行状况模型的关键是确定哪些部分至关重要，以及每个组件对系统整体运行状况有何贡献。
绘制最终运行状况模型结构
将收集的信息置于运行状况模型结构的图形表示形式中。 应如下图所示：
从上到下，Web 应用程序运行状况模型具有以下层：
用户流
- 列出目录项。 依赖于前端 Web 应用程序和目录 API。
- 添加注释。 依赖于前端 Web 应用程序、目录 API 和后台处理器。
应用程序组件
- 前端 Web 应用程序。 依赖于 Blob 存储和目录 API。
- 目录 API。 依赖于 Azure Cosmos DB、Key Vault 和事件中心。
- 后台处理器。 依赖于 Azure Cosmos DB、Key Vault 和事件中心。
Azure 资源
- Blob 存储
- Azure Cosmos DB
- 密钥保管库
- 事件中心