再论架构――架构的前世与今生

[从兴公司 - 陈百平]

很多热心的同事对上期的《面对架构，我们准备好了么？》一文给回了反馈意见，使我获益良多。上文主要从项目管理角度讨论了架构，并建议在对架构没有充分认识前慎用架构。本文再次论述软件架构，看看其前生与今世，及其是如何发展的。希望大家透过此文对各种架构及其之间的关系有进一步认识。

大型机的年代，是个“美好”的年代，编程不需要考虑网络、多层架构等问题。但大型机昂贵的价格也限制了它的使用范围只在一些大的机构和企业。随着需求不断地增大，计算机性能不断地提高、价格不断地下降，小型机、pc server开始进入普通的机构和企业使用。然而，单个小型机或pc server在性能上是无法支持企业多用户应用的，于是一种所谓的分布式计算应运而生。这种分布式计算开始时是两层的C/S架构。它在用户的机器上需要部署客户端（即Client），客户端除了需要完成与用户的交互之外，还需要完成业务逻辑计算；后端是服务器（即Server），提供数据存储服务。这种方式的缺点是部署与维护困难。当需要改变业务功能时，需要更改各个用户端上的程序。用户数少时缺点还不是很明显，但对像移动这样全省有几千台用户机器的应用来说，一台台去更改则是一件不现实的事情。

于是，到了上世纪的90年代中后期，C/S架构开始扩展，从两层拉伸为三层架构。三层架构中，将业务逻辑计算从客户端独立出来，并放置在后端的服务器上，客户端只有用户界面，没有业务逻辑。于是，功能的维护就相对变得简单了。一般情况下当需要改变业务逻辑时，只需变动业务层，客户端无需变更。维护强度急速地下降。但另一方面，问题也接踵而来：两层时，客户端与数据库服务器的通信由数据库驱动完成，在三层中客户端与业务逻辑服务器的通信如何完成？很多都采用了通过socket和自定义的协议进行客户端与服务端的通信。但是，在网络环境中这种基于 TCP/IP的socket通信又不是十分的稳定，换一句话说，需要开发一个十分稳定的socket通讯机制需要投入大量的时间与资源，普通的公司都没有这个能力和魄力。于是一些跨国公司开始在国内营销它们的中间件产品，如IBM的MQ，IBM的 CICS和BEA的TUXEDO等。

IBM 的MQ是一个消息通讯中间件，完成数据交换功能，适用于频繁的数据传输中。IBM的CICS和BEA的TUXEDO则是交易中间件，它不但包含了数据传输功能，更重要的是它提供了强大的全局事务管理能力，通过两阶段提交保证了在分布式数据库环境下的数据完整性。交易中间件也有一个架构的概念。例如，以 TUXEDO中间件构建的程序实例称为一个服务器（Server），用户编写的每个业务逻辑称为服务（Service）。我们会发现，其实这就是EJB的前生。TUXEDO中的Server类似于EJB容器，负责安全、通信、调度和事务处理等功能；Service类似于EJB，只专注于业务逻辑。

但这些中间件还是面向过程的，不是面向对象的。八十年代末到九十年代是一个面向对象很热的年代，于是面向对象中间件CORBA(The Common Object Request Broker Architecture:通用对象请求代理架构)就出现了。不管从技术概念还是商业模式上，CORBA与EJB都很类似。从技术上说，CORBA与 EJB都是面向对象的，有着对象级的数据通信机制、事务处理、调度等，并且有着容器统一管理服务对象，CORBA中称为ORB(Object Request Broker对象要求代理)，EJB中就为EJB容器了。从商业模式上看，大家都以靠卖容器来盈利。

与CORBA竞争的还有微软的COM/DCOM组件技术。COM/DCOM技术加上微软MTS（Microsoft Transaction Server，事务服务器）也完成了组件之间的数据传输、事务处理等功能。COM/DCOM没有独立的容器概念，因为它已融入操作系统中了。COM /DCOM提供了更为简单稳健的分布式组件计算系统，但它只能局限于Window运行。

因为看见BEA、IBM等公司从中间件市场获取了大量的回报，SUN公司也要插足中间件市场。于是J2EE出现了。J2EE出现有它的必然性。虽然三层的C/S架构用得很好，但它的前端还是需要部署客户端应用程序，中间需要部署第三方的中间件，而这种中间件产品又是不规范的，各自的产商有自己一套的架构。也就是说，我们的应用必须与中间件紧密的捆绑在一起。而J2EE则有着官方的规范，所有的J2EE应用服务器遵循统一的标准。

在J2EE中，客户端是浏览器。而中间业务层，SUN说是 EJB容器及容器里的EJB。后面数据层为数据库，基本上没有变化。其实，如果算上web层，则一共是四层。与三层的C/S对比，可以发现，C/S中的客户端被浏览器取代；C/S中客户端应用与服务器的中间件通信被HTTP标准协议取代；C/S中的Service服务被EJB取代。下面就客户端、业务层及数据层分别做讨论。

