几种常见的架构模式

6.2.2 几种常见架构模式

 

《不是三维——软件项目的设计、开发与管理》从软件与三维实物的本质性不一样出发研究软件生产方法论。第6章会从设计与开发的各个层面，抽象、总结并介绍目前实践中实用的技术方法。本节说的是几种常见架构模式。

AD：2013大数据全球技术峰会课程PPT下载

6.2.2  几种常见架构模式

前文讲过，在实践中，人们总结出了一些经常使用的软件系统结构高层模式，以供应用系统设计时参考。这些模式包括：单服务两层/多层C/S；MVC结构；面向服务的SOA与多服务集合；数据交换总线等。

1. 单机应用系统（Standalone）

准确地讲，单机应用系统是最简单的软件结构，是指运行在一台物理机器上的独立应用程序。固然，该应用能够是多进程或多线程的。

在信息系统普及以前的时代，大多数软件系统其实都是单机应用系统。这并不意味着它们简单，实际状况是，这样的系统有时更加复杂。这是由于软件技术最初普及时，多数行业只是将软件技术当作辅助手段来解决本身专业领域的问题，其中大多都是较深刻的数学问题或图形图像处理算法的实现。

有些系统很是庞大：笔者早年曾经参与的一个大型纯软件系统开发，多达160万行程序！要知道，这些程序当时可都是一行行写出来的。这应该算是一个超大型的软件系统了，共有十多个子系统集成在一个图形界面上执行，并可在多行UNIX/DOS平台下运行，其中不少算法的复杂困难程度，能够说，若是讲给今天这些所谓的架构高手与计算机高手听，他们会感受如听“天书”通常深奥；有些系统则算法很是复杂：个人一个同窗，在他们专业领域内编制的软件程序，在当时最高级的专业工做站上（应该要比今天的最快的微机性能还好些），一敲回车键运行，就每每要等待一个星期的时间才能获得结果。

而这些软件系统，从今天的软件架构上来说，却很简单，是标准的单机系统。即使是今天，复杂的单机系统也有不少，它们大多都是专业领域的产品，如CAD/CAM领域的CATIA、ProEngineer，Autodesk的AutoCAD，还有咱们熟悉的Photoshop、CoralDraw，等等（这些系统的高级版本可能提供了一些网络化的功能，但改变不了其单机系统的实质）。

因此这里笔者要说的是，软件架构复杂并不表明软件系统复杂，其实，软件架构设计较为重要的领域只有一个，那就是信息系统领域，即以数据处理（数据存储，传输，安全，查询，展现等）为核心的软件系统。其余行业的软件应用对该概念其实并非那么强调。

因此，读者应该明白，后面几节介绍的所谓流行软件架构，都是指在信息系统的领域内。

2. 客户机/服务器（Client/Server）结构

客户机/服务器结构是软件系统中最多见的一种。笔者认为该概念应该来源于基于TCP/IP协议的进程间通讯IPC编程的“发送”与“反射”程序结构，即Client方向Server方发送一个TCP或UDP包，而后Server方根据接收到的请求向Client方回送TCP或UDP数据包（这里是指创建TCP/IP链接之后的应用程序逻辑，不涉及如TCP创建链接的三方握手过程），IPC编程的客户端/服务器概念图如图6-2所示。

诚然，上述IPC编程中的客户与服务，在过去只是一个再普通、传统不过的标准程序结构与编程方法，不会有人将其提升到软件架构的高度。但其实，现代流行的各类C/S架构，其本质却正是如此：即TCP/IP IPC编程中的客户机/服务器。目前为止，尚未任何一种客户机/服务器架构的软件超出了这个范围。

因此，准确地讲，现代各类客户机/服务器模式的软件架构其实是对IPC编程中客户/服务程序结构更加产品化与成熟化的结果。

让咱们来看看几种常见的客户机/服务器的软件结构。

● 两层C/S

两层C/S，其实彻底是IPC客户端/服务器结构的应用系统体现。两层C/S其实就是人们所说的“胖客户端”模式。

在实际的系统设计中，该类结构主要是指前台客户端+后台数据库管理系统，如图6-3所示。

