Tuxedo应用设计指南v12.docx
- 文档编号:9403872
- 上传时间:2023-05-18
- 格式:DOCX
- 页数:27
- 大小:348.81KB
Tuxedo应用设计指南v12.docx
《Tuxedo应用设计指南v12.docx》由会员分享,可在线阅读,更多相关《Tuxedo应用设计指南v12.docx(27页珍藏版)》请在冰点文库上搜索。
Tuxedo应用设计指南v12
TuxedoDesignPattern
BEA(中国)系统有限公司上海办事处
二○○二年一月,上海
修订日志
日期
版本
作者
描述
2001-12
1.0
王玉亭
最初的第一版本
2002-01
1.1
王玉亭
重新调整框架,充实内容
第一章.导论
作为构建大规模的C/S应用系统的体系结构,三层构架已经得到实践的检验和人们的认可,成为企业关键应用的唯一可靠和成熟的选择模式。
Tuxedo作为三层架构体系结构中的关键部件-中间件,在各行各业发挥着越来越大的作用。
在本文中,BEA(中国)有限公司上海办事处把在帮助客户构建三层架构应用中所积累的经验进行总结,供客户在运用Tuxedo构建企业级关键大规模C/S应用系统时参考。
本文档作为论述Tuxedo的高级资料,需要读者初步掌握Tuxedo,有一定的使用经验。
企业应用框架架构的演变和发展
这一块需要好好重写,以下仅仅是原样
了解一个事物的最好方法是考察该事物的历史。
为了更清楚地理解中间件和Tuxedo,我们在这个章节中先对支撑企业关键应用系统的架构的历史演变作一个回顾。
毋庸置疑,随着信息技术的发展,越来越多的企业需要依靠信息技术系统来支撑它们的日常运转。
在大部分的企业中,它们的关键应用系统都是所谓的联机事务系统(OLTP:
OnLineTransactionProcessing),这类系统最常见的是民航的售票系统、银行的柜台系统、电信的计费系统等等。
OLTP系统往往具有如下的特点:
具有大量的用户,譬如成百上千个,这些用户的请求都是非常类似的。
每一个用户的请求称为一个交易,这些交易的输入元素是固定的。
每笔交易的时间一般都很短,传输的数据很少。
后端往往是由大型数据库来存储数据。
由于OLTP系统需要满足大量客户的交易请求,在一个良好的OLTP系统中必须解决系统的各种瓶颈问题,使得系统的性能达到最好。
当大量客户请求时,网络、应用和数据库往往都可能成为系统性能的瓶颈。
同时,作为企业关键的应用系统,OLTP系统必须追求更高的稳定性、更高的可拓展性。
OLTP系统的构架就是在解决这些问题的过程中不断从主机、两层C/S方式演化到目前的构建大型和超大型的应用系统的三层C/S方式的。
我们可以从下面这张图中看出这个历史演化过程:
在这个图上,从左到右表示时间的先后次序。
最早期的系统的构架是采用的一个主机带多个“哑”终端的方式。
所有的计算,包括访问数据库,商业逻辑、事务管理和终端的界面现实统统是由主机进行。
终端通过串行口和主机连接。
这样的主机往往是大型机,具有很强的计算能力。
这种体系结构造成随着终端数目的增加,主机需要将越来越多的资源用于终端的管理,决定了主机能连接的终端数据是一定的。
这种模式至今依然可以在一些大型机构中看到它们的影踪。
在OLTP系统架构方面具有革命意义的变革就是从上面的主机架构发展成为“客户机/服务器”(C/S:
Client/Server)模式。
在C/S模式中,最终用户作为客户端,并不是直接对数据库进行操作,而是把必要的数据打成数据包传送给后台的服务器,服务器中相关的部件执行操作、访问数据库,然后把最终的结果返回给客户端。
C/S模式具有如下的优点:
1.客户端不直接访问后端的数据库,提高的系统的吞吐量,使得具有同样计算能力的服务器可以为更多的客户端服务,而且每笔交易的时间缩短。
2.C/S模式使得客户端和服务端使用不同的机器,相互之间通过网络连接,可以跨越地理上的限制,符合企业的组织架构。
3.C/S模式的模块化更强。
数据库不受客户端的错误的干扰,有利于保护数据的完整性。
每个模块可以单独修改升级,不影响整体。
4.系统的可扩展性、可靠性增强。
随着系统规模的扩大,可以采用冗余等手段提高后台的计算能力和可靠性。
早期的C/S模式可以称为“两层”的C/S模式。
在这种模式中,客户端负责用户界面和商业逻辑的处理。
当需要访问后台的数据库的时候,客户端构造访问数据库的SQL语句,传递给后台的数据库服务器,由数据库服务器对SQL语句进行解析、执行,最后把结果返回给客户端。
“两层”C/S模式进一步的改进是将数据库访问密集的商业逻辑剥离出来,利用数据库管理系统提供的“存储过程”的功能,做成单独的存储过程模块,供客户端访问。
这种“两层”C/S模式带来的一些弊端,主要有:
每个客户端的请求都要有相应的数据库服务器分配资源为其服务。
由于数据库的连接是有限的,所以能同时“享受服务”的客户端的数据还是有限的。
网络上传输的是SQL语句和从数据库返回的数据,这些数据很多是不必要的,造成大量的网络堵塞。
例如:
客户端查询出10000条记录,但是可能只需要其中一条。
这10000条记录必须通过网络传输。
这个问题在客户端和服务器是通过带宽资源有限的广域网的时候尤为突出。
商业逻辑代码集中在客户端,使得客户端的程序臃肿不堪,维护和升级的成本会非常高。
为了解决这些问题,出现了大家目前熟悉的“三层”或者“多层”C/S模式,也出现了象Tuxedo这样的中间件。
事实上,“三层”C/S模式体系结构在实际上应用的是如此只好,以至于中间件的功能在不断扩展,发展成为现在流行的“应用服务器”(ApplicationServer)的产品。
应用服务器实际上站在应用软件的立场上考虑问题,把功能单一的操作系统给包裹起来了,使得在应用服务器上构建应用系统变得单纯和简单了。
目前几乎所有的应用系统都是构建在网络之上的,所以应用服务器又称为“网络操作系统”,它的概念内涵比“中间件”丰富得多了。
虽然如此,中间件所定义的“三层”C/S模式还是最基本的系统构架。
“三层”C/S模式把应用的商业逻辑和用户界面进一步细分。
客户端的功能演化成单纯的负责用户界面功能。
商业逻辑建立在中间件之上,进行纯粹的计算和数据库访问。
这种模式克服了“两层”C/S模式带来的以上诸多的问题,使得OLTP系统的性能、稳定性、可扩展性等进一步增强。
目前,以“三层”C/S模式为基本架构的企业关键应用已经得到实践的考验,称为构建大型企业关键业务系统的唯一可靠和成熟的选择。
关于三层架构的详细分析,我们结合对Tuxedo的介绍来详细讨论分析。
Tuxedo的历史发展
这一块需要好好重写,以下仅仅是原样
作为最开放的交易中间件产品和事实上的中间件标准,Tuxedo的历史是和开放系统的化身Unix的历史是紧密不可分的。
1969年,贝尔实验室的工程师KenThompson最初创建Unix的时候,Unix实际上是一个单用户的操作系统,就象MS-DOS一样,只不过它比DOS要强壮的多。
关于Unix的历史,读者可以从任何一本介绍Unix的书籍中获得,这里我们不多重复。
当多任务的功能加入到Unix以后,最初的Unix内核缺少一个非常重要的功能:
如何在不同的进程之间通讯。
这个功能主要是通过原始的管道和磁盘文件等拙劣的方式来满足的。
为了改进这个方面,Unix内核作为扩展的选项,加入了我们现在非常熟悉的“进程间通讯”(Inter-ProcessCommunication,简称IPC)。
IPC功能的引入完全是内部需要的驱动,而它的意义确实非常大的。
当初贝尔实验室开发Unix的一个目的就是想在实际的项目中使用这个操作系统。
当IPC引入到Unix以后,贝尔实验室的工程师们很快地围绕这个特性,建立了一套工具,并且把这套工具应用在AT&T的很多项目中。
这些工具就形成了后来的BEATuxedo的核心部分。
Tuxedo的最初形态是一些帮助用户构建不同进程间通讯的函数库。
这些工具在很多AT&T的著名的项目中得到了应用和实践的检验,非常可靠。
与此同时,AT&T内部开始产生了为Unix开发数据库的兴趣,因为当时没有商业化的数据库系统。
这些兴趣导致了AT&T的UNITS项目(UNITS是UNIXTransactionSystem的简称)。
这个项目产生了两个不同的产品:
DUX和TUX。
DUX(DatabaseforUniX的简称)为Unix实现了一个SQL数据库的引擎,该引擎为外部独立的事务管理器(TM:
TransactionManager)留了一些管理接口。
DUX后来变成了BEATuxedo的“/D”的部件。
但是由于其它商业数据库系统,例如Oracle、Sysbase、Informix的兴起,这个部件逐渐被废弃了。
TUX(TransactionsforUniX)是负责保证事务完整性的引擎,这个引擎后来演变成Tuxedo的“/T”部件,这是BEATuxedo的核心部件。
TUX也就成为了BEATuxedo的命名的来源。
在传统的数据库管理系统产品(如Oracel、Informix、Sysbase等)中,事务的范围局限在本地的一个进程内部。
这是数据库编程的一个基本假设,而且至今还是这个样子。
TUX和DUX是两个独立的产品,但是它们两个可以配合使用,并且引入了一个重要的概念:
分布式事务处理(DistributedTransaction)。
在分布式事务处理中,事务的范围突破了单个进程的限制。
每个进程是一个大事务的临时参与者而已。
TUX使用底层的消息传递机制来为应用开发提供了一个稳固的框架。
在这个框架中,TUX负责管理和跟踪应用的数据流,使得分布式事务的管理和监控对应用程序是透明的。
TUX和DUX配合使用,使得TUX的事务管理器TM能够做两件事情:
第一,TM负责通知DUX的数据库作为单个的参与者“参与”一个“全程”的事务;第二,TM在外部可以根据全局事务的状态来控制单个参与者的提交或者回滚。
TUX/DUX实际上提供了一个从应用程序角度来看待数据库的抽象的模型。
当商业数据库系统开始越来越流行的时候,TUX/DUX的接口被提交给国际标准组织X/OPEN,作为标准的TM和数据库的集成的工业标准。
经过少量无关大局的修改以后,这个标准,就是大家熟悉的XA标准,被大多数数据库系统支持,而且也得到了所有的“开放系统事务管理器”的支持。
这个最初发源于Tuxedo的标准成为所有交易中间件的标准,也是Tuxedo自豪的一个地方。
与此同时,TUX为开发和管理多任务的应用系统提供了一个非常良好的框架。
这个框架在很多AT&T的著名的大型项目中得到实践的检验和认可。
基于这个原因,除了它的分布式事务管理器的功能以外,BEATuxedo作为应用系统开发框架的价值也被迅速地认可。
随着时间的流逝,越来越多的关键功能被加入到BEATuxedo中来,这些功能包括:
基于LAN的服务器集群、不同的服务器可以参与全局事务、对大型机的支持、允许从远端的客户端发起全局事务、安全管理、对各种通讯模式的支持等等。
BEATuxedo越来越成为支持企业关键业务的多层应用的核心部件。
今天,经过十几年的发展和无数世界范围内的大型和超大型的应用实践的考验,BEATuxedo已经成为高性能的、具有艺术般品质的企业关键应用的引擎。
现在BEATuxedo已经可以支持超过80种的Unix平台,也支持Windows-NT/2000、Open-VMS等操作系统。
Tuxedo是基于C写成的,在保持其高性能和高稳定性的同时,作为BEA公司的旗舰产品,它紧跟着世界IT技术的发展潮流,已经开始支持Java、Web管理、CORBA等代表未来发展方向的技术。
Tuxedo作为传统中间件的代表,它的生命正在不断向前迅猛发展。
第二章.Tuxedo体系结构和设计思想
在本章中,我们将从体系结构的高度,系统地讨论Tuxedo的各个部件和蕴含在这些设计中的设计思想。
这一章主要解决“Tuxedo是什么”的问题,它的整体思路是从抽象的概念讨论到具体的技术细节。
每一部分自成一个体系,使得读者可以在较短的文字里面了解比较深刻,如果不能成章节的就归拢放在一部分
中间件需要解决的问题
这一块在<
原因是企业关键应用,需要解决如下的很多问题,这些是中间件(应用服务器)致力于解决的主要技术问题:
负载均衡
对应用程序透明的容错机制
后端的集成
事务完整性的保证
集群功能
动态的软件部署
CleanShutdown
日志和审计
系统管理
线程
面向消息的中间件
ResourePooling
安全
Cache
Andmuchmuchmore
Tuxedo整体结构考察
在这部分结合上面需要解决的目标,提出Tuxedo的整个系统框架图,使得读者对Tuxedo有一个更为全面的了解
Tuxedo的Server和Services
这里讨论Server和Services的问题
Services的类型:
Request/Response类型的Service
会话方式的Service
Servers的结构
这里阐述Server的结构类型
Tuxedo/Q
这一部分的写作思路是:
先介绍抽象的模型,然后介绍Tuxedo/Q的一些概念,然后再深入到技术细节去探讨管理和编程的内容。
第一部分论述Q的通讯模型,应用的例子
第二部分论述QueueSpaces和Queues的介绍,enqueuing和dequeuing的需要设置的参数。
第三部分详细论述Tuxedo/Q的管理
第四部分论述Tuxedo/Q的两个API的内容
第五部分论述Tuxedo/Q的应用举例
―――》 对于长时间甚至超长时间的查询,为了加快速度,采用Q的方式。
―――》对于跨广域网的全局交易,拆分成local的交易
Tuxedo的事务管理
这一部分的写作思路是:
先介绍抽象的模型,然后介绍Tuxedo事务的一些概念,然后再深入到技术细节去探讨管理和编程的内容。
DTP的基本概念,两阶段提交的基本概念,etc.
详细的细节讨论
应用举例:
Tuxedo/Q和数据库组成事务的应用的例子。
Tuxedo的会话机制
事件的订阅和发布
这一部分的写作思路是:
先介绍抽象的模型,然后介绍Tuxedo事件订阅发布的一些概念,然后再深入到技术细节去探讨
Tuxedo的错误处理
超时机制和状态码,异常句柄
Tuxedo超时机制
对Tuxedo的各种超时机制进行探讨,使得读者对Tuxedo的超时机制有全面的了解
Tuxedo的状态码
Tuxedo的管理框架
这里全面介绍Tuxedo的管理的设计思想,TMIB为核心。
管理的目标,TMIB,管理工具等等
Tuxedo管理的目标是什么?
什么是Tuxedo的应用?
Tuxedo的TMIB
Tuxedo管理工具
Tuxedo的CORBA
这里要介绍一下关于Tuxedo8.0的CORBA的体系结构等内容。
如何介绍?
?
?
其它
在这里论述一些小的方面的东西
Tuxedo的名字解析
Tuxedo的安全管理
Tuxedo高性能的设计思想评述
高性能方面,我仔细列举了以下,有如下内容:
Tuxedo的通讯是如何设计成高效的,Tuxedo的负载均衡的问题,Tuxedo的DDR,Tuxedo的线程和线程的自动派生,基于内存的Q,对XA的支持(6.5是10个TMS,7.1以后是256个TMS),Tuxedo的数据包的压缩。
还有哪些可以当做Tuxedo高性能的设计特色?
?
?
?
作为世界领先的中间件,高性能是Tuxedo追求的极其重要的目标。
利用Tuxedo构建的系统的规模和性能也屡屡突破世界记录。
Tuxedo应用系统中,支持的用户经常是上千个,甚至上万个。
按“交易/笔”性能来衡量,最高的指标达到每秒钟10000笔交易的规模。
下面我们从技术角度来考察一下Tuxedo在设计的时候是如何做到高性能的。
Tuxedo的通讯机制
Tuxedo的通讯分成四个部分:
Tuxedo/WS部分,Tuxedo内部Server之间的通讯(MSSQ,SSSQ,msg内核参数对性能的影响),Tuxedo通过BRIDGE和通讯,Tuxedo通过Domain的通讯。
这四个部分要分别论述,洋洋大观,能写很多。
通过这些论述,使得读者对Tuxedo涉及通讯的部分有一个比较深刻的理解,在设计系统的时候,当考虑到这些通讯方面的瓶颈的时候,能知道解决的原则和方法。
客户端的连接
Tuxedo服务器要面对成千上万的客户端的请求,同时并发的请求可能达到上千个。
第一个瓶颈就在如何处理这些大量的网络连接上。
Tuxedo负责处理客户端的网络连接主要有两个守候进程:
WSL(WorkstationListener)和WSH(WorkstationHandle)。
WSL负责在服务器的IP地址上的某个端口上侦听,等待即将到来的客户端的网络连接请求。
当一旦有来自客户端的网络连接请求后,WSL与之建立初步的网络连接,随后把这个网络连接通过共享内存传递给WSH进程,以后这个客户端和后台的交易请求都是通过WSH来进行的。
WSL进程和某个IP:
PORT绑定在一起,和它相联系的WSH进程可以由用户配置成多个,这些WSH进程实际上组成了一个“进程池”,随时准备处理客户端的请求。
另外,Tuxedo在网络连接上还提供如下的功能:
支持数据压缩和加密选项,使得大量数据包在网络上传输的时候能够有效地利用带宽。
这一点在广域网上尤其明显。
自动的数据格式转换。
由于客户端机器和服务器机器的体系结构可能存在不同,例如一个是Intel体系的PC,另一个是Sun的小型机。
为了使数据能够正确地解释,Tuxedo自动对数据进行了转换。
超时机制。
如果某个客户端和WSH建立连接后,长时间没有数据传输,WSH判定这个客户端的连接是IDLE的,会自动将起断开,保证有限的WSL/WSH资源能为更多的客户端服务。
Tuxedo的进程间通讯
Tuxedo的BRIDGE通讯
Tuxedo的Domain通讯
负载均衡
介绍负载均衡和DDR的概念,思想用法。
负载均衡的算法:
●本地优先
●Round-Robin
●最闲优先
线程的自动派生
Tuxedo/Q
介绍Tuxedo/Q的改进:
基于内存的Q等等
多线程
Tuxedo高可靠性的设计思想评述
读者通读了上面的内容,对Tuxedo整体有个了解后,这里是对Tuxedo的如何保证高可靠性的设计思想进行评述。
这一部分要重新写。
按如下组织:
通讯的可靠:
FailOver,包括客户端->后端,BRIDGE,DOMAIN之间的容错,都要论述一遍。
进程之间的监控:
采用软件心跳线的技术。
DBBL/BBL/ApplicationServer
事务的容错。
TUXEDO的运行管理机制提供了对软件错误的自动监控和修复功能。
每个物理的节点、网络连接、应用进程、客户端以及Tuxedo本身的管理进程(包括DBBL、BBL、BRIDGE等)都被自动监控起来。
而且当出现错误的时候,Tuxedo会自动尝试去修复这些错误,不需要管理员的人工干预。
Tuxedo的事件机制允许出现错误的时候有相应的事件被触发,而这些被触发的事件可以被应用进程所捕获。
这种机制进一步提高了的Tuxedo的监控能力。
当Tuxedo出现错误的时候,相应的信息被记录在Tuxedo的日志文件(ULOG)里面,可以供事后分析使用。
缺省的日志记录是每台物理机器每天产生一个对应本机的日志文件。
BEA的ManagerLogCentral可以统一管理这些分布式的日志文件。
下图表现了Tuxedo是如何自动对各个部件进行监控和错误恢复的。
节点之间的监控
DBBL进程定期向各个节点的BBL进程发送询问消息包。
各个节点的BBL收到该询问消息包以后,会向DBBL发送类似“IAMOK”的消息。
这种机制可以称作“软件心跳线”,类似硬件容错使用的硬件心跳线。
如果DBBL在询问某个BBL的时候没有得到该BBL的应答,则master节点将尝试去启动相应服务器上的BBL进程。
如果该节点上的BBL不能被启动,则该节点被标记为”partitioned”的状态。
当负责节点之间通讯的BRIDGE进程因为通讯超时而导致DBBL收不到BBL的回应的时候,也可能导致这种”partitioned”状态的出现。
由于DBBL无法确定节点分离的持续时间,所以被侦测到的处于partitioned状态的节点并不是自动从整个系统中脱离,Tuxedo会抛出一个系统事件表明这个事件的发生,并且会在日志文件里面做记录。
当节点分离是暂时的,例如由于BRIDGE通讯流量超过负荷而导致的,则DBBL和BBL的这种心跳连接稍后重新尝试,直到自动恢复。
这种情况往往发生在系统负荷太大(客户端请求太频繁),超过服务器的承载能力的情况下。
系统管理员可以在事后通过查阅系统日志来察觉这种情况的发生。
当问题非常严重,被分离的节点永久地和其它节点脱离以后,需要系统管理员通过管理命令(tmadmin中的pclean)将该分离节点从整个系统中脱离开来,其余节点会依然组成一个独立的系统,继续运转。
该分离节点上的服务不涉及到和其它节点通讯的时候可以继续为客户端提供服务。
除了DBBL对BBL进行检查以外,BBL会监控DBBL的状态,必要时也尝试去重新启动DBBL。
但是当DBBL无法启动的时候,就需要手工地将运行DBBL的master节点迁移到备用节点上(通过tmadmin的migrate命令)
进程的状态检查
BBL进程会定期检查运行在本地节点的进程(包括应用进程和其它Tuxedo系统进程)。
当有错误被检测到以后,TUXEDO会将正在进行的事务终止,必要的情况下根据配置重新启动应用服务进程。
这个时候,正在被处理的交易请求可能丢失,但是交易请求方会得到通知,以便采取适当的行动(例如:
重新发送这笔请求)。
等待在消息队列里面尚未被处理的交易请求包将在应用进程重新启动后继续得到处理。
当应用进程被重新启动的时候,用户可以指定让Tuxedo启动用户事先指定好的一个应用进程。
这种机制为客户提供了灵活的控制手段。
BBL也对客户端进程进行监控。
对于本地的客户端进程,BBL对其的监控和对应用服务进程的监控是一样的。
另外本地客户端进程有一个超时的概念,当超时发生的时候,BBL也认为客户端进程出现问题,会断开客户端和Tuxedo的连接。
对于远端的客户进程管理,BBL只能监控网络连接。
当在一定时间中,远端客户进程的网络连接处于不活动状态,则BBL会自动断开网络连接,需要远端的客户进程重新连接和登录。
网络连接
BRIDGE进程是负责提供各个服务器节点之间的通讯的。
根据用户的配置,一个BRIDGE进程可以维护多个网络连接。
这些网络连接被赋予不同的优先级别。
BRIDGE对这些网络连接的使用策略如下:
BRIDGE优先使用优先级最高的网络连接进行通讯。
当优先级最高的网络连接发生故障的时候,BRIDGE会自动选择优先级次之的网络连接进行通讯。
同时BRIDGE进程会定期检测优先级别最高的网络进程是否恢复。
一旦恢复,则BRIDGE会重新使用优先级别最高的网络连接。
如果正在使用的网络连接由于传输流量过大而发生阻塞情况的话,BRIDGE会启用优先级相同的另外一条备份网络连接进行网络传输,从而增大了网络传输的吞吐量。
在服务器配置多个网卡的时候,可以利用BRIDGE的这些特性将不同的网络连接配置在不同的网卡中进行,这样当某个网卡出现物理故障的时候,不影响Tuxedo的运行。
如果想利用BRIDGE的多条网络连接同时传输数据,增大网络流量,可以将这多条网络连接的优先级设置成为相同。
BRIDGE对网络通讯的监控是采用超时机制,当BRIDGE检测到超时发生的时候,它会尝试着重新建立网络连接。
如果某个节点的全部网络连接都无法和其它节点连接的时
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Tuxedo 应用 设计 指南 v12