CN108304211A - 一种服务地图构建方法及装置 - Google Patents

Abstract

本发明提供了一种服务地图构建方法及装置。该方法包括：采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；获取各个服务规格化对象的调用关系；根据所述各个服务规范化对象的调用关系生成服务关系文件；根据所述服务关系文件构建服务地图。本发明实施例克服了现有的管理服务工作量大、无法清晰展示服务关系的缺陷，通过服务地图对服务关系进行展示，提升了系统的透明度，有助于业务系统的开发及维护。

Description

一种服务地图构建方法及装置

技术领域

本发明涉及计算机技术领域，具体涉及一种服务地图构建方法及装置。

背景技术

目前的大型业务系统都拥有丰富的服务资源，通过流程编排工具组合现有服务解决业务问题是开发人员经常使用的一种方式，服务之间的组合及调用关系是开发人员在开发阶段中形成生的，假如一个业务需求需要编排一组服务被一个新的服务A调用，以后服务A也会因新的需求被其他服务编排使用，如此往复，服务的使用及服务间的调用关系将会极其复杂，甚至连开发人员也未必理的清楚。

针对服务资源的管理，目前有两种方式：一种是文档记录管理，即对开发及发布的服务采用文档记录的形式进行管理；另一种是企业服务总线(Enterprise Service Bus，ESB)工具注册管理，企业通过购买ESB产品对服务资源进行管理，对需要对外发布的接口进行注册，注册之后，可以提供外部系统使用。

然而，针对千万行代码的大型业务系统，手工进行文档记录无法实现对服务的动态及时的管理，对服务的检索及分析将非常困难，管理工作量非常大。现有的服务资源管理中服务关系不清晰，无处可查，服务接口出现故障时，不知道该服务接口被哪些服务调用，不能对该接口进行停启操作，避免其他服务接口继续调用该接口，故障处理困难。同时，现有技术不能实现精确的标准化管理，缺乏统一标准，模块边界不清晰，服务开发重复严重。

发明内容

本发明实施例提供一种服务地图构建方法及装置，用于解决现有的管理服务工作量大、无法清晰展示服务关系的问题。

本发明实施例提供了一种服务地图构建方法，包括：

采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

获取各个服务规格化对象的调用关系；

根据所述各个服务规范化对象的调用关系生成服务关系文件；

根据所述服务关系文件构建服务地图。

可选地，所述采集业务系统的各个服务的服务属性，包括：

在各个服务的需求分析阶段采集所述各个服务的需求属性；

在各个服务的开发阶段采集所述各个服务的实现属性；

在各个服务的运行阶段采集所述各个服务的签名属性；

在各个服务的维护阶段采集所述各个服务的管理属性。

可选地，所述获取各个服务规格化对象的调用关系包括：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；

根据所述调用数据获取调用关系。

可选地，所述根据所述各个服务规范化对象的调用关系生成服务关系文件，包括：

确定各个服务规范化对象的服务类型；

根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

可选地，所述根据各个服务类型的服务规范化对象的调用关系生成服务关系文件，包括：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。

本发明实施例提供了一种服务地图构建装置，包括：

服务规格化对象构建单元，用于采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

调用关系获取单元，用于获取各个服务规格化对象的调用关系；

服务关系文件生成单元，用于根据所述各个服务规范化对象的调用关系生成服务关系文件；

服务地图构建单元，用于根据所述服务关系文件构建服务地图。

可选地，所述服务规格化对象构建单元包括：

需求属性采集模块，用于在各个服务的需求分析阶段采集所述各个服务的需求属性；

实现属性采集模块，用于在各个服务的开发阶段采集所述各个服务的实现属性；

签名属性采集模块，用于在各个服务的运行阶段采集所述各个服务的签名属性；

管理属性采集模块，用于在各个服务的维护阶段采集所述各个服务的管理属性。

可选地，所述调用关系获取单元进一步用于：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；根据所述调用数据获取调用关系。

可选地，所述服务关系文件生成单元包括：

服务类型确定模块，用于确定各个服务规范化对象的服务类型；

