架构-系统架构设计模块-2

软件架构风格

经典架构风格

数据流风格

批处理
管道过滤器

调用/返回风格

主程序/子程序
面向对象风格
层次结构风格

独立构件风格

进程通信
事件驱动的系统

虚拟机风格

解释器
基于规则的系统

仓库风格/数据共享风格

数据库系统
黑板系统
超文本系统

闭关/过程控制
C2风格
C-S结构于B-S结构

概述

• 软件体系结构（架构）风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个系统结构定义一个词汇表和一组约束。
• 词汇表中包含一些构件和连接件类型
• 约束指出系统是如何将这些构件和连接件组合起来的。
• 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

经典体系结构风格

数据流风格

• 批处理：每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据必须是完整的，以整体的方式传递。如日志分析、计费程序等。
• 管道过滤器：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程常常通过对输入流的变换及增量计算来完成，所以在输入完全消费之前，输出便产生了。如传统的编译器、unix 管道等。

所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构，就像流水线。

1

2

3

4

5

批处理风格

典型的批处理应用基本流程：从数据库、文件等数据媒介读取大量记录，用某种方式处理数据，以修改后的形式写回数据。

garph LR
输入数据 --> 读数据 --> 处理数据 --> 写数据 --> 输出数据

中间三步即为构件

• MySQL 语句执行过程即为批处理风格
  

管道过滤器风格

管道过滤器风格的特点是：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

管道

管道

管道

管道

管道

管道

过滤器1

过滤器2

过滤器4

过滤器5

过滤器6

过滤器3

批处理	管道过滤器
整体数据传送	增量
构件粒度大	构件粒度小
延迟高、实时性差	实时性好
无并发	可并发

调用/返回风格

• 主程序/子程序：这种风格一般采用单线程控制，把问题划分为若干处理步骤，主程序的正确性取决于它调用的子程序的正确性。如单片机。

• 面向对象：数据的表示和它们相应操作被封装起来，对象的行为体现在其接受和请求的动作中。对象具有封装性，一个对象的改变不会影响其他对象。如面向对象开发语言。

• 层次：每层为上一层提供服务，使用下一层服务，只能见到与自己邻接的层。在层次结构中，修改某一层，最多影响其相邻的上下两层（通常只能影响上层）。上层必须知道下层的的身份，不能调整层次之间的顺序。如TCP/IP协议。

独立构件风格

• 这种风格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。

• 独立构件

  • 进程通信：进程间消息传递的方式可以是点对点、异步或同步的方式，以及远程过程（方法）调用等。
  • 事件驱动：当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这是一种隐式的调用方式，优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。如断点调试、新闻、公众号等订阅信息。

• 这种风格的主要特点是：每个构件都是独立的个体，可代表一切体现封装的”对象“。例如小到代码级的函数、类，大到一个服务端进程、集群、完整的系统。
  
  

进程通信风格

• 进程通信风格中，构件是独立的过程，连接件是消息传递。进程间消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
  

事件驱动风格

发布

通知或分发

通知或分发

事件源

事件

事件管理器

事件处理器1

事件处理器2

• 构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。

虚拟机风格

• 当底层不支持上层时，在两者之间加入一层虚拟机做模拟仿真，消除硬件和软件之间的差异。

  • 解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释器当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。缺点是执行效率比较低。如JVM。
    
    

  • 基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存。一般用在人工智能领域和DSS中。

源代码

解释器-解释执行

宿主系统OS硬件

仓库风格

• 数据库系统：构件分为中央共享数据源、独立处理单元。构件控制中央共享数据。如 IDE 集成环境。
• 黑板：包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中。如语音识别，信号处理。
• 超文本系统：网页

仓库风格包含一个数据仓库和若干其他构件。数据仓库位于该体系结构的中心，其他构件访问该数据仓库并对其中的数据进行增删改查等操作。

数据库风格

黑板风格

• 与数据库风格相反，一个或多个构件以被动触发的方式以不确定的顺序去更新共享数据存储区。每个构件可能多次参与执行流程，但流程本身无法事先确定。
  

超文本风格

• 超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间按照人类的联想思维方式任意跳转到相关构件。
• 早期的静态网页是比较经典的超文本系统。
  

闭环控制

