通过

有关设计简单高效的建议

  • 项目

适用于此 Power Platform Well-Architected 可靠性检查表建议：

回复：01 将工作负荷设计为与业务目标保持一致，并避免不必要的复杂性或开销。 使用实用且平衡的方法做出设计决策，以提供所需的结果。 将您的设计包含在必要条件中，以减少低效和潜在问题。

本指南介绍有关最大限度地降低不必要的复杂性和开销以保持工作负荷简单高效的建议。 选择最佳组件来执行必要的工作负荷任务，以优化工作负荷的可靠性。 若要减轻开发和管理负担，请利用平台提供的服务提供的效率。 此设计可帮助您创建可复原、可重复、可缩放且可管理的工作负荷体系结构。

定义

术语 定义
工作负载 可以在逻辑上与其他任务分开的离散功能或计算任务。

关键设计策略

设计可靠性的关键原则是保持简单高效。 将工作负荷设计重点放在满足业务要求上，以降低不必要的复杂性或过多开销的风险。 请考虑本文中的建议，以帮助您就设计做出决策，以创建精简、高效且可靠的工作负荷。 不同工作负荷在可用性、可伸缩性、数据一致性和灾难恢复方面可能有不同的要求。

必须根据业务要求来证明每个设计决策的合理性。 此设计原则看似显而易见，但它对于工作负荷设计至关重要。 您的工作负载是支持数百万个用户还是几千个用户？ 是存在大型流量突发，还是稳定的工作负荷？ 什么级别的中断是可以接受的？ 业务要求驱动着这些设计注意事项。

权衡： 复杂的解决方案可以提供更多功能和灵活性，但它可能会影响工作负载的可靠性，因为它需要更多的协调、通信和组件管理。 或者，更简单的解决方案可能无法完全满足用户的期望，或者随着工作负荷的发展，它可能会对可扩展性产生负面影响。

协作设计练习

与利益干系人合作，以：

  • 定义并分配工作负载及其组件的关键性级别。 本练习将帮助您确定所需的组件和最佳方法，以实现所需的复原级别。 有关详细信息，请参阅定义应用程序层。

  • 定义功能和非功能需求。 功能性要求定义系统的功能和行为。 它们由用户指定，在用例中捕获。 非功能性要求定义系统的性能和质量属性。 确保您了解非功能性要求，例如可用性、合规性、数据保留/驻留、性能、隐私、恢复时间、安全性和可伸缩性。 这些要求会影响设计决策和技术选择。

    下面是针对处理支出报表的工作负荷的功能性和非功能性要求的一些示例：

    功能要求 非功能性要求
    工作负荷应允许用户使用凭据登录，并且只能访问其个人数据。 工作负荷应在至少 99.9% 的时间内可用。
    工作负荷应包含提供了未结、已批准和已拒绝支出报表概述的仪表板。 工作负荷应遵守有关数据保护和隐私的相关法规和标准。
    工作负荷应支持对工作负荷数据的备份和还原操作。 对于大多数用户请求，工作负荷的响应时间应小于 5 秒。
    当触发某些事件或阈值时，工作负荷应向用户和管理员发送通知。 对于传输中的数据和静态数据，工作负荷应具有高级别的安全性和加密。

    有关详细信息，请参阅名为处理 Microsoft Power Platform 和 Dynamics 365 的要求的培训模块。

  • 将工作负载分解为多个组件。 在发现和要求收集流程期间，某些解决方案想法应逐渐变得清晰。 确定组成建议的解决方案组件以满足您的业务要求的解决方案组件。 优先考虑设计的简单性、效率和可靠性。 确定支持工作负荷所需的组件。 突出显示可以使用现成功能的位置，以及可能需要自定义开发的位置。

  • 使用故障模式分析 来识别单点故障和潜在风险。 清楚地了解企业对风险的容忍度。 有关详细信息，请参阅有关执行故障模式分析的建议。

  • 为您的工作负载定义可用性和恢复目标 ，以便为架构决策提供信息。 业务指标包括服务级别目标 (SLO)、服务级别协议 (SLA)、平均恢复时间 (MTTR)、故障之间的平均时间 (MTBF)、恢复时间目标 (RTO) 以及恢复点目标 (RPO)。 定义这些指标的目标值。 本练习可能需要技术团队与业务团队之间的妥协和相互理解，以确保每个团队的目标都符合业务目标并且切实可行。 有关详细信息，请参阅有关定义可靠性目标的建议。 Power Platform SLA 提供 Microsoft 正常运行时间和连接性的承诺。 不同的服务具有不同的 SLA，有时服务中的 SKUS 具有不同的 SLA。 有关详细信息，请参阅联机服务的服务级别协议。