服务关系文件生成模块，用于根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

可选地，所述服务关系文件生成模块进一步用于：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。

本发明实施例提供的服务地图构建方法及装置，采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；获取各个服务规格化对象的调用关系；根据所述各个服务规范化对象的调用关系生成服务关系文件；根据所述服务关系文件构建服务地图。本发明实施例克服了现有的管理服务工作量大、无法清晰展示服务关系的缺陷，通过服务地图对服务关系进行展示，提升了系统的透明度，有助于业务系统的开发及维护。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例的服务地图构建方法的流程示意图；

图2是本发明一个实施例的服务规格化对象的示意图；

图3是本发明一个实施例的各个服务规格化对象的调用关系的示意图；

图4是本发明一个实施例的服务关系模型的示意图；

图5是本发明一个实施例的服务地图模型的示意图；

图6是本发明一个实施例的服务地图构建装置的结构示意图；

图7是本发明一个实施例的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1是本发明一个实施例的服务地图构建方法的流程示意图。如图1所示，该实施例的方法包括：

S11：采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

需要说明的是，本发明实施例中不同的服务属性面向不同的人员，不同的服务属性在服务生命周期不同阶段产生，分别由不同的人员维护。服务规格化对象以一定的数据结构将采集的服务的服务属性进行保存。

S12：获取各个服务规格化对象的调用关系；

在实际应用中，业务系统通常部署多个节点，从某一节点采集调用关系是不全面的，需要从每个节点采集调用关系。调用是某个服务规格化对象对应的程序的执行交给其他服务规格化对象对应的程序，同时保存必要的信息，从而使被调用的程序执行完毕后返回到调用点继续执行。举例来说，服务规格化对象A对应的程序在执行中需要调用执行服务规格化对象B对应的程序，则服务规格化对象的调用关系为服务规格化对象A调用服务规格化对象B。

S13：根据所述各个服务规范化对象的调用关系生成服务关系文件；

需要说明的是，本发明实施例确定各个服务规范化对象的服务类型，根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

S14：根据所述服务关系文件构建服务地图；

在实际应用中，借助使用一些开源的js插件根据服务关系文件绘制服务地图，生成右键菜单，可以查看服务对象的属性。服务地图绘制时，需要考虑屏幕的分辨率及用户对浏览器窗口的缩放操作。

本发明实施例提供的服务地图构建方法，克服了现有的管理服务工作量大、无法清晰展示服务关系的缺陷，通过服务地图对服务关系进行展示，提升了系统的透明度，有助于业务系统的开发及维护。

在本发明实施例的一种可选的实施方式中，与图1中的方法类似，所述采集业务系统的各个服务的服务属性，如图2所示，包括：

在各个服务的需求分析阶段采集所述各个服务的需求属性；

在各个服务的开发阶段采集所述各个服务的实现属性；

在各个服务的运行阶段采集所述各个服务的签名属性；

在各个服务的维护阶段采集所述各个服务的管理属性。

需要说明的是，需求属性面向需求者，在需求分析阶段完成，需求者通过需求管理平台系统进行维护；实现属性面向服务开发者，开发者通过代码定义实现；签名属性面向服务使用者，可在服务规格化对象生成过程中获取；管理属性面向维护者，定义管理属性的注解标准，编写在服务代码中，通过JDK注解方法来识别程序中服务对象，对服务注解进行解析，解析出服务属性。

在实际应用中，进行服务接口检查，检查每个服务接口是否都有相应的接口类和实现类；生成服务属性Key值，建立服务属性对象关联关系，系统中的每个服务都是唯一的，给每个服务分配一个Key值，通过Key值关联服务的需求属性、签名属性、实现属性及管理属性；根据实现属性及管理属性，生成签名属性；将服务规格化对象保存在数据库中。

具体地，所述获取各个服务规格化对象的调用关系包括：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；

根据所述调用数据获取调用关系。