• 闭环（过程）控制是将过程输出的指定属性维护在一个特定参考值（设定值），将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。示例，空调的温度自动调节器（设定值是温度），巡航系统（设定值的速度）。
• 闭环控制是根据控制对象输出反馈来进行校正的控制方式，它是在测量出实际与计划发生偏差时，按定额或标准来进行纠正的。

C2 风格

• C2 体系结构风格可以概括为通过连接件绑定在一起按照一组规则运作的并行构件网络。
• C2 风格中的系统组织风格如下。
  • 系统中的构件和连接件都有一个顶部和一个底部
  • 构件的顶部应连接到某个连接件的底部，构件的底部应连接到某连接件的顶部。而构件与构件之间的直接连接是不允许的
  • 一个连接件可以和任意数目的其他构件和连接件连接
  • 当两个连接件直接相连时，必须由其中一个的底部连接到另一个的顶部。
    

二层 C/S架构

• 二层C/S架构结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；软、硬件的组合集成能力有限；它的缺点主要有：
  • 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
  • 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么在客户端上的其他程序也可以想办法访问数据库服务器，从而使数据库的安全性受到威胁。
    

三层C/S架构

与二层 C/S 架构相比，在三次 C/S 架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机。三层 C/S 架构将应用系统分成表示层、功能层和数据层三个部分。

层次	功能
表示层	用户接口，检查用户输入的数据，显示输出数据
功能层	业务逻辑层，是将具体的业务处理逻辑编入程序中
数据层	对DBMS进行管理和控制

• 与传统的 C/S 二层架构相比，三层 C/S 架构具有以下优点：
• 允许合理的划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
• 允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这个平台和各个组成部分可以具有良好的可升级性和 开放性。
• 系统的各层可以并行开发，各层也可以选择各自最合适的开发语言，使之能并行且高效的进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
• 利用功能层可以有效的隔离表现层和数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础。
  
  

B/S 架构

• B/S 浏览器/服务器架构是三层 C/S 架构的一种实现方式，其具体结构为浏览器/Web服务器/数据库服务器。利用 www 浏览器技术，结合浏览器的多种脚本语言，能通过浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。
  

轻量级架构

• 表现层

  • 用户界面的逻辑位于最顶层。表现层负责把用户要求的业务逻辑处理结果以可视化的友好方式返回给用户，并提供接受用户命令的接口和表现层页面控制逻辑的代码。

• 业务逻辑层

  • 业务逻辑层负责处理问题领域的业务规则和根据用户需求进行的业务处理以满足用户的功能需求。通常情况下，业务逻辑层处理使用的实体对象由持久层提供。

• 持久层

  • 数据通过持久层进行持久化。所谓持久化，即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）

• 数据库

• 持久层的设计，使得业务逻辑层只需要负责业务逻辑的实现，而把数据的操作交给了持久层。持久层对数据及对数据操作的封装有以下几个优点：

  • 屏蔽数据库平台的变化对业务逻辑层的影响。当数据库变化时，只需修改持久层操作数据库的代码，而持久层提供给业务逻辑的对象模型没有变化，从而避免了业务逻辑的修改。
  • 通过持久层的封装处理，可以在持久层实现支持多种数据库平台，而对业务逻辑层提供统一接口。
  • 代码可重用性高，能够完成所有的数据库访问操作。

• 通过持久层的设计，将复杂的业务逻辑和数据逻辑分离，降低系统的耦合程度，从而在开发时更明确的分工，维护工作也更容易进行，系统的体系结构也变的更加清晰。

• SSH：指的是 Struts（做前端控制器），Spring（管理各层的组件），Hibernate（负责持久化层）

• SSM：指的是SpringMVC（做前端控制器），Spring（管理各层的组件），Mybatis（负责持久化层）

所在分层	SSH	SSM
页面层（View）	JSP	JSP
控制器层（controler）	Struts2	SpringMVC
业务层（Service）	java	java
持久层（DAO）	Hibernate	MyBatis
数据库层（DB）	MySql/Oracle	MySq/Oracle
组件管理层（Bean）	Spring	Spring

Hibernate 和 MyBatis 的区别

• 开发方面：Hibernate开发中，sql 语句已经被封装，直接可以使用；MyBatis 属于半自动化，sql 需要手工完成。
• Sql 优化方面：对复杂查询的 sql 语句进行人工调优的时候， MyBatis 更方便。
• 可移植性方面：Hibernate 使用时自动生成相应的 sql 语句，因此具备良好的数据库移植性，er MyBatis 中手动编写的 sql 语句需要针对不同厂商的数据库进行修改。

