简介

在设计系统架构时,您必须做出决定。这些决定将影响您的系统在不同场景中的行为方式。该行为将以一种或另一种方式影响系统或产品的功能。

例如,面向服务的架构 (SOA) 将复杂的功能实现为松散耦合服务的组合。每项服务都或多或少地独立开发、部署和运营。与单体架构相比,松散耦合应该为桌面带来某些好处。

但是我们如何讨论、衡量和评估架构决策的影响呢?您可能听说过人们谈论“A 是一个可扩展、容错的数据库”或“B 比 C 更易于维护”。这些概念的常用术语是_非功能性需求_(NFR)。 NFR 是每个架构师的重要话题。该名称是作为受业务利益相关者严重影响的_功能需求_ (FR) 的补充而衍生的。

我个人更喜欢术语_质量属性_而不是 NFR。 “非功能”中的“非”意味着需求和功能之间的脱节,这在大多数情况下是不正确的。如果您的系统不可用,它也无法运行。

FR 和质量属性之间的联系可以通过识别具有架构意义的 FR [1] 来建立。架构上重要的需求需要特别注意,因为架构方面的错误决策可能会导致需求无法满足。

您如何确定与利益相关者和您的团队相关的质量属性?相关质量属性在您的系统或服务环境中有何不同?在这篇博文中,我们将介绍一种称为迷你质量属性研讨会的技术,它有助于回答这些问题。之后我们将详细解释几个常见的质量属性。

迷你品质属性工坊

概述

质量属性用于评估系统的质量。维基百科列出了82个不同的质量属性。哪些属性对您很重要,很大程度上取决于您的情况和系统的不同利益相关者。

Michael Keeling 将小型质量属性研讨会描述为传统质量属性的替代方案 [2]。本次研讨会的目标是确定对系统利益相关者很重要的质量属性。利益相关者通常是代表用户、业务专家、项目经理、IT 部门和开发团队。

研讨会的成果应该是质量属性情景列表。这些场景可能已经过细化,并且可能已经存在某种优先级。活动应有时间限制,开放点应作为后续行动项目制定。

研讨会的主要工具是_系统属性web_,或_质量属性web_。它允许对质量属性场景进行聚类,并且还用于在整个研讨会中对属性和/或场景进行点投票。

