CN114968409A

CN114968409A - 软件服务复杂依赖关系的管理方法、装置和设备

Info

Publication number: CN114968409A
Application number: CN202210631025.6A
Authority: CN
Inventors: 姚宏宇; 朱朝强; 高维昌
Original assignee: BEIJING YOYO TIANYU SYSTEM TECHNOLOGY CO LTD
Current assignee: BEIJING YOYO TIANYU SYSTEM TECHNOLOGY CO LTD
Priority date: 2022-06-06
Filing date: 2022-06-06
Publication date: 2022-08-30

Abstract

本申请的实施例提供了软件服务复杂依赖关系的管理方法、装置、设备和计算机可读存储介质。所述方法包括在服务集成时，按照约定的规范撰写定义文件；所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系，与其它服务配置文件、配置分组、配置项的依赖关系；所述服务之间的依赖关系的最小粒度为服务组件；根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理。以此方式，可以为开源服务、采购产品以及自研应用提供统一的状态监控、配置管理能力。

Description

软件服务复杂依赖关系的管理方法、装置和设备

技术领域

本申请的实施例涉及服务依赖关系管理领域，尤其涉及软件服务复杂依赖关系的管理方法、装置、设备和计算机可读存储设备。

背景技术

随着信息技术的发展，各类信息化平台建设数量与日俱增，规模愈发庞大，结构也日趋复杂，往往需要几十个甚至上百个软件服务才能构建起所需的业务平台。平台上的软件通常分为三类：开源服务、采购产品、以及自研应用。开源服务中应用最多的是各种大数据服务，构建于在大数据之上，还有提供业务能力的其他采购产品或自研服务。在运维管理方面，通常采购Cloudera Manager或使用开源的Apache Ambari做为大数据运维管理工具，实现对大数据服务的配置、监控管理，使用Zabbix或Prometheus，实现对采购产品及自研应用的状态监控和告警。

软件服务之间存在着复杂的依赖关系，采购产品或自研应用运行在开源服务之上，启动/停止等操作需要严格按照依赖顺序执行。采购产品或自研应用也可能会引用开源服务的配置项或配置文件，例如：HDFS的hdfs-site.xml文件、Kafka通讯端口等，被上层服务大量的引用。随着服务升级、安全策略变更、以及性能要求的提升，在运维操作中，修改配置、启动/停止等操作的越来越频繁。有复杂依赖关系的软件服务，进行启动/停止、配置更新等操作时牵一发而动全身，需要登录到服务器进行修改并进行交叉验证，人工操作极易出错，在平台建设之后的实施和运维环节产生了巨大的工作量。Cloudera Manager和Apache Ambari针对Hadoop体系的部分大数据服务提供了配置管理、状态监控等运维工作，无法为第三方服务提供同等的管理粒度。Zabbix、Prometheus提供了进程级别的状态监控，但无法实现配置管理功能。目前市场上的应用只能为有限的服务提供有限的管理监控，亟需一种复杂依赖关系的软件服务管理方法，为开源服务、采购产品以及自研应用提供统一的状态监控、配置管理能力。

发明内容

根据本申请的实施例，提供了一种软件服务复杂依赖关系的管理方案。

在本申请的第一方面，提供了一种软件服务复杂依赖关系的管理方法。该方法包括：

在服务集成时，按照约定的规范撰写定义文件；所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系，与其它服务配置文件、配置分组、配置项的依赖关系；所述服务之间的依赖关系的最小粒度为服务组件；

根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理。

进一步地，所述根据所述定义文件更新平台所有服务之间的依赖关系链包括：

在服务注册、服务安装、服务启动、停止、服务卸载和服务禁用时，通过所述定义文件，获取服务间的依赖关系，并在服务激活时进行更新。

进一步地，所述根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理包括：

根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的配置引用关系管理；所述配置引用关系包括配置项引用、配置分组引用和配置文件引用；

其中，配置项为配置的基础信息，存储于配置仓库中。

进一步地，所述配置仓库包括：

默认配置库，用于保存服务的默认配置，在服务注册时将服务配置信息写入数据库；

