N-tier architecture N层架构
N-tier architecture N层架构
下面的内容既有我的理解，也有翻译的内容，翻译的书名为：
<<Expert C# 2008 Business Objects >>http://www.douban.com/subject/3442908/
n层架构，包括两方面的架构。一方面是n-tier 的物理架构，一方面是n-tier的逻辑架构。笼统的说呢，物理架构就是计算机和其他辅助硬件的架构，要分层，目的是获得高性能Performance、高扩展性Scalability、高安全性Security、和高容错性Fault tolerance；逻辑架构指的是代码设计方面的架构，代码的分层，主要的目的都是方便我们开发人员的，主要好处：
l 使代码更有逻辑性
l 更加容易维护
l 更好的代码复用
l 更好的团队开发体验
l 更清晰的代码职责
在N-tier物理架构带给我们的好处中，高性能和高扩展性、高安全性、高容错性是成反比的，需要我们在设计的时候来衡量。其实，是层数越少，性能越高，减少了网络通信量，但是其他性能就会下降，其他性能如果高了，就意味着需要加加入更多的层，至少是增加验证，增加错误的处理，这些都会带来性能的损耗。
这就需要我们针对具体的客户环境进行设计，例如银行类系统，那么他的安全性好容错性当然要比高性能更重要，用安全来换取一些性能的损耗是值得的；但是某些要求实时性高，用户体验更重要的场合，安全的地位相对要低一些，要保证处理的及时性，保证网站或者系统的运行性能。
逻辑的n-tier架构，这里我引用CSLA.NET的设计，5-layer login architecture。
<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype>
五层的作用分别是
| Layer |
Roles |
| Interface |
向用户呈现信息和收集用户的输入 |
| Interface Control |
扮演用户和逻辑层之间的角色，将用户的输入交给逻辑层，然后将返回结果给用户 |
| Business Login |
提供所有的业务逻辑规则，验证，操作，处理和应用程序的安全保证 |
| Data Access |
扮演业务逻辑层和数据管理层的中间角色，包装和包含所有的数据访问技术、数据库和数据结构 |
| Data Storage and Management |
物理的创建、获取、更新和删除存储在持久存储中的数据 |
逻辑的五层可以分布在单一物理环境或者是多层物理环境，逻辑的一层可以分布在多个物理的一层，多个逻辑的层也可以分布在一个物理层中。
在两层的物理环境中，通常是将数据存储和管理层分离出来，也就是用单独的服务器安装MS SQL或者是Oracle这类数据库管理系统，使得数据库管理系统充分发挥它的作用。
两层物理架构中，MS SQL Server最多可以处理350人左右的并发请求。两层物理架构极大的提高了性能，但是他们不如三层物理架构的可扩展性好。一个好的原则是，如果你的并发用户超过50甚至到了100，你最好将数据访问层也分离出来，组成三层物理架构。
将数据访问层分离出来的另外一个原因是安全。因为数据访问层包含和数据库的直接交互，数据访问层所在的机器被数据库服务器所信任，与其将这种信任放在一个客户端机器上，不如将它独立在一个应用服务器中。这样用户的计算机就不会直接被数据库服务器信任，这样就增加了数据库服务器的安全。
前面讲过了，可以将一个逻辑的层分布在多个物理的层中，你可以将数据库访问层分布在一个应用服务器中，将业务逻辑层分布在客户端应用层和应用服务器层中。在.NET中，如果所有用户链接数据库都使用相同的用户ID和密码，你可以使用连接池来管理所有的用户。这样可以使用更少的数据库连接代替每个客户直接连接数据库服务器的做法。实际中这些需要依赖于应用的细节，但是这就意味着，两三个数据库连接可以支持150到200的并发量。
当然了，这么做，所有的请求都需要经过外部网络，这就增加了潜在问题（例如性能的下降）。这种性能的花销，换来了大的可扩展性，因为这种物理配置比2-tier可以处理更多的并发请求。
将业务逻辑层部署在客户端和服务器端，这种应用可以完全的发挥两端计算机的长处。一些验证和业务处理可以放在客户端计算机上，这样提供了丰富的、很好的客户交互体验，同时非交互性的处理也能在应用服务器上高效的运行。
如果设计的好，这样的架构可以支持上前用户的并发请求，同时提供足够的性能保证。
性能最优的web client
在WPF和WinForm应用中，通过较少物理层的数量来获得好的系统性能。但是，这类交换在web方案中就不一样了：在增加性能和可扩展性的同时，对于安全的花销，下面也将证明。
为了在web应用中获取最佳的性能，将大部分代码运行在一个单一机器的环境中是可取的。
接口层一定是物理分离的，因为他运行在浏览中，但是接口控制层、业务逻辑层、数据访问层可以运行在相同的物理机器上，同时处理。有时候，你会把物理存储也放在一起，但是这只适用于很小的应用。
上面的这幅图中展示的是最优的性能，同时可以获取好的可扩展性，因为web服务器可以使web服务器场的一部分，所有的web服务器运行相同的代码。
这种类型的安装提供了很好的数据库连接池，因为每台web服务器可以处理上百的请求，所有的数据库连接都在池中。
除非来自服务器场的连接占了主要地位，否则不需要分离出应用服务器，因为额外的应用服务器增加了物理的层，带来了可扩展性的同时也降低的性能。在这样的环境中考虑容错性是必要的，因为大量的应用服务器会出现点的失败。
高安全的web client
在前面我们已经讨论过，我们的许多项目规定web服务器不能直接访问数据库。Web服务器一定要运行在DMZ（军事隔离区）中，夹在外部防火墙和内部防火墙中。Web服务器一定会通过内部防火墙的一个服务和内部的数据库或者是其他系统进行交互。上图的虚线代码防火墙。
在winform的解决方案中，这种业务逻辑层部署在web服务器和应用服务器两层的方式带来很多的好处。
分离数据访问层，将它运行在一个分布的应用服务器中，增加了应用的安全。但是，这样做带来了性能损耗，这在前面已经讨论过了。这种配置大概会导致性能下降50%。从另外一个角度看，这种配置的可扩展性很好。比如说第一个web配置，你可以通过实现一个服务器场类提高可扩展性，每一个服务器都运行相同的接口控制层和业务逻辑代码。