关于多层架构一些思考

关于多层架构一些思考

1：关于多层架构(N-Tier)

 

多层架构是一种被行业证明过的软件架构模型，对开发一些解决可扩展性、安全性、容错性方面的企业级(客户端/服务端)应用程序支持是相当给力。但在.NET世界里，我们有许多工具和产品，却没有指导手册是关于如何设计和实现一个良好的多层架构模型，比如一些样例版，Demo等等,我们或许多少有听到、看到一些关于多层架构模型的用途和益处，但更多知道的仅仅是如何使用和实现，没有过多的思考为何我们要这样设计呢？这样设计符合了哪些设计模式呢？遵循哪些设计原则呢？或者了解一点多层的概念，甚至是根本不理解其中的定义。所以本篇文章主旨是围绕“多层架构”来打造，介绍其中的概念、优缺点、与其他架构区别、使用场景等等。但，总体来说，这是一个良好的软件架构的解决方案之一。

 

2：名词介绍

 

物理层和进程(Tier And Process)

 

在英文中都有表示层的意思，简单来说——物理层和逻辑层。有一种说法是Layer是水平方向切割的，Tier是垂直方向切割的，这个只是从观察角度不同来定义的。Tier通常意味着物理部署的计算机，在一层可以单独运行某一个服务。而Layer则意味着软件功能相似的组件逻辑组合，Layer是为了能够更好的开发，更好的组织。严格定义来说，

 

Tier是这样的：客户机->web服务器->应用服务器->数据库，仅此而已。如果想要更多的Tiers，只能去扩展应用服务器，把应用服务器分割出若干的Tier。更多时候，一个Tier可以Host多个Layer外，某个Layer可以分布到多个Tier,比如提供基础公共服务的Layer,对于富客户端的应用程序，就是这种情况。

 

同时，Layer还暗示了"下面的Layer一般要为上面的Layer提供服务"，那么用逻辑层来表达就显得比较合适，而Tier这方面的暗示比较薄弱，用物理层来表达也贴切。

 

图1：

 

 

 

 

  在图1中我们能看到，持久层(persistence layer)包含了两部分：持久操作类库(persistence lib)和wcf数据服务(wcf Data Service)。持久操作类型在持久层中通常运行同一个进程并结合wcf数据服务，作为业务层的提供者，而wcf数据服务，又可以单独的运行在独自的一物理层。另一个例子是，我们可能会从业务层中提取数据验证来作为独立的类库(此时逻辑定义上，数据验证还在业务层中)，是为了给客户展现层调用提供更好的交互性能。那这样的话，数据验证类库与客户展现层运行的同一个进程中，而业务层剩余的部分则单独运行在一个物理层。

 

 

 

物理层和进程(Tier And Process)

 

通常来说，一个逻辑层运行一个进程，并同时运行在一台单独的计算机上。两个不同逻辑层可以是在两个不同的进程中独立运行，进程间也互相通信。但如果碰到IPC情况，不是基于分布式的，那么这两个进程就会共享内存空间，那么不同进程的处理得放在一个计算机中，那么相对来说，一个物理层对应两个进程，相当于对应两个逻辑层

 

 

 

逻辑层和进程(Layer And Process)

通常，一个逻辑层运行在一个独立的进程中，也有多个逻辑层运行在一个独立的进程中，也有一个逻辑层运行多个进程。可以分不同种情况

 

3：三层架构

首先先介绍下三层架构，三层是多层架构中典型的例子。包括了：表示层、应用层、数据层，顺序是从顶层到底层依次继承。

 

表示层(Presentation layer)：用户可以直接访问和交互的层次，比如桌面UI、网页页面等等，也可以叫为客户端。

 

应用层(Application layer)：这个层封装了业务逻辑(简单来说就是业务运算的规则和数据验证)，领域概念、数据访问逻辑等等，也可以叫为中间层

 

数据层(Data layer)：用来存取应用程序数据的外部数据源，比如数据库服务，CRM系统，ERP系统，主机或者其他遗留系统等等。其中一个是我们常见的是数据库服务，在多层架构中，我们需要使用到非嵌入式的数据服务系统，比如SQL Service,Oracle,DB2,MySql或者PostgraSQL.非嵌入式的数据库服务可以运行在独立计算机中，而嵌入式数据库服务，比如access,db在独立计算机，所以这种数据库服务类型是不能在三层架构中使用的。

 

