ESB平台服务管理系统概要设计说明书(共38页).doc

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设计约束.9开发过程.9运行环境配置.102.2设计策略和方法.102.3系统技术结构.112.4面向层次的技术架构构成.133业务监控分析业务监控分析.153.1业务监

2、控总体需求.153.2业务监控流程介绍.154功能模块概述功能模块概述.174.1标准代码管理模块.17模块描述.17功能操作.17信息结构.19数据流图.194.2业务信息管理.19模块描述.19功能操作.20信息结构.20数据流图.204.3业务流程管理.21模块描述.21功能操作.21信息结构.21数据流图.214.4业务进程管理.21模块描述.21功能操作.21信息结构.21数据流图.214.5业务预警管理.22模块描述.22功能操作.22信息结构.22数据流图.224.6用户权限管理.22模块描述.22功能操作.22信息结构.22数据流图.224.7业务监控的展示.23模块描述.23

3、功能操作.23数据流图.234.8数据统计分析.23模块描述.23功能操作.23数据流图.235服务监控服务监控.245.1服务监控相关数据流图.245.2服务监控模块设计.25服务信息监测模块.25服务控制模块.27服务监控主程序.28服务监控任务.30服务监控基础功能模块.325.3服务接口规范.32服务处理成功失败定义规范.32服务调用方规范.33服务流量控制规范.335.4服务实现规范.33服务调用信息规范.33服务调用信息消息规范.346编码规则编码规则.356.1服务流程调用号.356.2系统调用方.357系统安全性和出错处理设计系统安全性和出错处理设计.367.1安全性.367.

4、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 服务内部发送服务信息示意图.36图 24 服务调用执行信息类型定义.36图 25 服务监控程序主流程图

5、.40图 26 服务调用信息接收存储流程图.41图 27 服务控制流程图.42图 28 HAWK架构.47表目录表 1 缩略语.61 引言引言1.1 目的目的编写本概要设计说明书的目的是对 ESB 平台服务管理系统当中业务监控系统进行总体设计的说明，包括业务监控流程、输入输出、与被监控系统的接口设计、数据库设计、预警设计和系统出错处理设计等。该概要设计是指导相关工作人员进行后续详细设计、数据库设计、编码、测试用例设计、系统部署的重要依据，是联结需求阶段和开发阶段指导性文档。1.2 文档范围文档范围系统名称：ESB 平台服务业务监控系统用户方：XXXX 银行开发方：ESB 平台开发小组任务提出方

6、：XXXX 银行任务承受方：XXXX 银行营运中心预期读者：系统设计开发人员、系统测试人员和用户使用人：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 系

8、统。表 1 术语和缩略语2 系统概述系统概述行内 SOA 是一种架构理念，通过松耦合方式更好的实现了软件资产的复用，因而可以很方便地构建业务敏捷的应用系统，以应对不断变化的业务需求。在 SOA 架构下的业务功能都会以不同的技术方式，以服务的形式提供服务请求方使用，在现在的运行环境中服务主要是通过 Java、.Net 和 BusinessWorks 进行服务封装和服务提供的，其中 ESB 作为主要的提供手段和服务介质。TIBCO ESB 产品本身具备非常强大的集成能力，提供了一系列适配器产品链接套装软件和技术基础设施，比如通过 Lotus Notes 适配器、Oracle 应用适配器和 MQ 适

9、配器等产品，方便通过 ESB 进行服务封装和服务提供。图 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 、 JDK 1.5；开发工具采用 MyEclipse6.0；数据库

12、为 Oracle10g()；采用 B/S(Browser/Server)技术进行软件开发，客户端操作系统为Windows2000、Windows2003、WindowsXP，客户端浏览器主要为IE6.0 或以上版本等软件。系统操作简便，用户界面友好，符合用户使用的习惯；系统响应速度快，运行稳定，用户使用时无等待感，查询或刷新时间不超过 10 秒；软件不能有空链接，软件应该能根据客户端机器分辨率(主要有800*600、1024*768 两种分辨率)自动合理布局；用户瞬间访问高峰时界面查询或刷新时间不超过 20 秒。系统能够支持 100 个以内的用户同时访问。客户机的最低配置为：256M 内存。2