在两层C/S结构中，图6-3前台界面+后台数据库服务的模式最为典型，前文所说的不少数据库前端开发工具（如PowerBuilder、Delphi、VB）等都是用来专门制做这种结构的软件系统的。

有人也许要问，上述典型的两层C/S模式应该没有你所说的TCP/IP通讯呀？怎么你前面讲全部的C/S模式都脱离不了这个范围呢？其实，每一种数据库都提供了其专用的访问API或通用的ODBC/JDBC接口，若是这个数据库的开发支持从不一样的机器上以网络方式链接，则笔者相信其在客户端与数据库后台的通讯大多状况下是TCP/IP的客户机/服务器模式！若是这个数据库不支持网络链接方式（如之前基于FoxBase的开发，或如今基于MS Access的开发），则咱们不能称这个软件是C/S模式。

另外，如图6-3所示，两层C/S其实是将前台界面与相关的业务逻辑处理服务的内容集成在一个可运行单元中了。

● 三层C/S结构与B/S

三层C/S结构如图6-4(a)所示，其前台界面送日后台的请求中，除了数据库存取操做之外，还有不少其余业务逻辑须要处理。三层C/S的前台界面与后台服务之间必须经过一种协议（自开发或采用标准协议）来通讯（包括请求、回复、远程函数调用等），一般包括如下几种：

（1）基于TCP/IP协议，直接在底层socket api基础上自行开发。这样作通常只适合需求与功能简单的小型系统；

（2）首先创建自定义的消息机制（封装TCP/IP与socket编程），而后前台与后台之间的通讯经过该消息机制来开发。消息机制能够基于XML，也能够基于字节流（Stream）定义。虽然是自开发，但能够基于此构建大型分布式系统；

（3）基于RPC编程；

（4）基于CORBA/IIOP协议；

（5）基于Java RMI；

（6）基于J2EE JMS；

（7）基于HTTP协议。如浏览器与Web服务器之间的交流即是如此。须要指出的是，HTTP不是面向对象的，因此面向对象的应用数据会被首先平面化后进行传输。

目前最典型的基于三层C/S结构的应用模式即是咱们最熟悉、较流行的B/S（Brower/Server，浏览器/服务器）模式，如图6-4（b）所示。

图6-4（b）的B/S结构中，Web浏览器是一个用于文档检索和显示的客户应用程序，并经过超文本传输协议HTTP（HyperText Transfer Protocol）与Web服务器相连。该模式下，通用的、低成本的浏览器节省了两层结构的C/S模式客户端软件的开发和维护费用。这些浏览器你们都很熟悉，包括MS Internet Explorer、Mozilla FireFox、NetScape等。

Web服务器是指驻留于因特网上某种类型计算机的程序。当Web浏览器（客户端）连到服务器上并请求文件或数据时，服务器将处理该请求并将文件或数据发送到该浏览器上，附带的信息会告诉浏览器如何查看该文件（即文件类型）。服务器使用HTTP（超文本传输协议）进行信息交流，这就是人们常把它们称为HTTPD服务器的缘由。

咱们天天都在Web浏览器上进行各类操做，这些操做中绝大多数其实都是在Web服务器上执行的，Web浏览器只是将咱们的请求以HTTP协议格式发送到Web服务器端或将返回的查询结果显示而已。固然，驻留Web浏览器与服务器的硬件设备能够是位于Web网络上的两台相距千里的计算机。

应该清楚，B/S模式的浏览器与Web服务器之间的通讯仍然是TCP/IP，只是将协议格式在应用层标准化了而已。实际上B/S是采用了通用客户端界面的三层C/S结构。

● 多层C/S

多层C/S结构通常是指三层以上的结构，在实践中主要是三层与四层，四层即前台界面（如浏览器）、Web服务器、中间件（或应用服务器）及数据库服务器，典型的客户机/服务器软件结构如图6-5所示。

多层客户机／服务器模式主要用于较有规模的企业信息系统建设，其中中间件一层主要完成如下几个方面的工做：