实例配置库，用于保存服务在每个部署节点上的配置；其中，每个部署节点为一个服务组件实例；

历史配置库，用于存储服务在实例库中的配置信息；

全局配置库，用于在定义服务将配置项声明为全局配置时，保存该配置项的的真实值。

进一步地，还包括：

若所述配置项的值在集群内唯一，且该配置项能够被其它服务引用时，则将该配置项声明为全局变量；所述全局变量包括集群全局变量和服务全局变量；

其中，所述集群全局变量为根据服务组件安装节点数量动态变化的全局变量；

所述服务全局变量为集群内值唯一的全局变量。

进一步地，所述完成服务间的配置引用关系管理包括：

将同一类功能的配置项定义为一个配置分组，将所述配置分组提供给其它服务进行使用。

根据所述定义文件更新平台所有服务之间的依赖关系链，完成配置项之间的联动关系管理；

当用户修改配置时，检查被修改的配置项是否存在联动关系，若是，则将修改后的值与目标值进行比对，根据比对结果执行对应的管理操作；所述管理操作包括变更配置文件启用/禁用状态、变更配置分组启用/禁用状态和/或变更指定配置项的值；

完成管理操作后，根据配置分组、配置项生成配置文件，发布到目标服务器指定位置，完成配置更新。

在本申请的第二方面，提供了一种软件服务复杂依赖关系的管理装置。该装置包括：

定义模块，用于在服务集成时，按照约定的规范撰写定义文件；所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系，与其它服务配置文件、配置分组、配置项的依赖关系；所述服务之间的依赖关系的最小粒度为服务组件；

管理模块，用于根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理。

在本申请的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

在本申请的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如根据本申请的第一方面的方法。

本申请实施例提供的软件服务复杂依赖关系的管理方法，通过在服务集成时，按照约定的规范撰写定义文件；所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系，与其它服务配置文件、配置分组、配置项的依赖关系；所述服务之间的依赖关系的最小粒度为服务组件；根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理，为开源服务、采购产品以及自研应用提供了统一的状态监控、配置管理能力。

应当理解，发明内容部分中所描述的内容并非旨在限定本申请的实施例的关键或重要特征，亦非用于限制本申请的范围。本申请的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本申请各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了根据本申请的实施例的软件服务复杂依赖关系的管理方法的流程图；

图2出了根据本申请的实施例的服务与配置关系示意图；

图3出了根据本申请的实施例的服务依赖关系管理示意图；

图4出了根据本申请的实施例的配置项引用关系管理流程图；

图5出了根据本申请的实施例的配置文件/分组引用关系管理流程图；

图6出了根据本申请的实施例的配置项之间的联动关系管理流程图；

图7示出了根据本申请的实施例的软件服务复杂依赖关系的管理装置的方框图；

图8示出了适于用来实现本申请实施例的终端设备或服务器的结构示意图。

具体实施方式

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

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

名词解释

服务：提供一类业务能力的软件称之为服务。一个服务可以以单机的形式运行在一个主机上，也可以以分布式的方式运行在多个主机上，例如HDFS；

服务组件：服务中的一类功能称之为服务组件。一个服务可以包含一个或多个服务组件，例如HDFS的服务组件包括NameNode、DataNode等；

配置文件：为服务提供运行参数和初始设置的文件称之为配置文件。一个服务可以有多个配置文件，例如hdfs-site.xml，core-site.xml等；

配置分组：当多个配置项共同完成一个服务功能的时候，可以将这多个配置项定义为一个配置分组。配置分组可以被其它的服务引用，可以设置启用/禁用状态；

配置项：服务配置文件中的最小单元。例如HDFS中的hadoop.http.logs.enabled等。

图1示出了根据本公开实施例的软件服务复杂依赖关系的管理方法的流程图。所述方法包括：

S110，在服务集成时，按照约定的规范撰写定义文件。

其中，所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系（强制依赖），与其它服务配置文件、配置分组、配置项的依赖关系（非强制依赖）；所述服务之间的依赖关系的最小粒度为服务组件。

进一步地，所述配置项可直接引用，配置文件和配置分组需要声明引用位置。