SOA架构

SOA面向服务的架构

概述

实现方式

服务注册表模式

企业服务总线模式

概述

服务：现实生活中的收银员、服务员、客服电话，都叫”服务“，你用不用它都在那里，长期驻守。有人需要，就请求它了提供“服务”。

• 面向服务的架构（Service-oriented architec徒惹，SOA）其实就是如何”基于服务“，或”基于一堆服务“来实现的业务架构。面向服务是在面向对象的基础上发展起来的，但这里的服务与对象不同：
  • 对象主要是面向系统的而服务是面向业务的
  • 对象的粒度级别主要集中在类级而服务是粗粒度的
  • 类是以函数调用为基础来交互的，而服务是以网络请求为基础来交互的。
• 为了解决面向服务的架构，我们需要解决服务之间的交互、交互的方式、数据格式定义等，还有决定把哪些业务”封装“成服务，达到封装性、可重用性、易维护性、易扩展性等（服务注册表模式）；或者把哪些业务整合成服务，达到对外统一、通用的目的（企业服务总线模式）

面向服务的架构（SOA）

• 服务常见的设计原则有
  • 明确定义的接口
  • 自包含和模块化
  • 粗粒度
  • 松耦合
  • 互操作性
• SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP等，而这些技术都是以XML为基础发展起来的。

服务注册表

注册自己的WSDL信息

调用方在首次调用前
先从UDDI构件获取需要的WSDL信息

web-service

UDDI组件
可以用zookeeper Redis等开源组件来实现

业务方

• SOA VS SOAP

  • SOA 指的是架构方法及流程，Webservice（服务提供者）、UDDI（注册中心）、业务方（调用者、消费者）三者的地位、作用以及需要遵从的执行流程：WebService 将自己的 WSDL 注册给 UDDI，业务方先从 UDDI 获取到 WSDL，进而才能访问 WebService。
  • SOAP 指的是SOA的三个组件互相访问时遵从的网络协议，即：用HTTP请求承载，XML为组织格式，来传递输入输出的有约束的数据（例如必须有envelop、bind、soap：body等元素）。

• WebService 的特征：

  • 是应用程序服务组件
  • 使用开放协议进行通信
  • 是独立的（self-contained）并可自我描述
  • 可通过使用UDDI来发现
  • 可被其他应用程序使用
  • XML是基础（目前使用更多JSON）

• 业务方若想使用某个WebService的服务，什么都不用耦合，只需要记住UDDI在哪儿，用的时候现场查询、现场使用即可。

企业服务总线模式（ESB）

• 企业服务总线（Enterprise Service Bus，ESB）架构模式在于整合，可能是公司内部各团队的服务，也可能是不同公司之间的不同服务，组成一个整体，来向外提供服务。业务方只跟业务总线交互，将请求提交给业务总线，由业务总线转发请求给相应的后端服务，收到回复后再转发给业务方。即业务总线也兼具“代理”的功能。业务方只需要知晓业务总线的地址，无需耦合所有服务。
  
• ESB的作用
  • 是SOA的一种实现方式，ESB在面向服务的架构中起到的是总线的作用，将各种服务进行连接与整合；
  • 描述服务的元数据和服务注册管理
  • 在服务请求中和服务提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式，如同步模式、异步模式等；
  • 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量的保证、可管理性和负载平衡等。

微服务架构

概述

• 微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能。每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（通常是HTTP/JSON），每个服务围绕业务能力进行构建，并且能够通过自动化机制独立的部署。

浏览器

产品服务/订单服务/用户服务
产品 / 订单 / 用户

数据库

PC

产品服务/产品

DB1

手机

订单服务/订单

DB2

用户服务/用户

DB3

优势

• 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变，但整体的并发却得到极大提升。
• 让每个服务能够独立开发，开发者能够自由选择可行的技术，提供API服务。
• 微服务架构是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。
• 微服务使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。

挑战

• 并非所有系统都能转成微服务
• 部署较以往架构更加复杂：系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
• 性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。
• 数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面要比传统架构更加困难。

其他架构类型

MVC

