软考 - 系统架构设计师（软件架构设计）

架构的定义

软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较为权威的定义。

软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式的约束组成。

软件架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471-2000）

从技术角度看，软件架构的重要性：

项目关系人之间交流的平台

早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。

表现为：（1）架构明确了对系统实现的约束条件；（2）架构影响着系统的质量属性；（3）架构可以用来预测系统的质量；（4）架构为维护的决策提供依据；（5）架构有助于原型开发。

在较高层面上实现软件复用

架构对开发的指导与规范意义不容忽略

基于架构的软件开发模型则明确地把整个软件过程划分为：架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。

架构的模型

最常用的是结构模型和动态模型。

结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反应系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。框架模型。框架模型于结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的机构。动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置和演化。动态可能指系统总体结构的配置、建立或查出通信通道或计算的过程。过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看做是一种特殊的框架模型。

“4+1”视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图、场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反应系统的软件架构的全部内容。如下图所示：

软件质量属性

案例分析常考

软件架构风格

这部分内容比较多，我又总结了另一篇文章

软考-系统架构设计师（软件架构风格）

层次系统架构风格

二层C/S架构

提出的原因：C/S架构是基于资源不对等，且为实现共享而提出来的

结构：C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与客户的交互任务。

优点：C/S软件架构具有强大的数据操作和事物处理能力，模型思想简单，易与人们理解和接受。

局限：（1）二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；

（2）软、硬件的组合及集成能力有限；

（3）服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；

（4）数据安全性不好。

三层C/S架构

结构：将应用功能分成表示层、功能层和数据层三个部分

表示层：是应用的用户接口部分，它负担着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需修改显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。功能层：相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交互要尽可能简洁。数据层：就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。

解决方案：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况下是只将表示层配置在客户机中，如果将功能层也放在客户机中，与二层 C/S 结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变差。如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。

B/S 架构风格

使用技术：B/S 结构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原本需要复杂的专用软件才能实现的强大功能，并节约了开发成本。

优点：基于 B/S 架构的软件，系统安装、修改和维护全在服务器端解决（零客户端），很容易在运行时自动升级。也可以更加充分利用网络上的各种资源，同时应用程序维护的工作量也大大减少。

不足：（1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；

（2）采用 B/S 架构的应用架构，在数据查询等响应速度上，要远远地低于 C/S 架构；

（3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不抢，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP ）应用。

MVC架构风格

定义：全名是 Model ViewController，是模型（model）- 视图（view）- 控制器（controller）的缩写，分层架构的一种。

分工协作：

Model 是对应用状态和业务功能的封装。Model 接受 Controller 的请求并完成响应的业务处理，在状态改变的时候向 View 发出相应的通知。View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。View 捕获到用户交互操作后直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。

MVP架构风格

定义：全称为 Model-View-Presenter。MVP 是从MVC 演变而来。

与MVC的相同点：基本思想有相通的地方：Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。

与MVC的不同点：MVC模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在MVP 中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC中的Controller）来进行的，所有的交互都发生在Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。

缺点：由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。还有一点需要明白，如果 Presenter 过多的渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。

优点：（1）模型与视图完全分离，我们可以修改视图而不影响模型；

（2）可以更高效的使用模型，因为所有的交互都发生在一个地方——Presenter 内部。

（3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；

（4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

面向服务的架构（SOA）

典型的定义：（1）W3C 的定义：SOA 是一种应用程度架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

（2）Service- 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。

（3）Gartner 的定义： SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 于大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。

**概述：**SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。由于 SOA 考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。

服务的基本结构：

SOA 设计原则：

明确定义的接口自包含和模块化粗粒度松耦合互操作性、兼容和策略声明

SCA 服务构件于传统构件的区别：服务构件往往是粗粒度的，而传统构件以细粒度居多；服务架构的接口是标准的，主要是服务描述语言接口，而传统构件常以具体 API 形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供 QoS 的服务，而传统构件完全由程序代码直接控制。

SOA 的关键技术：这些技术都是以 XML 为基础而发展起来的。

SOA 的实现方法：

Web Service 服务注册表

（1）服务注册

（2）服务位置

（3）服务绑定

企业服务总线（ESB）

内容：ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者和服务提供者进一步解耦。EJB 是由中间件技术实现并支持 SOA 的一组基础架构，是传统中间件技术于 XML、Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。

功能：（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性；（2）通过使用 ESB ，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准；（3）充当缓冲的 ESB 与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码；（4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能；（5）头攻可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。

优势：（1）扩展的、基于标准的连接；（2）灵活的、服务导向的应用组合；（3）提高复用率，降低成本；（4）减少市场反应时间，提高生产率。

微服务

优势：（1）技术异构性；（2）弹性；（3）扩展；（4）简化部署；（5）与组织结构相匹配；（6）可组合型；（7）对可替代性的优化

挑战：（1）分布式系统的复杂度；（2）运维成本；（3）部署自动化；（4）DevOps 与组织结构；（5）服务间依赖测试；（6）服务间依赖管理

微服务与 SOA ：