4：1-Tier,2-Tier,3-Tier或More-Tier架构

1-Tier：所有的逻辑层运行在一台计算机中，为了实现1-Tier架构，我们需要用到签入式类型的数据库系统，并且是不能运行在单独的进程中，相反，那些至少2-Tier因为是非嵌入式数据库通常可以在独立的计算机中运行。

 

2-Tier：表示层和应用层，其中一个单独运行在一台计算机中，或应用层和数据层，其中一个单独运行在一台计算机中，整个应用程序不超过两台计算机。

 

3-Tier：是多层架构中，最典型的一种。三层中的每一层都可以单独运行在分离的计算机中，但也可以被部署在同一台计算机（其中最常见的是，三层架构，但最终部署作为一台中）。

 

N-Tier：3或者更多层架构。图3描绘的是一个N层架构体系。一些三层类型可以进一步分割，变为多层架构。比如应用层可以进一步划分为业务层和持久层，表示层可以进一步划分为客户端层和客户端表现层。当然，所有这些逻辑层都可以部署在同一台计算机中的。

 

 

客户端层：这个层是直接与用户交互的，可能有几种不同的类型共存，如WPF窗口，HTML网页等等

客户端表现层：包含客户所需的表现逻辑。如asp.net mvc 的IIS服务器，也适应不同客户的业务层

业务层：处理并封装业务所涉及的所有领域和逻辑，也可被称为领域层

持久层：处理和对业务数据到数据层进行读写操作，也可被称为数据访问层

数据层：外部的数据源，比如数据库

 

5：N-Tier与MVC架构有什么区别

MVC模式(Model-View-Controller)是 软件工程中的一种 软件架构模式，把软件系统分为三个基本部分：模型(Model)、视图(View)和控制器(Controller)。

1.控制器(Controller)- 负责转发请求，对请求进行处理。

2.视图(View) - 界面设计人员进行图形界面设计。

3.模型(Model) - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

 

 

就拿多层架构中最典型的三层来说，在三层中，数据访问层(DAL)、业务逻辑层(BLL)，Web层各司其职，目的是职责分离。MVC是Model-View-Controller。严格说起来这三个加起来才是三层架构中的Web层，换种说法就是MVC就是表示层中再度分化，分成了控制器、视图、实体三个部分。View完成页面逻辑，Model则封装需要传递到View进行显示的数据，而控制层则与三层中的BLL进行通信。

MVC的优点：耦合性低、重用性高、部署快、可维护性。

 

6：不同层架构优势和劣势

1 or 2-Tier 架构

优势：由于流程和层次比较少，对于用户数量少的应用程序是简单又快速部署，同时又低成本的硬件、网络维护。

劣势：但当用户数量增大时，将会出现大问题。由于只能部署1到2台计算机，在程序的安全性、可扩展性、容错性等方面会有局限性。

 

N-Tier架构

优势：

1,可伸缩性。这是由于多层的功能和低耦合性所决定的。比如，由于没有其他层的耦合，数据层可以扩大数据库集群，web客户端可以通过负载平衡器扩大而不影响其他层，Windows服务器可以轻松进行集群通过负载平衡和故障转移。

2,可安全性。更好和更安全的控制整个系统，我们可以对每个层执行不同的安全策略，比如，业务层和数据层通常比表示层需要更高的安全级别，我们可以把这两高安全层放在防火墙后面进行保护。

3,可容错性。比如，在不影响其他层的情况下，数据库在数据层中可以为故障转移，进行负载平衡集群。

4,可独立性。在不影响其他层情况下，可以进行独立升级和改变。在面向对象世界里，接口依赖实现可以把所有层解耦的非常好，那么就会导致如果其中某一层改变了，对于其他层是影响是非常小甚至是不影响。接口依赖意味着层跟层之间仅仅通过接口来互相通信，一层依赖于另一层的接口，而不是内部类来通信。当然，在改变整个系统时候，层的依赖性影响到的只是他低层次的实现，进而把其中副作用的影响降到最低。比如，如果接口不改变，在不影响整个系统下，我们可以更改或替换这个接口所实现的层。