13、.1.2 运行环境配置运行环境配置应用服务器为 Apache Tomcat ；应用服务器软件为 Oracle Application Server: app10g.；客户端操作系统为 Windows2000、Windows2003、WindowsXP，客户端浏览器主要为 IE6.0 或以上版本等软件。客户机的最低配置为：P4/256M 内存2.2 设计策略和方法设计策略和方法业务监控系统在设计时，将从以下几方面进行可复用性、可移植性、可靠性等方面的考虑：复用性的支持业务监控系统应对架构、代码等的复用性进行考虑，为行内其它项目做技术储备。对于系统的代码复用，可通过加强模块的合理分割来实现一部分类

14、似功能的代码复用，从而减少开发时间。移植性的支持本项目采用 Ajax+Spring+DAO 开发架构，使得每一层都以一种松耦合的方式彼此沟通，可移植性极强。可靠性的支持本系统的数据库使用 ORACLE。业务监控系统采用的开发架构对表示层采用 Dwr 实现、业务层采用 Spring 完成，持久层采用 DAO 来处理，而这个框架本身提供了底层的代码访问封装，开发人员只是调用接口实现业务逻辑处理。在这些支持软件的基础上所进行的应用开发，可靠性是有保证的。2.3 系统技术结构系统技术结构业务监控系目标图如下所示。整个业务监控系主要实现三大目标即：业务流进程跟踪监控、异常预警和数据统计分析。核心信息核心

15、信息数据库数据库业务流跟踪业务流跟踪根据预定规则，自动跟踪各业根据预定规则，自动跟踪各业务流进程，并适时动态显示，务流进程，并适时动态显示，方便各级领导和工作人员及时方便各级领导和工作人员及时关注业务流的进程状态，以便关注业务流的进程状态，以便合理的做合理的做出工作安排。出工作安排。业务流进程跟踪业务流进程跟踪业务流发生异常时，系统业务流发生异常时，系统能自动给相关技术和业务能自动给相关技术和业务人员通过短信或邮件的方人员通过短信或邮件的方式发出预警提醒，方便相式发出预警提醒，方便相关人员第一时间了解业务关人员第一时间了解业务流异常。流异常。业务、技术异常预警业务、技术异常预警异常预警异常预警

16、数据统计数据统计根据各业务流的基础信息，根据各业务流的基础信息，可对业务流涉及的业务按可对业务流涉及的业务按照多维度、全视角进行统照多维度、全视角进行统计分析，并为业务状态预计分析，并为业务状态预测提供基础信息。测提供基础信息。业务数据统计业务数据统计图2业务监控系统目标图 业务监控系统的功能架构是为实现端到端的业务进程跟踪监控，该系统功能模块主要包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户权限管理、系统接口和安全及审计管理等，核心模块为业务信息管理、业务流程管理和业务进程管理。业务监控系统标准代码管理业务信息管理业务流程管理业务进程管理进程预警管理用户权限

17、管理安全及审计管理系统接口业务流跟踪 异常预警数据统计图3 系统功能架构示意图业务监控系统在获取具体业务流的基础信息和进程信息的基础上，通过控制流程驱动和预警管理机制实现业务流跟踪时时动态图和数据统计；在发生异常时，通过与外部系统的接口实现邮件或短信提醒，进而通过人工干预，恢复业务流程的正常运转。 图 4 业务监控逻辑图 2.4 面向层次的技术架构构成面向层次的技术架构构成业务功能展示数据组件Event/Data/Remote Object Req/ResWeb Server用户控制器UCCApplication Server用户定义业务信息服务信息展现业务信息服务部署业务信息.异常管理工具类

18、日志管理UserDAODomainDAOAppinsDAO.数据库A 用户交互层B 交互控制层C 业务服务层D 公共服务层E 数据访问层F 数据存储层 图 5 面向层次视角的技术架构从面向层次设计的视角，可将系统设计为如下层次：用户交互层、交互控制层、业务服务层、公共服务层、业务流程管理扩展、数据访问层和数据存储层。 用户交互层，基于 Web2.0 实现技术，负责用户与系统的人机交互界面，为用户提供一定的本地计算能力。 交互控制层，负责为界面和业务服务之间进行数据转换，同时对系统的事务进行总体控制，隔离界面实现与后台服务实现，使后台业务服务实现更为标准化。 业务服务层，主要包括各类封装了业务实