（1）提升系统可伸缩性，增长并发性能。在大量并发访问发生的状况下，Web服务器可处理的并发请求数能够在中间件一层获得更进一步的扩展，从而提升系统总体并发链接数；

（2）中间件/应用层一层专门完成请求转发或一些与应用逻辑相关的处理，具备这一做用的中间件通常能够做为请求代理，也可做为应用服务器。中间件的这种做用在J2EE的多层结构中比较经常使用，如BEA WebLogic、IBM WebSphere等提供的EJB容器，就是专门用以处理复杂企业逻辑的中间件技术组成部分。

（3）增长数据安全性。在网络结构设计中，Web服务器通常都处于非军事区，即直接能够被前端用户访问到，若是是一些在公网上提供服务的应用，则Web服务器通常均可以被全部能访问与联网的用户直接访问。所以，若是在软件结构设计上从Web服务器就能够直接访问企业数据库是不安全的。所以，中间件的存在，能够隔离Web服务器对企业数据库的访问请求：Web服务器将请求先发给中间件，而后由中间件完成数据库访问处理后返回。

● MVC

MVC的概念在目前信息系统设计很是流行，严格来说，MVC（Model-View-Controller）其实是上述多层C/S结构的一种经常使用的标准化模式，或者能够说是从另外一个角度去抽象这种多层C/S结构。

在J2EE架构中，View表示层指浏览器层，用于图形化展现请求结果；Controller控制器指Web服务器层，Model模型层指应用逻辑实现及数据持久化的部分。目前流行的J2EE开发框架，如JSF、Struts、Spring、Hibernate等及它们之间的组合，如Struts+Spring+Hibernate（SSH）、JSP+Spring+Hibernate等都是面向MVC架构的；另外，PHP、Perl、MFC等语言都有MVC的实现模式。

在之前传统JSP程序中网页与数据访问是混合在一块儿的，在MVC中强制要求表示层（视图）与数据层（模型）代码分开，而控制器（如Servlet）则能够用来链接不一样的模型和视图去完成用户的需求。

从分层体系的角度来说，MVC的层次结构如图6-6所示，控制器与视图一般处于Web服务器一层，而根据“模型“有没有将业务逻辑处理分离成单独服务处理，MVC能够分为三层或四层体系。

● 对分层标准的探讨

以上所讲各类C/S结构，包括两层、三层、四层甚至多层的概念，在IT界目前很是流行，绝大多数的信息处理系统与门户网站，都会将本身应用的结构宣传为多少多少层C/S架构。但究竟应该是属于多少层，两层仍是三层？目前的实际情况是比较混乱的。

例如上面所说B/S结构，有人说是三层，也有很多人说是两层，各有道理；又好比MVC，有人说是四层，又有人说是三层，同时在不少宣传中它确实被归结到J2EE宣传的四层架构中；另外，还有许多应用系统在某一层采用主从模式的集群服务器结构，有时也会使分层的概念混淆。

本书在这里给出一个分层问题的判断标准，即应该将应用系统的分层与服务分级区别开来。即某个应用架构到底分多少层，应该由其纵向深度上有多少个不一样种类的（服务器集群显然排除在外）、两两相互通讯的独立运行单元组成来决定；而服务分级应该由其纵向深度上以其由多少个不一样类型的服务实例以两两双向通讯的模式组成？也就是说，一共由多少对简单客户机/服务器组成。

因而，B/S应该是三层架构，可是由两级不一样类型的服务组成：Web服务与数据库服务；而四层架构则一般应该是由三级服务组成的。还有，在有些J2EE框架（如JSF+Spring+Hibernate），除了Web服务器与浏览器的通讯之外，再没有其余的分布式应用了（没有用到EJB，RMI或JMS），而有些人将HibernateDAO等的数据持久化层单独算作一层，称之为四层，这也是不稳当的，由于数据持久化层与数据层毕竟不是一组客户机/服务器的关系，所以，统一算作数据层，因此应该仍是归为三层架构；

前面所说“服务”的概念，不管在Windows平台仍是UNIX平台，都应该是很清楚的：服务是主机提供的功能，它以被动等待信号或按期启动的方式来实现。在UNIX-LIKE的系统中，服务通常是由Daemon来实现的。