5,可便捷性。更便捷和更高效的开发环境，解耦主要是通过软件组件组合来实现某一模块，这样软件开发是非常便捷和高效的。可以把每一层要实现的功能单独分配给不同的开发组，只需通过接口来互相通信，每个层又可以自己做单元测试，到最后完成时组合起来就变成一个完整的系统。

6,可维护性。

7,可扩展性。由于对业务开发是以组件式来的，对于新功能的添加和删除是非常方便的。

8,可重用性。由于是高内聚和低耦合，通用的功能和代码可以重复使用，也可以被其他更多的应用程序调用。

劣势：

1，由于许多网络、计算机和进程都是独立运行的，一旦系统的硬件和网络带宽比较差的话，整个系统运行的性能就会比较慢。

2，如果需要更好的硬件和网络带宽，对于硬件和网络、维护和部署的成本比较高。

 

7：多层架构中的业务数据验证

在多层架构中，为了保证整个业务系统健康的和良好的，其中数据验证是非常必须和重要的步骤。那么首先有一个问题对于数据验证？哪个层我们应该进行数据验证，并且在哪里进行验证呢?这里有几个点：

1,可以任何一个层中进行数据验证。通常，数据验证离客户层越近，是越高效。离客户端越远，则需要越可靠、越健壮。

2,当我们决定哪个层进行数据验证时，我们需要处理好性能、可靠性和健壮之间的平衡关系。

3,客户端验证是是一种非常有效的手段，列如：Javascript客户端验证，当同时，用户也可以轻松绕过客户端验证，比如网页黑客所干的事情。因此，在考虑性能和可靠性时候，在客户端和服务的数据验证是非常需要的。

4,对于一些数据交互的应用程序，无论我们是否将在服务器端进行验证，我们都需要在客户端做可接受数据验证。

 

8：多层架构中的开发技巧

设计、维护、实现、部署在多层架构中是一项艰巨的任务。如果一开始没清晰的规划，那么有可能导致后期开发的时候会做无用功。这里有几点如下建议：

1，用一些松散耦合的技术，尽可能把层和层之间的关系解耦，比如soap xml或接口等。在面向对象中，每一个层仅仅依赖于它接口所直接实现的具体层，而不是通过内聚类。这样我们就可以尽可能的最大解耦，对于我们之后的开发会带来更大的好处，比如单元测试、维护、系统升级，可扩展和可靠性。

2，尽可能多的自动生成技术或对于整个系统，通过poco版本方式进行业务实体的维护。利用特性、分部类、DTO等方法。

3，利用一些自动工具或包进行实体映射在业务实体和传统的关系数据库之间。比如Entity Framework 和 NHibernate 等工具。

4，利用代码生成器。

5，我们应该尽量避免业务层与持久层的高度耦合，。比如，我们可以通过WCF业务服务来直接访问Entity Framework，这种情况很常见。但这样做有一个问题是，会把业务层和持久层进行高度耦合。而这种高度耦合会带来更多的问题。通常我们通过一种适配器来解决这种耦合，进而把高耦合变成松散耦合，他们仅仅通过接口来通信。

6，在客户表现层，我们把共同的代码抽象并封装，以达到通用的目的。

7，为了提高性能，往往要增加缓存。

8，为了适应需求的变更，良好的多层架构可以轻松应对部署的伸缩性和配置的灵活性。

 

9：结论

描述了多层架构的概念和定义，介绍多层架构中的典型代表——"三层架构"。并说明了一个完整的三层架构应该是表示层、应用层、数据层分别运行在单独的计算机中。并描述了三层架构和MVC架构之间的关系，应该是属于和被属于的关系。分析了多层架构的优势和劣势，在多层架构中的数据验证的重要性，最后说明在多层架构中可以用到的一些工具和技术技巧，谨记层和层之间的通信是通过接口来交互，而不是内聚类，那样才会做到开发时模块的高内聚和通信的低耦合。

这是学习了《N-Tier Architecture and Tips》这篇文章 所思考，如有理解错误，望不吝赐教。

原文参考： http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips

 

 

 

 

 

 

分类:  框架杂想

标签:  架构思想,  三层架构,  多层架构