19、现逻辑的业务服务组件，调用数据访问层的数据服务，本身不直接访问数据库。 公共服务层为整个应用的公共需求提供统一的、重用的服务。包括：日志、异常、事务、认证、校验等。 数据访问层，负责进行数据访问及系统间交互操作，关注数据的存取操作，不关心业务服务如何调用数据， 屏蔽对数据库表的直接 SQL 操作。3 业务监控分析业务监控分析3.1 业务监控总体需求业务监控总体需求业务监控系统的业务流程端到端跟踪监控的实现是在配置业务流程信息的前提下，对业务流进程信息进行管理，即在业务流程中，每次业务流经不同作业处理点（被监控点）时，应向业务监控系统发送状态消息（具体消息通过报文或消息的方式约定） ，实际操作过

20、程中，该系统可灵活的添加或减少作业处理点，通过对业务流程信息的管理实现具体业务端到端的业务流程跟踪监控；当系统业务流异常时，根据预先配置的预警规则，通过短信或邮件方式提醒预警提示人员；被监控系统每形成一条业务流时，应向监控系统发送业务基础信息，监控系统将以此自动生成一条监控信息和业务流程，并且该基础信息为业务流程含义展示和统计汇总提供数据。3.2 业务监控流程介绍业务监控流程介绍当业务系统生成一条具体业务流时，在初始点及各监控点应向监控系统发送消息，具体业务流程消息发送的方式为：在业务流起始时，向业务监控系统发送一条基础信息，监控系统据此自动生成一条业务流跟踪监控流程；在业务流程中，每一作业处

21、理点（即：监控点）接收到一条需处理作业时，向业务监控系统发送一条已接收到该作业的状态消息，当该作业处理点完成作业后，向下一作业处理点发送时，同步应向业务监控系统发送一条该作业处理结果的状态消息（状态消息可为：该作业内容更改并成功向下一作业处理点发送，或作业处理成功并向下一作业点发送，或拒绝作业返回至上一或几作业处理点，或流程结束） ；当在某监控点或流转中，由于系统技术原因发生异常，应向监控系统发送系统技术异常消息（如：无法发出、系统延时、系统无法接收等） ，以上发送的各类消息可在具体添加被监控系统时，约定消息内容。业务系统发送至监控系统的消息内容应包括：该具体作业流程的唯一标识代码（全流程不变

22、） ，本处理点名称代码，本节点所处系统代码；收发作业标识，收发类型（七种：1.正常接收；2.正常发送至下一作业处理点；3.退回上一或几作业处理点；4.作业流程终止并退出；5.技术延时异常;6.技术异常，系统终止;7.作业流程终止并退出，该类内容可在监控系统实现维护） ，内容更改标识，具体更改内容代码，更改后的具体内容。监控系统核心数据库监控基础信息业务流信息管理员输入基本信息注册服务系统基础信息代码业务流基础信息业务系统进程信息发起业务系统基础信息业务流基础信息业务流进程信息业务流跟踪显示业务流约定发送消息内容预警发送业务流基础信息业务流进程信息结束数据统计显示 图 6 业务监控进程示意图4

23、功能模块概述功能模块概述通过对业务需求的分析，要实现业务流程端到端的跟踪监控、异常预警和数据统计功能，本系统主要功能模块包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户及权限管理、进程跟踪展示、数据统计分析等部分，对于每一部分具体功能及信息分析逐一展开。4.1 标准代码管理模块标准代码管理模块4.1.1 模块描述模块描述为使整个系统内容规范、一致，便于与被监控系统定义业务信息、进程信息的内容，以及部分元数据与服务注册系统进行同步，本系统需建立标准代码管理，独立维护本系统所使用的标准代码，当与服务注册系统实现对接后，服务注册系统作为本系统部分标准代码源信息，通过接

24、口向本系统提供标准代码信息，本系统可关闭服务注册系统提供源数据部分的代码添加、修改功能，仅保留具体内容本系统是否可见功能。形成标准代码的目的是为保证系统间的标准信息格式定义一致，以及对业务及业务进程基础信息进行统计和分析提供便捷。本系统涉及到的主要标准代码包括：系统类别代码、系统代码、业务种类、业务流代码。4.1.2 功能操作功能操作代码添加代码添加用户填写代码详细信息，包括代码、名称、备注等，系统提供校验代码是否重复、是否符合约定格式、名称不能为空等功能，提交后在数据库中形成一条正确的新数据；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：代码、名称、备注等需填写

