你当前正在访问 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) 方法创建反映业务流程和用例的域模型。
定义功能性和非功能性要求。 功能要求确定应用程序是否执行其任务。 非功能要求决定了应用程序的性能。 请确保了解可伸缩性、可用性和延迟等非功能要求。 这些要求影响设计决策和技术选择。
将工作负荷分解为离散功能。 工作负荷是应用程序资源、数据和支持基础结构的集合，它们共同发挥作用，以实现定义的业务成果。 工作负荷由各个组件以及开发和操作程序组成。 工作负荷通常可以分解为与用户、数据或系统流一致的离散功能，而这些流可以被赋予属性值，并具有非功能性要求。
不同的用户、数据或系统流通常在可用性、可伸缩性、数据一致性和灾难恢复方面可能有不同的要求。 精心设计的系统可以优化每个流的设计。 为此，必须将工作符合分解为可调整的组件。 典型的策略是根据组件的价值来对其进行分类。 例如，第 1 层组件至关重要，应不计成本地进行优化。 第 2 层组件非常重要，但可以暂时减少，后果也微乎其微。 第 3 层组件为可选组件；应保持其成本效益高且易于管理。 建立对流价值的共同理解，有助于设计和改进工作负荷的每个人在成本和其他非功能性要求之间保持平衡。
规划增长。 解决方案可能支持当前对用户数量、事务量和数据存储的需求，但也需要处理增长，而无需进行重大体系结构更改。 也请注意，你的业务模型和业务需求可能在一段时间后发生更改。 如果应用程序的服务模型和数据模型过于死板，则很难将解决方案用于新的用例和方案。
使业务模型和成本保持一致。 系统的寿命取决于其成本与业务模式的有效匹配程度。 架构师必须考虑价值驱动因素，并利用这种见解来为决策提供指导。 应确定解决方案将提供价值的维度（如盈利能力），然后确保体系结构遵循价值流。 这样，体系结构就能实现投资价值最大化，从而带来符合业务预期的投资回报 (ROI)。
管理成本。 在传统的本地应用程序中，需要为硬件预付费用作为资本支出。 在云应用程序中，为使用的资源付费。 确保了解服务的定价模型。 总成本可能包括网络带宽使用情况、存储、IP 地址和服务消耗。
也需考虑操作成本。 在云中，无需管理硬件或其他基础结构，但仍需管理应用程序 DevOps、事件响应和灾难恢复。