目录
一、软件架构概念
在结构化分析流行之后，软件架构的概念才被提出，又称之为软件体系结构。软件架构设计阶段，放在需求分析之后，在软件设计之前。架构设计的目的就是需求分配，将满足需求的职责分配到技术组件上。架构设计师的工作，就是将客户所提的需求，大刀阔斧地将一个大需求砍成多个板块把每个板块分配给相关职责部门去完成。
软件架构风格描述某一特定应用领域中系统的组织方式的惯用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束，词汇表包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。同时，软件架构也是项目干系人进行交流的手段，通过经典的架构描述系统的组织结构，制约着系统的质量性。软件架构为软件系统提供一个结构、行为和属性的高级抽象，软件架构也是可传递可复用的模型。
二、软件架构建模概念
实际上软件架构的4+1视图，和UML的4+1视图可以一一对应上。为了把架构的事情搞清楚，就把架构的工作拆成4个别分进行建模。逻辑视图关注的是系统功能；开发视图关注的是源代码、组件、DLL等，进程视图关注性能，可扩展性等非功能指标；物理视图关注的是软件和硬件的映射关系。
三、软件架构的风格
架构设计的核心问题是能否达到架构级的软件复用，架构风格反应了领域中众多系统共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的大系统；架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。软件架构风格分类有很多，但是实际应用中也会有多个风格混合使用
1.数据流风格
强调处理数据，按照流程将数据一步一步地的加工，得到最终结果。有严格的流程、并且是为了数据处理系统适合数据流风格。
(1)管道—过滤器
管道过滤器是以数据流的方式进行数据间传递。就是说，当前部件将部分数据处理好之后就可以将处理好的数据传递给加一个部件。比如早期的编译器，将代码一段段地进行词法分析、语法分析、语义分析，而不是将全部代码进行词法分析完后才会进行语法分析。这样的操作过程就是为了快。
所谓管道是一种连接件，将一个过滤器的输出传输给下一个过滤器的输入。而过滤器相当于流水线的处理单元，负责处理输入数据。过滤器需要将前序管道拉取数据，并将输出数据压入后续管道。
(2)批处理序列
与管道—过滤器差不多都是按照流程一步步走，只不过每一个处理步骤是一个独立的程序，每一步走完才可以走下一步。数据必须是一整套的，以完整、全量的数据进行传递。
2. 调用/返回风格
每个系统都绕不开调用、返回。主程序/子程序风格应该是最原始的架构风格，即向一个函数调用另一个函数那样，一个构件调用另外一个构件。面向对象风格也是大家常用的风格，构件就是对象，把属性和方法封装给起来。
层次结构，构件组织成一个层次就够，每一层为上一层提供可调用的服务接口，最常见的就是三层架构，有表示层(UI); 业务逻辑层(BLL); 数据访问层(DAL)。数据访问层写访问数据库，访问数据文件的方法。 业务逻辑层作为数据访问和UI层的桥梁，负责业务逻辑的实现。UI层主要负责与用户交互，调用BLL层进行请求处理、数据处理等。
层次结构风格支持基于可增加抽象层的设计，允许一个复杂的问题分解成一个个增量步骤实现。越靠近底层抽象级别越高，越容易复用。但是，每个系统并不容易将系统进行层次划分，层次越多，请求响应越慢。
3.独立构件风格
基本出发点，将功能封装成构件，每个构件相互独立，可以单独运行。
(1).进程通信 和 事件驱动系统(隐式调用)
构件不直接调用一个过程。而是输出某种信息，触发或广播一个或多个事件。而进程通信也有类似思想，每个进程是一个独立的功能，相互独立。
例如一个系统有数据接入，数据加工，计算，计算结果入库四个功能，分别为四个进程。
- 数据接入进程定时循环遍历某一个目录是否有符合格式的数据文件出现，文件到达就进行加载入库。入库完成后向数据库的"任务表"插入一个“待加工”的任务，触发后续工作
- 数据加工进程定时扫描数据库中任务表是否有“待加工“的任务,如果有就进行数据加工，将加工好的数据整合成一个新的文件，来触发后续计算
- 计算进程定时循环遍历某一个目录是否有符合格式的数据文件出现，循环读文件进行计算，把计算结果输出到结果文件中，并向后续入库进程提供信号
- 数据加工进程收到信号后，把结果文件中的数据进行入库。
独立构件风格可以适应分布式系统，别个构件相互独立，分工明确，耦合性低。
4.虚拟机风格
包含解释器风格，和基于规则的系统。能够适应自定义需求的场景，
基于规则的系统更高级一点，解释器更普遍一点。基于规则的系统不仅包含解释系统，还有包含类似知识库的一些东西，在辅助决策领域比较适用。
5.仓库风格
仓库风格是以数据为中心的风格，具有该风格的系统，有一个中央数据结构（仓库）说明当前状态，独立构件在中央数据存储上执行，然后周围有一堆的处理部件，对仓库的数据进行处理。
一方面，若构件控制共享数据，那么仓库就是数据库系统风格，另一方面，若中央数据结构的当前状态触发进程执行选择，则仓库是黑板系统，
(1).数据库系统
将基本数据信息放在一个大的数据文件中，周围的一堆部件别分将数据通过不同维度的方式展现出来。
(2).黑板系统
包括知识源，黑板和控制三部分。知识源就是计算部件，黑板就是共享数据。和数据库系统结构类似。区别在于”黑板“不仅用来数据存储，而且用来当成数据传递的机制。就像在教室的黑板一样，黑板上的数据是全局的，不仅用来数据存储，还能够触发知识源进行数据处理，就像学生看见黑板内容决定是做笔记还是联系书本思考一样，是知识源相互作用的唯一媒介。黑板系统通常用于解决问题没有确定性算法的软件中，比如信号处理，问题规划，语音识别，编译器优化等。
(3).超文本系统
构件以网状链接的方式相互连接，用户可以在构件之间进行任意跳转。现代集成编译环境一般用这种风格
例如IDE集成的开发环境，编辑器、调试器、变量监控等共用一个语法树。当敲的代码有语法异常时，就会有错误提示，而不是像传统编译器要等到编译时才会报编译异常。
6.闭环控制架构(过程控制)
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态。适合于嵌入式系统，涉及连续的动作与状态。
有闭环就有开环。开环控制系统，给定值然后由控制器进行发送指令给执行器执行。执行后给被控对象发送控制量，然后被控对象根据控制量进行执行。比如用电视遥控器调频道，给遥控器输入频道数字，电视机就会进行跳转到对应频道。缺点使开环控制系统没有反馈机制，不会对指令进行动态调整，要求一次性把指令下发到位，这个过程可能会把信息丢失掉。
而闭环控制系统，给定一个值，然后跟反馈量进行比较，之后继续执行。比如空调系统，你想把目标温度调成18度，而空调会采集当前室温，这个室温就是反馈量，与目标指令18度进行比较，如果室温过高，空调就会开启最大功率制冷，不断进行室温反馈，如果室温接近目标温度，那么制冷功率就会降低或停止。
7.C2风格
C2是一种并行构件网络，具有这总风格的系统，它的构件与构件不直接相连。
基本规则包括
- 构件和连接件都有一个顶部和一个底部
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部。
- 一个连接件可以和任意数目的其他构件和连接件连接
- 当两个连接件进行直接连接时，必须由一个的底部到另一个的顶部
8.客户/服务器(C/S)风格
C/S属于层次风格中的一种。二层C/S风格，在客户端上的应用程序不仅负责与用户交互，又负责对数据的管理。客户端上的应用程序分为与用户交互的前端和管理数据的后端。比如磁盘机，打印机，和调制解调器等。该风格应用时，互联网未普及。它的缺点包括：
- 客户端对软硬件的配置要求高，尤其是软件不断升级，造成客户端对数据管理的成本越来越高。
- 客户端程序设计复杂。把后端逻辑放在客户端上，增大了前端开发者的压力。
- 软件可移植性低，可维护性低等
而三层C/S风格，在二层C/S风格的基础上将应用逻辑单独抽离出来，放在了应用服务器上。只有表示层存在于客户端上。三层分为表示层，功能层，数据层。
9.浏览器/服务器(B/S)风格
虽然三层C/S，比二层C/S维护更便利些，但还是要求用户需要有客户端。没有客户端就无法使用软件。比如手机APP
而 B/S风格，不要求用户安装客户端。例如微信小程序， 把表示层当作浏览器去用。只需要用户键入网址，就可以将功能反馈给用户。 B/S 与 C/S相比，客户端变成了WWW浏览器，应用服务器变成了WEB服务器。应用程序以网页的形式存放于Web服务器上。用户只需要一个浏览器就可以运行所有功能模块，实现了"零客户端"的功能。
10. 富互联网应用 (RIA)
RIA是由三层B/S架构上演变而来。在三层B/S架构中，用户通过浏览器运行，避免了去下载应用软件的问题。但是三层B/S架构中缺乏对动态页面支持的能力，也就是说运行一些复杂动作时，整个系统运行就会变得慢。基本上无法流畅得支持动画。
而RIA就是为了提升动态页面支持能力的一种架构风格。他的特点时，打开页面时慢，执行时流畅表现力强。RIA的思想是，在每次提交复杂的请求时，都要交换大量的数据，还不如一次性将常用请求中要用到的数据在第一次打开时就全部加载到本地缓存。加载完后，交换数据量的工作就会小很多。最常见的网页游戏就是采用这种风格，在第一次打开时就会将整个地图资源加载进本地。加载的过程是慢的，但是进入游戏之后，就省去了交换地图资源数据的步骤了，画面也就可以支持丰富化的效果了。
11.REST架构风格
（Resource） Representational State Transfer，（资源）表现层状态转移，一种使用HTTP和XML、JSON来组织WEB服务的架构。可以降低开发的复杂性，提高系统的可伸缩性。
原理就是用URL定位资源，用HTTP描述操作。URL中只使用名词来定位资源，用HTTP协议里的动词（GET、POST、PUT、DELETE）来实现资源的增删改查操作。
比如，我们有一个friends接口，对于“朋友”我们有增删改查四种操作，怎么定义REST接口？
增加一个朋友，uri: generalcode.cn/v1/friends 接口类型：POST
删除一个朋友，uri: generalcode.cn/va/friends 接口类型：DELETE
修改一个朋友，uri: generalcode.cn/va/friends 接口类型：PUT
查找朋友，uri: generalcode.cn/va/friends 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词friends，都是通过Http请求的接口类型来判断是什么业务操作。
举个反例：generalcode.cn/va/deleteFriends 该接口用来表示删除朋友，这就是不符合REST协议的接口.。
REST有五个原则：
- 网络上的所有事物都被抽象为资源
- 每个资源对应一个唯一的资源标识
- 通过通用的连接件接口对资源进行操作
- 对资源的各种操作不会改变资源标识
- 所有的操作都是无状态的
四、基于服务的架构风格（SOA）
在面向对象的基础上，演变出了构件。构件是一个可以单独运行的功能。但是构件的标准化程度低，也就是说“你开发出来的一个构件，可能别人不知道要如何使用”。还可能会有跨平台的问题。 比如JAVA中的构件无法在C++中使用。为了解决标准化，规范化程度低，提出了基于服务的架构风格。将自己开发的功能用服务的形式进行对外发布。完成服务间的交互。比如WebService。
SOA的实现要求有一个重要的技术，就是ESP企业服务总线(Enterprise Service Bus)，ESP充当中介者。这种中介者能够负责起数据传输，服务描述数据存储，提供位置透明的消息路由和寻址服务，协议以及数据格式的转换，提供服务注册接口，日志监控等。把服务间点对点交互的的网状结构转化成了星型结构。
五、微服务架构风格
微服务架构是面向服务的架构风格中的一种。微服务与SOA区别就像是活字印刷与雕版硬刷的区别。SOA将所有系统中服务进行集成，而微服务将整个业务进行打碎，每个单一应用程序划分成一个服务，每个服务只需关注很小的业务功能。每个服务间进行相互沟通为用户提供最终价值。特点是：
- 小，且专注于一件事情
- 轻量级的通信机制
- 松耦合,独立部署
六、模型驱动架构（MDA）
Model Driven Architecture ， 采用了净室工程的思想,利用模型进行代码自动化生成。虽然没有普及，但是有些系统在局部功能上有所应用。比如拖动按钮生成相关代码，比如UML类图转换成实际代码等。