25、的详细信息；输出：对应的相关数据库表中增加一条正确记录。代码修改代码修改用户选中要修改的一条代码，可对代码、名称、备注等进行修改，系统对修改部分除提供与代码添加同样校验功能外，还应提供该代码是否已被引用等校验功能，对于已被引用和约定使用的代码，原则上不得进行修改，修改后系统更新数据库；参与者/角色：代码维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：对应的相关数据库表中一条记录数据发生变化。代码删除代码删除用户选中要删除的代码，系统应校验该代码是否已经被引用，若被引用应待引用记录全部删除后，方可进行删除，对于不能删除又需用户不可见的代码，提供客户

26、端是否隐藏（即客户端不可见，不可在引用）功能；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：无；输出：对应的相关数据表中一条记录被删除或发生变化。代码查询代码查询用户登录后，输入代码、名称等条件，进行代码查询，理论上各个字段都可以作为查询条件，并支持字母和汉字的模糊查询；描述：系统通过用户输入条件，查询相关记录；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：代码详细条目信息。4.1.3 信息结构信息结构标准代码主要包括：行内信息系统类别代码、信息系统代码、业务种类代码和业务流代码，前三类代码应与行内其他系统保持一致，待服务注册系统建成后

27、，通过数据库订阅等方式实现数据同步，本系统无须再修改，仅对其在本系统是否可见做调整，业务流代码是根据各业务系统的具体业务种类不同而形成不同业务流代码，作为具体业务流程的依据。系统代码表PK信信息息系系统统代代码码 信息系统名称FK1所属系统类别代码 是否可见 备注系统类别代码表PK系系统统类类别别代代码码 系系统统类类别别名名称称 是否可见 备注业务种类代码表PK业业务务种种类类代代码码 业务种类名称FK1所属信息系统代码 是否可见 备注业务流代码表PK业业务务流流代代码码 业务流名称FK1所属业务种类代码 是否可见 备注标准代码管理信息结构图4.1.4 数据流图数据流图4.2 业务信息管理业

28、务信息管理4.2.1 模块描述模块描述当业务系统发起一笔被监控的业务流程时，发起系统应根据系统接入时的约定，通过消息方式向监控系统发送该笔业务信息，作为监控系统自动建立一条具体业务流程的起始依据，并且为业务进程监控提供业务信息。本系统可人工修改此类基础消息（具体业务流程结束后，该类基础信息不得修改） 。在该具体业务流程运行中，某流程中合法用户对初始业务信息内容发生更改，本系统应能自动对已入库的数据进行修正；并且本系统可根据业务流状态，自动变更存储位置，即当具体业务流程未结束时，应一直存于进程中业务信息数据表，结束（包括取消、正常完成及合法终止）进程后，此基础信息应存于已完成业务信息表，已完成业

29、务信息表中内容为统计汇总功能提供数据。具体业务进程中的业务信息应包括：唯一标识（作为具体业务流程唯一标识） 、发起系统、发起单位、目标系统、目标单位、业务种类、涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人等，对于与固定字段无法对应的业务信息，应与预留字段对应，对于各预留字段，根据对应情况，逐步约定各预留字段对填入信息的要求。被监控系统在被接入前，双方应确定以上具体信息格式，对各字段应按照服务注册系统业务属性要求进行约定，并确定以上内容在被监控系统标准名称（即在原系统所使用的称谓） ，方便在浏览和统计时，依数据原本意义展现此类基础信息。4.

30、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

31、.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 模块描述模块描述4.8.2 功能操作功能操作4.8.3 数据流图数据流图5 服务监控服务监控服务监控程序是独立运行的程序，主动定时获取服务运行状态信息，接收服务调用信息并存入数据库供后续查询操作；同时服务监控程序可以接收用户方发来的主动服务控制请求，或者根据预定义的

32、服务控制策略，向运行态服务发出服务控制命令，也可以同时通过邮件通知系统运维人员。5.1 服务监控相关数据流图服务监控相关数据流图 （9）主动控制请求数据库-服务信息控制策略服务监控-信息获取服务监控-服务控制服务监控运维人员服务信息展现-信息获取服务信息展现-服务主动控制（6）服务状态信息 （3） 服务调用信息服务应用实例服务实例（2）服务调用信息（10）主动服务控制命令（8）服务控制命令（4）服务信息查询结果（7）服务信息 （5） 服务信息 （1） 服务状态信息图 3 服务监控操作流图服务监控程序包含两个主要的功能模块，服务信息获取模块和服务控制模块。服务信息获取模块通过接收包含服务调用信息