• 模型：执行业务流程（不包括输入输出），存储业务数据。模型不依赖于视图和控制器，提高了架构的灵活性。
• 视图：展示模型中的数据，用户的同一份数据可以通过不同的视图以不同的方式展示。视图必须了解模型中的数据结构，对模型有很强的依赖性，但是模型对于视图则没有依赖性。
• 控制器：把模型接收的事件和用户输入的数据转化为对模型方法的调用。控制器对用户的行为做出解释，并决定调用模型的哪个方法。

MVC设计表示层优点

• 允许多种用户界面的扩展。在MVC模式中，模型与视图没有必然的联系，都是通过控制器发生关系，这样如果要增加新类型的用户界面，只需要改动相应的视图和控制器即可，而模型则不需发生改动。
• 易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展，只要保持一种公共的接口，控制器和视图的旧版本也可以继续使用。
• 功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使用更清晰，可将友好的界面发布给用户。

上述模式产生的问题

• controller 既处理业务逻辑，又处理拼接视图，不符合单一职责原则，当 VIEW 需要频繁修改时会导致 controller 也会跟着变，二者耦合性太强。
• 视图依赖过多，又依赖 controller，又依赖 model，不符合依赖倒置原则，且破坏了“分层”架构思想。
• model 既处理前端业务逻辑（例如用户检查），又处理后端数据库的访问细节，不符合单一职责原则，且拼接 SQL 语句的方式，有 SQL 注入的风险，又因为 model 直接面向用户请求，所以还需要大量的安全检查代码

MVP

优点

• 低耦合。模型与视图完全分离，可以修改视图而不影响模型。
• 可以更高效的使用模型，因为所有的交互都发生在一个地方一个 Presenter（主持人） 内部。
• 复用性好。可以将一个 presenter 用于多个视图，而不需要改变 presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
• 可测试性好。如果把逻辑放在 presenter 中，就可以脱离用户接口来测试这些逻辑（单元测试）

VIEW

PRESENTER

MODEL

MVVM

• 由MVP进化而来，模式上基本相同，只是把 P 变成了 VM，即 ViewModel，MVVM 数据可以实现双向绑定，当 model 变化时，View-Model 会自动更新，View 也会自动变化。很好做到数据的一致性。所有有时候又称为 model-view-binder 模式。
• 比较适合逻辑复杂的前端项目，如管理系统等。

特定领域的软件架构

特定领域软件体系结构DSSA

领域分类

垂直域
水平域

系统模型

领域开发环境
特定领域的应用环境
应用执行环境

基本活动

领域分析
领域设计
领域实现

参与角色

• 特定领域软件架构（Domain Specific Software Architecture, DSSA）是在一个特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构。
• 从功能覆盖的范围角度有两种理解DSSA中领域的含义的方式。
  • 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。
  • 水平域：定义了在多个系统和多个系统族中功能区域的共有部分。在子系统级上涵盖多个系统族的特定部分功能。
    

基本活动	主要目标
领域分析	获得领域模型。领域模型描述领域中系统之间共同的需求，级领域需求。
领域设计	获得特定领域架构。DSSA描述领域模型中表示需求的解决方案。
领域实现	依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

参与角色：领域专家、领域分析人员、领域设计人员、领域实现人员。

• 领域专家的任务是提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA 等领域工程产品等。
• 领域分析人员的任务是控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
• 领域设计人员的主要任务包括控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。
• 根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件之间的联系。

架构评估

这章是考察重点，选择题、案例题高频考点

架构评估

质量属性

性能
可用性
安全性易用性

可修改性

可维护性
可扩展性
结构重组
可移植性

其他质量特性

敏感点
权衡点
风险点
非风险点

架构评估方法

基于调查问卷或检查表的方式
基于度量的方式

基于场景的方式

软件架构分析方法
架构权衡分析法
成本收益分析方法

质量属性

• 非功能需求，并不被功能所决定
• 不同的软件项目，关注不同的质量属性
• 质量属性之间可能相互抑制

属性	作用及要点
性能	处理任务所需时间或单位时间内的处理量
可用性	正常运行的时间比例，出现故障多久能启用备用系统
安全性	系统向合法用户提供服务并阻止非法用户的能力
可维护性	错误发生后进行局部性修改，对其他构件负面影响最小
可扩展性	使用新构件、改进或删除原有构件或特性
结构重组	重新组织构件及构件关系、灵活配置构件
可移植性	多样的环境（硬件平台、语言、操作系统等）
易用性	在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力

