软件体系结构设计

上图为瀑布模型的软件生命周期。

计划阶段：主要任务为：问题的定义和规划，可行性分析。

设计阶段：包含软件体系结构设计(概要设计)和详细设计两个阶段。

每一阶段都会产生相应的文档。这里我们主讲的阶段为软件体系结构设计。

• 软件危机（software crisis），20 世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。
• 60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发 。
• 1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而1960年代中期开始爆发众所周知的软件危机。                                   —— 来源于百度百科

如何改变软件生产方式，提高软件生产效率？

• 不仅仅是技术问题，更重要的是管理问题。
• 采用工程化的开发方法与工业化的生产技术。
• .......

软件体系结构的兴起

• 随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。
• 对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起算法和数据结构的选择重要得多。
• 对软件体系结构的研究将会成为提高软件生产率和解决软件维护问题的有效途径。

从审视的视角看软件体系结构

软件体系结构有四个角度，它们从不同方面对系统进行描述：

• 概念角度描述系统的主要构件及它们之间的关系；
• 模块角度包含功能分解与层次结构；
• 运行角度描述了一个系统的动态结构；
• 代码角度描述了各种代码和库函数在开发环境中的组织。

软件体系结构的发展史

这里主要了解4+1模型：

场景视图、逻辑视图、开发视图、过程视图、物理视图

[wppay]

https://juejin.cn/post/6844903566285471752#heading-12  (使用4+1模型进行开发实践)

• C/S软件体系结构
• B/S软件体系结构

https://blog.csdn.net/sea_snow/article/details/81187804

可以看看这篇文章，接下来的部分内容会对这篇文章进行总结。

• C/S架构是第一种比较早的软件架构，主要用于局域网内。也叫 客户机/服务器模式。
• 可以分为客户机和服务器两层：
  • 第一层:  在客户机系统上结合了界面显示与业务逻辑；
  • 第二层:  通过网络结合了数据库服务器。
• 简单的说就是第一层是用户表示层，第二层是数据库层。

C/S优缺点：

优点：

• 1 C/S架构的界面和操作可以很丰富。（客户端操作界面可以随意排列，满足客户的需要）
• 2 安全性能可以很容易保证。（因为只有两层的传输，而不是中间有很多层）。
• 3 由于只有一层交互，因此响应速度较快。

缺点：

• 可以将QQ作为类比：
• 1 适用面窄，通常用于局域网中。
• 2 用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户。
• 3 维护成本高，发生一次升级，则所有客户端的程序都需要改变。

• B/S架构的全称为Browser/Server，即浏览器/服务器结构。
• Browser指的是Web浏览器，极少数事务逻辑在前端实现，但主要事务逻辑在服务器端实现。B/S架构的系统无须特别安装，只有Web浏览器即可。
• B/S架构的分层： •与C/S架构只有两层不同的是，B/S架构有三层，分别为：
  • 第一层表现(客户)层：完成用户和后台的交互及最终查询结果的输出功能。
  • 第二层逻辑(业务)层：对客户层操作的响应，利用服务器完成客户端的应用逻辑功能。
  • 第三层数据层：简单理解就是存放数据的地方，它是为业务层的数据访问提供数据资源和操作。

B/S的优缺点

优点：

• 1、客户端无需安装，有Web浏览器即可。
• 2、BS架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。 
• 3、BS架构无需升级多个客户端，升级服务器即可。可以随时更新版本，而无需用户重新下载啊什么的。

缺点：

• 1、在跨浏览器上，BS架构不尽如人意。 
• 2、表现要达到CS程序的程度需要花费不少精力。
• 3、在速度和安全性上需要花费巨大的设计成本，这是BS架构的最大问题。
• 4、客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。（在Ajax实现页面不刷新加载后此问题得到了一定程度的缓解）

B/S架构的几种形式

第一种：客户端-服务器-数据库

这个应该是我们平时比较常用的一种模式：

• 1、客户端向服务器发起http请求
• 2、服务器中的web服务层能够处理http请求
• 3、服务器中的应用层部分调用业务逻辑，调用业务逻辑上的方法
• 4、如果有必要，服务器会和数据库进行数据交换. 然后将模版＋数据渲染成最终的html, 返送给客户端

第二种：客户端－web服务器－应用服务器－数据库(前后端分离)

类似于第一种方法，只是将web服务和应用服务解耦

• 1 客户端向web服务器发起Http请求
• 2 web服务能够处理Http请求，并且调用应用服务器暴露在外的RESTFUL接口
• 3 应用服务器的RESTFUL接口被调用，会执行对应的暴露方法.如果有必要和数据库进行数据交互，应用服务器会和数据库进行交互后，将json数据返回给web服务器
• 4 web服务器将模版＋数据组合渲染成html返回给客户端

第三种方法：客户端－负载均衡器(Nginx)－中间服务器(Node)－应用服务器－数据库

这种模式一般用在有大量的用户，高并发的应用中。

• 1、整正暴露在外的不是真正web服务器的地址，而是负载均衡器器的地址
• 2、客户向负载均衡器发起Http请求
• 3、负载均衡器能够将客户端的Http请求均匀的转发给Node服务器集群
• 4、Node服务器接收到Http请求之后，能够对其进行解析，并且能够调用应用服务器暴露在外的RESTFUL接口
• 5、应用服务器的RESTFUL接口被调用，会执行对应的暴露方法.如果有必要和数据库进行数据交互，应用服务器会和数据库进行交互后，将json数据返回给Node
• 6、Node层将模版＋数据组合渲染成html返回反向代理服务器
• 7、反向代理服务器将对应html返回给客户端