而这里须要指出的是，上面所说的“服务”与6.2.2.3节要讲的“多服务结构SOA”中提出的“服务”涵义是不一样的：多层结构的软件系统，不管其自己由多少层级的服务组成，对外都是一个完整的单点应用系统，对应SOA中的一个“服务”。

3. 多服务结构（SOA）

以上所讲，不管多少层的C/S软件结构，对外来说，都只是一个单结点应用（不管它由多个不一样层的“服务”相互配合来完成其功能），具体表现为一个门户网站、一个应用系统等。下面咱们讲多个单点应用相互通讯的多服务结构。

● 多服务结构

若是两个多层C/S结构的应用系统之间须要相互进行通讯，那么，就产生了多服务结构，称为Service Oriented Architecture。如图6-7所示：

在SOA的概念中，将由多层服务组成的一个结点应用看做是一个单一的服务。在SOA的定义里，对“服务”的概念进行的广义化，即它不是指计算机层面的一个Daemon，而是指向外提供一组总体功能的独立应用系统。所谓独立应用系统是指：不管该应用系统由多少层服务组成，去掉任何一层，它都将不能正常工做，对外能够是一个提供完整功能的独立应用。这个特征即可以将多服务体系与多层单服务体系彻底区分开来。

两个应用之间通常经过消息来进行通讯，能够互相调用对方的内部服务、模块或数据交换、驱动交易，等等。在实践中，一般借助中间件来实现SOA的需求，如消息中间件、交易中间件，等等。

多服务结构能够在实践中又能够具体分为异构系统集成、同构系统聚合、联邦体系结构等，在下面咱们对此会做一介绍。

● Web Service

多服务结构体如今Web应用之间，就成为了Web Service，即两个互联网应用（如门户网站）之间能够相互向对方开放一些内部“服务”（能够理解为功能模块、函数、过程等）。现阶段，一个Web应用对外开放其内部服务的协议主要是SOAP与WSDL，其资料不少，本书不对其作详细介绍。

Web Service是多服务体系结构的一个最典型、最流行的应用模式，但除了其由Web应用为主而组成的特色之外，Web Service最主要的应用是一个Web应用向外提供内部服务，而不像传统意义上SOA那样有更加丰富的应用类型。

● 多服务结构的实质

多服务结构的实质是消息机制或远程过程调用（RPC）。虽然其具体的实现底层并不必定是采用了咱们所熟悉的RPC编程技术，但两个应用之间的相互配合确实是经过某种预约义的协议来调用对方的“过程”实现的，这与咱们6.2.2.2节所讲多层架构的单点应用系统中，两个处于不一样层的运行实例相互之间通讯的协议类型基本是相同的。

4. 企业数据交换总线

实践中，还有一种较经常使用的架构，即企业数据交换总线，即不一样的企业应用之间进行信息交换的公共通道，如图6-8所示：

这种架构在大型企业不一样应用系统进行信息交换时使用较广泛，在国内，主要发生在银行或电信等信息化程度较高的行业。其余的许多行业虽然也有相似的需求，但大多都是手工或半自动化来实现该项需求的，并无达到“企业数据交换总线”的层次。

关于数据总线自己，其实质应该是一个可称之为链接器的软件系统（Connector），它能够基于中间件（如消息中间件或交易中间件）构建，也能够基于CORBA/IIOP协议开发，主要功能是按照预约义的配置或消息头定义，进行数据（data）、请求(request)或回复(response)的接收与分发。

从理论上来说，企业数据交换总线能够同时具备实时交易与大数据量传输的功能，但在实践中，成熟的企业数据交换总线主要是为实时交易而设计的，而对可靠的大数据量传输需求每每要单独设计。若是采用CORBA为通讯协议，交换总线就是对象请求代理（ORB），也有一些资料中将这种架构称为“代理体系”。另外，在交换总线上挂接的软件系统，有些也能够实现代理的功能，各代理之间能够并行或串行的方式进行工做，经过挂接在同一交换总线上的控制器来协调各代理之间的活动。

 

原文地址：http://book.51cto.com/art/201004/195732.htm