03-质量属性

Charlie
  2024-04-23 14:04 2024-04-23 14:04 创建   2024-07-05 12:55:04 2024-07-05 12:55:04 更新    

1. 需求

1.1. 功能需求

约定系统行为

功能独立于结构

1.2. 质量需求

系统完成功能好坏程度

1.3. 约束

约束是完全没有自由的设计决定，在设计之前就确定下来。

2. 质量属性

质量属性替代术语：可以表述成非功能需求或者架构需求

2.1. 要素

  • 六元素：作为架构设计的输入
    1. 刺激 stimulus：到达系统时需要考虑的条件
      • 外部的变化、输入，发出者可能是人也可能是外部系统
    2. 源 source：产生刺激的实体
    3. 响应 response：刺激到达后采取的活动
    4. 响应度量 measure: 我们会对响应做可以量化的度量
    5. 工件 artifact：需求适用的整个系统或系统的一部分
    6. 环境 environment：发生刺激时系统的状况，例如过载，运行等
  • 设计决定：
    • 最小单元是tactic
    • 几个tactic可以组合成pattern/strategy

2.2. 可用性 Avaliability

2.2.1. 概述

在两次Failure之间：

image.png

Unabaliable(Detect-Repair-Restart)-Avaliable
MTTR——MTBF

MTTR: mean time to repair
MTBF: mean time between failures

提高可以性：降低MTTR,提高MTBF

image.png
image.png

2.2.2. 可用性策略

image.png

2.2.2.1. Detect

  1. Ping/Echo: Monitor主动给Server询问，Server响应。
    1. 需要应答，带宽利用率更低
  2. Heartbeat: Server按照一定频率主动给Monitor发消息。
  3. Timestamp:
    • 收到一系列的消息应该在时间上有先后顺序
    • 进行常识的信息的检查，如果和常识不符合那么可能是出现了问题
  4. Sanity Checking: 如果数据超出合理范围，认为系统出现问题
  5. Condition Monitoring: 对运行的环境进行检查，如网络带宽、占用内存等。当环境达到某些阈值时，产生可用性问题的概率较大。
  6. Voting: Voter之间不一致，认为系统出现问题。基本上使用奇数个Voter。
    1. Clone: 多个Voter完全一致，只根据结果投票。
    2. Voter实现不同，为了防止组件的实现影响可用性。如果没有发生可用性问题，输入一致，输出也一致。
    3. Voter实现不同，输入也不同，但是输出在合理范围内，也认为系统可用。
  7. Exception Delection: 发生错误时抛出异常，异常的处理过程通常和抛出异常的地方在同一个进程中。
  8. Self-Test
  • Ping/Echo和Heartbeat区别：
    1. 始终检测，heartbeat比ping/echo的带宽开销更小
    2. 偶发请求，不需要时刻保证可用性，请求前ping/echo

2.2.2.2. Recover

优先级：让系统恢复正常状态>组件恢复

  • Preparation and Repair
    1. Active redundancy：所有冗余组件并行处理输入，但是只是用一个组件的返回结果。
      • 发生故障时，通常不存在停机时间，因为备份是最新的，恢复时间就是切换时间。
    2. Passive redundancy：主组件响应输入，并通知其他组件当前的状态
      • 发生故障时，系统必须首先确保备份在恢复服务之前，状态足够新。
      • image.png
    3. Spare：备用计算平台替换发生故障的组件
    4. Exception Handling: 捕获异常，处理。和redundancy配合，主机发生异常后，启动副本。
    5. Rollback：按照一定时间间隔，记录系统的正常状态checkpoint，发生意外时可以回滚。
    6. Software Upgrade: 软件提供商已经解决了问题
    7. Retry: 问题不是系统造成，而是由于环境问题，如网络不稳定，一段时间后retry可能就可用了。
      • 会设置最大retry次数
    8. Ignore faluts behavior: 把有问题的输入屏蔽掉
      • 白名单，黑名单
    9. Degradation: 服务水平降级
    10. Reconfiguration: 系统重新配置。
      • 基于微服务的系统，每个微服务有众多实例
  • Reintroduction
    1. Shadow operation：之前发生过错误的组件会有一段时间的shadow mode，如果出现问题立刻恢复。
      • 组件恢复之后有一段监视期，防止再次出现问题。
    2. State re-synchronisation
      • 被动和主动冗余策略要求要恢复的组件在恢复服务之前对其状态进行升级。
    3. Escalating restart：扩大重启范围，但先从最小范围开始。只重启出现错误的组件可能无法解决问题。
    4. Non-Stop Forwarding：设备发生主备切换时最大程度地减少中断时间

2.2.2.3. Prevent

目的：延长系统正常运行的时间MTBF。

  1. Removal from service：把带病工作的组件尽早替换掉
  2. Transaction：事务
  3. Predictive Model：使用基于以往数据的概率模型预测
  4. Exception Prevention：在异常捕获上提供更高级的处理能力
  5. Increase Competence Set：对可能会出现faults的原因进行针对性设计

2.3. 互操作性 Interoperability

2.3.1. 概述

  • 互操作性：是指两个或多个系统可以在特定的上下文中通过接口有效交换有意义的信息的程度。互操作性需要确定谁，什么以及在什么情况下（上下文）。

  • 要素

    1. Discovery：发现服务。和哪个对象互操作，怎么查找。
      1. location
      2. identity
      3. interface of service
    2. Handling of response：处理响应
      1. reports back to the requester
      2. sends its response on to another system
      3. broadcasts