为什么有一层Node服务器？

https://blog.csdn.net/brokenkay/article/details/112711241?utm_term=nodejs%E5%B1%82%E7%9A%84%E4%BD%9C%E7%94%A8&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~sobaiduweb~default-0-112711241&spm=3001.4430

这三种并不是全部，可能存在第三方提供的服务，如对象存储服务，CDN加速服务等。

• 分层是软件体系结构的一个重要体现。
• 层是软件结构的一种组织风格。层可以在代码层面组织，如MVC设计模式；层也可以是系统构成的物理节点，如服务器与客户机；层也可以是逻辑上的划分，如业务层与持久层等；
• 从不同的角度分层，分层的名字有若干，比如除了客户层、业务层和数据层三个基本名词以外，还有Web层、中间层、持久层、控制层、逻辑层、视图层、资源层、对象层、关系层、DAO层等等。

• 分层是进一步体现“松耦合”“分而治之”的思想，为了提高软件的开发、维护、部署和扩展性。
• 早期的信息处理软件，无论是界面、数据处理、数据存放都是在单机上运行的，没有分层的必要也无需分层的概念，开发也是个人“一贯到底”，那时的软件也没有体系结构的概念，维护是困难重重。
• 随着分布式计算的推广，出现了两层结构C/S(Client/Server)，代码的部署和运行出现了分离，Client客户端部署了面向用户的应用程序，Server服务端部署了存放数据的数据库。

内聚：模块内部各成分紧密程度。耦合：模块之间联系的程度。

• 软件的数据应用和数据存放在物理和逻辑上都进行了分离，各有分工，很大程度上改进了软件的可维护性。
• 但人机交互的界面中掺杂大量的逻辑代码，应用程序的每次维护都涉及大量的客户端，维护仍面临很大问题。
• Web技术的不断改进，人们逐步意识到最好是把业务逻辑部分从客户端(或数据服务端)分离出来单独设定一层，这样界面、业务逻辑和数据三者分离，更好地解决开发、部署和维护问题。(Web的B/S三层结构)

1.客户层与业务层

由于客户层是程序运行的可见部分，为软件使用的前端，故俗称“前端”；业务层和数据层是使用者不可见的，在服务器端运行，故俗称“后端”。这种分层结构是以客户层为主导引发事件的，后台响应事件并发生一系列的运算过程。

2. 数据层

数据层进一步分为“对象持久层”和“资源层”。

对象持久层(说明持久化，持久层，对象持久化)就是对数据对象进行访问(增、删、改、查)的动作层；(为什么需要持久层？)

为什么需要持久层：有了持久层业务逻辑不用关心有关资源访问的底层细节，全权交由持久层处理。进行一定的解耦，这样在数据设计或业务逻辑发生改变时，可以使改变只限定在各自的范围之内，而不会扩散至其他部分，两侧变更、修改、维护尽量互不干扰。

持久化(Persistence)：就是对数据对象和程序状态的保存，也就是将内存中的对象保存到磁盘上加以固化，目前主要通过数据库来完成。

持久层(Persistence Tier)：加了一个“层”字，就把对数据库操作当作一个逻辑层面独立出来。

对象持久化(Object persistence)：在面向对象为主导的应用程序中，一切都视为对象，数据实体也不例外。

资源层永久性保存对象，以数据库(DB)为主。

对象持久层的DAO模型

DAO(Data Access Object)数据访问对象，由两部分构成：DAO＝Data Access+Data Object。

DO数据对象。

DA负责对资源层连接，创建数据库连接Connection 对象，然后将数据库的基本操作CRUD ( Create、Read、Update和Delete)全部封装在里面。

业务层是软件系统的核心

业务层再由两个子层组成：BP+BS

BS该层对象依赖于下层的DA，提供给上级业务流程，封装BP中使用的所有业务方法。

BP满足用户需求的业务流程控制，本层没有具体的业务方法，该层要依赖于业务服务层BS提供的服务消息。

ORM(OR映射层，即对象关系映射)：在操作数据库之前，先把数据表与实体类关联起来。然后通过实体类的对象操作（增删改查）数据库表：https://blog.csdn.net/qq_41107231/article/details/106292737

还剩下VM装配层，先说一个MVC模式。

• Model层：模型（用于封装业务逻辑相关的数据以及对数据的操纵）；
• View层：视图（渲染图形化界面，也就是所谓的UI界面）；
• Controller层：控制器（M和V之间的连接器，主要处理业务逻辑，包括显示数据，界面跳转，管理页面生命周期等）。

https://blog.csdn.net/zhouym_/article/details/90611839

MVC模型与B/S架构结合：

可以看到Controller层代表VM映射层。

MVC模型更体现在代码中：

• 框架给人们提供了有条理存放构件的“空间基础”；
• MVC是人们总结出摆放物品的良好“习惯”。
• 让“框架”与“MVC”在开发者身上完美结合，实现系统松耦合，易维护、易扩展、易重用的美好目标。

其他模式：MVP、MVVM ?

其他包名：PO、VO、DAO、BO、DTO、POJO的使用场景 ?

[/wppay]