软件架构模式书籍精选：模型与推荐

一：软件架构风格

1、架构风格的演变：

在互联网发展至今，系统软件架构风格也一直在摸索着前进，适应时代的潮流。在最开始的时候软件架构是两层的C/S架构，即只有表示层和数据层，后来慢慢的演进为三层的C/S以及三层B/S架构等。

2、二层C/S 架构风格

二层的C/S架构是互联网初期使用的一种架构风格，C/S 架构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。但随着企业规模的日益扩大，软件的复杂程度不断提高，C/S架构逐渐暴露了以下缺点：

• 开发成本较高。
• 客户端程序设计复杂。
• 信息内容和形式单一。
• 用户界面风格不一，使用繁杂，不利于推广使用。
• 软件移植困难。
• 软件维护和升级困难。
• 新技术不能轻易应用。

3、三层C/S架构架构风格

二层C/S架构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet，软、硬件的组合及集成能力有限。与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种结构被称为瘦客户机（thin client）。三层C/S架构是将应用功能分成表示层、功能层和数据层三个部分。三层C/S物理结构图如下

现在的手机上的功能，如app等就类似于C/S架构风格。

4、B/S架构

浏览器/服务器（Browser/Server，B/S）风格其具体结构为：浏览器/Web服务器/数据库服务器。B/S架构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B/S结构是一种全新的软件架构。B/S物理结构图如下：

5、混合架构风格

混合架构风格就是B/S架构和C/S架构的结合体，在某一些特定环境至今还在使用。

6、层次架构风格

7、MVC架构风格

Model （模型）：是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。

View （视图）：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。

Controller （控制器）:是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

在J2EE体系中：

• 视图（ View) : JSP
• 控制（ Controller ）：Servlet
• 模型（ Model ) : Entity Bean、Session Bean

8、MVP架构风格

MVP是MVC的变种，它实现了V与M之间的解藕（ V不直接使用M ，修改V不会影响M)，并且更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑；可以将一个P用于多个V，而不需要改变P的逻辑），MVP中V要处理界面事件，业务逻辑在P中， MVC中界面事件由C处理。

9、富互联网应用（RIA）

为了弥补B/S架构存在的一些不足，提高用户体验，RIA（Rich Internet Application，富互联网应用）应运而生。RIA是一个用户接口，它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性。RIA简化并改进了B/S架构的用户交互以及数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。这样，用户开发的应用程序可以提供更丰富、更具有交互性的用户体验。支持RIA的平台如上图所述。

10、基于服务的架构（SOA）

服务是一种为了满足某项业务需求的操作、规则等的逻辑组合， 包含一系列有序活动的交互，为实现用户目标提供支持。SOA其实是由构建技术演变而来，对遗留系统的集成有着非常大的优势。服务的特点有松耦合、粗粒度、标准化接口。

1）服务和构建的区别：

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

2）SOA的实现方式--Web Service

   Web Service 也称为Web服务。其基本思想是会把各种业务职能封装为一个个Web服务，以web服务的形式对外去提供相应的服务支撑。目前来说绝大多数用的都是这种形式。

（3）SOA的实现方式--ESB（企业服务总线）

Web Service就相当于一个个的终端，ESB就相当于网络中的交换机路由器，是一个中间连接件。实际开发中，经常的把Web Service 和ESB综合使用。

4）SOA的实现方式--服务注册表（只需要了解是SOA的一种实现方式即可，实际用的非常少）

服务注册：应用开发者（服务提供者）向注册表公布服务的功能。

服务位置：服务使用者（服务应用开发者），帮助他们查询注册服务，寻找得合自身要求的服务。

服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定、调用注册的服务，以及与它们实现互动。

11、微服务的架构风格

微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常是基于HTIP协议的RESTful API ），每个服务部围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

1）微服务的特点：

• 小，且专注于做一件事情
• 轻量级的通信机制
• 松耦合、独立部署。

2）微服务架构和传统架构体系的区别：

3）微服务的特点：

• 技术异相性：允许不同的微服务对接不同的数据库，允许不同的微服务实现的技术不同。
• 弹性：因为是相对独立的，所以具有一定的可伸缩性。
• 扩展：服务与服务之间松耦合，便于扩展。
• 简化部署：前提条件是要实现自动化部署。
• 与组织结构相匹配：因为微服务强调小，且专注做一件事情。
• 可组合性：服务与服务之间可以相互组合。
• 对可替代性的优化：由于颗粒度小，所以替换难度小。

4）微服务面临的挑战：

• 分布式系统的复杂度增加。
• 运维成本增加。
• 部署自动化难度相对于传统服务大。
• DevOps与组织结构。
• 服务间依赖测试。
• 服务间依赖管理。

5）微服务与SOA的区别

12、特定领域软件架构（DSSA）

   特定领域软件架构（Domain Specific Software Architecture，DSSA）是在一个特定应用领域中为一组应用提供组织结构参考的标准软件架构，是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标是支持在一个特定领域中多个应用的生成。

   关于DSSA中“领域”的含义，从功能覆盖的范围角度可以有两种理解方式：

       a、垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可

作为系统的可行解决方案的一个通用软件架构。

       b、水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，无法为系统提供完整的通用架构。

在垂直域上定义的DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足；若将领域分割成较小的范围，则更相对容易，也容易得到一个一致的解决方案。

（1）领域分析机制

• 领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
• 领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
• 领域设计人员：领域设计人员应由具有经验的软件酷队员来担任．
• 领域实现人员：领域实现人员应由具有经验的程序设计人员来担任．

2）建立过程

3）三层架构模型

• ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。
• 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成（甚至远远没再完成），就开始了软件设计。
• ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中， ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。
• ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删