通常所述服务间的依赖关系包括：假设服务A有组件a1、a2，服务B有组件b1、b2。在服务A的定义文件中，可以定义a1依赖b1。无法直接定义服务A依赖服务B。即，服务之间的依赖关系实质上就是服务组件之间的依赖关系。服务组件是服务之间依赖关系的最小粒度，也是唯一粒度。

在一些实施例中，服务与配置的关系，如图2所示，一个服务可以有多个服务组件。一个服务组件可以有多个配置文件，一个配置文件也可以被多个服务组件引用。一个配置文件可以包含多个配置项或配置分组，配置项和配置分组可以被多个配置文件引用。一个配置分组可以有多个配置项，一个配置项可以被多个配置分组引用。一个配置项可以定义一个配置关联策略。

其中，所述配置关联策略在服务定义文件之外，使用单独定义文件进行描述，用于配置项之间的联动关系管理。

在一些实施例中，服务依赖可分为本地依赖（local）和集群依赖（remote）。

例如，服务A和服务B，服务B依赖于服务A运行：

若服务A和服务B必须安装在同一个主机上，则服务A和服务B的依赖关系为本地依赖；

若服务A和服务B可以在集群中的不同主机上运行，则服务A和服务B的依赖关系为集群依赖。

在一些实施例中，约定的规范可根据实际的应用场景（应用环境），进行具体设定。例如，管理需求、服务结构、类型和/或服务器配置等。

S120，根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理。

在一些实施例中，如图3所示，在服务注册、服务安装、服务启动、停止、服务卸载和服务禁用时，通过所述定义文件，获取服务间的依赖关系，并在服务激活时进行更新。即，进行服务依赖关系管理。

具体地，在服务注册时进行依赖关系检查，若当前服务依赖的服务不存在，则提示不允许激活；

在服务安装时进行依赖关系检查，选择安装节点后，若节点上缺少依赖服务，则提示不允许安装；

在服务启动、停止时进行依赖关系检查，若存在受影响服务，则进行提示，并将所有受影响服务按照依赖等级的先后顺序进行启停；

在服务卸载时进行依赖关系检查，若当前卸载服务被其它服务依赖，则提示不允许卸载；

在服务禁用时进行依赖关系检查，若有服务组件依赖当前服务，则提示不允许禁用。

在一些实施例中，根据所述定义文件更新平台所有服务之间的依赖关系链，进行配置引用关系管理；所述配置引用关系包括配置项引用、配置分组引用和配置文件引用；

其中，配置项为配置的基础信息，存储于配置仓库中。

在一些实施例中，所述配置仓库包括：

实例配置库，用于保存服务在每个部署节点上的配置；其中，每个部署节点为一个服务组件实例；在服务安装或配置修改时将服务配置写入实例配置库；

历史配置库，用于存储服务在实例库中的配置信息；服务修改配置后不会立即生效，在部署配置时，会将服务在实例库中的配置信息拷贝到历史配置库，并记录发布版本，服务启动时，从历史库获取最新版本配置；

全局配置库，用于在定义服务将配置项声明为全局配置时，保存该配置项的的真实值；定义服务时可以将配置项声明为全局配置，该配置项的值在集群中唯一，真实值在安装或配置修改时保存在全局配置库中。

在一些实施例中，配置项引用关系管理包括：

实际应用中，存在不同服务之间配置项引用的需求。例如，服务B中需要配置服务A的端口号，当服务A的端口号发生变更时，服务B的配置也需要进行相应的修改，此时就存在配置项之间的依赖。配置项的引用基于全局变量实现，全局变量在服务定义文件中进行定义，可以被其它服务直接引用。当服务某配置项的值集群内唯一，且该配置项可能被其它服务引用时，可以将该配置项声明为全局变量。根据使用场景的不同，全局变量可分为集群全局变量和服务全局变量。

其中，所述集群全局变量为，根据服务组件安装节点数量动态变化的全局变量；