质量场景

质量属性场景是一种面向特定的质量属性的需求

• 刺激源：谁造成的刺激
• 刺激：一个响应系统的情况
• 制品：系统被刺激的部分
• 环境：刺激发生时，系统所处的状态
• 响应：刺激所产生的结果
• 响应度量指标：如何评估响应

可用性

系统正常运行时间的比例，出现故障多久能够启用备用系统。

• 刺激源
  • 故障，来自系统内部或外部
• 刺激
  • 系统出错
  • 系统崩溃（反复出错）
  • 给出结果不及时
  • 给出错误结果
• 制品
  • 计算或存储或网络
• 环境
  • 正常状态
  • 降级模式
• 响应
  • 错误报告，回传厂家
  • 通知管理员或其他系统
  • 关闭系统，系统在维修期间不可用
• 响应度量指标
  • 故障时间百分比、平均故障修复时间、平均无故障时间

---

• 提升可用性的策略
  • 错误检测：
    • 心跳：被监控组件定期向监控的组件发出心跳消息。若连续未收到的心跳信号到了一定的数目，则认为相应的系统已经出现故障。
    • ping/echo：监控组件不定期向被监控的组件发送ping消息，并根据受到的echo消息做出响应
    • 异常：需要编程语言的支持。如抛出+捕获+处理
  • 错误恢复：
    • 表决：多个冗余的组件，用同一或不同的算法来完成一个任务，如果计算结果不同，则由表决器按照算法（少数服从多数的原则）确定。
    • 主动冗余：服务器A和B并行完成同样的运算，它们的状态时刻保持一致，平时只取出A算出的结果。当A出现故障时，系统可以迅速切换到B。
    • 被动冗余：服务器A完成运算后，在一定时间内通知服务器B进行更新
    • 重新同步：主动冗余和被动冗余都需要在重新上线前，做状态的重新同步
    • 内测：如游戏的内测
    • 检查点/回滚：定期保存，便于恢复
  • 错误避免：
    • 服务下线：停业整改
    • 事务：多个操作连续完成，如转账
    • 进程监视器：监控进程异常退出时，执行相应行为，如重启进程

性能

处理任务所需时间或单位时间内的处理量

• 刺激源
  • 来自系统内部或外部
• 刺激
  • 事件（定期、随机、偶然事件）
• 制品
  • 系统所提供的服务
• 环境
  • 正常状态
  • 超载模式
• 响应
  • 可能改变系统的状态
• 响应度量指标
  • 处理事件所花的时间
  • 单位时间内处理事件的数目
  • 处理的错误率/丢失率

---

• 提升性能的策略
  • 资源的需求：
    • 减少处理事件时对资源的占用：
      • 改进算法
      • 减少计算开销
    • 减少处理事件的数量
      • 控制事件到来的速率
      • 控制采样频率
    • 控制资源的使用
      • 限制执行时间，如吃饭时长
      • 限制队列大小，如景区限流
  • 资源管理：
    • 并发机制：多核、多线程
    • 增加资源：计算资源、存储资源、带宽资源
  • 资源仲裁：先来先服务、固定优先级、动态优先级、静态调度

排序方法	时间复杂度	稳定性
直接插入	O（n2）	稳定
简单选择	O（n2）	不稳定
冒泡排序	O（n2）	稳定
希尔排序	O（n2）	不稳定
快速排序	O（nlog2n）	不稳定
堆排序	O（nlog2n）	不稳定
归并排序	O（nlog2n）	稳定

可修改性

能够快速的以较高的性价比对系统进行变更的能力

• 提升可修改性的策略
  • 局部化修改
    • 高内聚低耦合：将对程序的修控制在一个模块内
    • 预测变更
    • 使模块通用
  • 防止连锁反应
    • 信息隐藏：利用面向对象中的可访问性
    • 维持现有接口：接口不变的情况下，双方都能独立变化
    • 限制通信路径
      • 使用中介：数据中介（仓库-数据共享风格）
      • 服务中介：桥接模式、工厂方法模式、代理模式等
  • 推迟绑定时间
    • 运行时注册：即插即用（U盘）
    • 多态：动态绑定
    • 配置文件：避免修改代码

安全性

系统向合法用户提供服务并阻止非法用户的能力

