联通系统间数据同步解决方案

联通系统间数据同步解决 Xx联通 系统间数据同步 解决方案 缩写字汇表 ............................................................................................................ 2 第一章 应用背景和现状描述 ........................................................................................................ 3 1.1. 应用背景 ............................................................................................................................ 3 1.2. 现状描述 ............................................................................................................................ 3 第二章 需求概述 ............................................................................................................................ 5 2.1. 系统建设目标 .................................................................................................................... 5 2.2. 管理上的要求 .................................................................................................................... 6 2.2.1. 最大限度地保护投资 ................................................................................................ 6 2.2.2. 不影响现有生产系统的运行，易实施，见效快 .................................................... 6 2.3. 技术上的要求 .................................................................................................................... 6 2.3.1. 跨平台性 .................................................................................................................... 6 2.3.2. 实时性 ........................................................................................................................ 7 2.3.3. 高效性 ........................................................................................................................ 7 2.3.4. 高可靠性 .................................................................................................................... 7 2.3.5. 高可扩展性 ................................................................................................................ 7 2.3.6. 可独立性 .................................................................................................................... 7 2.3.7. 易维护性 .................................................................................................................... 7 第三章 xx公司解决方案 ............................................................................................................... 8 3.1. 方案选型 ............................................................................................................................ 8 3.1.1. 通过数据库存取API编程 ........................................................................................ 8 3.1.2. 数据库系统产品 ........................................................................................................ 9 3.1.3. 中间件产品 ................................................................................................................ 9 3.2. 方案定型 .......................................................................................................................... 11 3.2.1. 以TIBCO Rendezvous信息总线作为数据同步系统的底层平台 ........................ 12 3.2.2. 采用TIBCO的适配器将各应用系统与信息总线集成......................................... 13 3.2.3. 采用TIBCO的Hawk对整个集成系统进行监控 ................................................. 14 3.3. 最终方案 .......................................................................................................................... 15 3.4. 系统扩展与企业应用集成EAI....................................................................................... 16 3.5. TIBCO产品在当前系统建设中的技术优势 ................................................................. 17 第四章 系统升级 .......................................................................................................................... 20 4.1. 升级前系统现状 .............................................................................................................. 20 4.2. 为什么要系统升级 .......................................................................................................... 22 4.3. 系统升级后架构 .............................................................................................................. 22 4.4. 系统升级带来的好处 ...................................................................................................... 23 4.5. 升级后的操作系统、数据库支持说明 .......................................................................... 24 4.6. 系统升级的步骤和情况说明 .......................................................................................... 25 第五章 TIBCO产品介绍 ............................................................................................................. 27 5.1. TIBCO Adapters ............................................................................................................... 27 5.1.1. TIBCO Adapter for ActiveDatabase ......................................................................... 27 5.2. TIBCO BusinessWorks..................................................................................................... 29 1/39 5.3. TIBCO Rendezvous.......................................................................................................... 30 5.4. TIBCO Hawk ................................................................................................................... 34 2/39 1.1. 目前中国电信行业面临着一系列的挑战，首先是快速变化的市场如何提高灵活应 对市场的能力，迎接WTO挑战已经成为电信运营商们亟待解决的一个问题。其次是日益成熟的客户在降低客户流失率的同时又能吸引新的客户群，这样电信运营商才能够 保证有较高的收益。最后是随着电信行业的不断发展，电信运营商不得不面对越来越 繁杂孤立的系统和复杂的内部流程。 面对这些挑战，电信运营商们又如何来保证数据的完整性？如何降低维护和运营 成本？如何有效扩展业务？如何增加部门间协作的透明度？如何增强生产流程实时 监控处理能力? ……所有这些问题的解决都要求电信运营商提高运营管理能力；同时 随着电信市场的竞争日渐加剧，某些细分市场日渐饱和，粗放式的占领市场、增加用 户量等经营策略已经难以保持企业的竞争优势。提升内部管理水平，向管理要效益正 在成为新的应用热点；而从长远和根本的观点看，真正能为电信运营商提供持续发展 能力和竞争能力的，除了一些体制改革手段（例如融资、并购、重组等）以外，其实 更重要的是应用信息技术提升运营管理水平和服务水平。 因此，在基础营运系统全面实现信息化，营业、计费、网管这三大块主要生产业 务已经完全实现计算机化管理以后，营运商的信息化建设的重点必然转到重点为管理 信息化建设上来。 1.2. 目前xx联通主要有如下的应用系统：综合营帐、计费系统、结算系统、话单采 集、客户服务系统、经营分析系统、CDMA计费子系统、OA办公网，增值系统，代理 商酬金系统、积分系统等。 所有这些系统并不是孤立无援的，它们彼此之间需要进行通讯、信息共享，如： 代理商酬金系统需要综合营帐系统提供本系统中一些重要的数据如：代理商资料，用 3/39 户资料，开帐和销帐记录等；积分系统中的用户信息、付费帐号信息也要通过综合营 帐系统中取得；同时酬金系统中的代理商信息和积分系统中的用户积分信息也需要提 供给营帐系统，以实现管理最优化。而企业的发展不仅要求系统间能相互交换共享数 据，更需要系统间的协作，来共同满足xx联通的业务增长的需要。 但是，由于所有的这些系统是xx联通在不同的时间分期建设的，各个系统的硬 件平台、操作系统、网络结构、数据库环境以及开发环境也不尽相同，虽然各系统在 构建时对数据的交换共享有一定程序的考虑，但因为系统间的巨大的平台和架构的差 异，已经在影响信息的交换与共享，如果严重的话，各系统更可能形成一个个“信息 孤岛”，最终影响了企业的发展。 目前，系统间的信息交换与共享大都采用传统的点对点的方式，当系统数据逐渐 增多的情况下，系统间的连接将发展成如图1.2所示的网状架构，这在当前数据量不 断扩大、系统不断增加、时效性要求越来越高的今天，已不能满足要求。 CRM OA 所以必须亟待一种灵活、高效、通用的解决方案，以实现这些系统之间的通讯与 协作。 4/39 2.1. 从xx联通信息系统的现状可以看出，其数据同步系统存在以下不足： , 接口众多，外挂系统多，缺乏统一规范，导致系统可扩展性差，维护难度 大，不利于管理 , 数据比较散乱，甚至可能同一数据在多个系统间有不一致的现象 , 没有对数据进行整体管理，无法进行数据分析和数据挖掘 , 即使有个别系统实现有互连，仍缺乏统一的的数据交换标准 针对这些问题，其实质是解决xx联通各异构系统间互联和接口统一的难题，使 信息在各异构系统中交换与共享。 xx联通系统间数据同步的目标：选择一个合适的数据集成平台，以统一的方式 实现现有系统间(营帐系统、代理商酬金系统、积分系统、客户维系等系统)互通互连，以一种开放的架构能实现后续系统与现有系统的连接难题，以一种统一的数据格式实 现系统间的数据交换与共享，将公司内的各个相对独立的应用系统、数据库等信息资 源有机的集成起来，从而提升运营管理水平和服务水平。 酬金系统 数据库 营帐系统 数据库 积分系统 数据库 客户维系系统 数据库 以下将分别从管理与技术的层面阐述系统建设的具体要求。 5/39 2.2. 2.2.1. xx联通在信息化的建设过程中，已建立营帐、大客户、积分、代销商系统和办公 自动化等多种系统，各系统在软硬件资源如网络结构、操作平台、数据库平台上都存 在着一定的差异。这就要求在系统建设的过程中充分考虑到这些差异，以将这些不同 的软硬件资源整合在一起，实现最大限度的投资保护。 2.2.2. 现有的各业务系统均是成熟的生产系统，每天都会从这些生产系统中产生大量的 业务数据，系统运行过程中短暂的停顿就可能带来巨大的损失，所以应在实施中尽量 规避使生产系统中断运行的风险。实现这一目标的具体要求如下： , 系统实施过程中要求不影响到生产系统的正常运行，须提供相应的保障机 制； , 解决方案在保证可行性的同时，要求能够尽量的缩短系统实施的时间，提 高系统实施的效率，简言之，即要求“易实施，见效快”。 2.3. 电信行业的工作性质和行业特点决定了其对系统间数据的同步系统的实时性、安 全性、可靠性有较高要求，并根据系统建设实用性、先进性、开放性的，结合现 有系统情况，对系统建设提出以下要求： 2.3.1. 能够屏蔽各应用系统在网络结构、操作系统、数据库以及开发平台上的差异，实 现跨平台数据交换的解决方案。 6/39 2.3.2. 电信行业竞争激烈，要求企业即时对信息作出反应，这要求数据在传输过程中具 有较高的实时性，尽量避免由于数据传输延迟所导致的数据不一致问题。 2.3.3. 电信行业各系统如营帐系统产生巨量数据，这就要求数据同步系统具有高效性。 高效性体现在各系统现有的性能不应受到大的影响，尽量提高网络及软硬件资源的利 用效率，对大批量数据的传输有良好的性能，尽量减少各应用系统的响应时间。 2.3.4. 要求数据传输的可靠性，应提供相应的容错机制，避免由于网络及其它硬件故障 导致的数据丢失。 2.3.5. 要求在整个系统环境中能够很方便得增加新的结点，为后续系统加入数据同步系 统即系统的扩充提供保障。 2.3.6. 要求系统的构建独立于各应用系统，不影响各应用系统的业务逻辑，保证应用的 独立性。同时保证一旦某个系统发生故障，不影响参与数据同步系统的其它系统的运 行。 2.3.7. 应提供一定的监控及排错机制来降低维护工作的难度，减少系统维护的工作量。 7/39 xx 3.1. 要实现系统间数据的同步，可以有以下几种方式： 3.1.1. API 使用数据库存取API编程，如ODBC和JDBC编程的方式来实现系统间的数据同 步，这是一种最灵活，但却也是最原始的，对于实现两个系统间的数据同步，这 或许是一种可选择的方式，但如果要实现三个或三个以上的系统间的数据同步，那么 以下问题就会明显地表现出来： , 编程工作量大 编程工作量大，并且需要对两个以上数据库系统深入的了解。 , 容错性差 通过编程方式来实现两个或多个系统间的数据同步，容错性差，需要经过较 长时间的测试和使用，才能获得一个稳定的系统。 , 传输不可靠 通过编程很难实现可靠的传输机制，数据传输的正确性不能得到可靠的保证， 容易丢失数据。 , 难以维护 由于通过开发专用的接口实现通讯，系统之间是一种紧耦合的连接方式，其 中任何一个系统发生变更时，将需要作大量的修改工作。 , 扩展性差 由于采用了点到点的连接方式，当有更多的应用需要作集成时，将会形成网 状的结构，使整个系统变得越来越复杂，越来越难以控制。 这种方式只适合于少量系统的数据同步。对于要实现象xx联通系统间数据同步 8/39 的需求来说，这肯定不是一种很好的方式 。 3.1.2. 数据库厂商提供的工具，如Oracle的数据连接，SQL Server的数据复制等技术，这种方式在单一数据库系统（即各系统使用的是同一厂商的数据库系统）中实现起来 相对容易，但其在多数据库或异构的数据库环境中来实现系统间数据同步，就会暴露 出数据类型转换有差异，数据不能实时同步，性能差、扩展不易等缺点，这也不是一 种好的选择。 3.1.3. 由于现有各应用系统在操作系统、数据库等信息环境的不统一，要实现系统间的 数据同步，其的难点在于实现跨操作系统、异构数据库环境的信息交流，当前业界广 泛采用的方法是应用消息中间件来作为系统集成的基础。 基于消息中间件，其消息通讯机制又可以分为星型消息处理机制与总线型消息处 理机制。以下分别对这两种不同结构的消息处理机制进行说明。 3.1.3.1. 星型的消息处理机制必须要有一个专门的消息中介者，以实现对消息的路由及转 发。其体系结构如图3.1.3.1所示。 9/39 图3.1.3.1 在这种处理机制中，所有的消息都要经过一个消息中转服务器转发，发送消息的 所有用户也都需要事先在中转服务器中进行登记。这种处理的方式会带来以下的一些 问题： , 位臵依赖性较强，维护困难：消息的传输是和IP相关的，变更主机或队列到 另外一个网络上时需要对队列和应用程序重新进行配臵。 , 存在节点故障：在这种结构中，位于星型结构中央的消息中转服务器对消息 的传送起到关键作用，系统对服务器的要求高，并且一旦该服务器发生故障， 将使整个集成系统陷于瘫痪。 , 可扩展性差：当需要增加更多用于消息传送的结点时，特别是在增加额外的 消息中转服务器时，需要进行大量的配臵管理工作。 , 消息通过中心服务器转发，使消息传递不实时，从而使系统效率低下 , 各系统与中心服务器是一种紧耦合的关系 3.1.3.2. 在总线型消息处理机制中，所有参与消息传送的节点都处于同等的地位，它们通 10/39 过一条虚拟的消息总线进行通讯。 其体系结构如图3.1.3.2所示： A B C D 图3.1.3.2 在这种体系结构中，由于各节点处于一种分散式的、松耦合的架构，它们之间没 有相互依赖性，所以当一个节点出现故障时，只是对与该节点的消息传送有影响，但 不会影响到其它节点的信息传递和接收。而且这种体系结构更易于扩展，当有更多的 接点参与到消息通讯中时，容易实现即插即用。另外在这种结构中，各接点的压力得 到均衡，更加适合于作群集服务。由于取消了星形架构中的中心节点，使消息在各节 点间的传递达到电信级的零延迟，效率很高。 3.2. 通过以上对几种解决方案的分析和比较，并针对xx联通的系统现状，本方案将采用TIBCO公司用于企业应用集成的系列产品来构建连接系统间数据同步系统。 11/39 其中，TIBCO信息总线实现的是一种总线型的消息处理机制，在这种机制下，TIBCO在底层建立一个虚拟的消息总线，各系统数据库都以统一的方式(数据库适配器或其它适配器)连接到消息总线上，以实现系统间的数据同步；并用TIBCO的Hawk来监控管理集成系统的运作。 3.2.1. TIBCO Rendezvous 在分布式环境下，信息通讯平台是一个企业系统集成的基础。同样在xx联通现有多操作系统、数据库环境下，要实现各应用系统的数据同步，其难点在于跨平台的 信息交流，并且电信行业对信息传输的高实时性、高效性、高可靠性的要求，也决定 必须有一个优秀的信息平台来实现企业系统集成。当前业界广泛采用的方法是应用消 息中间件来作为系统集成的基础平台。 TIBCO公司作为全球领先的EAI厂商，其总线型的消息中间件TIB/RV信息总线已经被电信、金融等行业认定为标准。它通过在不同的应用平台上使用消息代理来实 现消息的发布/转发与接收，采用统一的消息格式，从而屏蔽系统平台的差异，实现 跨平台的应用。 12/39 TIB/RV是作为一种总线性消息中间件，相对于其它公司的星型消息处理机制， 消除了节点间的位臵依赖性，提供了更好的容错能力，而且这种体系结构更易于扩展， 当有更多的接点参与到消息通讯中时，容易实现即插即用；TIB/RV的消息传输是采用基于主题的寻址方式的，从而屏蔽了网络细节，实现了位臵无关；TIB/RV的信息是自描述型的，与平台无关，带有用户可扩展的输入系统，提供对XML之类数据格式的支持；并且TIB/RV提供机制使信息在传输过程中确保送达，以保证信息在传输过程中 的可靠性；因为使用TIBCO RV不用考虑网络的技术细节，而只需专注于企业应用的 开发，所以能快速建立和配臵一个可伸缩的分布式应用系统；其消息传递与现有系统 独立，不会对现有系统的业务逻辑产生影响。如图3.2.1。 图3.2.1 所以，本方案将采用TIB/RV信息总线作为xx联通系统间数据同步系统基础平 台。 3.2.2. TIBCO 现有系统和网络资源特别是数据资源是企业的宝贵财富，要对其进行保护和利 用；同时我们也必须考虑后续的系统怎样扩展。 基于消息中间件平台，一般情况下有三种方式来将各应用系统集成，一采用自 然接入，即用API编程方式，这种方法编程工作量大，不适合于多系统的集成；二采 13/39 用整体封装方式，这种方式不对现有系统作任何修改，只对现有系统的I/O作API封装，它只适合于现有系统；三以适配器的方式，即将现有系统通过API适配器接入消息中间件，它对现有系统和未来的系统都合适，并且由于用户不必再为每个子系统开 发专用的接口，用户只需要关心各个子系统应该提供什么数据以及它需要接收什么数 据，因此将大大减少开发的工作量，对现有系统的影响也最小，为系统建设快速、高 效的实施垫定了基础，是一种具有优势的方式。 TIBCO公司有70多种针对软件厂商如PeopleSoft，Oracle应用和针对技术如数据库、CORBA、EJB等的适配器，它是连接应用系统与信息总线的桥梁，与TIB/RV信息总线作无缝连接。当用户的系统需要一些特殊的适配器来集成时，TIBCO提供适配器SDK，使用户用编程的方式来定制自己的适配器，并且编程工作量小。 对于xx联通的系统间数据同步项目，我们建议用数据库适配器的方式使现有系 统的数据库与信息总线进行连接。 3.2.3. TIBCOHawk 一个企业的应用系统实施完成后，其运行性能的好坏也是整个项目成功的重要因 14/39 素。对于xx联通这种电信行业对系统的实时性、高效性有特殊的要求，系统运行性 能的好坏尤其关键。 TIBCO的Hawk产品，是TIBCO的分布式应用监控与管理工具，Hawk使用TIB/RV 进行相互之间的通信，继承TIBCO RV的许多优点，包括灵活的架构、企业级的高可 扩展性、位臵无关性，易于配臵等。Hawk以事件驱动的方式实现用户所定制的各种监 控功能。 有了Hawk，系统管理员能够对本地或广域网络每个节点的应用程序参数、运转 状态和载入活动进行监控，并在预设定的情况发生时采取行动。在许多情况下，运行 中的故障或迟缓能够在发现后几秒钟内自动修复，从而减少关键性企业系统的意外中 断和减速。 所以，我们建议采用TIB/Hawk来作为整个数据同步系统的监控工具。如图3.5。 用Hawk来对操作系统和应用系统的全面监控。 图3.5 3.3. 结合xx联通系统间数据同步的需求，并考虑到数据库适配器的共用问题，我们 建议目前xx联通系统间数据同步的架构如下： 15/39 Hawk ADB ADB ADB 3.4. EAI 一个好的方案不仅要实现其基本需求，更要考虑到系统的扩展和未来发展。通过 实现系统间数据同步，以达到数据交换共享的目的，从站在企业应用集成的角度来看， 它就是一种数据集成，同时这也是实现企业应用集成的基础和根本。对于象xx联通这样的大型企业，企业信息化的过程决定其将来势必要实现企业应用集成，即在实现 系统间数据交换与共享的基础上，实现流程管理和自动化。 本方案在实现系统间数据同步即数据集成的同时，更考虑了后续其它系统的加入 与扩展，最重要的是可以在本系统的基础上，实现企业应用集成。其系统架构如图3.2所示。 16/39 3.5. TIBCO 接下来让我们看看TIBCO的产品如何满足此次系统建设中对实时性、高效性、 高可靠性、高扩展性以及易维护性等的要求。 TIBCO通过其Rendezvous产品在底层建立一个虚拟的消息总线来实现各节点间 的通讯，各节点之间的关系是平等的。各节点通过TIBCO提供的适配器将信息发布到消息总线上，以实现系统间数据的交互，其体系结构如图3.6-1所示： A B C D 图3.6-1 因为各节点只关心发布数据到信息总线上以及从总线上获取信息，因此各节点之 间实现了松耦合，有利于系统的扩展。消息的传输采用基于主题的寻址方式，从而屏 蔽了网络细节，实现了位臵无关。另外，TIBCO采用事件驱动的方式来对各节点上的 TIBCO应用进行统一的监控与管理，简化了系统维护的工作。 各应用系统间通过适配器技术实现交互，其系统结构示意图如图3.6-2所示。 17/39 Oracle Oracle SAP, Baan OA SAP, Baan OA Informix Informix PeopleSoft Systems PeopleSoft Systems DB2 DB2 Oracle Oracle Database Domino Adapter Database Domino Adapter ERP Adapter ERP Adapter Adapter Adapter TIB/RV Web Service EventConsole EventConsole Web Service EventConsole EventConsole Notifications Notifications 图3.6-2 如上图所示，各应用系统均可通过适配器技术与信息总线进行交互，在数据层面 上，可以采用TIBCO的Adapter for ActiveDatabase产品或者通过TIBCO的API调 用来实现与数据库产品的接口，从而实现在数据层面上的数据传输。 采用TIBCO消息中间件技术的优点可以概括如下： , 实时性 除传统C/S架构的请求/回答(Request/Reply)通信机制外，TIB/RV还具有广 播/订阅(Publish/Subscribe)通信机制，帮助企业从传统的请求/回答模式 转到自动数据接受的事件驱动模式(Event-Driven，或称之为Push)，使集成 的各应用系统间的数据、消息传递具有电信级的实时性，从而加快企业信息 流，提高效率，增强企业竞争力。 , 易实施 由于采用了适配器技术，（本系统采用数据库专用适配器即TIBCO Adapter for ActiveDatabase，简称ADB），用户只需要通过简单的配臵工具即可生 成与系统进行通讯的代理；TIBCO不仅对数据库层面具有专用适配器ADB， 而且对一些著名软件厂商如PeopleSoft，Oracle等提供的软件有现成的适 配器，提供TUXEDO、COM、CORBA、EJB等的适配器；对一些特殊化的系统， 18/39 TIBCO提供适配器SDK，通过编程方式来定制自己的适配器，从而使企业各 应用系统能快捷、容易地接入到信息总线。TIB/RV特有的基于主题的消息传输方式，用户不必关心网络节点的分布情况及网络传输的细节，当某个 节点的地址发生变化时，也不必对程序进行修改。 , 高效率 TIB/RV利用Ethernet广播和IP多点传送来满足最基本的一对多端的传送， 然后再通过专利技术来填补两个之间的差距，因此TIB/RV非常小巧玲珑。无论有多少收端在收听某一信息，发端的传送次数会在1次至1.3次之间。TIB/RV的编码只会为弥补1%-5%的网络终端并提供可靠的通讯做轻 量的重复运作。并且TIBCO公司的通信基础架构可对分布式系统进行远程 监控和管理。它利用分布式微代理为系统管理员提供了监控局域或广域网 络上的应用参数、行为和加载活动的能力，同时还可对预定义的情况做出 响应。很多情况下系统性能下降问题可以在发现后数秒内修复，从而使系 统高效地运行。TIBCO在NASDAQ上80亿笔交易/天，6000笔交易/秒的数据也足以证明TIB/RV具有高效性。 , 可靠性 TIB/RV对信息发布支持从可靠、认证和交易型传递的各种等级服务，即使 是在网络中断等故障的情况下，也能保证每条消息准确可靠的到达目的地。 RV内臵的容错功能也使系统能可靠地运行。同时与TIB/Hawk的集成使基于Rendezvous的部件能在发生意外故障或应用程序中断时立即恢复。十多年 的实际使用证明Rendezvous是所有类型的软件产品中最可靠的产品之一。 , 扩展性 Rendezvous的信息是自描述型的，与平台无关，带有用户可扩展的输入系 统，提供对XML之类数据格式的支持。 采用适配器的方式使各应用系统集成到TIB/RV信息总线，消除了点对点系 统需要在两点上编写接口的缺陷，使集成到系统中的各应用系统之间不再 是直接关联，从而使各应用系统间实现松散耦合，接入信息总线的各应用 19/39 系统是平等的，任何一个应用系统故障都不会影响其它系统的运行，因此 它具有良好的扩展性。当有新的应用加入时，可以实现“即插即用”，而且 不会影响到原有的应用。 TIB/RV支持多种硬件平台如IBM、SUN、HP等，也支持多种操作系统平台如 UNIX、WINDOWS、LINUX等，使系统不再受硬件平台和操作系统平台的约束， 具有良好的扩展性。 TIB/RV已经被集成或内嵌于世界主要技术公司的产品，对超过100个主要 应用程序、技术、信息源，已经实现了“买来不经更改就能用”的集成。 , 易维护 TIBCO产品采用直观的图形用户界面，为快速过程和过程标准化创造条 件。通过采用分布式的监控平台，实现对整个TIBCO消息体系的监控，并 可通过设臵规则库实现自动检错与修复，大大简化了系统的维护工作。 , 独立性 采用TIBCO信息总线作底层平台，它只负责系统间的消息传输，不影响现 有和后续系统的业务逻辑，使其具有良好的独立性。 4.1. xx联通的系统间数据同步系统已运行了一段时间了，它成功地解决了营帐系统、 积分系统、大客户系统和代理商酬金系统间的数据同步问题，取得了良好的经济效益。 在营帐系统割接前，系统间数据同步系统运行良好，其系统架构如图4.1-1： 20/39 Oracle 9i Oracle 9i Oracle 9i RV RV ADB 4.1 RV ADB 4.1 RV 图4.1-1 由营帐系统通过ADB把营帐系统的相关异动数据发布到RV信息总线上，酬金系统和积分系统通过RV程序接收RV信息总线上的相关数据，并更新到相关的数据库系 统，完成从营帐系统到酬金系统、积分系统间的数据同步。 后续系统的接入和业务的扩展，数据同步系统不仅要完成从营帐系统到酬金系 统、积分系统、客户维系系统间的单向的数据同步，还要完成积分系统的数据同步给 营帐系统，即完成系统间数据的双向同步。由此系统架构改成如下图4.1-2的架构。 Oracle 9i Oracle 9i Oracle 9i Oracle 9i ADB 4.1 RV RV RV ADB 4.1 RV RV RV 图4.1-2 营帐系统所在机器上的ADB发布营帐系统数据到RV信息总线，积分系统、酬金 系统和客维系统的各自的RV程序接收营帐系统发布的数据，写入对应系统的数据库； 营帐系统所在机器上的ADB远程取积分系统数据发布到RV信息总线，而积分系统所 在机器的RV程序接收积分数据，远程写入营帐系统。 21/39 4.2. 业务的发展对系统间数据同步系统提出更多更高需求，营帐系统还提出了需要同 步客维系统数据，以及后续系统的接入和扩展，在现在这种架构方式下虽然实现容易， 但系统的稳定性，大数据量对系统性能的高要求性等架构的缺陷越来越显现出来；这 种架构也同时不符合分布式系统架构特点，所以必须对架构作一次升级改造。 同时，xx联通的营帐系统已成功割接，因割接需要，对数据同步系统之营帐系 统的数据适配器所运行的机器的操作系统的升级，即由升级到了，而数据适配器()不能在升级后的操作系统()中正常运行，所以必须对营 帐系统的数据适配器进行升级，以使系统间数据同步系统能正常运行。 因此，考虑到系统现状和后续的扩展，建议数据同步系统作一次整体的升级改造。 4.3. 如第三章方案所说，虽然在管理上和技术架构上来说，采用一个系统一个数据库 适配器那样的分布式架构是一种理想的和最佳化的架构，但是我们在对数据同步系统 进行升级改造的同时，考虑到数据库适配器作为一种连接数据库与RV信息总线的桥梁，它既可以连接本地数据进行数据的发布/接收，同时也可以连接远程数据库对数 据进行发布和接收，所以，本次升级改造的系统架构如图4.3所示。 积分系统和酬金系统共用一个ADB数据库适配器，（本地连接酬金系统数据库， 远程连接积分系统数据库），来发布积分系统和酬金系统数据，同时该ADB可以接收RV信息总线上的其它系统发布的数据并写入相关数据库；而营帐系统和客户维系系统 则各自用与数据库本地的ADB发布/接收数据。 利用Hawk来监控管理ADB数据库适配器，若有什么故障，即按预先制订的规则 或方案去处理，以确保整个同步系统安全可靠稳定地运行。 22/39 Oracle 9i Oracle 9i Oracle 9i Oracle 9i ADB 5.2 ADB 5.2 ADB 5.2 Hawk 4.5 ADB 5.2 ADB 5.2 ADB 5.2 Hawk 4.5 图4.3 4.4. 升级后数据同步系统更改了一定的架构，抛弃了因编程来实现的接收程序开发、 维护难的缺点，全部在易学、易用的图形化的界面下，采用拖拉的方式来实现开发、 维护，同时把系统的性能调整到最佳。 升级后数据库适配器采用版本，从技术角度上来看，与原系统 相比，它有以下好处： 1) 升级后的数据库适配器在底层不仅支持TIB信息总线的消息传输，还支持 JMS消息传输机制，用户可以对这两种传输机制作任意的选择，从而使数据 同步系统扩展到采用JMS作底层消息传输的系统和应用。 2) 升级后的系统在消息传输格式增加了对XML的支持，即消息以XML格式传输， 这符合目前IT行业的流行趋势。 3) 升级后的系统可以在消息订阅端作分布式队列（distributed Queue）的设 臵，来提高系统的运行性能。 4) 升级后的系统可以设臵是单条数据库记录作为一个消息发布，还是多条数据 库记录合并作为一个消息发布。采用多条数据库记录一个消息的方式，更加 有利于提高系统运行性能。 5) 对于消息发布端，可以有两种机制来得到要发布的数据：支持旧版的用轮询 （polling）的机制来得到数据库异动的数据，（这种方式适合于数据库数据 23/39 异动比较频繁的情况）；同时支持数据库内部的Alter异步的机制，即当数 据库有数据异动时，Alter驱动ADB来发布数据库的更新数据，（这种方式在 数据异动不太频繁的情况下性能会更优）。 6) 对一个表既是消息发布的源表，又是消息订阅的目标表，消息发布和订阅采 用相同的主题，在老系统中就会产生死循环的现象，但升级后的系统可以对 此进行检测，不对接收的数据进行再次发布。 7) 升级后的系统增加了对各版本操作系统和各版本数据库的支持。 4.5. 升级后系统的核心组件之一数据库适配器统一采用ADB5.2版本，它支持的操作系统和数据库版本如下表－、二所示： Database Solaris 7, 8, HP-UX AIX 5.1, Red Hat 9 11, 11i 5.2 AS 3.0 Oracle 10g Yes Yes Yes Yes Oracle 9i/RAC Yes Yes Yes Yes Oracle 9.2.0 Yes Yes Yes Yes Oracle 8.1.7 Yes Yes Yes Yes Sybase 12.5 Yes Yes Yes No DB2 UDB 8.1 for Unix Yes Yes Yes Yes DB2 UDB 6.1 for OS390 (via remote Yes Yes Yes No connection only) DB2 UDB V5R2 for AS400 (via remote Yes Yes Yes Yes connection only) 表一、支持的UNIX类操作系统和数据库 Database Windows Windows Windows XP Windows NT 2000 Professional Server 2003 Oracle 10g Yes Yes Yes Yes 24/39 Oracle 9i/RAC Yes Yes Yes Yes Oracle 9.2.0 Yes Yes Yes Yes Oracle 8.1.7 Yes Yes Yes Yes Microsoft SQL Server 2000 Yes Yes Yes Yes Microsoft SQL Server 7.0 Yes Yes No No Sybase 12.5 Yes Yes Yes Yes DB2 UDB 8.1 for Windows No Yes Yes Yes DB2 UDB 6.1 for OS390 (via Yes Yes Yes Yes remote connection only) DB2 UDB V5R2 for AS400 (via Yes Yes Yes Yes remote connection only) 表二、支持的Windows操作系统和数据库 4.6. 数据同步系统的升级可以按下列步骤进行： 1) 原系统备份 , 备份原营帐系统机器上用于发布的ADB项目文件、odbc.ini文件 , 发布数据库适配器ADB的shell文件和.tra文件 , 营帐、积分系统创建用于发布的创建临时表及触发器的SQL文件 , 各系统接收端的RV程序 2) 安装TIBCO软件 在营帐系统、酬金系统、客户维系系统的机器上安装以下软件： TIBCO/Tra 5.2 TIBCO/Adapter for ActiveDatabase 5.2 25/39 TIBCO/Hawk4.5 3) 设臵环境变量，并配臵ODBC驱动 4) 使用Designer工具对原来的项目文件进行升级，并对系统所用到的数据库、 发布/接收的表和字段进行复核检查；对新增的需求重新设计适配器。 5) 部署升级改造后的项目文件，并测试 6) 系统性能优化 7) 系统割接，正式投入运行 26/39 TIBCO 5.1. TIBCO Adapters TIBCO Adapters让应用软件包、数据库和网络技术，不管其数据格式或模式有 否差异，都能成为企业信息流的主动参与者。Adapters采用一种“非编码”的途径来 集成，提供第三方技术和数据格式的简单、自动化的对应。 Adapters使新的部件可以快捷而方便地加入到系统中来，而不干扰现有平台架 构。每个新部件只需要和ActiveEnterprise的数据模式适配即可，而不需要和它所 要接驳的所有应用软件、数据库和网络一一对应。 5.1.1. TIBCO Adapter for ActiveDatabase TIBCO Adapter for ActiveDatabase作为连接数据库的专用Adapter，是一个在ODBC数据库和TIBCO RV消息系统之间的双向网关。它既支持publish/subscribe，也支持request/reply。 采用允许trigger的ODBC数据库，TIBCO Adapter for ActiveDatabase代理可以主动地通知TIBCO RV数据库中的变化。相反地，代理可以配臵成订购TIBCO RV的消息，将它们捕获到数据库的表中。 代理处理来自TIBCO RV的请求，并将回应返回给请求的程序，其中包含已经被 处理的请求。 TIBCO Adapter for ActiveDatabase可以将数据库中数据变化在发生的同时传 送给其它的数据库和应用程序。它将publish/subscribe和request/reply技术延伸到数据库。它支持ODBC兼容的数据库如DB2、Informix、Oracle、Sybase和Microsoft SQL Server。 27/39 当数据库表中预先指定的行被插入、更新或删除时，自动地将数据作为TIBCO RV的消息发布出去 自动地订购作为TIBCO RV消息发布的数据，并对数据库中预先指定的表进行插 入、更新和删除操作 采用Request/Reply机制发布SQL语句和/或存储过程 对TIBCO Adapter for ActiveDatabase进行定制，以满足需求 采用命令行配臵工具，可以很方便地对代理进行配臵 如下图所示，当一个应用程序更新一个由TIBCO Adapter for ActiveDatabase publisher代理监视的数据库时，代理从数据库表被修改的行中提取数据，利用TIBCO RV将它们发布到适当的subject上。发布的消息通过组播（multicast）传送给subscriber应用程序。TIBCO Adapter for ActiveDatabase subscriber代理监听相应的subject，接收到消息后，对与其相关联的数据库中的有关表进行更新。其它应 用程序再访问数据库时，数据就已经是最新的了。 28/39 TIBCO Adapter for ActiveDatabase的Request/Reply功能可以使TIBCO RV应用程序能提交一个或多个SQL语句、存储过程。当执行完毕，代理将一个或多个结果 集，连同结果代码返回给请求的应用程序。Request和Reply都采用TIBCO RV的消息格式。如下图： 5.2. TIBCO BusinessWorks TIBCO BusinessWorks这一产品是一个方便易用的集成解决方案。这一解决方案 利用了TIBCO公司创新的技术和多年的业界领导地位及经验，在一个可快速部署的解 决方案中提供了世界级的集成技术，并可以对集成项目的整个生命周期进行管理。 TIBCO BusinessWorks包括了一个用于创建和定义集成项目的图形化用户界面 （GUI）、一个可使例行任务顺序自动化的引擎，以及一个用于应用、系统资源和流程 监控的基于Web的接口。 29/39 优 点 ? 通过集成和自动化，支持快速解决关键的业务问题。 ? 通过实时信息交换和业务流程自动化，从现有系统中获得更大的价值。 ? 通过自动化例行任务和为异常管理提供支持提高运营效率。 ? 避免过去系统不能互相通信时需要手工步骤所带来的延迟和错误。 ? 通过Web接口对系统和流程进行监控，从而提供更好的业务活动可视性。 特 点 ? 采用标准技术，如XML、J2EE和Web服务。 ? 方便易用的设计接口允许快速部署和培训。 ? 流程模板以及与领先应用的现成连接能力。 ? 支持流程模型和变换映射的重利用和共享。 ? 系统部件和使用人员的全面认证和授权。 ? 图形化数据变换环境简化了解决应用间数据结构差异的过程。 ? 基于Web的管理控制台支持在分布式环境中对系统和流程进行实时监控。 TIBCO BusinessWorks对集成的整个生命周期进行管理 , 设计: BusinessWorks具有的方便易用的接口使用户可对一个集成项目进行管理。 它还可扩展适应定制的业务对象和适配器配臵，并使用户不必依赖于程序员进行 代码修改即可对流程进行优化。 , 提交: 流程和变换映射一旦定义好，利用所需要的配臵信息更新所有服务器,只需 一步即可完成。 , 控管：BusinessWorks采用一个基于Web的接口进行用户和系统管理以及对应用、 流程和系统资源进行监控。企业用户可以分析实时的性能信息及趋势，并确定和 解决流程中的低效率部分。 5.3. TIBCO Rendezvous TIBCO Rendezvous（或称为TIBCO RV）它是一种中间件，也是TIBCO ActiveEnterprise的核心组件，它具有广播/定制(Publish/Subscribe)、主题传送(Subject-Based Addressing)和自定义数据信息(Self-Describing Data Messages) 30/39 等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。这些技术能有效地帮助企业从传统的请求/回答(Request/Reply)模式转到自动数据接受的事件驱动模式(Event-Driven，或称之为Push)。TIBCO RV有助于在各种应用系统中获取信息和数据，能将异种平台有机地联 结起来, 通过以即插即用(Plug & Play) 、位臵无关（Location-Independent）和分布式服务（Distributed Services）的方式在WAN和LAN间配臵系统。并且TIBCO RV具有认证信息传递(Certified Message Delivery)和容错(Fault Tolerance)功能。因为使用TIBCO RV不用考虑网络的技术细节，而只需专注于企业应用的开发，所以 能快速建立和配臵一个可伸缩的分布式应用系统。 信息总线是依赖于消息系统实现多个应用系统的相互通信，消息的传递方式一般 包括： , 存储/转发（Storage/Forward）； , 发布/预定（Publish/Subscribe）； , 请求/响应（Request/Reply）； , 请求/提交（Request/Delivery）； 这其中，存储/转发、请求/响应、请求/提交等方法本质上都属于客户机/服务器（Client/Server）方式的通讯方式，这种Client/Server方式的通讯方式是属于“点 对点”（Point-To-Point）的通信方式。当两个应用进行一对一的通讯时，点对点的 通信方式并没有什么问题，但是当一个信息需要发送给多个业务应用模块时，即“点 对多点”的应用模式时，采用这种通信方式，需要分别单独建立多个点对点的通信对 话，进行数据的通信。其工作效率和性能显然是较低的。发布/预定方式恰好能够解决这个问题。发布/预定方式是将需要传递的消息以广播方式公布到消息总线上，此 之谓“发布”，对于这个消息“感兴趣”的应用将接收这个消息，而对这个消息 “不感兴趣” 的应用将“抛弃”这个消息，此之谓“预定”。发布/预定方式是广播方式 31/39 的消息传递方式，这种方式是真正的分布式通信方式，无论信息要被发送到多少的目 的应用，一个消息在网络上只会传播一次，在“点对多点”的通信模式下，其工作效 率和性能是“点对点”的通信方式所不能比的。 因此，在通信机制上，是否真正支持发布/预定方式，是衡量信息总线产品的技术水平的关键指标之一。 , 加快应用的开发减少维护费用； , 唯一独立于硬件、操作系统、网络和协议平台供应商； , 动态组件替换:进程可以随时加载、退出、替换，而不影响系统运行； , 屏蔽网络细节； , 应用伸缩性高； , 地址无关简化增加/改变组件； , 提高分布系统的生命期； ： , 分布式队列实现一对多信息传送； , Java API； , 安全信息传送； , 冗余机制实现容错； ： , 所有平台间对等传输； , 与其他通讯协议并存于统一系统； 32/39 , 支持多种数据内部交换格式； , 系统开销低，容易嵌入； , 线程安全，多进程安全保护； , 支持多点传送； , 通讯和数据特性： , 异步通讯； , 广播/定制，可靠的广播机制； , 点对点请求/应答； , 基于主题信息传送； , 自定义数据信息与硬件/操作系统无关； , 透明的信息打包或重组； ： , 明确的信息认证，确保信息传送到目的地； , 在进程中断和重新启动状态下确保要传递的信息不丢失； , 传递信息给队列种的某一成员； , 队列成员进程保持异步运行； , 通过冗余进程实现系统容错； , 监控活动的冗余进程； 33/39 , 提供Java、C、C++、ActiveX、Perl的API库； , 源码兼容所有的平台； , 与Microsoft Windows 或ActiveX等Event Manager兼容； , 支持同步/异步事件管理结构； TIBCO Rendezvous Daemon为应用进程传递信息，过滤主题信息，分配信息； TIBCO Rendezvous Agent Process提供Java或applets与TIBCO Rendezvous后台进程的接口； TIBCO Rendezvous Routing Daemon在WAN和LAN间跨网段有效地传递信息,对TIBCO Rendezvous 应用编码不做任何修改； 5.4. TIBCO Hawk TIBCO HAWK是一个分布式应用的监控与管理工具，与其他监控工具不同的是， TIBCO HAWK使用TIBCO RV进行互相之间的通信，继承TIBCO RV的许多优点，包括灵活的架构、企业级的高可扩展性、位臵无关性，易于配臵等。 TIBCO HAWK是基于事件的系统，采用分布在每一台机器上的智能代理技术，该 系统针对分布式的应用系统监控而设计，因此他没有中央的控制台和采用polling技术。基于这种架构，TIBCO HAWK可以扩展到数千个节点，而当增加、删除或管理节点 时，不需要进行重新配臵或重新启动系统。 执行系统监控任务的是TIBCO HAWK的代理（Agent）。每一个代理运行于被管理 的每一个节点上，每一个代理依据系统监控逻辑采集信息、处理情况，监控逻辑规则 决定代理监控的资源和当某个条件出现时采取的行动。TIBCO HAWK提供预制的规则用来监视系统的基本参数。 34/39 TIBCO HAWK Display订阅代理发布的告警消息，并显示在组织视图中。告警信 息可以依据不同的颜色代表不同类型的警告，点击显示告警的节点，可以看到相关的 出错的历史记录。 TIBCO HAWK主要由两个主要组件构成：代理（agents）和控制台应用（Console）。代理执行监控任务，控制台（TIBCO HAWK Display）作为用户界面，显示系统状态和 提供配臵。如上图右侧，TIBCO HAWK的代理安装在各个机器上监控本地的资源，微代 理（Microagents）用来监控操作系统性能、进程、日志文件等指标。TIBCO HAWK应用管理接口协议（AMI，Application Management Interface）作为应用与代理之间的网关。 TIBCO HAWK具有可扩展性强、位臵无关和可靠性高的特点。 , TIBCO HAWK采用TIBCO RV作为通信工具，这种通信十分高效且十分可靠，被发 送给100个节点的消息所占用的带宽同发送给10个消息所占用的带宽是一样的， TIBCO HAWK继承了TIBCO RV的可扩展性。 TIBCO HAWK代理监控本地机器，在发生问题发送告警消息，由于采用这种分布 式的系统结构，不必周期性地进行polling，避免了轮询所带来的带宽消费。另一个 优势是，只有当告警消息产生时，代理才发布告警消息，因此在正常状态下占用的网 络带宽更小。 使用TIBCO HAWK Display，管理员可以很容易地监控一个大型的网络。 , TIBCO HAWK代理运行于每一个节点上，TIBCO HAWK代理同TIBCO HAWK Display相独立，在TIBCO HAWK代理与TIBCO HAWK Display之间的TIBCO RV消息使用基于主题的寻址技术，所以每一个组件的具体物理位臵就变得不重要了。 容错性是建立在代理与代理之间的工作独立性，一些代理无法继续工作，其他代 35/39 理仍然可以继续工作，监控系统的资源与性能。 TIBCO HAWK Display可以有多个运行实例，并且不需要额外的配臵与占用额外 的带宽。 , TIBCO HAWK提供了非常大的灵活性用于监控任务。定义的规则或任务可以十分 简单也可以十分复杂。可以实现的监控逻辑有： , 自动启动一个失败的进程； , 产生一系列的动作响应故障或问题； , 清除满足条件的故障； , 清除故障时，执行动作； , 自动切换规则，支持不同的监控要求； , 基于预先定义的日程的自动化的告警监控处理； , TIBCO HAWK支持多种平台，可以监控许多不同的被管理对象和任务，具有很强 的灵活性。 通过定义自己的规则和编写自动化执行的任务脚本的方式，系统管理员可以“裁 剪”TIBCO HAWK。也可以通过AMI协议扩展TIBCO HAWK对于应用的监控能力。Console API也提供了一个综合的接口用来与代理进行通信，使得系统管理员可以开发自己的 显示界面系统。RuleBase API可以用来开发客户自己的规则库，也可以利用Rulebase API开发客户化的规则编辑器。 本节介绍在TIBCO HAWK监控环境中的主要功能部件。 , TIBCO HAWK利用TIBCO RV进行TIBCO HAWK部件之间的跨越网络与机器之间的通信。支持广播型网络和组播型网络，通过TIBCO RV 路由Daemon支持广域网的连接，可以实现跨越网络的互连互通，具有很高的可靠性和传输效率。 36/39 , 在TIBCO HAWK管理环境中，安装在每一台机器上的代理执行管理任务。代理使 用微代理来管理每一个被管理对象，微代理通过可以调用的方法（methods）采用监 控信息或执行管理任务，微代理的方法可以被TIBCO HAWK Display或其他基于Console API开发的应用所调用，微代理可以应用代理的规则引擎执行监控功能。微 代理能够监控： , 日志文件； , 应用执行； , 操作系统性能； , 进程； , 文件系统； , 事件日志； , 服务； 应用通过AMI协议被微代理发现并被微代理监控与管理，每个微代理都运行在代 理里，但是微代理所管理的应用的管理进程则是分别独立的。代理本身也可以被微代 理所表示（represent），因此也可以通过同样的方式被管理。 , 规则库是一系列规则的集合，一个规则是用户定义的监控政策，他代表微代理通 过“方法”调用产生的源数据，以及相应制定的条件和满足条件时所触发的管理动作 （action）。 基于规则库，可以执行监控任务，并为监控任务设臵特定的条件。TIBCO HAWK Display中包含一个规则库编辑器，可以定义和修改复杂的监控规则，不需要使用脚 本语言就可以完成规则的定义。 规则库可以被分发到多个需要执行相同监控管理任务的代理那里，增加一个新的 规则库给一个代理或给1000个代理所使用的时间是一样的。改变一个规则库不需要 重新启动代理。 37/39 , TIBCO HAWK Display是主要管理界面，TIBCO HAWK Display的主界面以图形化的方式显示所有被管理对象的行为，每一个被管理对象被组织成“容器”（Container）方式。 可以通过菜单或对话框来创建、修改和分发规则库。TIBCO HAWK Display占用的带宽十分小，可以通过拨号方式连接在网络上执行管理任务，TIBCO HAWK Display不是执行管理逻辑的中央控制服务器，而是本地的管理窗口。所有的TIBCO HAWK Display若没有额外的特殊配臵将显示相同的被管理对象，系统管理员可以客户化自 己的显示视图而不会影响其他的TIBCO HAWK Display运行实例。代理可以被TIBCO HAWK Display或其他基于Console API开发的第三方应用所监控，如果代理停止了同 应用的通信，TIBCO HAWK Display可以检测出这种情况，并通知系统管理员。 , AMI协议 TIBCO HAWK应用管理接口协议（AMI，Application Management Interface）是开放的、基于TIBCO RV的协议，AMI协议的主要特点是： , AMI API库提供C、C++和JAVA语言的协议实现，同时利用TIBCO RV API 可以支持ActiveX和Perl； , 第三方应用可以通过编写AMI wrapper（通过AMI API）而被管理与监控； , Console API是基于JAVA的API，用于同TIBCO HAWK 代理的交互。TIBCO HAWK Display使用Console API来监控和管理代理的活动。使用Console API，可以开发客户应用来监控和管理TIBCO HAWK 代理，订阅告警消息，调用微代理的方法 （methods）。 38/39