33、的消息(数据流 2)并存入数据库(数据流 3)。考虑到服务调用信息消息条数会比较多，使用一个消息队列会影响消息收发性能，所以一个应用实例下所有服务实例的调用信息消息使用同一个队列来收发。服务监控程序在启动后，根据数据库里的应用实例基本信息，决定在几个队列上监听消息。服务控制模块通过 HAWK 获取服务状态信息(数据流 6)，同时从数据库中获取服务基本信息和调用信息(数据流 7)，当满足预定义条件时，按既定规则控制服务运行(数据流 8)。使用 HAWK Agent 和应用实例进行通信，获取应用实例状态信息。每个应用实例含有一个或者多个HAWK Agent。5.2 服务监控模块设计服务监控模块设计

34、服务信息监测模块服务监控主程序服务控制模块基础功能模块日志模块线程管理模块RV消息收发模块HAWK应用模块配置项读取模块程序终止资源释放初始化资源创建服务调用信息获取模块服务自动监控模块数据库操作管理模块服务调用信息存储模块服务状态信息获取模块图 4 服务监控模块层次结构图服务监控程序主线程负责读取配置项，初始化创建资源，结束程序释放资源。服务监控程序执行两个主要的工作任务：获取服务调用信息并存库，获取服务状态信息根据预定义策略进行服务控制。各个任务由预先配置的一个或者多个线程运行。使用 HAWK 来获取服务运行状态信息和控制服务运行。服务的调用信息使用消息机制，调用信息按定义的格式序列化和反

35、序列化。5.2.1 服务信息监测模块服务信息监测模块服务调用信息获取模块服务调用信息获取模块服务内部流程的实现如图 6 所示。记录服务接口调用执行的相关信息，以消息的形式发送到消息中间件的队列上。服务信息监控程序循环地从队列上接收这些消息。队列的默认名称为：.Invokation record。图 5 服务内部发送服务信息示意图.1服务调用信息线格式服务调用信息线格式承载服务调用执行相关信息支持复杂类型，调用信息的类型定义如下：图 6 服务调用执行信息类型定义如果需要记录服务调用的输入和输出，可以按以下的序列化格式，将各种不同类型的输入数据和输出数据序列化为字符串。

36、表 2 服务调用报文结构序号序号命名命名参数类型参数类型说明说明约束条件约束条件是否必输是否必输1instancenameSTRING服务流程号参见编码规则Y2starttimeDATETIME流程开始时间Y3endtimeDATETIME流程结束时间Y4inovkerSTRING系统调用方参见编码规则Y5inputSTRING服务调用的输入N6outputSTRING服务调用的输出N7success STRING服务调用是否成功 1/成功 9/失败Y8 errorcodeSTRING服务调用发生异常时的异常码N服务调用信息存储模块服务调用信息存储模块服务监控程序接收到消息后，将

37、消息内容读取处理并插入数据库中对应的表中。在上文中提到每个应用实例中所有服务实例的调用记录存放在一个表中。表名为： SERVICEINVOKE。同时将服务实例的一部分调用记录信息记录在内存里，供服务控制使用。5.2.2 服务控制模块服务控制模块服务监控程序执行三种控制策略的服务控制操作。程序使用 HAWK API循环获取服务实例的状态信息，同时使用在内存中的服务调用记录信息，来进行状态判断，执行相应的控制操作。服务控制策略服务控制策略服务宕机服务宕机监测服务运行状态，当发现服务宕机时，通知运维人员或者自动重启服务。每个应用实例都有一个 HAWK Agent，当服务监控程序通过 H

38、AWK API 连接一个 HAWK Agent 失败，就可知道该 HAWK Agent 对应的服务应用已经宕机。服务控制策略服务控制策略服务调用失败服务调用失败统计服务调用处理成功失败次数，当最近一段时间内(比如最近 1 小时内)失败次数占总次数的百分比超过控制策略中的设置值时，通知运维人员。服务监控程序在内存中保存每个服务实例的服务调用成功与失败的次数，程序循环进行判断。服务控制策略服务控制策略服务负载过大服务负载过大根据服务实例当前的排队请求数，历史平均单次处理时间，最近 1 分钟或者 5 分钟的服务请求数来判断服务是否负载过大。通知运维人员，同时把该服务忙的信

