协商切合实际的性能目标
 定义了预期的用户体验，并通过一项策略根据预先确定的业务要求制定基准和度量目标。 |
|---|
从性能角度来看，最好有明确的性能目标来开始设计过程。 若要设置这些目标，需要充分了解业务需求以及工作负荷预期提供的预期服务质量。 与业务利益干系人合作定义预期。 不要只关注技术指标，要确定对关键流的用户体验的可接受影响。
存在循环依赖。 没有定义就无法度量，没有度量就无法定义。 因此，度量工作负荷性能也很重要，除非你通过集体协议对可接受的阈值进行了满意的定义。
性能和可靠性目标之间存在很强的相关性，而可靠性目标有助于确定性能、可用性和复原能力方面的服务质量。 如果没有明确的定义，对性能进行度量、预警和测试就会很困难。 建立目标并通过一段时间的测试确定实际数字后，你可以实现自动化以针对这些目标进行连续测试。
坚持在宏观层面定义目标时采用的最佳做法，即使它们是近似的或在一定范围内的。
示例场景
Contoso Bicycle 是美国的直接面向消费者的自行车品牌。 他们的开发团队已开始构建一个应用，以支持 Contoso 的计划内移动自行车维修服务产品。 该应用目前处于概念证明阶段。 技术人员将使用移动应用来管理其日程安排和工作订单以及收款。 将使用一个网站，供客户安排服务。 Web 应用、移动应用和后端 API 都可能托管在 Azure 应用服务上。
准备协商性能目标
通过了解技术概念、探索可用基础结构的设计可能性以及使用具体试验的结果（如果有），为有效的协商做好准备。 通过历史数据来了解使用模式和瓶颈。 从外部因素中获取见解，例如来自市场分析、专家和行业标准的意见。
你可以根据实际见解做出明智的决定。
性能目标侧重于用户体验，而用户体验基于可行方案、行业最佳做法和当前市场趋势。
Contoso 的挑战
- 在与业务利益干系人讨论该应用程序时，尚未讨论性能。
- 开发团队是 Azure 方面的新手，因此不熟悉该平台的性能和缩放功能。
- 团队担心，如果没有利益干系人的指导，也没有对可能发生的情况的实际了解，他们将不得不部署基础结构进行测试，纯粹只是为了以后进行重建。
- 团队还担心，下次开会时，没有人愿意谈论现实的性能目标。
应用方法和成果
- Contoso 业务分析师和开发人员讨论他们的担忧并提出一个计划：业务分析师将通过竞争力分析和非正式投票来研究性能预期，开发团队将研究 Azure 的对应于不同定价层的功能和选项。
- 团队与业务利益干系人重新组合，带来他们编译的数据，并将这些数据用作性能目标协商的基础。 通过讨论潜在的性能和关联的成本，各方都对使用应用服务处理工作负荷感到满意。
有效协商性能目标
与业务所有者合作，了解用户在质量和法规合规性方面的承诺（如果适用）。 在此阶段保持广阔的视野，避免陷入细节。 明确什么代表可接受的性能（具体取决于投资），并了解业务上下文和预期增长。
采用这种方法，你可以避免做出可能与业务目标不一致的假设。 它还有助于在工作负荷团队中澄清事项和提高积极性。
拥有有关功能需求和非功能需求的业务上下文之后，可能会发现其他 Azure 架构良好的支柱中的设计更改，有助于你进行明智的权衡。
尽早定义参数有助于避免与以后重新设计潜在解决方案相关的成本；它使你能够确保性能目标涵盖未来的预测，使当前的努力与长期目标保持一致。
Contoso 的挑战
- 体系结构团队对可接受的内容有粗略的想法，但还没有具体细节。 架构师普遍认为，他们应该能够通过选择应用程序平台来避免返工，但如果目前所获得的东西的特异性更强一些，他们会感到更有信心。
- 到目前为止，关于性能的讨论一直不是很明确，只是提出“网站需要速度快”之类的说法。
- 如果没有更多一些的细节，架构师担心他们可能会过度进行性能设计，或者面临延迟，导致将内容发布到生产环境的工作推迟。
应用方法和成果
- 业务合作伙伴和技术团队会面，就一般但现实的目标以及必须避免的一些绝对限制达成共识。 有了这些，架构师就可以在初始设计中进行概念证明，以便在应用程序平台上达成广泛一致，并提出一些有关性能与定价的结果。
- 这次会议的成果之一是知道 Contoso Bicycle 计划第一年仅在美国西南部运营，但第二年会扩展到全国范围。 此信息会纳入设计。
以流为中心进行设计
识别工作负荷流并确定体系结构图中的流的优先级。 将每个流的性能容差定义为一个从理想性能到不可接受性能的范围。 评估每个流的入口点和出口点，考虑路径的关键性、使用频率和体系结构强度。
通过确定流的优先级，可以将资源集中在对用户和业务成果影响最大的关键领域。
通过将系统分解为部件和依赖项，可以了解每个组件的功能以及对性能的影响。 你还会意识到潜在的问题。
它有助于建立性能基线并促进优化。
Contoso 的挑战
- 到目前为止，技术团队已与利益干系人合作确定大致的性能目标，但尚未关注单个流。 为了能够更深入地了解服务定位器和支付流等流，设计团队需要了解这些流的要求。
- 如果没有这些特定要求，设计就会面临为关键流分配资源过少或为较低优先级流过度分配资源的风险。
应用方法和成果
- 体系结构团队现在会在审查企业的用户流后为每个流记录非常具体的目标。 工作负荷的分解现在考虑到了每个流的从理想性能到不可接受性能的范围。
- 架构师会努力通过设计实现理想目标，以便为系统留出随着时间的推移开发附加功能的空间，同时在一定程度上做出妥协以控制成本和其他非功能需求。
- 团队能够围绕已商定的目标完成设计。现在，实施团队会负责确保遵守这些限制，并会在无法通过所用设计实现这些限制时提出担忧。