图3是本发明一个实施例的各个服务规格化对象的调用关系的示意图。实现属性中的服务接口、服务实现类有一定的命名规则及关键字，设置成抽象表达式，系统运行过程中，可以获取到服务对象的接口名称、实现类名称，然后与抽象表达式进行匹配，进而识别出服务对象。服务关系采集程序通过Java拦截器实现，根据服务对象的关键属性实现对所有服务对象调用的拦截，获取运行时刻的调用数据(调用的类名及方法名)。调用数据包括前服务节点、当前服务节点和后服务节点。如果前服务节点或后服务节点不存在，用○表示。

可选地，所述根据各个服务类型的服务规范化对象的调用关系生成服务关系文件，包括：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。

如图4所示，本发明实施例的服务关系模型纵向分为4个层次，业务层、中心服务层、组件服务层和原子服务层。业务层中的服务指流程服务，通过编排中心服务实现；中心服务是各中心向外提供的服务，由ESB向外开放；组件服务是封装的可重用的功能块，不对外开放，仅供中心服务编排引用；原子服务实现对数据库的增、删、改、查操作。服务层间的调用规则是业务服务调用中心服务、中心服务调用组件服务，组件服务调用原子服务，不允许跨层调用。

以下以图3中的调用关系为例说明生成服务关系文件的具体过程。

首先确定各个服务规范化对象的服务类型：中心服务节点：①②③；组件服务节点：④⑤⑥；原子服务节点：⑦⑧。

然后根据各个服务类型的服务规范化对象的调用关系生成服务关系文件：

(1)中心服务层关系识别，由中心服务节点及调用顺序进行识别。中心服务有①②③3个节点，调用关系有○①②与②③○两条记录，从第一条记录前是○可以判断出①是起始节点,从第二条记录最后是○可以判断出③是最后一个节点。由此可以推导出3个节点的服务关系是：①→②→③

(2)组件服务层关系识别，由组件服务节点及调用顺序进行识别。组件服务节点有④⑤⑥3个节点，调用顺序④⑤⑥与⑤⑥⑦。由此可以推导出3个节点的服务关系是：④→⑤→⑥

(3)原子服务层关系识别,由原子服务节点及调用顺序进行识别。原子服务节点有⑦⑧，无调用顺序记录，无调用关系。

(4)层间服务关系识别，根据有服务调用顺序记录有跨层节点进行识别。

中心服务层与组件服务层关系识别。①②④，其中②为中心服务节点，④为组件服务层节点，由此可以推导出②与④有层间服务关系②→④

组件服务层与原子服务层关系识别。⑥⑦○与⑥⑧○，其中⑥为组件服务层节点，⑦⑧为原子服务层节点，由此可以推导出⑥与⑦⑧有层间服务关系

综上可以得到完整的服务关系如下所示：

图5是本发明一个实施例的服务地图模型的示意图。如图5所示，本发明实施例从多维度，不同面展示服务状态、属性、关系及版本变迁过程，立体的呈现出了服务全生命周期的变迁过程。正对面呈现是面向不同用户用到的属性；右侧面从外向里看，呈现的是一个版本的服务集合；横切后从上往下看呈现的一个版本的所有的服务关系；纵切呈现的是一个从不同用户视角观察到的服务属性；垂直方向代表时间周期，呈现服务族的版本变化。

本发明实施例的服务地图构建方法，在业务系统运行状态下，实时、动态、全面采集服务的调用关系，及时呈现服务关系的变化，采集效率及质量非常高。从多维度，不同面展示服务状态、属性、关系及版本变迁过程，立体的呈现出了服务全生命周期的变迁过程，有助于解决服务在开发、运维及管理中出现的问题。本发明实施例提出的4层服务关系模型，定义了每层服务的应用范围及访问规则，有助于理顺服务间的调用关系，通过地图式的服务关系展示，能够极大提升系统的透明度，促进运维人员对系统的感知。

以下以某电信公司业务支撑CRM系统(以下简称CRM系统)为例，说明本发明实施例的服务地图构建方法的工作原理。

该CRM系统服务标准化程度不够，造成开发成本高，维护工作量大，主要表现在：系统烟囱式建设严重，相同功能及接口重复开发；多渠道规则不一致，造成客户感知不一致引起大量投诉。