其他设计建议

无需利益干系人参与即可执行以下建议：

  • 力求在设计中保持简单明了 。 为组件和服务使用适当的抽象级别和粒度。 避免过度设计或设计不足的解决方案。 例如:

    • 如果通过 Power Automate 解决流程自动化要求，将大型流程分解为多个较小的云端流可能会使其很难理解、测试和维护。 另一方面，将一切保留在大型流中可能会对性能和 API 调用量产生负面影响。

    • 如果通过 Power Apps 解决面向用户的要求，具有许多控件的大型单体画布应用可能会对性能产生负面影响。 将该应用分解为单个应用或自定义页面可能会使测试更困难，但会对性能产生显著的正面影响。

  • 预测随时间的变化，无论是修复错误、实施新功能或技术，还是使现有系统更具可扩展性和弹性。

  • 将横切关注点卸载到单独的服务。 最大程度地减少跨不同函数重复代码的需求。 首选定义完善的接口重用服务，这些接口可由不同组件轻松使用。 例如，如果需要从不同位置执行一组数据操作，您可以将此功能移动到低代码插件。

  • 评估常见模式和做法 是否适合你的需求。 避免遵循可能不适合您的上下文或要求的趋势或建议。 例如，实施自定义代码组件并不是每个应用程序的最佳选择，因为它们可能会引入复杂性、开销和依赖项问题。

开发足够多的代码

简单性、效率和可靠性的原则也适用于开发实践。 请考虑以下建议：

  • 在满足业务要求时使用平台功能。 例如:

    • 使用新式控件而不是开发自己的代码组件来实现 Fluent 2 设计标准。
    • 使用本机连接器而不是开发自定义连接器来减少自定义代码。
    • 使用生成式答案 in Microsoft Copilot Studio 使您的 Copilot 能够查找和显示来自多个来源（内部或外部）的信息，而无需手动创建主题。

  • 将专用代码评审会话作为开发实践引入。

  • 实现识别死代码的方法。 对自动测试未涵盖的代码持怀疑态度。

  • 考虑开发团队拥有的技能组合。 学习一项新技能或采用一种新技术都需要时间。

考虑数据位于何处

作为体系结构设计的一部分，您需要考虑如何存储数据或如何检索读取活动的数据。 可以通过不同方式检索和存储数据：

  • 新数据：如果您的应用程序创建的数据尚不存在，例如在纸上完成现有业务流程时，我们建议将数据存储在其中 Microsoft Dataverse。

  • 从现有系统读/写：如果您的应用程序需要从现有数据库或系统中检索数据，则需要评估连接到数据库或系统的最佳方式：使用现成的连接器、自定义连接器或虚拟表。

  • 复制数据：在绝不应修改或覆盖原始数据的情况下，您可以将数据复制到其他数据存储，例如 Dataverse。 此策略可保持原始系统的数据不变，同时允许应用使用原始系统的数据。 在会计和收入相关系统中使用数据时，这种情况很常见。 您需要考虑数据的复制方式、更新频率以及是否需要进行双向同步。

Power Platform 便利化

有关实用的设计建议，请参阅以下文章：

可靠性清单

请参考整套建议。

可靠性检查表