[质量属性 web 示例](https://res.cloudinary.com/practicaldev/image/fetch/s--a_wMqrEy--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev. s3.amazonaws.com/i/rlsbpnqpl8lkv7epnno4.png)

议程

研讨会议程上有以下几点:

  1. **介绍形式。**这应该说明议程,解释会议的目的和方法。

  2. **介绍质量属性。**第二点应该介绍质量属性的概念。为了便于讨论和节省时间,提前准备一个可以用作基线的质量属性分类是很有用的。

  3. **生成场景。**下一步应该通过使用头脑风暴/大脑写作技术或沿着分类学更结构化的方法来创建尽可能多的场景。

  4. 对场景和质量属性进行优先级排序。 在生成场景后,必须对它们进行优先级排序,以确定哪些是需要改进和解决的重要内容。对质量属性进行优先级排序还可以对可用于制定符合质量要求的架构决策的优先级进行总体概述。可以使用点投票来确定优先级。

  5. 优化场景。 生成的场景通常以非结构化格式创建。在细化期间,目标是将原始场景转换为结构化格式。

  6. 审查。 将细化的场景呈现给利益相关者。

在研讨会期间,至少完成优先级排序非常有用。改进应该有时间限制,从最高优先级开始,如果需要更多时间,可以离线。如果您没有时间,可以在稍后阶段进行审核。

场景

质量属性场景代表了研讨会的核心组成部分。原始场景是描述质量要求的一种灵活、非正式的方式。原始场景通常由一个句子组成,并通过将其放置在网络中来分配给质量属性。这里有一些例子:

  • “将产品添加到购物篮应该始终有效。” (可用性)

  • “浏览投资组合应该感觉反应灵敏。” (表现)

在细化步骤中,原始场景被转换为正式场景。正式场景具有以下属性:

[正式场景](https://res.cloudinary.com/practicaldev/image/fetch/s--lTZd7cy4--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3。 amazonaws.com/i/drncqw2gadbu7dcp9wjb.png)

source 描述了谁或什么启动了这个场景。 stimulus 是启动场景的事件。 artifact 表示接收刺激并产生响应的组件。因此,response 被定义为刺激的显着结果。 response measure 包含一个可量化的、可测试的响应测量。 environment 通过描述系统的状态将所有前面的部分置于上下文中。

让我们从上面改进第二个原始场景示例:

[正式场景示例](https://res.cloudinary.com/practicaldev/image/fetch/s--9GPoj5vd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3 .amazonaws.com/i/i3hs8ld5b7h4wbp0w03k.png)

当用户在正常情况下向投资组合服务发出请求时,投资组合服务应该在 99% 的情况下在 200 毫秒内用投资组合响应。指定环境是一个关键部分,尤其是在稍后将场景转换为服务级别目标时。

接下来,让我们看一下可用于促进研讨会的示例性质量属性分类法。

通用质量属性分类

以下分类法的灵感来自 O'Brien 等人的技术说明。根据软件架构技术计划 [3] 发布。您可以将它作为您的第一个研讨会的基础。我只会提到每个属性并给出一个快速的定义。请参阅其他来源以获取详细说明。

  • 互操作性描述了服务与其他服务通信并允许其他服务与之通信的能力。它衡量信息交换的自由程度。与编程语言无关的数据格式、内容协商、向后兼容的 API 等措施可以支持服务之间的互操作性。

  • Reliability 反映服务正确运行的能力。启用回滚和恢复的自动化可以减少平均故障间隔时间 (MTBF)。

  • 可用性是服务响应请求/可访问的能力。可以通过添加容错措施和弹性来增加正常运行时间,例如通过冗余。

  • 可用性衡量服务提供的用户体验 (UX) 质量。可以通过以 UX 为重点的开发工作流程来增加它。由于不可用或缓慢的服务也不可用,因此可用性和其他属性之间存在很强的依赖性。

  • 安全有两个主要方面:机密性(仅授予授权用户访问)和真实性(信任提供的信息)。在密码学领域可以找到有用的技术,例如加密和数字签名。此外,您应该实施安全流程,例如定期使凭证无效或轮换凭证或执行两因素身份验证。通过执行常规渗透测试来检查你的表现。

  • 性能是一个广泛的话题。在服务的上下文中,人们通常将响应时间或延迟称为性能度量。它可以通过为问题选择正确的算法和数据结构并根据负载调整系统大小来实现。添加自动化性能或负载测试以检测回归。

  • 可扩展性描述了处理变化的能力。在谈论可扩展性时,重要的是定义系统对什么变化做出反应,例如用户数量的增加、商店中提供的新产品、更多的请求进入,甚至更多的开发人员加入公司。可扩展性通常通过解耦和关注点分离以及选择算法和数据结构来实现,这些算法和数据结构允许通过添加更多资源来提高性能。

  • 可扩展性表示在不触及系统其他组件或部分的情况下向组件添加功能的能力。涉及松散耦合、通信标准和进化友好的接口和模式的架构促进了可扩展性。

  • 适应性会影响在需求发生变化时更改系统的难易程度。与可扩展性类似,这可以通过松散耦合来实现,也可以通过抽象来实现,例如在您的数据库和应用程序之间放置一个层,以便您可以交换数据库技术。适应性也受到可配置性的影响。

  • 可测试性 在构建和自动化单个组件、组件之间的交互以及整个系统的测试时很重要。除此之外,了解这些测试检测错误的能力也很重要。可测试性在分布式系统或面向服务的架构中尤其困难,因为组件通过不可靠的网络连接,可能存在不同版本的服务,并且没有单个实体知道所有组件的内部状态。另请注意,涉及自动缩放和服务发现的动态环境的行为可能难以预测。

  • Auditability 捕获执行系统审计的能力。例如,出于法律、安全或财务原因,可能需要进行审计。可审计性是一个艰巨的目标,因为它要求流程中涉及的所有服务都是可审计的。通常,事件和数据的不可变存储和版本控制已经为可审计系统做出了很大贡献。

  • 可观察性表示系统中的变化是否在可能的情况下以定量方式反映。推广 DevOps 文化可以提高可观察性,因为负责变更的团队也负责运营,这极大地受益于可用的丰富指标。

  • 可操作性描述了系统在运行时部署和操作的难易程度。除了可观察性之外,自动化还可以支持操作。诸如混沌工程之类的技术可以通过故意引入错误来测试您的可操作性。

请注意,许多场景可能适合多个属性,并且场景也可以相互关联。在我看来,这不是一个问题,而是促进了关于质量的讨论。还要记住,还有更多可能的质量属性要包括在内。如果在研讨会期间您觉得其他人比这里提到的更重要,只需根据需要从选择中扩展、替换或删除。

总结

在这篇文章中,我们了解了您的软件架构如何影响应用程序的质量以及功能需求。没有正确的解决方案,相反,它始终是不同质量属性之间的权衡。

迷你质量属性研讨会是一种轻量级格式,用于收集利益相关者的质量属性场景并确定其优先级。从收集尽可能多的原始场景开始,然后您将优先考虑和优化最重要的场景。质量属性的优先级本身使您能够选择架构并做出有利于利益相关者优先级的选择。

你有没有过一个人们根本不谈论质量的项目?您的团队是否曾经在软件架构方面做出过决定,结果却阻碍了您的功能需求之一?如果您考虑上一个项目,您会说两个最重要的质量属性是什么?为什么?随时发表评论!

参考文献

  • [1] Keeling, M., 2018。设计它!第 1 版:实用书架。

  • [2] Chaparro, W., Keeling, M., 2014。促进小型质量属性研讨会 (PDF)

  • [3] O'Brien, L. 等人,2005 年。质量属性和面向服务的架构。技术说明:软件架构技术倡议 (PDF)

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