（计算机应用技术专业论文）分布式服务平台架构设计与实现.pdf

硕士论文分布式服务平台架构设计与实现 摘要 随着业务的发展和集成度的进一步提高，用户数量和应用服务数量在大规模集成应 用环境中具有显著的动态性和很强的增长趋势，这对系统提出了更高的伸缩性和可控性 要求。“同时提供多种应用服务并及时响应大量请求”是单机所无法胜任的。为解决单 机的性能瓶颈问题，系统需要一种兼具通用性和灵活性的分布式架构。 本文在分析和研究面向对象的中间件技术和面向服务体系结构的过程中发现了他 们共性的基础结构：软总线。在此基础上，本文展开如下研究与设计： 通过分析基于数据库、基于组件和基于a g e n t 等三种较为流行的总线方案，并 比较了并发体系下基于任务和基于消息的两种总线模式，确定了采用基于消息的软总线 模式，提出了一种基于消息总线的分布式架构模型，设计并实现了一个分布式服务平台。 针对大规模应用环境，在应用服务规则分布的情况下，提出基于分布式服务平 台的服务路由模式。该模式采用多消息总线分担服务的方式来满足应用服务规则分布情 况下，系统的持续扩充需求；在设计服务路由表的基础上，给出了消息总线的多种组合 方案；引入服务掩码思想，进一步优化了服务路由表，提高了效率。 借鉴p 2 p 搜索技术，提出基于d h t ( c h o r d ) 的应用服务定位策略，解决了大 规模分布式网络中服务不规则分布下的查找问题。本文通过分析不同p 2 p 网络结构的特 性，确定选择完全分布式结构化拓扑组织多个消息总线；然后分析了适合完全分布式结 构化p 2 p 网络下的搜索算法：c h o r d ；最后，针对大规模网络环境下应用服务不规则分 布的情况，提出虚节点的概念，通过c h o r d 算法进行应用服务定位。 在l i n u x 系统下，测试了平台的性能，并通过电信运营系统的应用，验证了分 布式服务平台设计的有效性。 论文的研究成果对于有实时性要求的大规模分布式系统的构建具有借鉴意义。 关键词：分布式，软总线，服务平台，服务路由，服务定位 他s t a c t 硕十论文 a b s t r a c t w i t ht h ed e v e l o p m e n to fb u s i n e s sa n df u r t h e re n h a n c e m e n to fi n t e g r a t i o n ，t h en u m b e ro f u s e r sa n da p p l i c a t i o ns e r v i c e ss h o w sar e m a r k a b l ed y n a m i cc h a r a c t e r i s t i ca n di n c r e a s i n g 龋陆di nt h el a r g es c a l ei n t e g r a t i o na p p l i c a t i o ne n v i r o n m e n t ，w h i c hr e q u i r e st h es y s t e mt o h a v eb e t t e rr e t r a c t i l i t ya n dc o n t r o l l a b i l i t y t h es t a n d a l o n es o l u t i o n sa r en o ta d e q u a t ef o r p r o v i d i n gs i m u l t a n e o u sm u l t i p l ea p p l i c a t i o ns e r v i c e so rt i m e l yr e s p o n s et oh i 曲d e m a n d s a n e f f i c i e n ts o l u t i o nt ob o t t l e - - n e c ko ft h es t a n d - a l o n ei st oc o n s t r u c tad i s t r i b u t e ds y s t e m f r a m e w o r kw h i c hi su n i v e r s a la n df l e x i b l e b a s e do nt h er e s e a r c ho fo b j e c t - o r i e n t e dm i d d l e w a r et e c h n o l o g ya n ds e r v i c e o r i e n t e d a r c h i t e c t u r e ，ac o m m o na r c h i t e c t u r e ，w h i c hi ss h a r e db yt h em a j o rs e r v i c es y s t e m s ，i s i d e n t i f i e d ：t h es o f t w a r eb u s r e s e a r c ha n dd e v e l o p m e n ti sc o n d u c t e di nt h ef o l l o w i n ga r e a s ： 1 c o m p a r i s o no ft a s k - b a s e db u sp a t t e m 、历t hm e s s a g e b a s e db u sp a t t e r na n da n a l y s i so f t h r e ep o p u l a rb u sm o d e s ：d a t a b a s e b a s e db u sm o d e ，c o m p o n e n t - b a s e db u sm o d e ，a n d a g e n t - b a s e db u sm o d e w ed e c i d et ou s em e s s a g e b a s e db u sp a t t e r n ，a n dt h e ni n t r o d u c ea m e s s a g e b a s e dd i s t r i b u t e da r c h i t e c t u r e ad i s t r i b u t e ds e r v i c ep l a t f o r mh a sb e e nd e s i g n e da n d i m p l e m e n t e d a sw e l l 2 a l l u d i n gt ot h el a r g e s c a l ea p p l i c a t i o ne n v i r o n m e n t ，t h ed i s s e r t a t i o ni n t r o d u c e sa d i s t r i b u t e ds e r v i c ep l a t f o r mb a s e ds e r v i c er o u t i n gm o d ew h e nt h ea p p l i c a t i o ns e r v i c e sa r e r e g u l a r l yd i s t r i b u t e d 3 u s i n gp 2 pa sar e f e r e n c e ，t h ed i s s e r t a t i o nb r i n g sf o r w a r dal o c a l i z a t i o ns t r a t e g yo f a p p l i c a t i o ns e r v i c eb a s e do nd h t t op r o v i d eas o l u t i o nt ot h el o o k u pp r o b l e mo fl a r g es c a l e d i s t r i b u t e dn e t w o r kw h e ns e r v i c e sa r ei r r e g u l a r l yd i s t r i b u t e d 4 s y s t e mp e r f o r m a n c eh a sb e e nt e s t e d u n d e rl i n u xe n v i r o n m e n t t h ed e s i g n p r i n c i p l e so fd i s t r i b u t e ds e r v i c ep l a t f o r ma r ep r o v e nt ob ee f f e c t i v ev i aa p p l i c a t i o no ft e l e c o m b u s i n e s ss u p p o r t i n gs y s t e m a c h i e v e m e n t so ft h ed i s s e r t a t i o nc a nb eu s e da sr e f e r e n c ei nc o n s t r u c t i n gl a r g e - s c a l e r e a l t i m ed i s t r i b u t e ds y s t e m s k e y w o r d s ：d i s t r i b u t e d ，s o f t w a r eb u s ，s e r v i c ep l a t f o r m ，s e r v i c er o u t i n g ，s e r v i c e l o c a t i o n l i 硕士论文 分布式服务平台架构设计与实现 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 2 2 2 2 4 图2 图2 图2 图2 图2 图2 图2 表2 图2 表3 4 2 5 1 1 5 2 1 5 2 2 5 2 3 5 3 1 5 4 1 5 5 1 5 6 1 1 1 1 表3 1 1 2 图3 1 1 1 图3 1 1 2 图3 1 。1 3 表3 1 2 1 表4 1 1 表4 图4 图4 图4 表4 1 2 2 1 2 2 2 3 2 5 图表目录 o m a 参考模型示意图4 对象请求代理的体系结构示意图一5 c o r b a 接口库与实现库示意图5 j a v a 远程方法调用( r m i ) 的体系结构示意图6 e j b 组件与e j b 容器关系示意图8 删s 点对点消息风格示意图9 j m s 发布订阅消息风格示意图9 s o a 的体系结构1 0 s o a 组件关系示意图1 1 基于任务的并发体系示意图1 3 基于消息的并发体系示意图1 4 分布式服务平台架构示意图1 5 分布式服务平台模块示意图1 6 m g c ( a p p ) 逻辑结构示意图1 7 m g c ( a p i ) 逻辑结构示意图1 7 m g c m e s s a g e 结构示意图一18 分布式服务平台处理流程示意图1 9 无状态服务与有状态服务对比2 0 应用服务t a s k h a n d l e s o c k e t b r o k e nu m l 示意图2 1 i p v 4 路由表结构一2 4 m g c 路由表结构2 5 m g c 直接互连示意图2 5 m g c 星型互连示意图2 5 m g c 混合模式互连示意图2 6 m g c 路由表结构示例2 7 p 2 p 定义2 9 p 2 p 与c s 对比3 0 集中式p 2 p 网络示意图3 0 完全分布式非结构化p 2 p 网络示意图3 1 混合式p 2 p 网络示意图3 2 四种p 2 p 网络结构性能比较3 3 v 1 2 3 4 5 6 7 1 2 1 图图图图图图图图图图 图表目录 硕士论文 图4 3 1 图4 3 2 图4 3 3 图5 2 1 图5 2 2 图5 2 3 图5 2 4 图5 3 1 图5 3 2 图5 4 1 图5 5 1 图5 7 1 1 图5 7 2 1 图5 7 2 2 图5 7 2 3 图5 7 2 4 图5 7 2 5 图5 7 2 6 表5 7 3 1 c h o r d 环示意图l 。3 4 c h o r d 环示意图2 3 5 c h o r d 环示意图3 一3 5 消息转发测试截图1 4 1 消息转发测试截图2 4 2 消息转发测试截图3 4 3 消息转发测试截图4 4 4 连接保持测试截图1 4 6 连接保持测试截图2 4 7 数据压缩测试截图4 8 数据吞吐测试截图4 9 电信运营平台逻辑架构示意图5 0 电信运营平台账户查询部分截图5 l 账户过滤消息对象u m l 示意图5 2 电信运营平台参数设置部分截图5 4 告警金额为1 0 元时，账户管理部分截图5 5 调整告警金额为2 0 元时，系统参数部分截图5 6 告警金额为2 0 元时，账户管理部分截图5 9 系统配置与电信运营平台性能指标5 9 声明 本学位论文是我在导师的指导下取得的研究成果，尽我所知，在 本学位论文中，除t ；o n 以标注和致谢的部分外，不包含其他人已经发 表或公布过的研究成果，也不包含我为获得任何教育机构的学位或学 历而使用过的材料。与我一同工作的同事对本学位论文做出的贡献均 已在论文中作了明确的说明。 研究生签名： 如8 年多月琴日 学位论文使用授权声明 南京理工大学有权保存本学位论文的电子和纸质文档，可以借阅 或上网公布本学位论文的部分或全部内容，可以向有关部门或机构送 交并授权其保存、借阅或上网公布本学位论文的部分或全部内容。对 于保密论文，按保密的有关规定和程序处理。 研究生签名： 如8 年占月咖 硕士论文 分布式服务平台架构设计与实现 1 引言 1 1 课题的研究背景 传统系统基于“人的实时 工作而设计，受到人的耐性的限制，今天，越来越多的 系统开始运行于“计算机的实时”环境下，唯一的限制是计算机和网络的速度。例如新 一代电信运营系统，就具有适应日益众多的业务并满足大量客户端连接的迫切要求，这 些系统需要更高的带宽以便提供更多更复杂的服务，同时需要更快的信息响应速度以改 善用户体验。在人类社会生活的其他方面也出现了类似的需求，比如医疗系统、网络监 控系统、运输系统，以及其他关键基础设施系统。 计算机硬件的快速进步，大幅提升了单机性能，同时，随着社会日益发展，各种应 用服务也变得日益复杂，但“同时提供多种应用服务并及时响应大量请求”仍然是单机 所无法胜任的。为解决单机的性能瓶颈问题，学术界开始考虑将系统向分布式、集群方 向发展，这需要一种兼具通用性和灵活性的分布式架构。 1 2 国内外相关技术研究现状 目前，成熟的分布式软件系统大都采用面向对象的中间件技术。具有代表性的有 o m g 组织的公共对象请求代理体系结构( c o r b a ) 、s u n 公司的企业级j a v a b e a n s ( e j b ) 和m i c r o s o f t 公司的分布式组件对象模型( d c o m 、c o m + ) 等。大多数面向对象的模型 需要依赖具体的编程语言，是一种紧耦合的体系结构。近几年出现了面向服务体系架构 ( s o a ) ，这是一种基于消息的、松耦合的软件体系结构，由各自独立的可复用的服务 去构成系统功能【l 诏】。 虽然s o a 的概念很有新意，但国内在具体方向上的研究尚存在几个问题： 认识上的局限性：s o a 是对o o a 的彻底颠覆。面向服务的体系结构是在面向对 象体系结构的基础上扩展的，从技术层面看它们的关注点是不同的，前者注重服务间的 交互，后者注重实现功能的技术组件。 研究上的局限性：过多的讨论s o a 的架构本身和各种实现技术，忽略了架构建 模和具体实现部署等深层次实践。 1 3 论文的主要工作 1 分析了面向对象的中间件技术和面向服务的体系结构，得出分布式系统的共性： 软总线；通过对比基于数据库、基于组件和基于a g e n t 等三种较为流行的总线方案，并 比较了并发体系下基于任务和基于消息的两种模式；提出了基于消息总线的分布式服务 l 引言 硕士论文 平台架构方案，该方案有效降低了系统各模块间的耦合度，提高了模块复用性，增强了 系统的灵活性，降低了开发和维护的成本： 2 针对大规模应用环境，提出了应用服务规则分布下，基于分布式服务平台的服 务路由模式：并通过p 2 p 技术分析，提出基于d h t ( c h o r d ) 的应用服务定位策略，解 决了大规模分布式网络中服务不规则分布下的查找问题；这些设计增强了系统的实时性 并有助于提高网络带宽利用率： 3 在l i n u x 系统下测试了平台的消息转发性能、连接保持性能、数据压缩性能以 及数据吞吐性能，并通过在电信运营系统中的应用，验证了分布式服务平台设计的有效 性。 1 4 本文的组织结构 本论文的章节安排如下： 第一章引言，介绍了本论文的研究背景和意义、国内外相关技术现状以及论文的 主要研究内容。 第二章服务平台架构，通过分析面向对象的中间件技术和面向服务体系结构，归 纳出它们共有的总线思想；通过多种软总线方案的对比，确定采用基于消息的总线模式 并提出了分布式服务平台架构模型及其详细设计。 第三章针对大规模应用环境，提出了应用服务规则分布情况下基于分布式服务 平台的服务路由模式。 第四章通过p 2 p 技术分析，提出基于d h t ( c h o r d ) 的应用服务定位策略，以解 决大规模分布式网络中服务不规则分布下的查找问题。 第五章平台性能测试及其在电信运营系统中的验证，在l i n u x 系统下对平台的消 息转发能力、连接保持能力、数据压缩能力和数据吞吐能力进行了全面测试；通过在电 信运营系统中的应用，验证了分布式服务平台设计的有效性。 第六章对全文工作的总结和对未来工作的展望。 硕士论文 分布式服务平台架构设计与实现 2 服务平台架构设计 在计算机硬件技术与网络通信技术的支持下，应用需求驱使计算机软件的规模与复 杂性不断增长。面对这种情况，对整个软件系统的体系结构进行分析和设计的重要性远 远强于对算法与数据结构的选择。软件体系结构( s o f t w a r ea r c h i t e c t u r e ) 所关心的是整 个软件系统的结构，它决定了一个软件系统由怎样的组件构成，以及这些组件间的交互 关系。 2 1 面向对象的中间件技术 当前，面向对象技术已经渗透到软件开发的每一个角落，成熟的分布式软件体系结 构大都是客户机服务器风格与面向对缘风格的有机结合，典型例子如：o m g 组织的公 共对象请求代理体系结构( c o r b a ) 、s u n 公司的企业级j a v a b e a n s ( e j b ) 和m i c r o s o f t 公司的分布式组件对象模型( d c o m ) 等【l 5 ，6 ，7 1 。 c o r b a 是o m g 早期最具影响力的规范集，它保证了应用程序的可互操作性以及 对于计算机硬件、操作系统、网络结构与通信协议、编程语言等平台的无关性。o m g 发布的一系列中间件规范均基于对象管理体系结构o m a ( o b j e c tm a n a g e m e n t a r c h i t e c t u r e ) 这一概念框架，c o r b a 也不例外。o m a 对象模型定义对象外部可见的、 独立于具体实现的语义，o m a 参考模型则标识组成o m a 的组件、接口与协议。参考 模型的核心组件是对象请求代理o r b ( o b j e c tr e q u e s tb r o k e r ) ，它支持客户程序与对象 实现在一个个分布式环境中通信。o r b 仅为分布式对象提供了最基本的通信枢纽设施， 在开发实践中可以提取各类对象中的共性，通过抽象并标准化为对象服务、公共设施与 领域接口。这些标准化工作主要针对对象接口而不是对象实现。 o m a 参考模型中o r b 组件与其他四类对象接口之间的关系如图2 1 ，1 所示。应用 接口是与特定应用问题有关的非标准化接口，必须由开发人员自己编写；领域接口是与 具体应用领域有关的接口；对象服务是基于面向对象的中间件技术的所有应用程序都可 能用到的通用服务的接口：公共设施是可用于大多数应用领域的、面向终端用户的工具 类接口，它与对象服务的主要区别在于对象服务更加基本，两者的共同点是同属于计算 机领域而不是应用领域。 为提高分布式对象的平台无关性和互操作性，o m a 参考模型分离了对象接口( 对 象结构与行为的外部可见的规格说明，采用接口定义语言i d l 描述) 与对象实现( 对 象内部的具体数据表示与可执行代码，同一对象接口的对象实现可以采用不同的程序设 计语言来编写) 。 从软件体系结构的角度看，o m a 的各个组件形成了一种层次设计风格，位于最上 2 服务平台架构设计硕士论文 暑篓嘉鬟用e l 问题i 磊塞冒领域有关i 通用设施的接口有关的接l 的接口l o 对象 。 被包装为对象的非面向对象应用 图2 1 1o m a 参考模型示意图 层的是应用接口，一往下依次是领域接口、公共设施和对象服务，底层是对象请求代理。 在这一层次结构中，上层组件可跨层调用底层组件，例如：开发人员编写应用接口时， 既可以直接调用领域接口与公共设施提供的可复用接口，也可以直接调用对象服务提洪 的可复用接口。 c o r b a 体系结构与规范建立在o m g 的对象模型基础上，主要由三个关键部分组 成： 作为分布式对象通信基础设施的对象请求代理o r b 的体系结构； 接口定义语言i d l 的语法和语义以及到各种程序语言的映射： 保证互操作性的标准o r b 间通信协议g i o p i i o p 。 对象请求代理( o i 强) 是o m a 的核心基础设施，由其提供的通信机制负责完成查 找请求的对象实现、让对象实现准备好接收请求、传递构成请求的数据等任务。客户程 序看到的对象接口完全独立于对象实现所在的位置、编写实现对象的程序设计语言以及 在对象接口中未反映的其他特性。 为调用对象实现的一个实例，客户程序必须首先获取一个对象的引用。客，、程序发 出远程调用的方式与本地调用类似，差别只在于获得的是远程对象实例的引片j 向已。对 于远程对象引用的调用，o r b 负责将参数扣包并通过网络传递给远程对象所存的o r b ， 4 硕士论文分布式服务平台架构设计与实现 由此o r b 将参数解包后再将调用请求转发给对象实现的一个实例。 o r b 提供的最初基本功能是从客户端程序向对象实现传递请求，这是一个双向的 通信，包含送出实际参数与送回处理结果两个部分。在逻辑上，o r b 可理解为一个由 o r b 接口定义的服务集合，但物理上o r b 通常不必实现为一个单独的组件，如进程或 程序库。o r b 内核( o r bc o r e ) 是o r b 中最关键的部分，真正负责传输请求。 l 二j对于所有o r b 实现都相同的接口 圆可能有多个对象适配器 巨薤渤每一个对象类型都有桩和框架 阿甲7 了1 匕。圳依赖于o r b 具体实现的接口 图2 。1 2 对象请求代理的体系结构示意图 图2 1 2 展示了o r b 体系结构的主要组件以及它们的关系，其中o r b 接口、动态 调用接口、动态框架接口等标准化接口在c o r b a 规范中均以i d l 定义。 图2 i 3c o r b a 接口库与实现库示意图 三 八u n u 2 服务平台架构设计硕士论文 图2 1 3 展示了客户程序与对象实现如何有效地组织和利用对象接口与对象实现的 有关信息。 客户对象1 。远程对象1 j n ：重 占位程序桩 l骨辛网 l i 。通一 “ 厂”_ 一 l ， i 远程引用层 l i _ 一一 传输层 l 图2 1 4j a v a 远程方法调用( r m i ) 的体系结构示意图 对比上述三图不难看出o r b 与j a v ar m i 的相似性，其中客户程序桩和对象实现框 架与j a v ar m i 中的作用相同，但o r b 的体系结构显然比j a v ar m i 更复杂、更完善。 o r b 不仅提供动态调用方式，还支持采用不同程序设计语言编写实现对象。 o m g 致力于解决分布式应用程序的复杂性与高成本问题。c o r b a 成功融合了基 于消息传递的客户机n 务器技术和面向对象软件开发技术。c o r b a 采用面向对象方法 创建在不同应用程序中可复用与可共享的软件组件，每个对象对外隐藏其内部工作细 节并提供一个具有明确定义的外部接口，从而降低了应用程序的复杂性。一旦实现并测 试一个对象后，它可以在新应用环境中多次重复使用，继而降低了开发应用程序的成本。 c o r b a 的平台无关性很适合用于集成企业内的异构计算机系统，包容不同供应商 的不同硬件平台、操作系统、网络系统、程序设计语言或其他特性。c o r b a 的最大特 点是提供了在异构分布式环境中对象之间的高度互操作性，从而保证了分布式对象间的 可互相通信。 c o r b a 的典型应用是开发需要有效处理大量客户请求的服务程序，其可伸缩和容 错的特性适于构筑企业级应用服务器的通信基础设施。众多的对象服务为解决分布式应 用的安全性、持久性、并发性等提供了强有力的支持，公共设施与领域接口进一步提高 了分布式应用开发的生产率。但鉴于分布式应用自身的高度复杂性，开发人员即使采用 完全遵循c o r b a规范的o r b 和对象服务产品，也需要大量编程工作才能借助这些 产品提供的a p i 解决问题，而学习和掌握各种对象q 艮务中复杂的a p i 也是对开发人员 的一种挑战。 6 硕士论文分布式服务平台架构设 + 与实现 由s u n 公司提出的e j b ( e n t e r p r i s ej a v a b e a n s ) 体系结构相对c o r b a 而言，其最 大的特点是简单性，可帮助软件开发人员快速地构建分布式应用系统【l0 1 。 为实现这一简单性目标，e j b 采用了基于组件的软件开发技术。所谓组件 ( c o m p o n e n t ) 是指一组根据固定规则或框架组织起来的接口与类，它们可以部署到某 些运行环境中并可在运行时享用由运行环境提供的各类服务。组件是一种具有高度可复 用的封装体，b e a n 是j a v a 世界对组件的特定称谓。 在e j b 组件模型中，一个组件本身只需要执行那些与企业应用的业务逻辑密切相 关的代码，而将组件的生存期管理、命名与查找、并发控制、安全性、持久性、事物处 理等服务交由组件的运行环境去执行。虽然运行环境执行的这些服务并未完全覆盖 c o r b a 对象服务，但已可以满足大多数的企业级应用开发需求。在组件部署阶段，开 发人员通过一个文本的部署描述文件定制这些服务的行为。和c o r b a 对象服务的a p i 方式相比，这种说明性方法不仅简化了对象服务的使用，还因每一个组件仅含业务逻辑 代码而提高的组件的可复用性。 e j b 组件模型将e j b 组件划分为三大类：实体组件、会话组件和消息驱动组件。组 件模型对组件类型的划分实际上是将在应用实践中被证明有效的设计模式固化在组件 模型中，为开发人员提供一种简单有效的组件开发与部署途径。 实体组件是持久化对象的抽象，代表了数据库或另一应用系统中的数据对象，一个 典型的实体组件对应着关系数据库中的一行记录。实体组件的特点是具有持久状态且允 许多个客户程序共享访问。 一 会话组件用于建模组件与客户程序之间的会话，可分为无状态会话组件( 会话组件- - 不保留客户程序调用的状态，即客户程序对这类组件的两次方法调用之间无关联) 和有 状态会话组件( 会话组件保持客户程序调用的状态，即这类组件的实例与客户程序在逻 辑上有一一对应的关系) 。 消息驱动组件建立在j a v a 消息服务( j m s ) 上，通常用于在服务端执行异步操作。 与其他类型组件不同，消息驱动组件不由客户程序以面向对象的消息传递方式直接调 用，而是由客户程序发送一个j m s 消息给一个j m s 目标，当j m s 消息到达j m s 目标 时，与该目标相关联的消息驱动组件的o n m e s s a g e 0 方法将自动地被调用。通过重定义 该方法，开发人员可以决定如何处理消息。 e j b 组件模型的主要目标是由e j b 容器负责为其中的e j b 组件提供各类对象服务， 从而使e j b 组件自身集中精力处理与企业应用密切相关的业务逻辑。 无论应用程序采用什么分布式计算模型，都存在着异步、组播的通信需求。基于 c o r b a 的应用程序利用c o r b a 消息服务子规范或事件服务、通知服务等对象服务满 足这个需求；e j b 组件模型中的实体细件与会话组件均采用一种同步的单目通信方式， 7 2 服务平台架构设计 硕士论文 图2 1 5e j b 组件与e 旧容器关系示意图 一基于e j b 组件的应用程序须借助j a v a 消息服务和消息驱动组件来实现异步、多目的分 布式对象通信。 j a v a 消息服务( j a v am e s s a g es e r v i c e ，j m s ) 由两部分组成：在应用程序中发送和 接收消息时调用的a p i 和用于接插j m s 驱动程序的服务供应商接口( s e r v i c ep r o v i d e r i n t e r f a c e ，s p i ) 。与j d b c 、j n d i 等a p i 的设计思想类似，每种j m s 驱动程序专用于连 接某个特定的面向消息中间件产品，而程序员只需掌握j m s 的a p i 就能编写出可在不 同面向消息中间件之间移植的j m s 应用程序f 2 - 1 4 。 调用j m s 提供的a p i 发送或接收消息的应用程序均称为j m s 客户程序，由面向消 息中间件和j m s 服务供应程序组成的消息系统则称为j m s 供应程序( p r o v i d e r ) 。典型 的j m s 应用程序由一个j m s 供应程序和多个j m s 客户程序组成。所有类型的e j b 组 件均可通过j m s 向其他j a v a 应用程序发送消息。 j m s 支持两种消息传递风格：点对点( p o i n tt op o i n t ，p 2 p ) 风格和发布订阅 ( p u b l i s h s u b s c r i b e ，p u b s u b ) 风格。 点对点消息风格，由供应商产生的一个消息只能传递给。个消费者。产生消息的供 应商称为发送方( s e n d e r ) ，处理消息的消费者称为接收方( r e c e i v e r ) ，传递消息的虚拟 信道称为队列( q u e u e ) 。发送方将一个消息发送到一个特定的消息队列中，接收方从一 r 硕士论文分布式服务平台架构设计与实现 个特定的消息队列中接收消息。 圈 图2 1 6j m s 点对点消息风格示意图 在点对点消息风格中，多个发送方和多个接收方可关联到同一个消息队列，但由一 个发送方产生的一个消息只能传递给一个接收方。如果一个消息队列当前没有任何接收 方正在监听，则到达的消息将保留在该消息队列，直到有一个接收方连接到该消息队列。 如果多个接收方正在监听同一个消息队列，则由特定供应商提供的服务策略决定接收 方，例如w e b l o g i cs e r v e r 提供的j m s 基于先到先服务策略( f i r s tc o m e ，f i r s ts e r v e ) 分派消息。 图2 1 7j m s 发布订阅消息风格示惫图 发布订阅消息风格支持将由供应商产生的个消息传递给多个感兴趣的消费者。 产生消息的供应商称为发布方( p u b l i s h e r ) ，处理消息的消费者称为订阅方( s u b s c r i b e r ) ， 传递消息的虚拟信道称为主题( t o p i c ) 。发布方向某个特定的主题发送消息，注册到某 个主题的所有订阅方都将接收到任一发布方发送到该主题中的所有消息。此风格的最大 特点是允许多个订阅方接收同一消息。 9 围园圃回 2 服务平台架构设计 硕士论文 发布订阅风格支持持久订阅( d u r a b l es u b s c r i p t i o n ) ，一个持久订阅方在非活动时 仍能接收所有的消息，即消息是被保存在数据库或文件中，在持久订阅方转为活动时被 再次传递；一个非持久订阅方只能在活动时才能接收消息，在非活动状态期间的全部消 息都会丢失。点对点风格与发布订阅风格不同，消息队列为保证消息从发送方可靠地 传递到接收方，总是采用持久方式保存接收方非活动状态下暂时未接收的消息。 2 2 面向服务的体系结构 不同于面向对象的中间件技术和软件组件技术，面向服务的体系结构 ( s e r v i c e o r i e n t e da r c h i t e c t u r e ，s o a ) 更侧重于服务的发布、发现和使用。 图2 2 1s o a 的体系结构 s o a 是一种松散耦合的软件体系结构，由各自独立的可复用的服务去构成系统功 能。这些服务对外公布出意义明确的接口，通过对这些透明接口的调用来完成软件开发 【2 ，3 ，4 ，9 1 o 所谓服务，就是对现实世界中业务活动的抽象与建模。在面向服务的体系结构中， 服务提供者负责提供服务实现的实体：服务请求者是请求某个特定服务的用户、应用程 序、对象或组件等实体；服务代理保存了关于服务的业务信息或软件信息，服务请求者 通过询问服务代理发现所需的服务并绑定到一个或多个服务提供者来使用服务。 每个实体的角色不固定，可以同时承担一种或多种角色。角色之间有三种操作： 发布：服务的描述信息通过发布以便服务请求者发现和调用：服务提供者向服 务代理注册自己的功能和接口。 查找：服务请求者通过查询服务代理以定位符合需求的服务。 绑定：使服务请求者能真l f 地使用服务提供者。 除应用服务组件外，s o a 系统有三种面向服务的基础组件：消息总线、信息转换 处理引擎和数据库。这些组件通过应用管理策略或框架进行部署。消息总线是s o a 的 1 0 硕士论文分布式服务平台架构设计与实现 核心组件，由它负责协调各个组件。 图2 2 2s o a 组件关系示意图 s o a 的特点简单概括为【9 】： s o a 是松耦合的； s o a 是基于消息的； s o a 是用于系统集成的； s o a 的用武之地在于构建组合型应用。 2 3 软总线技术 总线是一条信息传输线，由不同功能部件所共享。总线结构使得不同设备间的互联 互通得以实现，便于设备部件的更换和系统的扩充。在计算机的硬件总线上，通过插接 遵循统一标准的硬件模块，可以组成针对不同应用的计算机硬件系统【1 4 j 引。 在大规模集成应用环境中，用户数量和应用服务数量都具有显著的动态性。随着业 务的发展和集成度的进一步提高，两者都体现出很强的增长趋势。这就要求系统具有伸 缩性和可控性。具备可扩展性、可维护性和可复用性的软总线技术，十分适用于这类复 杂软件系统。 软总线的思想就是实现类似硬件总线的桥梁功能，把任何符合统一标准的应用程序 以插件的方式接入软总线，并同总线上的其他部件通讯。这一思想早在二十世纪七十年 代就被提出，直到九十年代分布式对象管理技术和软件复用思想的出现，才有了实现的 基础。 2 服务平台架构设计硕士论文 软总线是一组为多种计算机语言编写的多个、多种类型的组件服务的虚拟的数据传 输线。这组虚拟的数据传输线是软件，是一组通用的标准组件的接口界面，是一组标准 的软件模块。它也是计算机操作系统与各种组件或组件与组件之间进行数据传输与联系 的虚拟公共通道和接口界面。软总线满足应用程序的“即插即用”服务功能，通过总线 中的通信模块，任何应用程序，不论具有何种功能，只要遵循该“总线”接口标准，都 能直接集成到系统环境中，与其它应用程序进行各种类型的信息交互，实现数据集成和 模块间的通信 2 0 - 2 2 j 。 随着系统规模和应用范围的不断扩展，软件系统的开放性、可移植性和互操作性要 求越发突出。基于软总线的开放架构可以降低系统中各个模块间的耦合度，提高模块的 复用性，增强系统的灵活性，有效降低开发成本，提高开发效率。 c o r b a 中的o r b 相当于标准的软总线，提供了对象间的传输通道，使基于c o r b a 标准开发的对象可以跨平台、跨语言地进行互操作，实现高效的连接、复用。 作为s o a 中所有其他组件的交互中介，软总线在s o a 基础组件中也是最重要的。 2 4 不同模式总线对比 目前采用较多的总线方案有以下几种1 2 3 j ： 基于数据库的总线方案：将数据库作为传输媒质与信息存储点，不同的应用模 块可直接访问统一的数据库；各个模块可以直接操作数据库。在任何一个应用模块需要 扩展信息模型时，会对其他应用模块的运行产生很大影响，甚至导致系统无法正常运行， 可扩展性差。由于应用模块直接访问数据库，因此降低了整个软件平台的安全性。系统 受限于数据库的存储、访问性能，处理能力较差，不适合大规模环境下的应用。 基于组件的总线方案：通过统一组件对象模型定义的调用和服务等软件接口， 实现整个应用的集成、完成总线的构建常用的组件模型有：c o i m a 、e j b 和d c o m 等，不同模型间的相互调用还存在一些问题，通常采用中间应用来完成，降低了系统的 效率，因而具有一定的局限性。 基于a g e n t 的总线方案：核心思想就是将客户端应用程序与各应用接1 ：3 、数据 库的访问接口，设计为智能a g e n t ，完成对数据库的访问与控制、业务应用与服务调用 等。部分提高了资源的利用率，具有一定的可扩展性。虽然a g e n t 本身具有自主、学习、 智能等特点，但提供这些特性无疑也大大增加了系统的复杂度。 上述三种方案并不适合并发体系下的大规模集成应用环境。 并发体系联系起了以下三种要素：c p u 为应用程序代码提供执行环境； “数据”和“控制”消息在一个或多个应用程序或网络设备之间发送和接收；执 行任务的服务当消息到达、离开时，基于消息执行服务f 2 4 j 。 在个网络应用程序中，并发体系是影响“环境切换”、“同步”、“调度和“数据 1 2 硕士论文分布式服务平台架构设计与实现 移动”的成本，从而影响程序性能的几大要素之一。支持并发体系的规范类型有两种； “基于任务的体系和“基于消息 的体系。在这一设计空间，主要的取舍在于编程的 简化和程序性能的提升。 基于任务的并发体系根据应用程序中的“服务功能单元”来组织多个c p u 。在 这一体系中，任务是主动的，任务中处理的消息是被动的，如图2 4 1 所示。并发性是 通过在各个c p u 中执行服务任务，并在任务c p u 之间传递数据消息和控制消息而获得 的。“基于任务”的并发体系可以通过“生产者消费者( p r o d u c e r c o n s u m e r ) 模式来实 现【6 1 。 基于消息的并发体系根据“从应用程序和网络设备接收到的消息”来组织c p u 。 在这一体系中，消息是主动的，任务是被动的，如图2 4 2 所示。并发性是借助一个服 务任务栈，通过同时在各个c p u 上处理多个消息而获得的。“一个请求一个线程”、“一 个连接一个线程”及“线程池”模型可用来实现“基于消息”的并发体系。特别是“一 个连接一个线程模型，它们往往比“基于任务 的体系更有效率。但是，“基于任务” 的体系一般更易于编程。因为在一个任务中，或在一个层次上，般不需要同步，因为 并发的串行化是在