《ESB平台服务管理系统概要设计.docx》由会员分享，可在线阅读，更多相关《ESB平台服务管理系统概要设计.docx（38页珍藏版）》请在三一办公上搜索。
1、ESB平台服务管理系统概要设计说明书V0.1文档编号：当前版本：0.1作 者：编写日期：评 审:评审日期:审 核：审核日期：批 准：批准日期：文档状态: 变更次数:All rights reserved版权所有，侵权必究文档修订记录日期修订号描述作者2014-6-2V0.1创建目 录1引言61.1目的61.2文档范围61.3参考资料61.4术语和缩略语72系统概述82.1设计约束92.1.1开发过程92.1.2运行环境配置102.2设计策略和方法102.3系统技术结构112.4面向层次的技术架构构成133业务监控分析153.1业务监控总体需求153.2业务监控流程介绍154功能模块概述174.
2、1标准代码管理模块174.1.1模块描述174.1.2功能操作174.1.3信息结构194.1.4数据流图194.2业务信息管理194.2.1模块描述194.2.2功能操作204.2.3信息结构204.2.4数据流图204.3业务流程管理214.3.1模块描述214.3.2功能操作214.3.3信息结构214.3.4数据流图214.4业务进程管理214.4.1模块描述214.4.2功能操作214.4.3信息结构214.4.4数据流图214.5业务预警管理224.5.1模块描述224.5.2功能操作224.5.3信息结构224.5.4数据流图224.6用户权限管理224.6.1模块描述224.6
3、.2功能操作224.6.3信息结构224.6.4数据流图224.7业务监控的展示234.7.1模块描述234.7.2功能操作234.7.3数据流图234.8数据统计分析234.8.1模块描述234.8.2功能操作234.8.3数据流图235服务监控245.1服务监控相关数据流图245.2服务监控模块设计255.2.1服务信息监测模块255.2.2服务控制模块275.2.3服务监控主程序285.2.4服务监控任务305.2.5服务监控基础功能模块325.3服务接口规范325.3.1服务处理成功失败定义规范325.3.2服务调用方规范335.3.3服务流量控制规范335.4服务实现规范335.4.
4、1服务调用信息规范335.4.2服务调用信息消息规范346编码规则356.1服务流程调用号356.2系统调用方357系统安全性和出错处理设计367.1安全性367.2出错处理368参考文档378.1Hawk介绍37图目录图1 服务提供方式7图2业务监控系统目标图10图11 服务监控页面24图11 应用实例页面25图12 服务实例列表页面25图15 服务统计查询页面26图16 服务调用次数查询页面27图17 服务调用时间查询页面28图18 服务调用方查询页面28图19 服务调用次数对比页面29图20 服务排名页面30图21 服务监控操作流图34图22 服务监控模块层次结构图35图23 服务内部发
5、送服务信息示意图36图24 服务调用执行信息类型定义36图25 服务监控程序主流程图40图26 服务调用信息接收存储流程图41图27 服务控制流程图42图 28 Hawk架构47表目录表1 缩略语61 引言1.1 目的编写本概要设计说明书的目的是对ESB平台服务管理系统当中业务监控系统进行总体设计的说明，包括业务监控流程、输入输出、与被监控系统的接口设计、数据库设计、预警设计和系统出错处理设计等。该概要设计是指导相关工作人员进行后续详细设计、数据库设计、编码、测试用例设计、系统部署的重要依据，是联结需求阶段和开发阶段指导性文档。1.2 文档范围l 系统名称：ESB平台服务业务监控系统l 用户方
6、：XXXX银行l 开发方：ESB平台开发小组l 任务提出方：XXXX银行l 任务承受方：XXXX银行营运中心l 预期读者：系统设计开发人员、系统测试人员和用户l 使用人：ESB系统维护人员本文档用于系统设计阶段的概要设计，它的上游（根据的基线）是ESB平台服务监控需求规格说明书。系统概要设计的范围包括：系统的总体结构设计、系统的全局架构设计、主要业务功能设计，主要技术功能设计等放方面内容。该范围应覆盖ESB平台服务监控系统需求规格说明书。1.3 参考资料ESB平台服务监控系统需求规格说明书1.4 术语和缩略语名词说明ESBESB全称为Enterprise Service Bus，企业服务总线，
7、是行内构建基于服务架构的主要基础设施支持。BusinessWorks/BWBusinessWorks(BW)是行内ESB的基础运行容器，在ESB上实施的服务都会通过这个容器进行服务提供。BW提供完整的项目周期管理支持，包含了图形化的服务流程设计器、适配器配置和部署；服务流程的运行管理也可以通过基于Web浏览器实现。HawkHawk是一个监控和管理分布式应用和操作系统的工具。它是专为监控分布式系统而设计，无需中央控制台也无需通过频繁网络轮询获取监控目标运行信息。GIGeneral Interfaces是TIBCO推出的开源的基于Ajax技术的UI技术，方便开发具有高交互能力的基于Web系统。表1
8、 术语和缩略语2 系统概述行内SOA是一种架构理念，通过松耦合方式更好的实现了软件资产的复用，因而可以很方便地构建业务敏捷的应用系统，以应对不断变化的业务需求。在SOA架构下的业务功能都会以不同的技术方式，以服务的形式提供服务请求方使用，在现在的运行环境中服务主要是通过Java、.Net和BusinessWorks进行服务封装和服务提供的，其中ESB作为主要的提供手段和服务介质。TIBCO ESB产品本身具备非常强大的集成能力，提供了一系列适配器产品链接套装软件和技术基础设施，比如通过Lotus Notes适配器、Oracle应用适配器和MQ适配器等产品，方便通过ESB进行服务封装和服务提供。
9、图1 服务提供方式所以作为服务流程提供的主要载体，在ESB上实施和运行了数量较多的服务。TIBCO产品本身提供了基于Web的管理器(Administrator)软件对服务流程的部署和运行进行技术管理，但如果需要对更深层次的服务业务运行态的管理，需要进行定制化开发。所以ESB业务监控系统就是为了满足上述需求的。业务监控系统作为ESB平台服务管理系统（在建）三个主要组成部分之一，建设目标是建立一个基于映射转化（而非基于报文解析）的可配置、可管理的监控系统。该监控系统是通过建立核心数据库，实现业务流进程跟踪监控、异常预警和数据统计三大功能。业务监控系统是一个架构稳定灵活、接口实现方便的接入平台，只有
10、被监控系统接入才能发挥其功能。该系统建成的同时，将同步实现对柜台前移系统通过报文解析进而转化为基于映射的接入；并且随着ESB平台上接入系统的增加，将逐一实现对被监控系统核心业务流程的监控。被监控业务流接入时，监控系统仅需前台配置，无需后台代码更改，形成对业务流程的跟踪监控、异常预警和数据统计功能。由于需接入的业务系统自身功能各不相同，核心业务流各有差异，在该系统建设过程中，同步制定一套统一的基础信息与进程中信息（或进程报文）通信格式，形成一套制定基础信息与监控信息格式的规范，为被监控系统的接入方式做好基础架构，对后继业务系统接入提供统一的方法和流程根据预定义的控制规则对服务进行控制，同时记录服
11、务调用的相关信息，对服务负载和服务性能进行分析；获取的相关服务运行信息将存入数据库，供之后的数据分析和数据挖掘时使用。2.1 设计约束2.1.1 开发过程 软件开发要符合计算机软件产品开发文件编制指南GB 8567-88 的要求； 软件开发要符合ISO9001：2000的要求； 默认的编码格式是UTF-8； 应用服务器操作系统为Windows2000、Windows2003、WindowsXP、 Linux； 应用服务器软件采用Tomcat 5.5.27、 JDK 1.5； 开发工具采用MyEclipse6.0； 数据库为Oracle10g(10.2.0)； 采用B/S(Browser/Ser
12、ver)技术进行软件开发，客户端操作系统为Windows2000、Windows2003、WindowsXP，客户端浏览器主要为IE6.0或以上版本等软件。 系统操作简便，用户界面友好，符合用户使用的习惯； 系统响应速度快，运行稳定，用户使用时无等待感，查询或刷新时间不超过10秒； 软件不能有空链接，软件应该能根据客户端机器分辨率(主要有800*600、1024*768两种分辨率)自动合理布局； 用户瞬间访问高峰时界面查询或刷新时间不超过20秒。 系统能够支持100个以内的用户同时访问。 客户机的最低配置为：256M 内存。2.1.2 运行环境配置 应用服务器为Apache Tomcat 5.
13、5.27； 应用服务器软件为Oracle Application Server: app10g.； 客户端操作系统为Windows2000、Windows2003、WindowsXP，客户端浏览器主要为IE6.0或以上版本等软件。 客户机的最低配置为：P4/256M 内存2.2 设计策略和方法业务监控系统在设计时，将从以下几方面进行可复用性、可移植性、可靠性等方面的考虑： 复用性的支持业务监控系统应对架构、代码等的复用性进行考虑，为行内其它项目做技术储备。对于系统的代码复用，可通过加强模块的合理分割来实现一部分类似功能的代码复用，从而减少开发时间。 移植性的支持本项目采用Ajax+Spring
14、+DAO开发架构，使得每一层都以一种松耦合的方式彼此沟通，可移植性极强。 可靠性的支持本系统的数据库使用ORACLE。业务监控系统采用的开发架构对表示层采用Dwr实现、业务层采用Spring完成，持久层采用DAO来处理，而这个框架本身提供了底层的代码访问封装，开发人员只是调用接口实现业务逻辑处理。在这些支持软件的基础上所进行的应用开发，可靠性是有保证的。2.3 系统技术结构业务监控系目标图如下所示。整个业务监控系主要实现三大目标即：业务流进程跟踪监控、异常预警和数据统计分析。核心信息数据库业务流跟踪根据预定规则，自动跟踪各业务流进程，并适时动态显示，方便各级领导和工作人员及时关注业务流的进程状
15、态，以便合理的做出工作安排。业务流进程跟踪业务流发生异常时，系统能自动给相关技术和业务人员通过短信或邮件的方式发出预警提醒，方便相关人员第一时间了解业务流异常。业务、技术异常预警异常预警数据统计根据各业务流的基础信息，可对业务流涉及的业务按照多维度、全视角进行统计分析，并为业务状态预测提供基础信息。业务数据统计图2业务监控系统目标图 业务监控系统的功能架构是为实现端到端的业务进程跟踪监控，该系统功能模块主要包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户权限管理、系统接口和安全及审计管理等，核心模块为业务信息管理、业务流程管理和业务进程管理。图3 系统功能架构示
16、意图业务监控系统在获取具体业务流的基础信息和进程信息的基础上，通过控制流程驱动和预警管理机制实现业务流跟踪时时动态图和数据统计；在发生异常时，通过与外部系统的接口实现邮件或短信提醒，进而通过人工干预，恢复业务流程的正常运转。 图4业务监控逻辑图 2.4 面向层次的技术架构构成 图5面向层次视角的技术架构从面向层次设计的视角，可将系统设计为如下层次：用户交互层、交互控制层、业务服务层、公共服务层、业务流程管理扩展、数据访问层和数据存储层。 用户交互层，基于Web2.0实现技术，负责用户与系统的人机交互界面，为用户提供一定的本地计算能力。 交互控制层，负责为界面和业务服务之间进行数据转换，同时对系
17、统的事务进行总体控制，隔离界面实现与后台服务实现，使后台业务服务实现更为标准化。 业务服务层，主要包括各类封装了业务实现逻辑的业务服务组件，调用数据访问层的数据服务，本身不直接访问数据库。 公共服务层为整个应用的公共需求提供统一的、重用的服务。包括：日志、异常、事务、认证、校验等。 数据访问层，负责进行数据访问及系统间交互操作，关注数据的存取操作，不关心业务服务如何调用数据， 屏蔽对数据库表的直接SQL操作。3 业务监控分析3.1 业务监控总体需求业务监控系统的业务流程端到端跟踪监控的实现是在配置业务流程信息的前提下，对业务流进程信息进行管理，即在业务流程中，每次业务流经不同作业处理点（被监控
18、点）时，应向业务监控系统发送状态消息（具体消息通过报文或消息的方式约定），实际操作过程中，该系统可灵活的添加或减少作业处理点，通过对业务流程信息的管理实现具体业务端到端的业务流程跟踪监控；当系统业务流异常时，根据预先配置的预警规则，通过短信或邮件方式提醒预警提示人员；被监控系统每形成一条业务流时，应向监控系统发送业务基础信息，监控系统将以此自动生成一条监控信息和业务流程，并且该基础信息为业务流程含义展示和统计汇总提供数据。3.2 业务监控流程介绍当业务系统生成一条具体业务流时，在初始点及各监控点应向监控系统发送消息，具体业务流程消息发送的方式为：在业务流起始时，向业务监控系统发送一条基础信息，
19、监控系统据此自动生成一条业务流跟踪监控流程；在业务流程中，每一作业处理点（即：监控点）接收到一条需处理作业时，向业务监控系统发送一条已接收到该作业的状态消息，当该作业处理点完成作业后，向下一作业处理点发送时，同步应向业务监控系统发送一条该作业处理结果的状态消息（状态消息可为：该作业内容更改并成功向下一作业处理点发送，或作业处理成功并向下一作业点发送，或拒绝作业返回至上一或几作业处理点，或流程结束）；当在某监控点或流转中，由于系统技术原因发生异常，应向监控系统发送系统技术异常消息（如：无法发出、系统延时、系统无法接收等），以上发送的各类消息可在具体添加被监控系统时，约定消息内容。业务系统发送至监
20、控系统的消息内容应包括：该具体作业流程的唯一标识代码（全流程不变），本处理点名称代码，本节点所处系统代码；收发作业标识，收发类型（七种：1.正常接收；2.正常发送至下一作业处理点；3.退回上一或几作业处理点；4.作业流程终止并退出；5.技术延时异常;6.技术异常，系统终止;7.作业流程终止并退出，该类内容可在监控系统实现维护），内容更改标识，具体更改内容代码，更改后的具体内容。 图6 业务监控进程示意图4 功能模块概述通过对业务需求的分析，要实现业务流程端到端的跟踪监控、异常预警和数据统计功能，本系统主要功能模块包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户及
21、权限管理、进程跟踪展示、数据统计分析等部分，对于每一部分具体功能及信息分析逐一展开。4.1 标准代码管理模块4.1.1 模块描述为使整个系统内容规范、一致，便于与被监控系统定义业务信息、进程信息的内容，以及部分元数据与服务注册系统进行同步，本系统需建立标准代码管理，独立维护本系统所使用的标准代码，当与服务注册系统实现对接后，服务注册系统作为本系统部分标准代码源信息，通过接口向本系统提供标准代码信息，本系统可关闭服务注册系统提供源数据部分的代码添加、修改功能，仅保留具体内容本系统是否可见功能。形成标准代码的目的是为保证系统间的标准信息格式定义一致，以及对业务及业务进程基础信息进行统计和分析提供便
22、捷。本系统涉及到的主要标准代码包括：系统类别代码、系统代码、业务种类、业务流代码。4.1.2 功能操作4.1.2.1 代码添加用户填写代码详细信息，包括代码、名称、备注等，系统提供校验代码是否重复、是否符合约定格式、名称不能为空等功能，提交后在数据库中形成一条正确的新数据；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：代码、名称、备注等需填写的详细信息；输出：对应的相关数据库表中增加一条正确记录。4.1.2.2 代码修改用户选中要修改的一条代码，可对代码、名称、备注等进行修改，系统对修改部分除提供与代码添加同样校验功能外，还应提供该代码是否已被引用等校验功能，对于已被引用和约定
23、使用的代码，原则上不得进行修改，修改后系统更新数据库；参与者/角色：代码维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：对应的相关数据库表中一条记录数据发生变化。4.1.2.3 代码删除用户选中要删除的代码，系统应校验该代码是否已经被引用，若被引用应待引用记录全部删除后，方可进行删除，对于不能删除又需用户不可见的代码，提供客户端是否隐藏（即客户端不可见，不可在引用）功能；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：无；输出：对应的相关数据表中一条记录被删除或发生变化。4.1.2.4 代码查询用户登录后，输入代码、名称等条件，进行代码查询，理论上各个字段都可
24、以作为查询条件，并支持字母和汉字的模糊查询；描述：系统通过用户输入条件，查询相关记录；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：代码详细条目信息。4.1.3 信息结构标准代码主要包括：行内信息系统类别代码、信息系统代码、业务种类代码和业务流代码，前三类代码应与行内其他系统保持一致，待服务注册系统建成后，通过数据库订阅等方式实现数据同步，本系统无须再修改，仅对其在本系统是否可见做调整，业务流代码是根据各业务系统的具体业务种类不同而形成不同业务流代码，作为具体业务流程的依据。标准代码管理信息结构图4.1.4 数据流图4.2 业务信息管理4.2.1 模块描述当业务系统
25、发起一笔被监控的业务流程时，发起系统应根据系统接入时的约定，通过消息方式向监控系统发送该笔业务信息，作为监控系统自动建立一条具体业务流程的起始依据，并且为业务进程监控提供业务信息。本系统可人工修改此类基础消息（具体业务流程结束后，该类基础信息不得修改）。在该具体业务流程运行中，某流程中合法用户对初始业务信息内容发生更改，本系统应能自动对已入库的数据进行修正；并且本系统可根据业务流状态，自动变更存储位置，即当具体业务流程未结束时，应一直存于进程中业务信息数据表，结束（包括取消、正常完成及合法终止）进程后，此基础信息应存于已完成业务信息表，已完成业务信息表中内容为统计汇总功能提供数据。具体业务进程
26、中的业务信息应包括：唯一标识（作为具体业务流程唯一标识）、发起系统、发起单位、目标系统、目标单位、业务种类、涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人等，对于与固定字段无法对应的业务信息，应与预留字段对应，对于各预留字段，根据对应情况，逐步约定各预留字段对填入信息的要求。被监控系统在被接入前，双方应确定以上具体信息格式，对各字段应按照服务注册系统业务属性要求进行约定，并确定以上内容在被监控系统标准名称（即在原系统所使用的称谓），方便在浏览和统计时，依数据原本意义展现此类基础信息。4.2.2 功能操作4.2.2.1 业务信息字段对照管理4
27、.2.2.2 业务信息字段名对照添加4.2.3 信息结构4.2.4 数据流图4.3 业务流程管理4.3.1 模块描述4.3.2 功能操作4.3.3 信息结构4.3.4 数据流图 4.4 业务进程管理4.4.1 模块描述4.4.2 功能操作4.4.3 信息结构4.4.4 数据流图4.5 业务预警管理4.5.1 模块描述4.5.2 功能操作4.5.3 信息结构4.5.4 数据流图4.6 用户权限管理4.6.1 模块描述4.6.2 功能操作4.6.3 信息结构4.6.4 数据流图4.7 业务监控的展示4.7.1 模块描述4.7.2 功能操作4.7.3 数据流图4.8 数据统计分析4.8.1 模块描述
28、4.8.2 功能操作4.8.3 数据流图5 服务监控服务监控程序是独立运行的程序，主动定时获取服务运行状态信息，接收服务调用信息并存入数据库供后续查询操作；同时服务监控程序可以接收用户方发来的主动服务控制请求，或者根据预定义的服务控制策略，向运行态服务发出服务控制命令，也可以同时通过邮件通知系统运维人员。5.1 服务监控相关数据流图图3 服务监控操作流图l 服务监控程序包含两个主要的功能模块，服务信息获取模块和服务控制模块。l 服务信息获取模块通过接收包含服务调用信息的消息(数据流2)并存入数据库(数据流3)。考虑到服务调用信息消息条数会比较多，使用一个消息队列会影响消息收发性能，所以一个应用
29、实例下所有服务实例的调用信息消息使用同一个队列来收发。服务监控程序在启动后，根据数据库里的应用实例基本信息，决定在几个队列上监听消息。l 服务控制模块通过HAWK获取服务状态信息(数据流6)，同时从数据库中获取服务基本信息和调用信息(数据流7)，当满足预定义条件时，按既定规则控制服务运行(数据流8)。使用HAWK Agent和应用实例进行通信，获取应用实例状态信息。每个应用实例含有一个或者多个HAWK Agent。5.2 服务监控模块设计图4 服务监控模块层次结构图l 服务监控程序主线程负责读取配置项，初始化创建资源，结束程序释放资源。l 服务监控程序执行两个主要的工作任务：获取服务调用信息并
30、存库，获取服务状态信息根据预定义策略进行服务控制。各个任务由预先配置的一个或者多个线程运行。l 使用HAWK来获取服务运行状态信息和控制服务运行。l 服务的调用信息使用消息机制，调用信息按定义的格式序列化和反序列化。5.2.1 服务信息监测模块5.2.1.1 服务调用信息获取模块服务内部流程的实现如图6所示。记录服务接口调用执行的相关信息，以消息的形式发送到消息中间件的队列上。服务信息监控程序循环地从队列上接收这些消息。队列的默认名称为：.Invokation record。图5 服务内部发送服务信息示意图5.2.1.1.1 服务调用信息线格式承载服务调用执行相关信息支持复杂类型，调用信息的类
31、型定义如下：图6 服务调用执行信息类型定义如果需要记录服务调用的输入和输出，可以按以下的序列化格式，将各种不同类型的输入数据和输出数据序列化为字符串。表2 服务调用报文结构序号命名参数类型说明约束条件是否必输1instancenameSTRING服务流程号参见编码规则Y2starttimeDATETIME流程开始时间Y3endtimeDATETIME流程结束时间Y4inovkerSTRING系统调用方参见编码规则Y5inputSTRING服务调用的输入N6outputSTRING服务调用的输出N7success STRING服务调用是否成功 1/成功 9/失败Y8 errorcodeSTRIN
32、G服务调用发生异常时的异常码N5.2.1.2 服务调用信息存储模块服务监控程序接收到消息后，将消息内容读取处理并插入数据库中对应的表中。在上文中提到每个应用实例中所有服务实例的调用记录存放在一个表中。表名为： SERVICEINVOKE。同时将服务实例的一部分调用记录信息记录在内存里，供服务控制使用。5.2.2 服务控制模块服务监控程序执行三种控制策略的服务控制操作。程序使用HAWK API循环获取服务实例的状态信息，同时使用在内存中的服务调用记录信息，来进行状态判断，执行相应的控制操作。5.2.2.1 服务控制策略服务宕机监测服务运行状态，当发现服务宕机时，通知运维人员或者自动重启服务。每个
33、应用实例都有一个HAWK Agent，当服务监控程序通过HAWK API连接一个HAWK Agent失败，就可知道该HAWK Agent对应的服务应用已经宕机。5.2.2.2 服务控制策略服务调用失败统计服务调用处理成功失败次数，当最近一段时间内(比如最近1小时内)失败次数占总次数的百分比超过控制策略中的设置值时，通知运维人员。服务监控程序在内存中保存每个服务实例的服务调用成功与失败的次数，程序循环进行判断。5.2.2.3 服务控制策略服务负载过大根据服务实例当前的排队请求数，历史平均单次处理时间，最近1分钟或者5分钟的服务请求数来判断服务是否负载过大。通知运维人员，同时把该服务忙的信息以主题
34、消息的形式发布出去。服务调用者可以主动订阅服务状态事件消息，调整服务调用的时机和频率；或者服务应用实例订阅服务状态事件消息后，按既定的服务调用规范，服务直接给服务调用方返回服务忙的应答。判断负载过大策略规则如下：(1)IF (排队请求数 排队请求数阀值) THEN IF(最近1分钟或者5分钟的服务请求数 0 ) THEN 服务负载过大;ELSE IF(排队请求数*历史平均单次处理时间 =1分钟或者5分钟) THEN服务负载过大;ELSE 服务负载正常; (2)IF(最近1分钟或者5分钟的服务请求数 服务请求数阀值)THEN IF (排队请求数 0) THEN IF(最近1分钟或者5分钟的服务请
35、求数*历史平均单次处理时间=1分钟或者5分钟) THEN服务负载过大; ELSE服务负载正常; ELSE服务负载正常; 服务监控程序在内存中保存每个服务实例的最近一段时间的服务调用请求次数，同时程序循环更新每个服务实例的当前排队请求数，来进行服务负载是否过大的判断。5.2.3 服务监控主程序服务监控主程序使用BW实现, 主要逻辑使用Java程序实现。5.2.3.1 服务监控主程序启动配置文件(1) tibco.service_monitor.domaindomain1,domian2,domain3(2) tibco.service_monitor.DBURL(3) tibco.service
36、_monitor.DBusername(4) tibco.service_monitor.DBpassword(5) tibco.service_monitor.RvDaemon(6) tibco.service_monitor.RvNetwork(7) tibco.service_monitor.RvService(8) tibco.service_monitor.JmsProviderUrl5.2.3.2 服务监控主程序主流程图7 服务监控程序主流程图5.2.4 服务监控任务主程序创建多个线程来运行工作任务。工作任务有两个：服务调用信息接收存储任务和服务控制任务。5.2.4.1 服务调用信
37、息获取任务图8 服务调用信息接收存储流程图服务调用信息获取任务循环判断程序是否关闭，如果没有关闭，则从消息中间件上接收服务调用消息，更新内存中服务实例的相关信息，然后将调用信息写入数据库的相应表单。5.2.4.2 服务控制任务图9 服务控制流程图服务控制任务循环判断程序是否关闭，如果没有关闭，根据内存中应用实例和服务实例的状态信息，判断是否符合服务控制策略的条件，满足条件时通知运维人员，并做相应的服务控制操作。 5.2.5 服务监控基础功能模块基础功能模块包括配置文件读取，日志，线程创建管理，Hawk访问，消息收发，数据库操作六个模块。5.3 服务接口规范5.3.1 服务处理成功失败定义规范对
38、于封装已有业务应用的服务，接口调用层次如下(1) 业务应用的接口，在服务内部被调用。(2) 服务对外提供的接口，由服务调用者调用。服务封装已有应用，提供一定的功能。从功能是否可用这个角度，定义服务接口调用返回值类别如下：(1) 正常结果：服务提供的功能可用，返回业务层的正常结果。(2) 异常结果：服务提供的功能可用，但返回业务层异常结果。如输入值超出范围。(3) 错误：服务提供的功能不可用，返回服务错误结果。如已有业务应用不可连接，调用已有业务应用接口超时，服务忙等。服务调用成功定义：调用服务接口返回值为以上定义的正常结果或异常结果。服务调用失败定义：调用服务接口返回值为以上定义的错误结果。服
39、务调用成功失败次数统计即在一定的服务调用次数范围内，区别服务功能可用时的调用次数和服务功能不可用时的调用次数。5.3.2 服务调用方规范服务调用请求里需要包含调用方应用系统名。5.3.3 服务流量控制规范服务负载过大的事件会在整个系统中发布，服务调用方可以直接接收该信息。同时服务提供方也会在服务调用应答里添加服务负载过大的输出项，输出项包含在SOAPFault标签中，服务调用方收到此应答后，应该主动暂停发送服务请求。5.4 服务实现规范5.4.1 服务调用信息规范服务实现内部需要记录服务调用处理开始时间，结束时间，服务调用是否成功，调用输入输出等内容，在调用处理结束后，将此信息以消息的形式发送
40、给服务监控程序。5.4.2 服务调用信息消息规范服务调用信息按定义的格式构造成消息。其中调用输入，输出数据按定义的格式序列化为字符串。服务调用输入输出数据序列化格式定义：Message Body := ;*Field value := |Scale type value := |Nested value := |Array value := ;*Array item := |Class value := Field value;*SID := 0-9|(1-90-9*) e.g. 123456Integer := +|-?(0-9|(1-90-9*) e.g. -123456 +123456
41、123456Decimal := (.0-9*)? e.g. 123.123 123. 123Char := e.g. A 中 / 假如字符为, , ;, ，则在前面加上转义String := * e.g. A中Date := e.g. 20030507 20081211Time := (.SSS)? e.g. 000000.000 121109DateTime := e.g. 20030507 000000.0006 编码规则6.1 服务流程调用号服务流程调用号的编码规则是：XXXX-YYYY-ZZZZ ，其中第一组四位字符代表监控域，第二组四位字符代表服务应用，第三组四位字符代表该服务应用
42、下的服务。6.2 系统调用方 应用系统模块中，系统调用方的编码规则是：AAA-BBB-999,其中第一组三位字母代表主系统代码，第二组三位字母代表子系统代码，第三组三位数字代表系统的流水码。7 系统安全性和出错处理设计7.1 安全性ESB平台监控系统只是在内网运行，并且监控系统不会对在ESB平台运行的程序产生实质性的影响，所以监控系统采用的是用户名+密码验证的方式保证系统的安全。7.2 出错处理 如果被监控的服务实例发生异常，会通过邮件的方式发送给运维人员。8 参考文档8.1 Hawk介绍Hawk是一个用于监控分布式应用和操作系统的工具，Hawk与各监控参与方通过TIBCO消息机制进行通信。H
43、AWK作为ESB平台的监控工具，能对ESB平台进行一定程度的监控，但是不能满足ESB平台服务监控的全部需求，而本系统使用HAWK和其他定制化程序实现ESB平台服务监控需求。传统的监控架构，采用集中式的单一控制台管理模式，高度依赖于轮询，因此占用了大量的网络带宽并且影响了系统的执行效率，同时无法对分布式的应用进行监控管理。Hawk是一种分布式的、自治的和基于规则的智能代理。Hawk像一个管理者分布到每一个节点上，基于事件的触发产生消息，不需要进行轮询，不需要中央控制台，占用较少的网络带宽和系统资源。图 10 Hawk架构运行在各个物理服务器上的Hawk代理获得被监控对象的信息，通过TIBCO消息总线以HawkHawk地方未知未位置透明和分布式方式将监控信息发送到监控管理端。同时Hawk提供了控制调用功能(Invoke)，对服务的状态信息进行实时获取，甚至可以对服务的运行发布控制指令。第 37 页 共 37 页