开发人员在开发过程中按照本发明实施例的标准进行编码并注解，以便能够识别服务相关信息。本发明实施例的标准包括服务定义、服务签名、管理属性、服务层次分类等，比如：

服务定义：要求有接口类名、服务方法、出入参数定义等

示例：public String IProductCent4ServSV.getAttrsMapByServId(longparamLong)

服务签名：包括服务名称、出入参数描述、功能描述等。

示例：服务名称getAttrsMapByServId；入参名称：paramLong，类型：long；出参名称:result,类型：String；功能描述：根据产品编号查询销售策划

管理属性：包括服务名称、所属中心、服务描述、服务版本等。

示例：@CenterSrvAnno(name＝"根据产品编号查询销售策划",centerCode＝"PRODUCT",desc＝"根据产品编号获取当前发布版本的可销售策划列表",ver＝"1.0”，。。。)

服务层次：服务关系模型分4个层次，包括业务层，中心服务层、组件服务层、原子服务层，定义如下：busi_layer,center_layer,com_layer,core_layer

示例：@CenterSrvAnno(name＝"根据产品编号查询销售策划",centerCode＝"PRODUCT",desc＝"根据产品编号获取当前发布版本的可销售策划列表",ver＝"1.0”，srv_layer＝”center_layer”)

本发明实施例在业务系统运行时间动态采集服务调用关系，以便后续进行规格化处理，收集的关系信息包括：前服务节点，当前服务节点，后服务节点。

本发明实施例根据服务规格模型和服务关系模型数据要求的属性进行填充，构建服务规格对象。

服务运行出现故障时，维护人员打开服务地图页面，借助服务地图进行故障定位，在服务地图页面，根据服务名称可以查询该服务被那些业务流程调用及调用的先后次序，实现了服务可见、关系可见，提高了系统透明度，提高了系统运维人员定位问题、解决问题的速度。

开发人员根据需求开发服务时，进入服务查询页面，根据服务目录、服务名称、服务编码等信息可以查询服务，可以展示服务名称、服务编码、所属中心、服务类型、服务详情，根据系统提供的这些信息，足以协助开发人员判断该需求是否新开发服务。CRM系统开户，仅“开户”逻辑变更就涉及180处相关代码修改，如果有此系统协助开发人员，将大大降低这种情况出现的几率。

图6是本发明一个实施例的服务地图构建装置的结构示意图。如图6所示，本发明实施例的装置包括服务规格化对象构建单元61、调用关系获取单元62、服务关系文件生成单元63和服务地图构建单元64，具体地：

服务规格化对象构建单元61，用于采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

调用关系获取单元62，用于获取各个服务规格化对象的调用关系；

服务关系文件生成单元63，用于根据所述各个服务规范化对象的调用关系生成服务关系文件；

服务地图构建单元64，用于根据所述服务关系文件构建服务地图。

本发明实施例提供的服务地图构建装置，克服了现有的管理服务工作量大、无法清晰展示服务关系的缺陷，通过服务地图对服务关系进行展示，提升了系统的透明度，有助于业务系统的开发及维护。

可选地，服务规格化对象构建单元61包括：

需求属性采集模块，用于在各个服务的需求分析阶段采集所述各个服务的需求属性；

实现属性采集模块，用于在各个服务的开发阶段采集所述各个服务的实现属性；

签名属性采集模块，用于在各个服务的运行阶段采集所述各个服务的签名属性；

管理属性采集模块，用于在各个服务的维护阶段采集所述各个服务的管理属性。

调用关系获取单元62进一步用于：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；根据所述调用数据获取调用关系。

可选地，服务关系文件生成单元63包括：

服务类型确定模块，用于确定各个服务规范化对象的服务类型；

服务关系文件生成模块，用于根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

可选地，所述服务关系文件生成模块进一步用于：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。

本发明实施例的服务地图构建装置可以用于执行上述方法实施例，其原理和技术效果类似，此处不再赘述。

图7是本发明一个实施例的电子设备的结构示意图。

参照图7，电子设备包括：处理器(processor)71、存储器(memory)72和总线73；其中，

处理器71和存储器72通过总线73完成相互间的通信；

处理器71用于调用存储器72中的程序指令，以执行上述各方法实施例所提供的服务地图构建方法。

此外，上述的存储器32中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本实施例提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的服务地图构建方法。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的服务地图构建方法。

本发明实施例提供的服务地图构建方法及装置，采集业务系统的各个服务的服务属性，分别对所述各个服务根据对应的服务属性构建服务规格化对象；获取各个服务规格化对象的调用关系；根据所述各个服务规范化对象的调用关系生成服务关系文件；根据所述服务关系文件构建服务地图。本发明实施例克服了现有的管理服务工作量大、无法清晰展示服务关系的缺陷，通过服务地图对服务关系进行展示，提升了系统的透明度，有助于业务系统的开发及维护。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

需要说明的是术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明的说明书中，说明了大量具体细节。然而能够理解的是，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。类似地，应当理解，为了精简本发明公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释呈反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

以上实施例仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种服务地图构建方法，其特征在于，包括：

采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

获取各个服务规格化对象的调用关系；

根据所述各个服务规范化对象的调用关系生成服务关系文件；

根据所述服务关系文件构建服务地图。

2.根据权利要求1所述的方法，其特征在于，所述采集业务系统的各个服务的服务属性，包括：

在各个服务的需求分析阶段采集所述各个服务的需求属性；

在各个服务的开发阶段采集所述各个服务的实现属性；

在各个服务的运行阶段采集所述各个服务的签名属性；

在各个服务的维护阶段采集所述各个服务的管理属性。

3.根据权利要求1所述的方法，其特征在于，所述获取各个服务规格化对象的调用关系包括：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；

根据所述调用数据获取调用关系。

4.根据权利要求1所述的方法，其特征在于，所述根据所述各个服务规范化对象的调用关系生成服务关系文件，包括：

确定各个服务规范化对象的服务类型；

根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

5.根据权利要求4所述的方法，其特征在于，所述根据各个服务类型的服务规范化对象的调用关系生成服务关系文件，包括：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。

6.一种服务地图构建装置，其特征在于，包括：

服务规格化对象构建单元，用于采集业务系统的各个服务的服务属性，根据对应的服务属性分别为所述各个服务构建服务规格化对象；

调用关系获取单元，用于获取各个服务规格化对象的调用关系；

服务关系文件生成单元，用于根据所述各个服务规范化对象的调用关系生成服务关系文件；

服务地图构建单元，用于根据所述服务关系文件构建服务地图。

7.根据权利要求6所述的装置，其特征在于，所述服务规格化对象构建单元包括：

需求属性采集模块，用于在各个服务的需求分析阶段采集所述各个服务的需求属性；

实现属性采集模块，用于在各个服务的开发阶段采集所述各个服务的实现属性；

签名属性采集模块，用于在各个服务的运行阶段采集所述各个服务的签名属性；

管理属性采集模块，用于在各个服务的维护阶段采集所述各个服务的管理属性。

8.根据权利要求6所述的装置，其特征在于，所述调用关系获取单元进一步用于：

获取所述业务系统运行过程中各个服务规格化对象的调用数据，所述调用数据包括前服务节点、当前服务节点和后服务节点；根据所述调用数据获取调用关系。

9.根据权利要求6所述的装置，其特征在于，所述服务关系文件生成单元包括：

服务类型确定模块，用于确定各个服务规范化对象的服务类型；

服务关系文件生成模块，用于根据各个服务类型的服务规范化对象的调用关系生成服务关系文件。

10.根据权利要求9所述的装置，其特征在于，所述服务关系文件生成模块进一步用于：

根据中心服务节点之间的调用关系识别中心服务层关系；

根据组件服务节点之间的调用关系识别组件服务层关系；

根据原子服务节点之间的调用关系识别原子服务层关系；

根据跨层服务节点之间的调用关系识别层间服务关系；

根据所述中心服务层关系、组件服务层关系、原子服务层关系及层间服务关系生成服务关系文件。