C/S时代的客户端界面是很容易开发的，页面视图之间的关联跳转都是基于window的事件，而这种事件与视图之间的关系的管理则由集成开发工具IDE负责，如DELPHI，VB等。在J2EE中情况就变得复杂。因为JSP页面之间的松散的关系，加上并没有集成开发工具能管理与维护JSP页面之间的事件关联关系（在这方面.Net做得比较好），于是涌现出很多所谓的MVC架构来解决这个问题，如Struts、 Tapestry和JSF等。

J2EE业务层的EJB容器设计相对复杂化了。刚才提到，交易中间件完成了两件很重要的事情：一是提供了稳定的数据传输通道，二是提供了全局事务管理的功能。而现在数据传输已由HTTP提供，`EJB容器可以大展身手的只剩下事务处理。连SUN的官方EJB文档也是这么说的：The EJB architecture is a component architecture for the development and deployment of component-based business applications. In particular, EJB provides a programming model for components that access transactional resources. 即EJB提供了一个用于访问多个事务资源的组件编程模型。注意，这里的resources是一个复数。这也就是说，如果是单个数据库的话，我们就没有必要使用EJB了，因为单个数据库压根就不会用到两阶段提交的事务模型。在单数据库环境中，自己进行事务控制是很简单的。但是如果去掉了容器全局事务控制，应用服务器又是一个不值钱的东西，因为没有全局事务控制的应用服务谁都能做，没有技术门槛。因此各大应用服务器产商不断的鼓吹EJB的好处，好让大家花钱购买一些用不上的功能。正是大家看到了EJB大而无当，于是就有了与EJB容器竞争的所谓轻量级的Spring、PicoContainer 等架构。

C/S时代的数据层也是很容易开发的。特别是那些使用了IDE厂商或数据库厂商提供的数据访问控件来访问数据层，基本上都是不用写数据库代码。而到了J2EE，因为没有相应的工具，在这一层又衍生出一系列的架构，如IBATIS、HIBERNATE、JDO等。

最后提一下J2EE另一个技术JMS（Java Message Service, Java消息服务）。JMS是BEA、IBM等中间件公司互相角力并妥协后得出的规范，对谁都不是十分的有利。再且IBM、BEA的消息中间件产品是十几年、乃至二十几年前的产品，并不是为J2EE而生的，因为需要保证向下兼容，它们的核心是不会有大的改动的。因此使用在J2EE环境下，不但性能上不去，BUG也多多。

总的来说，架构并不是很深奥的技术，有着它自己一套发展的规律。说了这么多，那到底如何选择架构呢？我认为只要简单好用就行。换一句话问：我们公司的核心竞争力何在？不是在架构。架构是比较系统和基础的软件产品，我们现在还没有能力引领架构的发展。我们的长处是了解客户的需求，比客户更了解客户的业务，从而开发出优秀的业务系统。

假如问：作为全国软件行业百强之一，我们的责任何在？如果我们真的要考虑这个问题，那架构的来生确实是值得我们关注和研究的。

软件架构（Architecture）和框架（Framework）不能混为一谈，
框架是一种特殊的软件,典型地，框架是系统或子系统的半成品,是为了更好的开发软件，是对开发方法，开发习惯，开发技术等进行一种共性和通用性的提取，并保留足够的扩展性，从而形成的一种特殊软件产品，而架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的技术，层次，子系统及各部分之间的静态结构关系和动态交互关系等,因此架构和框架是不同的概念，在架构定下后才能谈得是框架的选取和开发。

好的框架不应当排斥，同时也应当在公司内部自已要有所积累。

2006-11-2 17:03:09 [投一票] 目前票数：0
陈百平 1楼

对于架构与框架的详细区分，可以参考http://imcc.blogbus.com/logs/2006/10/3741345.html。

作为程序员，我一般不去区分架构与框架概念上的区别。正如楼主所说的，很多人不细分架构与框架的区别，再加上这两个词在我们软件行业已经用滥了，大家也就更分不清了。比如说EJB，是架构呢还是框架呢？多数会说是EJB架构，很少人会说系统采用了EJB框架。

如果细想一层，会发现软件中的一个框架往往是实现了一个架构，两者紧密相关。如J2EE实现了B/C架构。因此说到J2EE，人们自然会联想到B/C架构，而不是C/S架构。可能也因为如此，我们都喜欢说是系统采用J2EE架构，这样说大家都明白。如果分开说反而累赘了：我们的系统采用了B/C架构，并使用J2EE框架实现的。

注：以上文章版权归立信集团《沟通》所有，不得转载、引用。