• 提升安全性的策略
  • 抵抗攻击
    • 用户身份验证：动态密码、一次性密码、生物识别
    • 用户授权：对用户访问进行控制管理（权限）
    • 维护数据机密性：给数据和传输过程加密
    • 维护数据完整性：MD5 校验码
    • 限制暴露：关闭无用端口、自启动的服务、无线路由 SSID 等
    • 限制访问：设置黑白名单
  • 检测攻击
    • 入侵检测系统
  • 从攻击中恢复
    • 恢复状态：恢复检查点
    • 识别攻击者：用于预防或惩罚目的

质量特性

质量特性	定义	关键词
敏感点	为了实现某种特定的质量属性，一个或多个构件所具有的特性	对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计
权衡点	指影响多个质量属性，并对多个质量属性来说都是敏感点的特性	改变业务数据编码方式会对系统的性能和安全性产生影响
风险	不以标准属于出现。某些做法有一些隐患可能导致一些问题	对系统某业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性
非风险	某些做法是可行的、可接受的	业务处理时间小于30毫秒，则将请求响应时间设定为一秒钟是可以接受的

架构评估方法

业界已开发出多种软件架构评估的方法，按基于技术手段来看，可以分为三类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。

• 基于调查问卷或检查表的方式：该方式的关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。
• 基于场景的方式：基于场景的方式包括架构权衡分析法（Architecture Tradeof Analysis Method,ATAM）和软件架构分析法（Sofoware Architecture Analysis Method,SAAM），以及CBAM（Cost Benefit Analysis Method）成本收益分析方法。通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
• 基于度量的方式：制定一些定量值来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射。

SAAM 方法

SAAM 方法是卡耐基梅隆大学软件工程研究所的 KaZMan 等人于 1983 年提出的一种非功能质量属性的架构分析方法，是最早形成文档并广泛应用的软件架构分析方法。

• SAAM 的主要输入是：问题描述、需求说明、架构描述
• 分析过程主要包括：场景开发，架构描述、单个场景评估、场景交互和总体评估。
  

ATAM 方法

架构平衡分析法 ATAM 是一种系统架构评估方法，主要在系统开发前，针对性能、可用性、安全性、可修改性等质量属性进行评价和折中。

-四个活动阶段：需求收集、架构视图描述、属性模型构造与分析、架构决策与折中，整个过程强调以属性作为架构评估的核心概念。

• 评估参与者：
  • 评估小组：组织内部或外部的、扮演特定的角色
  • 项目决策者：项目管理人员，重要客户代表，架构师
  • 模块干系人：模块开发人员、测试人员、客户。
• 活动评估步骤
  • 描述 ATAM 方法：评估小组负责人向参加会议的项目干系人介绍 ATAM 评估方法
  • 描述业务动机：项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关的限制、与该项目相关的业务目标和上下文、主要的项目干系人，以及架构的驱动因素等。
  • 描述架构：包括技术约束（如，操作系统、硬件和中间件等）、将与本系统进行交互的其他系统、用以满足质量属性要求的架构方法等。
  • 确定架构方法：通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法。
  • 生成质量属性效用树：评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。
  • 分析架构方法：这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
  • 讨论场景和对场景的分级：项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，必须设置优先级。评估人员通过投票表决的方式来完成。
  • 分析架构方法：在收集并分析了场景后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第六步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第 7 步中，如果未产生在以前的分析步骤中都没有发现的高优先级场景，则在第 8 步就是测试步骤。
  • 描述评估结果：最后，要把 ATAM 分析所得到的各种信息进行归纳，并反馈给项目干系人。ATAM 的评估结果包括一个简洁的架构描述、表达清楚的业务员目标、用例场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。

---

• 质量效用树：
  • 性能：正常负载情况下，系统必须在0.5秒内对客户的查询请求进行响应
  • 安全性：系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御
  • 可用性：网络失效后，系统需要在 10 秒内发现错误并启用备用系统。
  • 可修改性：在系统升级时，必须保证在 10 人月内可添加一个新的消息处理中间件。

CMAM 方法

• CBAM 用来对架构设计决策的成本和收益进行建模，它的基本思想是架构策略影响系统的质量属性，反过来这些质量属性又会为项目的干系人带来一些收益（称为：效用），CBAM 协助项目干系人根据其投资收益率选择架构策略。CBAM 可以看作是 ATAM 的补充，在 ATAM 评估结果的基础上对架构的经济性进行评估。