你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

针对业务需求进行构建

  • 项目

每个设计决策必须与业务要求相称。 此设计原则看似不言自明，但在设计 Azure 应用程序时请务必遵循此原则。

应用程序是否必须支持数百万用户或数千个用户？ 是否存在大型流量突发或稳定的工作负载？ 可接受的应用程序中断级别是什么？ 最终，业务要求驱动这些设计注意事项。

以下建议可帮助你设计和生成满足业务需求的解决方案：

  • 定义业务目标，包括恢复时间目标 (RTO)、恢复点目标 (RPO) 和可容忍的最长中断时间 (MTO)。 这些数字应为决策提供有关体系结构的信息。

    例如，假设你的企业希望恢复时间目标 (RTO) 和恢复点目标 (RPO) 都非常低。 你可以选择使用区域冗余体系结构来满足这些要求。 如果你的企业能容忍更高的 RTO 和 RPO，那么添加冗余可能会带来额外的成本，而无业务优势。

  • 请考虑需要缓解的故障风险。 按照自我修复设计指南来设计解决方案，使其对许多类型的常见故障模式具有弹性。 请考虑是否需要顾虑不太可能发生的情况，例如某个地理区域发生可能影响该地区所有可用性区域的重大自然灾害。 缓解这些不常见的风险通常成本更高，而且需要进行重要的权衡，因此请清楚地了解企业对风险的容忍度。

  • 记录服务级别协议 (SLA) 和服务级别目标 (SLO)，包括可用性和性能指标。 例如，建议的解决方案可以提供 99.95% 的可用性。 SLO 是否满足 SLA 是业务决策。

  • 为业务域建模应用程序。 分析业务要求，并使用这些要求对解决方案进行建模。 请考虑使用领域驱动设计 (DDD) 方法创建反映业务流程和用例的域模型。

  • 定义功能性和非功能性要求。 功能要求确定应用程序是否执行其任务。 非功能要求决定了应用程序的性能。 请确保了解可伸缩性、可用性和延迟等非功能要求。 这些要求影响设计决策和技术选择。

  • 分解工作负荷。 在此语境中，工作负荷是指某个离散的功能或计算任务，可以将它和其他任务逻辑分离。 不同工作负荷在可用性、可伸缩性、数据一致性和灾难恢复方面可能有不同的要求。

  • 规划增长。 解决方案可能支持当前对用户数量、事务量和数据存储的需求，但也需要处理增长，而无需进行重大体系结构更改。 也请注意，你的业务模型和业务需求可能在一段时间后发生更改。 如果应用程序的服务模型和数据模型过于死板，则很难将解决方案用于新的用例和方案。

  • 管理成本。 在传统的本地应用程序中，需要为硬件预付费用作为资本支出。 在云应用程序中，为使用的资源付费。 确保了解服务的定价模型。 总成本可能包括网络带宽使用情况、存储、IP 地址和服务消耗。

    也需考虑操作成本。 在云中，无需管理硬件或其他基础结构，但仍需管理应用程序 DevOps、事件响应和灾难恢复。

后续步骤