39、息以主题消息的形式发布出去。服务调用者可以主动订阅服务状态事件消息，调整服务调用的时机和频率；或者服务应用实例订阅服务状态事件消息后，按既定的服务调用规范，服务直接给服务调用方返回服务忙的应答。判断负载过大策略规则如下：判断负载过大策略规则如下：(1)IF (排队请求数 排队请求数阀值) THEN IF(最近 1 分钟或者 5 分钟的服务请求数 0 ) THEN 服务负载过大;ELSE IF(排队请求数*历史平均单次处理时间 =1 分钟或者 5 分钟) THEN 服务负载过大;ELSE 服务负载正常; (2)IF(最近 1 分钟或者 5 分钟的服务请求数 服务请求数阀值)THEN IF (排队

40、请求数 0) THEN IF(最近 1 分钟或者 5 分钟的服务请求数*历史平均单次处理时间=1 分钟或者 5 分钟) THEN 服务负载过大; ELSE 服务负载正常; ELSE 服务负载正常; 服务监控程序在内存中保存每个服务实例的最近一段时间的服务调用请求次数，同时程序循环更新每个服务实例的当前排队请求数，来进行服务负载是否过大的判断。5.2.3 服务监控主程序服务监控主程序服务监控主程序使用 BW 实现, 主要逻辑使用 Java 程序实现。服务监控主程序启动配置文件服务监控主程序启动配置文件(1) domain1,domian2,domain3(2)(3)(4)(5)(6

41、)(7) ti(8) tibco.service_monitor.JmsProviderUrl服务监控主程序主流程服务监控主程序主流程一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一HAWK一一一一一一一一一一一一一HAWK Agent一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一一图 7 服务监控程序主流程图5.2.4 服务监控任务服务监控任务主程序创建多个线程来运行工作任务。工作任务有两个：服务调用信息接收存储任务和服务控制任务

42、。服务调用信息获取任务服务调用信息获取任务一一一一一一一一一一一一一一一一一一一一一一一一一一一图 8 服务调用信息接收存储流程图服务调用信息获取任务循环判断程序是否关闭，如果没有关闭，则从消息中间件上接收服务调用消息，更新内存中服务实例的相关信息，然后将调用信息写入数据库的相应表单。服务控制任务服务控制任务一一一一一一一一一一一一一一一一一一一一一一一一一一一一一图 9 服务控制流程图服务控制任务循环判断程序是否关闭，如果没有关闭，根据内存中应用实例和服务实例的状态信息，判断是否符合服务控制策略的条件，满足条件时通知运维人员，并做相应的服务控制操作。 5.2.5

43、服务监控基础功能模块服务监控基础功能模块基础功能模块包括配置文件读取，日志，线程创建管理，Hawk 访问，消息收发，数据库操作六个模块。5.3 服务接口规范服务接口规范5.3.1 服务处理成功失败定义规范服务处理成功失败定义规范对于封装已有业务应用的服务，接口调用层次如下(1) 业务应用的接口，在服务内部被调用。(2) 服务对外提供的接口，由服务调用者调用。服务封装已有应用，提供一定的功能。从功能是否可用这个角度，定义服务接口调用返回值类别如下：(1) 正常结果：服务提供的功能可用，返回业务层的正常结果。(2) 异常结果：服务提供的功能可用，但返回业务层异常结果。如输入值超出范围。(3) 错误

44、：服务提供的功能不可用，返回服务错误结果。如已有业务应用不可连接，调用已有业务应用接口超时，服务忙等。服务调用成功定义：调用服务接口返回值为以上定义的正常结果或异常结果。服务调用失败定义：调用服务接口返回值为以上定义的错误结果。服务调用成功失败次数统计即在一定的服务调用次数范围内，区别服务功能可用时的调用次数和服务功能不可用时的调用次数。5.3.2 服务调用方规范服务调用方规范服务调用请求里需要包含调用方应用系统名。5.3.3 服务流量控制规范服务流量控制规范服务负载过大的事件会在整个系统中发布，服务调用方可以直接接收该信息。同时服务提供方也会在服务调用应答里添加服务负载过大的输出项，输出项包含在 SOAPFault 标签中，服务调用方收到此应答后，应该主动暂停发送服