若当前服务可以以集群的方式对外提供服务，则可以在服务定义文件中定义集群全局变量（cluster），可以由多个配置项的值以指定的规则生成。例如：Zookeeper通常以集群的方式对外提供服务，依赖Zookeeper的服务需要它的集群地址和服务端口号，通常格式为：172.xx.xx.1:2888; 172.x.x.2:2888; 172.x.x.3:2888。此时Zookeeper可以定义集群全局变量CLUSTER_ZOOKEEPER_ADDRESSES，依赖此全局变量的配置项的值输入为@{CLUSTER_ZOOKEEPER_ADDRESSES}，即可完成配置项值的引用。当Zookeeper集群需要扩展部署节点或减少部署节点时，集群全局变量会随实际部署节点数量进行变更。

所述服务全局变量为集群内值唯一的全局变量。服务全局变量由指定配置项的值产生，是全局唯一的。例如：服务A的端口号在集群内唯一，不随安装节点数量发生变化。此时，可以将服务A的端口配置项定义为全局变量，被其它服务引用。当服务A的端口号发生变更时，引用此全局变量的值也会随之更改。

进一步地，对配置项引用关系管理进行举例说明：

如图4所示，以服务A引用了服务B的配置项为例，配置项引用关系管理流程为：

a，当修改服务B配置时，检查修改的配置项是否包含服务全局变量，若包含服务全局变量，则查找引用了此服务全局变量的服务，将找到的服务A标注为配置过期；

b，当增加或减少服务B部署节点时，检查服务B是否有集群全局变量。若涉及集群全局变量，则查找引用了此集群全局变量的服务，将找到的服务A标注为配置过期。

c，选择合适的时间进行配置发布（根据实际的应用场景进行选择）。所述配置发布为，将数据库中的配置信息部署到目标服务器的过程，服务B从历史配置库中读取信息，服务A从历史配置库及全局配置库读取配置信息，根据服务依赖关系生成任务队列，例如：当服务A依赖服务B时，先停止上层服务A，再停止底层服务B，依次发布服务A和服务B的配置文件，最后先启动底层服务B，再启动上层服务A。

在一些实施例中，进行配置文件/分组引用关系管理，包括：

在配置项引用需求的基础上，服务之间可能存在批量配置项引用的需求，例如Hive依赖HDFS服务的hdfs-site.xml文件。除了直接的配置文件引用外，在本公开中，可将具备同一类功能的配置项定义为一个配置分组，然后将配置分组提供给其他服务使用。

其中，引用配置分组或文件的定义格式为：“服务名称：配置文件名称”，例如：HDFS:core-site.xml.template。

进一步地，如图5所示，以服务A引用了服务B的配置文件/分组为例（配置文件和配置分组引用关系管理流程相同），配置文件/分组引用关系管理流程为：

a，当修改服务B的配置时，检查修改的配置项所属配置分组或文件，若所属配置分组或文件被其他服务引用，则查找引用了此分组或文件的服务，将找到的服务A标注为配置过期；

b，选择合适的时间进行配置发布（根据实际应用场景进行选择），配置发布是将数据库中的配置信息部署到目标服务器的过程，服务B和服务A均从历史配置库中读取信息，根据服务依赖关系生成任务队列。例如：当服务A依赖服务B时，先停止上层服务A，再停止底层服务B，依次发布服务A和服务B的配置文件，最后先启动底层服务B，再启动上层服务A。

在一些实施例中，进行配置项之间的联动关系管理，包括：

配置项之间的联动关系管理，用于处理服务内配置项之间的复杂关联关系，例如：服务A有三个配置项，C1、C2、C3，当C1的值发生变更时，C2和C3的值也会跟着发生变化。此时，可以通过配置关联策略解决。类似需求有：启用Kerberos、启用HTTPS、切换数据源等。除变更配置项的值之外，配置关联策略还可以处理一些更复杂的操作，比如：启用/关闭指定配置文件，启用/关闭指定配置组等。

进一步地，如图6所示，配置项之间的联动关系管理流程为：

a，当用户修改配置时，检查被修改的配置项是否存在联动关系。若存在，则与修改后的值进行比对，将修改后的值与目标值匹配，执行对应的管理操作；所述管理操作包括：变更配置文件启用/禁用状态、变更配置分组启用/禁用状态和/或变更指定配置项的值。