image.png
image.png

2.3.2. 互操作性策略

image.png

2.3.2.1. Locate

  1. Discover Service：服务要在注册中心注册才能被找到

2.3.2.2. Manage Interfaces

  1. Orchestrate: 工作流编排，通过编排不同服务提供数据交换能力
  2. Tailor Interface：在interface上增加和删减一些能力
    1. e.g.区分付费用户和免费用户

2.4. 可修改性 Modifiability

2.4.1. 概述

可修改性涉及到更改以及进行更改所需花费的时间或金钱，包括这种可变更性影响其他功能或质量属性的程度。

设计的时候就要考虑未来的变化。

预先针对变化设计，还是变化发生之后再去修改，取决于成本。

image.png
image.png

2.4.2. 可修改性策略

image.png

  1. Reduce Size of Moudle：减小模块的规模
  2. Increase Cohesion：提高内聚
    1. 语义相近的部分往往需要同时修改
  3. Reduce Coupling
    1. Encapsulate：封装可能的变化
    2. Use an Intermediary：使用中间件
    3. Restrict Dependencies：使用分层结构简化依赖关系
    4. Refactor：不是针对系统内部重构，是架构层面的重构，把责任放到最合适的地方
    5. Abstract Common Services：把相似的服务放在一起，修改对外参数
  4. Defer Binding：推迟绑定时间
    1. 有越多的时间确定关系
    2. 但是也会对其他质量属性造成负面影响

2.5. 性能 Performance

系统满足时间需求的能力，单位时间可以做多少事情

  • 决定性能的时间
    1. processing time 处理时间
    2. blocked time 阻塞时间

2.5.1. 概述

image.png
image.png

2.5.2. 性能策略

减少任务
增加处理能力

image.png

  • demand side
    1. 降低采样频率
    2. 限制事件响应，如果系统来不及响应，把事件放入等待队列
    3. 优先级
    4. 使用中间层，提高资源利用效率
  • resource side
    1. 提升资源
    2. 并发
    3. 复制多个实例，使用负载均衡器把任务分配到实例上
    4. 复制多份数据，缓存、数据冗余

2.6. 安全 Security

2.6.1. 概述

保护系统不被未授权的访问影响

  • 特征
    1. Confidentiality：数据和服务不能被未授权访问
    2. Integrity：数据和服务不能被未授权操作
    3. Availability：系统对合法用户可以正常使用

image.png
image.png

2.6.2. 安全性策略

image.png

与可用性区别：检测到攻击时，还处在攻击状态，系统不一定失效

  • Detect
    1. 根据历史攻击的特征，检测识别攻击
    2. 检测服务拒绝DoS attack，白名单/黑名单
    3. 验证消息合法性
    4. 检测消息延迟
  • Resist
    1. 用户识别，宣称自己是谁
    2. 用户身份认证，看用户是不是真的那个人
      • e.g.手机号是identity, 验证码是authentication
    3. 用户权限认证
    4. 限制访问，过滤从外部到系统内部的访问
    5. 限制对外暴露
    6. 加密数据
    7. 分离数据，把敏感数据和公告访问数据分开
    8. 改变默认设置
  • React
    1. 撤回访问，限制攻击能访问的范围
    2. 系统上锁停止服务，攻击和普通用户都不能访问
      • e.g.密码错误超过十次，对设备上锁
    3. 通知使用者
  • Recover

2.7. 可测试性 Testability

2.7.1. 概述

系统是不是容易被测试，把问题暴露出来的能力
系统内部的质量属性，用户并不会关心

image.png
image.png

2.7.2. 可测试性策略

image.png

2.8. 易用性 Usability

外部质量属性

系统使用学习的难易程度

  • 层次
    1. 学习软件使用
    2. 高效地使用系统
    3. 最小化出错的影响
    4. 让系统适应用户的需要
    5. 提升用户使用系统时的信心和满足感
  • 标题: 03-质量属性
  • 作者: Charlie
  • 创建于 : 2024-04-23 14:04:00
  • 更新于 : 2024-07-05 12:55:04
  • 链接: https://chillcharlie357.github.io/posts/7a0fc498/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
此页目录
03-质量属性
  1. 1. 需求
    1. 1.1. 功能需求
    2. 1.2. 质量需求
    3. 1.3. 约束
  2. 2. 质量属性
    1. 2.1. 要素
    2. 2.2. 可用性 Avaliability
      1. 2.2.1. 概述
      2. 2.2.2. 可用性策略
        1. 2.2.2.1. Detect
        2. 2.2.2.2. Recover
        3. 2.2.2.3. Prevent
    3. 2.3. 互操作性 Interoperability
      1. 2.3.1. 概述
      2. 2.3.2. 互操作性策略
        1. 2.3.2.1. Locate
        2. 2.3.2.2. Manage Interfaces
    4. 2.4. 可修改性 Modifiability
      1. 2.4.1. 概述
      2. 2.4.2. 可修改性策略
    5. 2.5. 性能 Performance
      1. 2.5.1. 概述
      2. 2.5.2. 性能策略
    6. 2.6. 安全 Security
      1. 2.6.1. 概述
      2. 2.6.2. 安全性策略
    7. 2.7. 可测试性 Testability
      1. 2.7.1. 概述
      2. 2.7.2. 可测试性策略
    8. 2.8. 易用性 Usability