实用体系结构：逻辑分层(2)

但结果是，人们发现了这些并发连接的一个有趣特性：对于大多数客户机/服务器应用环境而言，针对数据库所建立的连接大多数时间（95% 以上）都处于空闲状态，来等待要针对数据库所执行的请求。也就是说，瓶颈在于连接的数量，而不在于所执行的任务。这就说明，要增加数据库的可伸缩性，我们需要以某种方式增加通过这些连接所完成的工作量。因此，我们创建了一个过渡层，客户机通过连接该过渡层以多工方式向数据库传输请求。简单地说，如果数据库只能支持 100 个连接，而每个客户机连接被用去 1% 的时间，那么我们可以这样来增加数据库的可伸缩性：将 100 个客户机连接到中间服务器，这个中间服务器仅使用 1 个连接（总共 100% 的时间，每个客户端占 1%）来对数据库进行操作。瞧，可伸缩性增加了一百倍。真不错。

尽管如此，有多少应用环境真正需要这种可伸缩性呢？当然，在将企业应用环境带到最终客户群面前的情况下，这种可伸缩性可能时必要的。但许多应用环境（无论是否基于 Web）仍然是完全部署在内部的，这种情况下只有不到 100（有时少于 10）个客户机将同时访问系统。在内部小用户群应用环境中还需要 n（物理）层方法吗？

这时安全因素发挥了作用。对于运行在最终用户计算机上的应用程序（基于 Web 或“富客户机”），任何系统管理员或安全顾问都不可能推荐将包含关键任务数据的数据库直接放在防火墙的后面（例如，从在安全范围之外运行的计算机直接访问）。如果加入一个中间计算机并将另一个防火墙置于其后，可以创建通常称为隔离区或 DMZ 的区域，在其中可以进一步限制对数据库的访问。这样一个 DMZ 极大地巩固了安全基础结构，降低了成功渗透的可能性。这不仅可以防止数据被窃取，而且还有助于保护服务器（及剩下的应用程序或系统）免受成功的拒绝服务攻击。

使许多大型系统所有者青睐 n（物理）层系统的另一个因素是部署，即物理地将软件放入客户机所能访问的计算机的过程。在传统的客户机/服务器环境中，业务逻辑与表现逻辑和数据访问逻辑交织在一起，使编程人员感觉非常不舒服：每次需要新的更新时（例如需要更改企业对数据的处理方式或增加数据的新视图），位于用户桌面的“胖客户机”就必须更换并/或加入新代码。这就意味着，至少在这个时候，有人（通常是开发人员或系统管理员，两者中级别较低的一个）需要在各计算机之间奔走，来安装新代码。或者是要求用户从网络下载最新的代码。当然，大多数的用户不是忽略了这一点就是不能正确操作。这两种情况都不能使人们对频繁发布这种明智之举真正产生信任。而且部署是需要时间的，在这段时间内，系统必须暂停工作，以避免因混合版本的应用程序匆忙操作数据库而造成的任何类型的语义数据损坏。

这一部署因素在很大程度上影响着人们对 n（物理）层模型，特别是对基于 Web 的应用程序的青睐程度。现在，人们无需再将代码部署到各用户桌面，而可以将其部署到（单个）Web 服务器，最终用户的浏览器只需去选取这些更改，而这并不需要任何进一步的工作。就其本身而言，部署并不是铺开 n（物理）层系统的原因；在传统客户机/服务器应用环境时代所无法获得的一些备选方案现在已经加入可能部署方案清单中，这其中包括“无触式部署”（在 .NET 1.x 中）和 ClickOnce（在 .NET 2.0 中），更不用说人们对 AJAX 和各种混合式结构日益浓厚的兴趣。事实上，发布能在启动时进行自我更新的富客户机应用程序（如我们在 iTunes 软件管理器、Windows Media Player，甚至是流行的 .NET 开发工具 Reflector 中所看到的）已变得越来越普遍。

采用 n 个物理层的第三个原因经常会被人们所提到，但往往却不能真正实现，即中间物理层可以成为一些业务逻辑的集中点，这些逻辑可以由多个表现物理层访问，却不能为它们所知。关于这一点的典型例子就是组合式内联网/外联网应用环境，其中内部员工使用 WinForms（很快将升级为 Windows Presentation Foundation）应用程序来访问中间层系统，中间层系统进而再访问数据库，而外部用户（合作伙伴和/或客户）使用 ASP.NET 或者可能是基于 SharePoint 的 Web 站点来进行同样的操作：访问中间层，中间层进而再访问数据库。

这个想法尽管在概念上似乎非常简单，然而事实证明要从结构上来可靠地实现它是极其困难的。也因为这个原因，区分物理层和逻辑层越发显得重要。如果在表现（逻辑）层、业务逻辑（逻辑）层和中间（物理）层之间有明确的区分，就可能将业务逻辑层嵌入客户机（物理）层（如果是富客户机应用前端）并通过避免网络访问来大大节约性能。

但是，设计在两个不同（物理）层中使用的业务逻辑层是非常棘手的事情。这就意味着，业务逻辑（逻辑）层必须避免对于表现（逻辑）层或数据访问（逻辑）层是否共同位于同一（物理）层做出任何假定，这样一来就必须假定两者都不位于其中。具体来说，在针对实际上运行于中间（物理）层服务器上的远程业务对象执行数据绑定（通过 .NET Remoting）时，这足以毁掉一个应用程序。现在，每次属性访问和方法调用都是一次网络遍历，性能将会比…嗯…比构建出如此糟糕系统的结构设计师的信誉下降得还要快。

幸运的是，世界各地的结构设计师已经开始意识到“分布式对象”方法的危险性，现在时代的主旋律是“松散耦合”和“粗粒度通信”，而所有这些都需要以面向服务的结构体系方法的支持。与软件开发的其他方面一样，服务导向也有其自身的缺陷，但那是其他月份另一个专栏的话题。

作者简介

Ted Neward 是致力于高级企业系统领域的独立顾问，其客户群包括从“财富”500 强企业到只有 10 名员工的小型企业的各种企业。他是 Java 和 .NET 技术方面的权威，尤其在 Java/.NET 集成（进程内和 Web 服务等集成工具方式）、后端企业软件系统和虚拟机/执行引擎管道领域造诣颇深。

他自行或与他人合作编写了《Effective Enterprise Java》（有效的企业 Java）、《C# In a Nutshell》（Nutshell 中的 C#）、《SSCLI Essentials》（SSCLI 精华）和《Server-Based Java Programming》（基于服务器的 Java 编程）等书籍，他同时也是一些技术期刊的特约撰稿人。Ted 还是 Microsoft 体系结构方面的 MVP、BEA 技术指导、INETA 讲师、Pluralsight 培训师、各种会议的发言人以及各种 JSR 的成员。他与妻子和两个儿子共同居住在太平洋西北区，家中还有两只猫和八台 PC。

（责任编辑 火凤凰 sunsj@51cto.com  TEL：（010）68476636-8007）