进一步地，当配置项的值发生变更、或配置文件/分组的状态由禁用变成启用时，展示受影响的配置项；当配置文件/分组的状态由启用变成禁用时，将相关配置项从页面隐藏。配置项变更后，将当前服务标注为配置过期；

b，选择合适的时间进行配置发布（根据实际应用场景进行选择），系统根据配置发布的服务，查找服务下配置过期的服务组件，查找服务组件下处于启用状态的配置文件，查找配置文件下处于启用状态的配置分组和直接属于配置文件的配置项，查找配置分组下的配置项。

根据配置分组、配置项生成配置文件，发布到目标服务器指定位置，完成配置更新。

根据本公开的实施例，实现了以下技术效果：

通过给软件服务增加定义文件，实现了复杂依赖关系的管理，同时对软件服务本身没有任何的侵入性。

通过服务依赖关系管理，解决了服务与服务之间的依赖关系，保障了服务全生命周期的稳定运行，避免了因错误的操作顺序导致生产故障，降低了运维学习成本。

通过配置引用关系管理方法，解决了跨服务的配置引用，实现了一处修改全局生效，有效降低了运维复杂度，相较于手动逐个修改，极大的减少了犯错机率，节约运维成本。

通过配置项之间的联动关系管理，提升了产品的易用性。即，通过配置关联策略，对一个配置项的值进行监听，当配置项的值发生变更时，根据规则批量启用或停用配置项，变更配置项的值，达到功能开启或关闭的目的，提升产品易用性。

综上，本公开提供的软件服务复杂依赖关系的管理方法，支持服务依赖关系管理，提供了服务全生命周期内的依赖关系解决方案，其中，生命周期流程包括：注册、安装、启动、停止、卸载、禁用。在执行上述操作时，会自动处理软件服务之间的依赖关系，以启动服务为例：操作触发时，根据软件服务间的依赖关系生成任务队列，先启动下层基础服务，再启动上层应用服务；支持配置引用关系管理，提供配置项引用、配置分组引用、配置文件引用能力。当被引用的配置发生变更时，所有引用这个配置项的服务配置均会更新；支持配置项之间的联动关系管理。根据预先定义的配置项间的关联策略，实现配置项联动效果。例如：选择不同的数据源，会对应不同的配置项，系统仅展示和选择数据源相关的配置项，隐藏无关配置项。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

以上是关于方法实施例的介绍，以下通过装置实施例，对本申请所述方案进行进一步说明。

图7示出了根据本申请的实施例的软件服务复杂依赖关系的管理装置700的方框图，如图7所示，装置700包括：

定义模块710，用于在服务集成时，按照约定的规范撰写定义文件；所述定义文件包括服务的名称、服务组件以及依赖关系；所述依赖关系包括服务之间的依赖关系，与其它服务配置文件、配置分组、配置项的依赖关系；所述服务之间的依赖关系的最小粒度为服务组件；

管理模块720，用于根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

如图8所示，终端设备或服务器800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本申请的实施例，上文方法流程步骤可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序，当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的申请范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述申请构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中申请的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims

1.一种软件服务复杂依赖关系的管理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述根据所述定义文件更新平台所有服务之间的依赖关系链包括：

3.根据权利要求2所述的方法，其特征在于，所述根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理包括：

其中，配置项为配置的基础信息，存储于配置仓库中。

4.根据权利要求3所述的方法，其特征在于，所述配置仓库包括：

历史配置库，用于存储服务在实例库中的配置信息；

5.根据权利要求3所述的方法，其特征在于，还包括：

所述服务全局变量为集群内值唯一的全局变量。

6.根据权利要求3所述的方法，其特征在于，所述完成服务间的配置引用关系管理包括：

7.根据权利要求1所述的方法，其特征在于，所述根据所述定义文件更新平台所有服务之间的依赖关系链，完成服务间的依赖关系的管理包括：

8.一种软件服务复杂依赖关系的管理装置，其特征在于，包括：

9.一种电子设备，包括存储器和处理器，所述存储器上存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1~7中任一项所述的方法。

10.一种计算机可读存储设备，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1~7中任一项所述的方法。