中间件技术在系统设计规划方面的经验总结

一、中间件技术在系统设计规划方面的经验总结

1.1、中间件应用架构的选择

这种架构选择的焦点就是业务逻辑到底是放在前台应用中还是放在后台中间件应用中。其实，引入中间件平台的原因之一就是业务逻辑的集中管理，出现这种争论的原因主要是开发商对这种业务逻辑集中的理解不深，在应用设计的过程中仍然没有摆脱以前两层结构的影响，再加上因为业务逻辑集中会增加程序开发量，才出现了这种情况。我们认为，把业务逻辑集中在中间件服务器上不仅对于业务逻辑的集中管理有好处，而且对于系统的后期运行维护、软件的升级管理都有着明显的优势。当然,在开发的工作量方面，业务逻辑集中时工作量大很多。

1.2、中间件服务分布的设计和优化原则

在Tuxedo中，Server可以理解成为Unix的一个进程，Service可以理解成为应用进程Server中的一个函数。用户可以任意划分Server和Service：既可以把所有的Service放在一个单一的Server中，也可以采用“一个Service一个Server”的方式。Tuxedo对此没有任何限制。

中间件应用的性能直接影响到营业前台服务的稳定性和连续*，而影响中间件应用性能的因素除了硬件资源的保证、数据库响应时间、中间件应用软件本身的质量之外，中间件应用服务的分布也起着至关重要的作用。我们有着这样的一个例子，在前台进入收费界面的时候，应用程序需要调用一个SERVICE名字叫A，A分布在一个叫SA的server中，而SA中又包含着很多其他的在线统计的SERVICE B，结果造成了SA响应B调用的时候执行时间比较长，所有的SA都在执行SERVICE B ，前台请求SERVICE A得不到响应，收费的界面怎么都进不去，从而导致前台收费业务中断。这就是个典型的因为服务分布不当造成的系统故障。

我们在系统规划设计过程中遵循的一个最基本原则就是尽量将“类似的Service”**在一个Server之内。所谓“类似的Service”是指这些函数有相似的大小、执行时间、复杂度或者功能。我们来考虑一个极端的例子：假设一个Service A是完成非常简单工作的，它的平均执行时间是100毫秒。另一个Service B进行数据库的查询，它的执行时间可能长达20秒。如果将这两个Service**在一起使用，就会出现非常严重的后果。大家知道，操作系统的基本调度单位是进程。在一个进程中的Service执行是串行的。Tuxedo把发往同一个Server的请求交易包放在同一个消息队列中。当Service B在执行的时候，Service A的请求包必须在队列里面等待20秒以上才可能被执行，虽然它的执行时间仅仅100毫秒。这显然是不能容忍和应该避免的。

实际上，用户在设计和开发应用程序的时候，并不能完全估计出每个Service的执行时间和频度。所以对Server和Service的划分优化是在应用程序开发完毕后进行调整的。调整的依据就是在系统运行的时候记录每个Service的执行时间和频度，然后根据这些数据来进行优化调整。下面就是我们在实际当中获得经验的一些系统总结。

1、 区分Service的不同类型：是业务操作还是简单的数据访问

在中间件应用中的Service可以进一步细分成负责完成业务操作和负责数据访问的两种类型。在设计的时候，最好把这两种不同类型的Service区别出来。所谓完成业务操作的类型其实就是进行数据修改的操作，负责数据访问的类型其实就是进行数据查询的操作。但是在实际的系统运行过程中，凡是涉及到数据修改的操作过程中必然会有数据查询的操作，这种类型的操作也应该规整到第1种类型中去。

2、 请求/响应类型的Service要