CN110113188A - 跨子域通信运维方法、总运维服务器和介质 - Google Patents

Abstract

本公开提供了一种跨子域通信运维方法、总运维服务器和介质。该方法包括：接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；接收跨子域服务发现请求；如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。本公开实施例能够对各个网络层或域运维系统内部服务及跨域服务进行协同运维管理，从而提高整个运维系统的运维管理能力和效率。

Description

跨子域通信运维方法、总运维服务器和介质

技术领域

本公开涉及通信运维技术领域，特别涉及一种跨子域通信运维方法、总运维服务器及计算机可读存储介质。

背景技术

在现有通信运维技术领域中，是分层或域进行管理的。移动通信网络包括移动核心网/接入网、传输承载网、业务云等不同的层或域。在每一层或域中，都需要有一个运维系统或运维服务器对本层或域进行运维管理。然而，每个运维系统通常只能对其内部进行服务功能之间的发现、调用等运维管理。这表明在传统通信运维技术领域中，各个层或域运维系统之间彼此独立而很难进行跨域综合运维管理，使得整个运维系统的协同管理能力弱、网络运维效率低。

发明内容

本公开的一个目的在于提出一种跨子域通信运维方法，能够对各个层或域运维系统内部服务进行协同运维管理，从而提高整个运维系统的运维管理能力和网络运维效率。

根据本公开的一个方面，公开了一种跨子域通信运维方法，各子域中分别具有运维服务器，所述方法应用于总运维服务器，总运维服务器用于各子域之间的通信运维，所述方法包括：

接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；

接收跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

根据本公开的一个示例实施方式，在接收跨子域服务发现请求之前，所述方法还包括：响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储。在接收跨子域服务发现请求之后，所述方法还包括：如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，调用该跨域服务注册信息对应的跨域服务。

根据本公开的一个示例实施方式，所述子域服务注册信息中含有子域服务调用权限信息；所述如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求，包括：

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，但该跨子域服务发现请求不符合该匹配的子域服务注册信息中的子域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，且该跨子域服务发现请求符合该匹配的子域服务注册信息中的子域服务调用权限信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

根据本公开的一个示例实施方式，所述跨域服务注册信息中含有跨域服务调用权限信息；所述如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，调用该跨域服务注册信息对应的跨域服务，包括：

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，但该跨子域服务发现请求不符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，且该跨子域服务发现请求符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，调用该跨域服务注册信息对应的跨域服务。

根据本公开的一个示例实施方式，所述跨域服务注册信息具有跨域服务标识。所述调用该跨域服务注册信息对应的跨域服务，包括：调用所述跨域服务注册信息中的跨域服务标识代表的跨域服务。

根据本公开的一个示例实施方式，所述跨域服务包含跨域注册管理服务和跨域服务发现服务，所述接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储的步骤是由所述跨域注册管理服务执行的，所述接收跨子域服务发现请求、发送子域服务调用请求的步骤是由所述跨域服务发现服务执行的。

根据本公开的一个示例实施方式，所述跨域服务还包含跨域业务编排服务，用于执行以下过程：接收对跨域业务编排服务的调用请求，所述调用请求中包含业务协议；根据所述业务协议，将业务拆解成业务单元；查找业务单元与运维服务器标识对应关系表，确定与拆解成的各业务单元对应的运维服务器标识。

根据本公开的一个示例实施方式，所述跨域服务还包含跨域业务分发服务，用于执行以下过程：接收对可以业务分发服务的调用请求，所述调用请求中包含业务拆解成的业务单元和对应的运维服务器标识；将业务拆解成的业务单元向对应的运维服务器标识的运维服务器分发。

根据本公开的一个示例实施方式，所述跨域服务还包含跨域业务故障定位服务，用于执行以下过程：接收对跨域故障定位服务的调用请求，所述调用请求中包含针对业务的故障描述；从所述跨域业务编排服务中，获取与该业务对应的业务单元和对应的运维服务器标识；基于所述故障描述、获取的业务单元和对应的运维服务器标识，确定产生故障的运维服务器标识和维护措施；将确定的维护措施发送给确定的运维服务器标识的运维服务器。

根据本公开的一个示例实施方式，在接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储之后，所述方法还包括：接收子域中的运维服务器发出的对已注册的该子域内的多个子域服务的合并请求；将所述多个子域服务的子域服务注册信息合并成合并后子域服务注册信息，替换所述多个子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

根据本公开的一个示例实施方式，在响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储之后，所述方法还包括：接收总运维服务器生成的对已注册的多个跨域服务的合并请求；将所述多个跨域服务的跨域服务注册信息合并成合并后跨域服务注册信息，替换所述多个跨域服务的跨域服务注册信息，与该运维服务器的标识对应存储。

根据本公开的一个示例实施方式，在接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储之后，所述方法还包括：接收子域中的运维服务器发出的对已注册的该子域内的子域服务的拆分请求；按照所述拆分请求，将所述子域服务的子域服务注册信息拆分成拆分后的多个子域服务注册信息，替换所述子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

根据本公开的一个示例实施方式，在响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储之后，所述方法还包括：接收总运维服务器生成的对已注册的跨域服务的拆分请求；按照所述拆分请求，将所述跨域服务的跨域服务注册信息拆分成拆分后的多个跨域服务注册信息，替换所述跨域服务的跨域服务注册信息存储。

根据本公开的一个示例实施方式，在接收跨子域服务发现请求之后，所述方法还包括：如果确定该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息中的任一个都不对应，获取该跨子域服务发现请求中的业务协议；将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。

根据本公开的一个示例实施方式，各子域中的运维服务器包括边缘云运维服务器；所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云流量指标信息和流量管控业务的业务协议；所述获取该跨子域服务发现请求中的业务协议，包括：如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。

根据本公开的一个示例实施方式，各子域中的运维服务器包括边缘云运维服务器；所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务故障定位服务的调用指示、发生故障的业务标识；所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务故障定位服务的调用指示，确定该跨子域服务发现请求对应于跨域业务故障定位服务；所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务故障定位服务发送对跨域故障定位服务的调用请求，所述调用请求中包括发生故障的业务标识，以便跨域业务故障定位服务确定该业务标识对应的产生故障的运维服务器标识和维护措施，将确定的维护措施的取消消息发送给确定的运维服务器标识的运维服务器。

根据本公开的一个示例实施方式，各子域中的运维服务器包括边缘云运维服务器；所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务分发服务的调用指示、修改后的分流策略；所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务分发服务的调用指示，确定该跨子域服务发现请求对应于跨域业务分发服务；所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务分发服务发送对跨域业务分发服务的调用请求，所述调用请求中包括修改后的分流策略和对应的运维服务器标识，以便跨域业务分发服务将修改后的分流策略向对应的运维服务器标识的运维服务器分发。

根据本公开的一个示例实施方式，各子域中的运维服务器包括边缘云运维服务器。所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云业务访问信息和业务访问管控业务的业务协议；所述将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，包括：将边缘云业务访问信息和业务访问管控业务的业务协议一起放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务；所述根据所述业务协议，将业务拆解成业务单元，包括：根据所述业务协议和边缘云业务访问信息，将业务拆解成业务单元。

根据本公开的一个方面，提供了一种总运维服务器，所述总运维服务器用于各子域之间的通信运维，各子域中分别具有运维服务器，所述方法包括：子域服务注册信息接收单元，用于接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；跨子域服务发现请求接收单元，用于接收跨子域服务发现请求；子域服务调用请求发送单元，用于如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

根据本公开的一个方面，公开了一种总运维服务器，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。

根据本公开的一个方面，公开了一种计算机可读程序介质，其存储有计算机可读指令，当所述计算机可读指令被处理器执行时，使计算机执行如上所述的方法。

在本公开的实施例中，各子域中的运维服务器采用服务这种模式进行运维。各个服务之间是松耦合的，可以互相调用，可以按需求定制服务的功能和容量，使得升级改造只要升级相应服务就可以，不会对其它服务造成影响。除了各子域中的运维服务器负责自己子域中的运维之外，本实施例引入一总运维服务器，通过接收不同子域运维服务器在其子域内生成服务后所发送的服务注册信息并与该运维服务器的标识对应存储。这样，就可以进行任何跨域服务调用，因为一旦接收到跨子域服务发现请求，如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，就可以向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。通过这样的方式，在满足服务调用权限的前提下，子域可以通过总运维系统调用其它子域事先注册的子域服务，从而实现总运维系统对各个子域的内部服务进行协同运维管理，从而提高整个运维系统的运维管理能力和网络运维效率。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1A示出了根据本公开一个实施例的跨子域通信运维方法的一个应用环境的构架图；图1B示出了图1A的体系构架每个运维服务器中的具体服务部署情况。

图2A-K示出了根据本公开一个实施例的边缘云智能运维的应用场景下总运维服务器显示的界面图。

图3示出了根据本公开一个实施例的跨子域通信运维方法的流程图。

图4示出了根据本公开一个实施例的跨子域通信运维方法的流程图。

图5示出了根据本公开一个实施例的跨域业务编排服务实施方法的具体流程图。

图6示出了根据本公开一个实施例的跨域业务分发服务处理方法的具体流程图。

图7示出了根据本公开一个实施例的跨域业务故障定位服务处理方法的具体流程图。

图8示出了根据本公开一个实施例的跨子域通信运维方法的流程图。

图9示出了根据本公开一个实施例的跨子域通信运维方法的流程图。

图10示出了根据本公开一个实施例的跨子域通信运维方法的流程图。

图11示出了根据本公开一个实施例的跨域服务发现服务的执行过程交互流程图。

图12示出了根据本公开一个实施例的跨域业务编排服务的执行过程交互流程图。

图13示出了根据本公开一个实施例的跨域业务故障定位服务的执行过程交互流程图。

图14示出了根据本公开一个实施例的在边缘云智能运维的应用场景下边缘云流量管控的实施过程交互流程图。

图15示出了根据本公开一个实施例的在边缘云智能运维的应用场景下边缘云故障处理的实施过程交互流程图。

图16示出了根据本公开一个实施例的在边缘云智能运维的应用场景下边缘云分流策略更新的实施过程交互流程图。

图17示出了根据本公开一个实施例的在边缘云智能运维的应用场景下边缘云业务信息上报的实施过程交互流程图。

图18示出了根据本公开一个实施例的总运维服务器的框图。

图19示出了根据本公开一个实施例的总运维服务器的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1A是本公开示例性实施例示出的实施例的跨子域通信运维方法的一个应用环境的构架图。该构架包括总运维服务器101、和各子域中分别具有的子域运维服务器104。子域是指根据网络通信协议的层级，将通信网分成的各层级上的网络。例如，通信协议中最底层的是承载层，与其相对应的网络子域就是传输承载网子域196。在其上分别由移动核心网子域197和边缘云子域198。通信协议中最高层是业务层，与其对应的子域有业务云子域199等。各子域具有它自己的子域运维服务器104。子域运维服务器104是指在该子域内负责该子域内的服务的运维的服务器。总运维服务器101是指负责在各子域之间服务的运维和调度的服务器，它不存在于任何一个子域内部。

本公开实施例的跨子域通信运维方法应用于面向服务的体系构架。通过一个一个服务来完成通信网中的各种功能。各运维服务器中存储有其自己生成的服务。如图1B所示，在每个子域运维服务器104中的服务106是由各子域运维服务器104根据其自身状况和用户的处理需要生成的标准动作序列。这些服务可以是流程管理、事件管理、问题管理、变更管理、发布管理、运行管理、知识管理、综合分析管理等运维管理等服务。调用该服务，就促使相应动作序列得到执行，完成该动作序列的功能。每个子域运维服务器104具有子域运维服务器中央处理器105，用于执行该子域运维服务器104内部各服务的调用和管理。总运维服务器101中的服务103是对子域之间的服务进行统一管理调度、或者在各子域间都可以共同使用的服务，它们不是在一个子域使用，往往是跨域使用，因此是跨域服务。例如，图1B中的跨域注册管理服务、跨域服务发现服务是对子域之间的服务进行统一管理调度的服务，而图1B中的跨域业务编排服务、跨域业务分发服务、跨域业务故障定位服务是统一提供的、在各子域间都可以共同使用的服务。这些跨域服务的具体功能和执行过程将在下面详细描述。

本公开实施例将移动网络、传输承载网、边缘云、业务云等通过统一的运维系统进行统一管理，进行故障定位等运维流程的优化。该运维系统基于服务化构架的理念，可以实现对于服务化构架通信网络的不同子域的运维管理，也可以用于传统非服务化构架通信网络的运维管理，使跨域运维具有大规模运维能力。

需要说明的是，各个子域运维服务器服务之间及子域运维服务器与总运维服务器之间的通信可以基于现有的通信协议，包含但不限于HTTP协议，RPC协议，gRPC协议等，也可以基于后续的各个协议的演进版本来实现，本发明不对通信协议做出限定。

图1A-B中的总运维服务器101可以是由一台计算机构成的服务器，也可以是由多台计算机合起来构成的集群服务器，也可以是只占用一台计算机的一部分的虚拟服务器，也可以是分别占用多台计算机的各自的一部分或全部的虚拟集群服务器。尤其在云环境下，虚拟集群服务器应用得比较普遍。

接下来，结合图2A-K，描述本公开实施例在在边缘云智能运维的应用场景下的一个具体应用。

边缘云是指靠近用户或终端的分布式云计算，它按照就近原则处理数据，而不是传回给“中心云”，可以减少数据迂回，提升用户体验，适用于应对物联网、AR/VR、人工智能，人脸识别等对实时响应高要求，低时延高可靠的业务场景。但是，边缘云引入后，边缘云和核心网云的交互成了一个很复杂的问题。如何实现对边缘云的控制、边缘云业务能力开放等边缘云的运维成了非常重要的问题，其中包括自动化运维管理、故障定位、恢复、分流策略更新。

在边缘云的场景中，如果边缘云的流量超过了某个阈值，图1A-B中负责边缘云子域的运维服务器向总运维服务器发送一个进行流量管控的服务发现请求。如图2A所示，该请求中包含边缘云流量指标信息，例如“边缘云超过流量阈值的百分比为X％”等等。同时，该请求中会携带流量管控的业务协议，以便总运维服务器可以根据该业务协议对这种流量管控业务进行编排。

总运维服务器101中的跨域服务发现服务先接收到该请求。由于该请求并不是要明显调用一个总域或子域中的服务，因此，跨域服务器发现服务不必按照该请求去检索在总域或哪个子域中有这种服务，而是发现其中有业务协议后，直接把该业务协议封装到对跨域业务编排服务的调用请求中，调用跨域业务编排服务，如图2B所示。

这样，跨域业务编排服务按照业务协议编排好该业务，将编排好的云流量管控策略通过跨域业务分发服务分发到核心网，实现流量管控，如图2C。

对于边缘云故障或者因为内部功能升级停止服务的情况，边缘云运维服务器可以将停止服务的请求上报给总运维服务器，由总运维服务器停止该边缘云的该业务。这样，边缘云运维服务器可以向总运维服务器发起一个服务发现请求，该请求指示出现了业务故障，并指示出发生业务故障的业务标识，如图2D所示。

跨域服务发现服务接收到该请求，由于该请求指示出现了业务故障，可以看作需要调用跨域业务故障定位服务这个跨域服务，因此，如图2E所示，调用跨域故障定位服务，跨域故障定位服务根据发生业务故障的业务标识，确定发生故障的运维服务器和维护措施，并且如图2F所示，将维护措施发送给相应发生故障的运维服务器。

边缘云运维服务器可能会根据自身的业务情况调整分流策略。分流策略是指，将哪些数据路由到该边缘云平台上而不将哪些数据路由到该边缘云平台上的策略。例如，更新分流策略中的IP地址，或者为防止该边缘云平台过载，减少路由到该边缘云平台上的消息的数量等。

如图2G所示，当需要进行分流策略调整时，边缘云运维服务器向总运维服务器发送分流策略更新的服务发现请求，该请求中具有修改后的分流策略。

跨域服务发现服务接收到该请求，由于该请求具有修改后的分流策略，默认调用跨域业务分发服务。此时，调用跨域业务分发服务，将修改后的分流策略向对应的运维服务器分发，如图2H所示。

另外，边缘云运维服务器可以上报边缘云平台的业务访问情况，例如某一个时间段内的业务访问失败率，或者业务访问失败的用户终端列表等。总运维服务器可以根据这些信息调整在某一个时间段对边缘云平台的业务访问量，或者调整访问失败的用户终端的分流策略等，从而提高业务命中率。

边缘云运维服务器向总运维服务器发送进行业务访问管控的服务发现请求，该请求中包含边缘云业务访问信息和业务协议，如图2I所示。

跨域服务发现服务接收到该请求。由于该请求没有明显指示对某个子域或跨域服务的调用，而且其中含有业务协议，跨域服务发现服务将边缘云业务访问信息和业务协议发给跨域业务编排服务进行业务编排，如图2J所示。由于边缘云业务访问信息不同，其调整策略可能就不同，因此，跨域业务编排服务不仅仅根据业务协议，还要根据边缘云业务访问信息进行对边缘云业务访问进行控制的业务的编排。

当编排完对边缘云业务访问进行控制的业务后，将该业务通过跨域业务分发服务下发给核心网，从而实现控制策略的下发，如图2K所示。

接下来，根据本公开的一个实施例，如图3所示，提供了一种跨子域通信运维方法，子域中分别具有运维服务器104。该方法应用于总运维服务器101，总运维服务器101用于各子域之间的通信运维。该方法包括：

步骤210.接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；

步骤220.接收跨子域服务发现请求；

步骤230.如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

下面对这些步骤进行详细描述。

在步骤210中，子域服务是指子域中的运维服务器生成的完成特定功能的一项服务，例如流程管理、事件管理、问题管理、变更管理、发布管理、运行管理、知识管理、综合分析管理，它包含一系列编程动作的集合，该编程动作的集合被计算机执行后能够完成服务所完成的功能。子域服务生成时，最初是为了满足子域内用户完成某一任务或目标的需要。但在本公开实施例的跨域调用的场景下，它可以被其它子域中的用户调用，供其它子域的用户完成相应目标，实现了服务的共享。

子域服务注册信息是指子域服务生成后注册时需要的信息，它可以包含子域服务的标识、功能、代码索引、编写人、编写日期等等。不同子域服务器的注册信息不同，子域服务注册信息可以用来区分不同的子域服务。

在一个实施例中，子域运维服务器生成子域服务后，生成子域服务注册信息。该注册信息可以放在一个消息内由子域中的运维服务器发送给总运维服务器。消息头中含有发送方运维服务器的标识。当总运维服务器接收到该消息后，从消息头中去除运维服务器的标识，与消息中的子域服务注册信息对应存储。这样，当接收到跨子域服务发现请求后，就可以根据该请求和存储的所有子域服务注册信息匹配，找到对应的子域服务注册信息，从而找到对应的运维服务器的标识，根据该标识向对应的运维服务器请求到该子域服务，实现跨子域服务调用。

在步骤220中，跨子域服务器发现请求是指为了发现在其它子域运维服务器中的子域服务而向总运维服务器作出的请求。该请求可以带有该服务的标识，或者该服务的功能等等，即子域服务注册信息的一部分。当进行请求的子域运维服务器清楚其需要的服务的标识时，其可以直接带有该服务的标识。如果只是知道该服务的功能，不知道具体标识，可以带有该服务的功能。这样，通过该请求中服务的功能与子域服务器注册信息中的服务的功能的匹配，也能找到相应功能。

在步骤230中，在一个实施例中，确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，可以包括：

如果该跨子域服务发现请求携带服务的标识，且该标识与存储的一个子域服务注册信息中的服务标识一致，则确定该跨子域服务发现请求对应于该存储的子域服务注册信息；

如果该跨子域服务发现请求携带服务的功能，将该服务的功能与存储的所有子域服务注册信息中的服务功能比对，将与该跨子域服务发现请求携带的服务的功能的汉明距离最小的子域服务注册信息，作为该跨子域服务发现请求对应的子域服务注册信息。

汉明距离的含义是指由一个字符串删除、增加若干字符后成为另一个字符串，删除、增加字符的次数。例如，从“视频去除模糊”到“视频帧中去模糊”，需要删除“除”，再增加“帧”、“中”，因此，汉明距离为3。两个服务功能的汉明距离越小，说明其意思可能越相近，相应的子域服务注册信息就可以作为该跨子域服务发现请求对应的子域服务注册信息。

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，由于子域服务注册信息与该运维服务器的标识是对应存储的，这样，就可以向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

图11示出了在上述跨域服务发现服务实现过程中各个运维服务器的交互流程。如图11所示，子域运维服务器1需要某一服务，但它并不知道该服务存在于哪个子域运维服务器中，因此，它通过步骤220，向总运维服务器发出跨子域服务发现请求。总运维服务器接收到该请求后，在步骤2301中，确定该跨子域服务发现请求想要找的服务与子域运维服务器2之前上报注册的一个子域服务注册信息相匹配，因此，在步骤2302中向子域运维服务器2发送子域服务调用请求，实现了跨子域服务调用。

在一个实施例中，上述子域服务注册信息除了可以包含上述内容，还包括子域服务调用权限信息，用于记录该服务的可访问主体。在该实施例中，步骤230包括：

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，但该跨子域服务发现请求不符合该匹配的子域服务注册信息中的子域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，且该跨子域服务发现请求符合该匹配的子域服务注册信息中的子域服务调用权限信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

拒绝所述跨子域服务发现请求可以包括对所述跨子域服务发现请求不做任何处理、或向该跨子域服务发现请求的发出方发送拒绝应答、或者向该跨子域服务发现请求的发出方发送开通权限的提示。

也就是说，在执行步骤S230时，如果核对发现该跨子域服务发现请求在存储的所有子域服务注册信息中可以找到一个对应的子域服务注册信息时，但该跨子域服务发现请求不符合匹配的子域服务注册信息中的子域服务调用权限信息，认为该该跨子域服务发现请求无权访问，不对该所述跨子域服务发现请求进行下一步处理或向与该子域服务注册信息对应的该运维服务器的标识的运维服务器104发送拒绝回应消息或提示其开通权限消息。相反，如果子域服务注册消息接收单元610核对发现该跨子域服务发现请求对应于一个存储的子域服务注册信息，且该跨子域服务发现请求符合该匹配的子域服务注册信息中的子域服务调用权限信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器104，发送子域服务调用请求。

该实施例的好处是，设置权限信息的限制，对各子域服务进行权限控制，只有被授予了权限的子域运维服务器才能够进行相应服务的调用，提高服务调用的安全性，和灵活的接入控制。

需要说明的是，步骤S230中所述的运维服务器的标识，包括但不限于运维服务器的通用唯一识别码UUID(Universally Unique Identifier、IP地址或媒体访问控制地址MAC(Media Access Control Address)地址。

当子域运维服务器产生的子域服务注册后，不一定是一成不变的，有可能进行合并或拆分。

在合并的情况下，可能多个子域运维服务器产生的子域服务合并成一个服务。在一个实施例中，如图8所示，在步骤210之后，所述方法还包括：

步骤S211、接收子域中的运维服务器104发出的对已注册的该子域内的多个子域服务的合并请求；

步骤S212、将所述多个子域服务的子域服务注册信息合并成合并后子域服务注册信息，替换所述多个子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

在一个实施例中，该合并请求中具有该多个子域服务的标识。在步骤212中，将具有所述多个子域服务的标识的多个子域服务注册信息合并成合并后子域服务注册信息，替换所述多个子域服务的子域服务注册信息，与该运维服务的标识对应存储。这样，原来存储的子域服务注册信息和运维服务器的标识的对应关系就被替换成新的合并后的子域服务注册信息和运维服务器的标识的对应关系。在步骤230中确定该跨子域服务发现请求对应于一个存储的子域服务注册信息时，可以在合并后的子域服务注册信息中匹配，仍然可以找到匹配的合并后的子域服务注册信息所对应的运维服务器的标识。

该实施例为子域服务的合并提供了实现的可行性。

在另一个实施例中，如图9所示，在步骤210之后，所述方法还包括：

步骤213、接收子域中的运维服务器发出的对已注册的该子域内的子域服务的拆分请求；

步骤214、按照所述拆分请求，将所述子域服务的子域服务注册信息拆分成拆分后的多个子域服务注册信息，替换所述子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

在一个实施例中，所述拆分请求具有将子域请求拆成多个子域请求的拆分标准，例如等分，或者将一个服务的多个功能分别拆成多个服务。当将一个服务的多个功能分别拆成多个服务时，该拆分标准包括所述多个服务的功能。

在该拆分标准包括要拆成的多个服务的功能时，在一个实施例中，步骤214可以包括：

根据要拆成的每个服务的功能，将所述子域服务中的服务于该功能的编程语句提取出，成为分出的一个服务；

根据所述子域服务的子域服务注册信息，为分出的每个服务，分别生成该服务的子域服务注册信息；

为分出的每个服务分别生成该服务的子域服务注册信息与所述子域服务的运维服务器标识对应存储，替换之前存储的所述子域服务的子域服务注册信息和对应的运维服务器标识。

在根据要拆成的每个服务的功能，将所述子域服务中的服务于该功能的编程语句提取出，成为分出的一个服务时，可以在服务原始编程时，为每个编程语句进行注释，在注释中指明编程语句的功能，这样，可以根据编程语句的注释中的功能与要拆成的每个服务的功能的匹配，确定与要拆成的每个服务的功能的编程语句。

在根据所述子域服务的子域服务注册信息，为分出的每个服务，分别生成该服务的子域服务注册信息时，由于子域服务注册信息包括子域服务的标识、功能、代码索引、编写人、编写日期，因此，在一个实施例中，对于子域服务的标识，可以生成新的子域服务的标识；对于子域服务的功能，可以将所述拆分请求中的要分出的服务的功能，作为新的子域服务的功能；对于代码索引，可以为新的子域服务生成相应的代码索引；对于编写人，将所述子域服务的编写人作为新的子域服务的编写人；对于编写日期，将当前时间作为新的子域服务的编写时间。

由于分出的每个服务分别生成该服务的子域服务注册信息与所述子域服务的运维服务器标识对应存储，替换之前存储的所述子域服务的子域服务注册信息和对应的运维服务器标识，这样，在步骤230中确定该跨子域服务发现请求对应于一个存储的子域服务注册信息时，可以在拆分后的子域服务注册信息中匹配，仍然可以找到匹配的拆分后的子域服务注册信息所对应的运维服务器的标识。

该实施例为子域服务的拆分提供了实现的可行性。

上面的实施例描述了子域服务的注册、跨域调用、合并和拆分，实际上，如图1B所示，还存在跨域服务，它们存在于总运维服务器101中而并非子域运维服务器中。它们对子域之间的服务进行统一管理调度，如跨域注册管理服务、跨域服务发现服务，或者是在各子域间都可以共同使用的服务，如跨域业务编排服务、跨域业务分发服务、跨域业务故障定位服务。对于对子域之间的服务进行统一管理调度的跨域服务，它们是为服务的调度服务的，但在服务化体系构架下，它们自己本身又是一种服务，因此是一种特殊的服务。实际上，上述步骤210是由跨域注册管理服务完成的，而上述步骤220-230是由跨域服务发现服务完成的。因此，下文中，对于这两个服务的功能不再赘述，会对跨域业务编排服务、跨域业务分发服务、跨域业务故障定位服务的功能进行详细描述。

在本公开一个实施例中，如图4所示，在步骤220之前，所述方法还包括：步骤215、响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储。另外，在步骤220之后，所述方法还包括：步骤235、如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，调用该跨域服务注册信息对应的跨域服务。

跨域服务注册信息是指跨域服务生成后注册时需要的信息，与子域服务注册信息类似，它可以包含跨域服务标识、功能、代码索引、编写人、编写日期等等。由于跨域服务标识在不同跨域服务之间不同，因此，当调用跨域服务时，可以通过跨域服务标识来调用跨域服务。步骤215与步骤210的一个区别是，步骤210的注册中，子域服务注册信息需要与运维服务器的标识对应存储，而在步骤215中，由于跨域服务都是总运维服务器生成的，不需要与生成其的运维服务器标识对应存储，但由于其中含有跨域服务标识，仍然区分不同跨域服务。

在该实施例中，确定该跨子域服务发现请求带有要发现的跨域服务标识。确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，包括：确定该跨子域服务发现请求中的跨域服务标识与存储的跨域服务注册信息中的跨域服务标识一致。在该实施例中，所述调用该跨域服务注册信息对应的跨域服务，包括：调用所述跨域服务注册信息中的跨域服务标识代表的跨域服务。也就是说，当子域运维服务器想调用一个跨域服务时，其向总运维服务器发送跨子域服务发现请求，该请求中有要调用的跨域服务的标识。跨域服务发现服务接收到该请求，将该标识与存储的所有跨域和子域服务注册信息中的服务标识对比，如果发现与其中的一个跨域服务的标识一致，则调用该标识的跨域服务。该实施例通过跨域服务标识，提供了一种简捷的定位跨域服务的方式。

另外，在一个实施例中，与子域服务调用可以具有权限控制一样，跨域调用也可以具有权限控制。在该实施例中，所述跨域服务注册信息中含有跨域服务调用权限信息。步骤230包括：

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，但该跨子域服务发现请求不符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，且该跨子域服务发现请求符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，调用该跨域服务注册信息对应的跨域服务。

上述过程与前述对子域服务调用进行权限控制的实施例的做法基本类似，为节省篇幅，故不赘述。它的好处是提高跨域服务调用的安全性和根据不同权限实现跨域服务调用。

与前面子域服务注册后可以合并和拆分一样，跨域服务注册后也可以进行合并和拆分。

在跨域服务合并的实施例中，在步骤215之后，如图8所示，所述方法还包括：

步骤216、接收总运维服务器生成的对已注册的多个跨域服务的合并请求；

步骤217、将所述多个跨域服务的跨域服务注册信息合并成合并后跨域服务注册信息，替换所述多个跨域服务的跨域服务注册信息，与该运维服务器的标识对应存储。

上述实现过程与步骤211和步骤212基本类似，只不过步骤211-212针对子域服务合并，步骤216-217针对跨域服务合并。为节约篇幅，故不赘述。上述实施例对已注册的跨域服务进行合并提供了实现上的可能性。

在跨域服务拆分的实施例中，在步骤215之后，如图9所示，所述方法还包括：

步骤218、接收总运维服务器生成的对已注册的跨域服务的拆分请求；

步骤219、按照所述拆分请求，将所述跨域服务的跨域服务注册信息拆分成拆分后的多个跨域服务注册信息，替换所述跨域服务的跨域服务注册信息存储。

上述实现过程与步骤213和步骤214基本类似，只不过步骤213-214针对子域服务拆分，步骤218-219针对跨域服务拆分。为节约篇幅，故不赘述。上述实施例对已注册的跨域服务进行拆分提供了实现上的可能性。

如上所述，上面实施例的过程基本上是由跨域注册管理服务和跨域服务发现服务实现的。如图1B所示，总运维服务器存储的跨域服务还有跨域业务编排服务、跨域业务分发服务、跨域业务故障定位服务等。下面对这些跨域服务的实现过程进行描述。

如图5所示，根据本公开的一个实施例，所述跨域服务103包含有跨域业务编排服务，用于执行以下过程：

步骤310.接收对跨域业务编排服务的调用请求，所述调用请求中包含业务协议；

步骤320.根据所述业务协议，将业务拆解成业务单元；

步骤330.查找业务单元与运维服务器标识对应关系表，确定与拆解成的各业务单元对应的运维服务器标识。

跨域业务编排服务是指为所有子域提供的、让所有子域共享的、当面临一项业务时能为该业务自己编写运行其的程序，让其运行起来的服务。由于不同业务，让其运行起来的程序是不一样的，因此要根据业务来定制让其运行起来的程序。因此，在一个实施例中，在调用请求中含有业务协议，业务协议反映了业务的要求，这样，就可以根据业务协议来定制让业务运行的程序。

业务的协议是一系列动作的集合，集合中的每个动作为一个业务单元，它实际上是让业务运行起来的程序中执行相应动作的那部分程序段。在一个实施例中，业务协议可以在一个通用的业务协议模板上填写相应参数得到，而每个业务协议模板上的模板协议段对应一个固定的协议段程序。每个模板协议段标识与协议段程序的对应关系事先存储在后台。在一个实施例中，步骤320包括：

查找与所述业务协议中的每个模板协议段标识对应的协议段程序；

用用户在业务协议模板中填写的参数，根据预定规则，修改相应模板协议段标识对应的协议段程序，得到相应协议段的业务单元。

由于业务协议模板包括多个模板协议段，每个协议段对应的协议段程序预先编写好，与协议段标识对应存储。由于业务协议模板上要在预定位置填写相应参数才能得到业务协议，因此，要对预先编写好的协议段程序按照这些参数进行修改，根据参数进行修改的规则可以预先制定好存储在后台。该规则可以是一个总体规则，也可以是针对每个模板协议段分别设置的规则。因此，接到业务协议后，获得该业务协议中每个模板协议段标识，找到每个模板协议段标识在后台对应存储的协议段程序。然后，对于每个模板协议段中用户填写的参数，获取该填写的参数所在的模板协议段对应的规则或设置的总体规则，按照该规则、和填写的参数，修改相应模板协议段标识对应的协议段程序，就得到相应协议段的业务单元。业务单元就是业务的运行程序中一个单独存在的程序代码段。

每种业务单元是一个程序代码段，其实现的基础操作功能是已知的，由哪个运维服务器(子域运维服务器或总运维服务器)执行也是已知的。事先可以列举出对于每种业务单元，执行其的运维服务器，将业务单元与运维服务器标识的对应关系一一列出，成为业务单元与运维服务器标识对应关系表。这样，查找业务单元与运维服务器标识对应关系表，就可以确定与拆解成的各业务单元对应的运维服务器标识。

上述实施例的好处是，针对每一种新的业务，可以通过跨域业务编排服务，编排出在各个子域之间都可以共享的业务执行代码，以后各个子域需要运行类似业务时，可以直接调用该共享的业务执行代码，从而大大提高了业务运行效率，优化了网络资源的使用。

如图6所示，根据本公开的一个实施例，所述跨域服务还可以包含跨域业务分发服务，用于执行以下过程：

步骤410、接收对跨域业务分发服务的调用请求，所述调用请求中包含业务拆解成的业务单元和对应的运维服务器标识；

步骤420、将业务拆解成的业务单元向对应的运维服务器标识的运维服务器分发。

在一个实施例中，对跨域业务分发服务的调用请求是由跨域业务编排服务发起的，即在步骤330中，确定与拆解成的各业务单元对应的运维服务器标识后，将这些业务单元和对应的运维服务器标识放到调用请求中，由跨域业务编排服务发送给跨域业务分发服务。在另一个实施例中，对跨域业务分发服务的调用请求是从子域运维服务器接收到或管理员输入的。子域运维服务器事先已知想要实现的业务分出的各业务单元、以及对应的运维服务器标识，将它们对应地放在调用请求中发送给跨域业务分发服务，或者管理员已知想要实现的业务分出的各业务单元、以及对应的运维服务器标识，将它们输入到跨域业务分发服务。然后，由跨域业务分发服务将业务拆解成的业务单元向对应的运维服务器标识的运维服务器分发。

图12给出了跨域业务编排服务、跨域业务分发服务中各子域运维服务器和总运维服务器的交互关系的一个例子。在图12中，通过步骤310，总运维服务器接收到对跨域业务编排服务的调用请求。具体地说，是跨域服务发现服务接收到对跨域业务编排服务的调用请求，然后交给跨域业务编排服务处理。跨域业务编排服务在步骤320中根据业务协议，将业务拆解成业务单元，在步骤330中，确定与拆解成的业务单元分别对应的子域运维服务器是子域运维服务器1和2。然后，在步骤420中，通过跨域业务分发服务，将业务拆解成的各业务单元向确定的子域运维服务器1和2分发。

上述实施例的好处是，通过跨域业务分发服务，可以将编排出的业务在不同的子域间进行分发，促进业务执行代码在各子域间的共享，提高网络资源利用效率和协同工作效率。

根据本公开的一个实施例，如图7所示，所述跨域服务还包含跨域业务故障定位服务，用于执行以下过程：

步骤510.接收对跨域故障定位服务的调用请求，所述调用请求中包含针对业务的故障描述；

步骤520.从所述跨域业务编排服务中，获取与该业务对应的业务单元和对应的运维服务器标识；

步骤530.基于所述故障描述、获取的业务单元和对应的运维服务器标识，确定产生故障的运维服务器标识和维护措施；

步骤540.将确定的维护措施发送给确定的运维服务器标识的运维服务器。

跨域业务故障定位服务是这样一种服务，当业务编排服务确定好与拆解成的各业务单元对应的运维服务器，并由跨域业务分发服务分发到相应运维服务器后，如果业务运行中出现了故障，如何定位该故障是哪个或哪些运维服务器执行业务单元时引起的，给出应当如何应对的措施。

跨域故障定位服务的调用请求有可能是子域运维服务器发出的，也有可能是管理员输入的。针对业务的故障描述是指对业务故障形成的文字描述，它可以通过向用户呈现候选故障描述列表，并接收用户对故障描述的选择实现。所述调用请求中包含针对业务的故障描述。在一个实施例中，该故障描述中含有业务标识。

获取业务的故障描述后，如果想要找到业务执行中哪一个环节出现了故障，并确定如何应对，必须要知道业务编排时都有哪些业务单元，这些业务单元都分配给哪些运维服务器执行，然后才能判断哪个或哪些运维服务器的执行出现了问题。在跨域业务编排服务编排好每一项业务后，都要把编排成的业务单元以及对应的运维服务器标识，连同该业务的标识对应存储。由于调用请求的故障描述中含有业务标识，就可以找到该业务编排成的业务单元以及对应的运维服务器标识。这样，在找到的该业务编排成的业务单元以及对应的运维服务器标识的基础上，再根据业务的故障描述，就能确定出哪个业务单元的执行出现了问题，对应哪个运维服务器，维护措施是什么。

在一个实施例中，步骤530包括：将所述故障描述、获取的业务单元和对应的运维服务器标识输入机器学习模型，由机器学习模型输出产生故障的运维服务器标识和维护措施，该机器学习模型预先通过以下方式训练而成：

将业务故障描述样本集合中的每个业务故障描述样本，以及已知的该业务故障描述样本针对的业务被业务编排服务编排成的业务单元和对应的运维服务器标识输入机器学习模型，由该机器学习模型输出产生故障的运维服务器标识和维护措施，该业务故障描述样本产生故障的运维服务器标识和维护措施事先已知，将机器学习模型输出的产生故障的运维服务器标识和维护措施与事先已知的产生故障的运维服务器标识和维护措施进行比对，如果不一致，则调整所述机器学习模型的系数，使机器学习模型输出的产生故障的运维服务器标识和维护措施与事先已知的产生故障的运维服务器标识和维护措施。

业务故障描述样本集合是用于训练所述机器学习模型的业务故障描述样本的集合。每个样本针对的业务是已知的，这样，该业务被业务编排服务编排成的业务单元和对应的运维服务器就是已知的。事先针对每个样本，由管理员人工调查出产生故障的运维服务器，并人工给出相应维护措施。将每个样本的所述故障描述、相应业务的业务单元和对应的运维服务器标识输入机器学习模型，由机器学习模型会输出一个产生故障的运维服务器标识和维护措施，该运维服务器标识和维护措施与事先人工给出的运维服务器标识和维护措施进行比对，如不一致，则调整机器学习中的系数，使机器学习模型输出的产生故障的运维服务器标识和维护措施与事先已知的产生故障的运维服务器标识和维护措施。经过大量样本的不断训练，该机器学习模型就能针对任何输入的故障描述、获取的业务单元和对应的运维服务器标识，得到比较准确判断的产生故障的运维服务器标识和维护措施。

得到比较准确判断的产生故障的运维服务器标识和维护措施后，就可以将将确定的维护措施发送给确定的运维服务器标识的运维服务器，实现业务故障定位服务。

图13给出了在业务故障定位服务的执行中各运维服务器之间交互的流程图。

如图13所示，通过步骤510，总运维服务器接收到对跨域故障定位服务的调用请求。具体地说，跨域服务发现服务先接收到该调用请求，将其传递给跨域故障定位服务。跨域故障定位服务在步骤520中通过调用可以业务编排服务，获取该业务对应的业务单元和对应的运维服务器标识，并在步骤530中，基于故障描述和该业务对应的业务单元、以及运维服务器标识，确定产生故障的运维服务器是运维服务器1和2和相应的维护措施，在步骤540中，将相应维护措施分别通知到子域运维服务器1和2。

该实施例的好处是，能够通过机器自动的方式，在业务运行中出现了故障时，快速定位到该故障是哪个或哪些运维服务器执行业务单元时引起的，给出应当如何应对的措施，整个过程不需要人工干预，且定位到运维服务器和给出应对措施的准确率高。

在一个实施例中，在步骤220之后，所述方法还可以包括：

步骤236、如果确定该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息中的任一个都不对应，获取该跨子域服务发现请求中的业务协议；

步骤241、将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。

一般来说，跨域服务发现服务是总运维服务器接收到外界请求的入口。当跨域服务发现服务接收到一个外界请求(跨子域服务器发现请求)后，首先要在注册的子域服务和跨域服务中查找该外界请求是否请求的是一个已注册的子域服务或跨域服务。如果请求的是一个已注册的子域服务或跨域服务，直接调用该子域服务或跨域服务。如果不是，这时有两种可能，一种可能是用户想要对一种新业务让总运维服务器帮它编排，另一种则是用户需要的服务确实没有人注册过。在后一种情况下，就要向用户返回该服务没有注册的结果，让用户想其它办法。因此，要获取该跨子域服务发现请求中的业务协议。如果能获取到，说明用户想要对一种新业务让总运维服务器帮它编排，就在步骤241中将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，进行业务编排。如果不能获取到，则是后一种情况，就要向用户返回该服务没有注册的结果。

该实施例的好处是，将跨域服务发现服务的流程与跨域业务编排服务的流程串联起来，在跨域服务发现服务没有发现到请求的服务时，在一些情况下直接转给跨域业务编排服务去编排，提高了服务之间协同运作的效率，也提高了新业务编排的效率。

在上述实施例中，将需要编排的业务协议直接放在跨子域服务发现请求、以及对跨域业务编排服务的调用请求中发送，这样，要编排业务时，可以直接从相关请求中取回，达到简单易行的效果。但很多情况下，受请求大小限制，往往该协议无法放入请求中发送，而是与业务类型对应存储在总运维服务器中。在跨子域服务发现请求中包含业务类型。业务编排服务编排业务时，就可以在总运维服务器中直接找到该业务类型对应的业务协议。在该实施例中，在步骤220之后，所述方法还包括：

如果确定该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息中的任一个都不对应，获取该跨子域服务发现请求中的业务类型；

将获取的业务类型放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，以便所述跨域业务编排服务找到与业务类型对应的业务协议。

该实施例的优点是，将业务协议存储在总运维服务器中，可以降低网络传输的拥塞。

下面描述根据本公开一个实施例的跨子域通信运维方法在边缘云智能运维的应用场景中的应用。

边缘云的运维是指对边缘云的运行的维护，包括对边缘云流量的管控、故障的处理、分流策略的更新、业务访问控制的实时控制等。

边缘云流量的管控是指为了防止某个边缘云上的流量过大导致处理速度过慢或边缘云崩溃，当边缘云上的流量超过一个阈值时将该边缘云的流量分出一部分到核心网云或其它边缘云。要实现这种管控，边缘云运维服务器要将边缘云流量指标信息(如边缘云流量)上报给总运维服务器，由总运维服务器确定该边缘云流量是否需要调整，如果需要调整，采用什么样的分流策略将该边缘云流量调整到合适水平。

在该应用场景下，如图1B所示的子域运维服务器104中的一个是边缘云运维服务器，即边缘云子域中处理边缘云业务(如边缘云计算)的服务器。步骤220包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云流量指标信息和流量管控业务的业务协议。

跨子域服务发现请求包括边缘云流量指标信息的目的在于，如上所述，使得总运维服务器根据该指标信息，确定该边缘云流量是否需要调整、以及调整后的分流策略。跨子域服务发现请求包括流量管控业务的业务协议的目的在于，如果根据边缘云流量指标信息确定需要管控，确定采用什么样的分流策略是需要一个流量管控业务来执行，而如果该业务目前还不存在的话，就需要进行编排，而流量管控业务的业务协议是编排所需要的。

边缘云流量指标信息是指能够反映出边缘云的流量的指标的信息，其可以是边缘云流量，或者是边缘云流量超过其流量阈值的百分比，或者是边缘云流量超过流量阈值的预警指示。在后两种情况下，在边缘云运维服务器中存储有流量阈值，在发送跨子域服务发现请求之前，边缘云运维服务器计算出该边缘云流量超过该流量阈值的百分比，或者将边缘云流量与流量阈值进行比较，当超过流量阈值时给出预警指示。

这样，总运维服务器接收到该跨子域服务发现请求后，由于目前尚无这种流量管控业务，其会确定出该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息都不对应，这样，执行步骤236，即获取该请求中的业务协议。本实施例中，所述获取该跨子域服务发现请求中的业务协议，包括：如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。

也就是说，本实施例中，不是当该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息都不对应都会获取业务协议，而是先将边缘云流量指标信息与预定流量指标信息标准比较，如果不符合该标准，则直接拒绝该跨子域服务发现请求。这里的拒绝该跨子域服务发现请求，在一个实施例中可以是指，向子域运维服务器发送没有找到对应子域服务的响应，在另一个实施例中可以是指，不做任何处理，直接丢弃该请求。

预定流量指标信息标准随边缘云流量指标信息的不同而不同。在边缘云流量指标信息是边缘云流量的情况下，该预定流量指标信息标准可以是该边缘云流量大于预定流量阈值；在边缘云流量指标信息是边缘云流量超过其流量阈值的百分比的情况下，该预定流量指标信息标准可以是在该请求中有这样一个边缘云流量超过其流量阈值的百分比；在边缘云流量指标信息是边缘云流量超过流量阈值的预警指示的情况下，该预定流量指标信息标准可以是在该请求中有这样一个预警指示。

流量管控的业务协议是反映流量管控这种业务的要求的协议。

确定边缘云流量指标信息是否符合预定流量指标信息标准是由跨域服务发现服务来执行的，在确定结果为符合时，在步骤241中，跨域服务发现服务将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给跨域业务编排服务。然后，跨域业务编排服务执行如图5所示的流程，进行跨域业务编排。执行完跨域业务编排后，跨域业务编排结果(实际上对该边缘云的路由策略)通过跨域业务分发服务分发到核心网子域运维服务器，由核心网子域运维服务器下发给核心网网元包控制模块(PCF)。PCF是CDMA2000 1X系统的新增物理实体，其作用主要是用于转发无线子系统和PDSN分组控制单元之间的消息，完成与分组数据有关的无线信道控制功能，对移动用户所进行的分组数据业务进行转换、管理与控制。

作为将该路由策略下发到PCF的结果，更新对该边缘云的路由策略。比如，PCF会修改业务分流策略，减少接入边缘云的用户设备(UE)的数量。比如，UE在建立协议数据单元(PDU)会话时，PCF下发策略指示业务管理功能(SMF)对于该UE的业务直接路由到核心网的UPF，即使本地边缘云上可以支持该UE的业务，也不给该UE下发相应的分流策略。

图14示出了边缘云流量管控实现中的各设备或模块之间交互流程图。在步骤220中，边缘云子域运维服务器向总运维服务器发送跨子域服务发现请求，该请求包含边缘云流量指标信息和流量管控的业务协议。跨域服务发现服务接收到该请求，在步骤236中，确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。在步骤241中，跨域服务发现服务将获取的业务协议放置于对跨域业务编排服务的调用请求中发送。在步骤410中，跨域业务编排服务向跨域业务分发服务发送对跨域业务分发服务的调用请求，该调用请求中包括业务拆解成的业务单元和对应的核心网运维服务器标识。在步骤420中，跨域业务分发服务将拆解成的业务单元分发给核心网子域运维服务器。在步骤610中，核心网子域运维服务器将拆解成的业务单元(分流策略)下发到核心网网元PCF。

该实施例的好处是，边缘云平台可以通过跨域运维系统，间接控制接入该平台的UE数量，实现流量管控。

另外，在业务协议不放入请求中发送，而是与业务类型对应存储在总运维服务器中的实施例中，步骤220可以包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云流量指标信息和流量管控的业务类型。所述获取该跨子域服务发现请求中的业务类型，包括：如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务类型。

故障的处理是指对于边缘云故障或者因为内部功能升级停止服务的情况，及时更新对边缘云的路由策略，停止边缘云对UE提供服务。

在边缘云故障处理的应用中，在一个实施例中，步骤310包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务故障定位服务的调用指示、发生故障的业务标识。

由于在总运维服务器中有一个专门的跨域业务故障定位服务，专门处理各个子域的业务故障，因此，在边缘云故障或者因为内部功能升级停止服务的情况下，边缘云运维服务器可以直接向总运维服务器发一个请求，该请求中有对该跨域业务故障定位服务的调用指示。另外，由于边缘云可能运行各种业务，到底哪个业务出现了故障，需要停止对UE进行服务，要进行区分，因此，该请求中还携带发生故障的业务标识。业务标识是唯一区分该业务，使得该业务区别于其它业务的标记。

一般来说，由总运维服务器的跨域服务发现服务从边缘云运维服务器接收到上述跨子域服务发现请求。

所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务故障定位服务的调用指示，确定该跨子域服务发现请求对应于跨域业务故障定位服务。该步骤也是由跨域服务发现服务执行。跨域服务发现服务发现该跨子域服务发现请求中有一个对跨域业务故障定位服务的调用指示，则确定这个请求是一个要调用跨域业务故障定位服务的请求。在这种情况下，调用该跨域业务故障定位服务。其包括：向跨域业务故障定位服务发送对跨域故障定位服务的调用请求，所述调用请求中包括发生故障的业务标识，以便跨域业务故障定位服务确定该业务标识对应的产生故障的运维服务器标识和维护措施，将确定的维护措施发送给确定的运维服务器标识的运维服务器。

如图7所示，对跨域故障定位服务的调用请求除了包括发生故障的业务标识之外，还应包括针对业务的故障描述。与此相应地，跨子域服务发现请求也应该包括针对业务的故障描述，否则跨域服务发现服务无法把这个故障描述传递给跨域业务故障定位服务。跨域故障定位服务可以如图7所示，根据业务标识，从跨域业务编排服务中，获取与该业务标识对应的业务单元和对应的运维服务器标识，基于所述故障描述、获取的业务单元和对应的运维服务器标识，确定产生故障的运维服务器标识和维护措施，通过跨域业务分发服务，将确定的维护措施发送给确定的运维服务器标识的运维服务器。

图15示出了在边缘云故障处理的情形下各设备或模块的交互流程图。

在步骤220中，边缘云子域运维服务器发现业务故障，向总运维服务器发送跨子域服务发现请求，该请求中包含对跨域业务故障定位服务的调用指示、和业务标识。总运维服务器中的跨域服务发现服务首先接收到该跨子域服务发现请求，按照其中的调用指示，在步骤235中，调用跨域业务故障定位服务。跨域业务故障定位服务在步骤530中，基于调用请求中的故障描述、业务对应的业务单元和对应的运维服务器标识，确定产生故障的核心网子域运维服务器标识和维护信息(即停止业务策略)，发送给跨域业务分发服务，由跨域业务分发服务进行分发。跨域业务分发服务在步骤540中，将确定的维护信息发给核心网子域运维服务器，以便在步骤510中，由核心网子域运维服务器下发到核心网网元PCF。PCF会取消分流到该边缘云平台上的该业务的分流策略，使得该业务可以路由回核心网，而不是路由到边缘云平台上，从而实现故障业务的隔离。

当边缘云平台的业务故障恢复正常后，边缘云子域运维服务器会重新发送启用该业务的跨子域服务器发现请求，恢复该业务。

在一个实施例中，步骤310包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务故障定位服务的调用指示、要恢复的业务标识。要恢复的业务标识是使得要恢复的业务区别于其它业务的标记。由总运维服务器的跨域服务发现服务从边缘云运维服务器接收到上述跨子域服务发现请求。

所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务故障定位服务的调用指示，确定该跨子域服务发现请求对应于跨域业务故障定位服务。跨域服务发现服务发现该跨子域服务发现请求中有一个对跨域业务故障定位服务的调用指示，则确定这个请求是一个要调用跨域业务故障定位服务的请求。在这种情况下，调用该跨域业务故障定位服务。其包括：向跨域业务故障定位服务发送对跨域故障定位服务的调用请求，所述调用请求中包括要恢复的业务标识，以便跨域业务故障定位服务确定该业务标识对应的该业务产生故障时指示进行维护的运维服务器标识，指示该运维服务器标识的运维服务器停止执行维护措施。

如图15所示，在步骤530中，跨域业务故障定位服务确定产生故障的核心网子域运维服务器标识和维护信息后，将该核心网子域运维服务器标识和维护信息与业务标识对应存储。当在恢复业务时，跨域业务故障定位服务接收到对跨域业务故障定位服务的调用请求，就可以按照该调用请求中的业务标识，查找与其对应存储的核心网子域运维服务器标识，然后就可以向该标识的核心网子域运维服务器发起一个停止执行维护措施的请求。该核心网子域运维服务器接收到该请求后，停止执行之前让其执行的维护措施。核心网子域运维服务器将请求发送给核心网网元PCF，该PCF重新配置到该边缘云平台服务区域内的UE的分流策略。当该区域内的UE发起访问该业务的PDU会话时，PCF会配置分流策略给UL CL的UPF，从而将相应的业务流路由到边缘云平台上，从而实现故障业务的恢复。

分流策略的更新是指边缘云平台根据自身的业务状况调整其需要的分流策略后，将该分流策略通过本公开实施例的体系构架进行执行，从而将实现该更新后的风流策略的过程。

在一个实施例中，步骤310包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务分发服务的调用指示、修改后的分流策略。

与上述边缘云故障处理要由跨域业务故障定位服务生成一个分流策略再下发不同，在分流策略更新的应用中，是边缘云子域运维服务器自身根据自己的业务状况生成一个修改后的分流策略，因此，不用调用跨域业务故障定位服务，只需要调用跨域业务分发服务就可以了。所以，该跨子域服务发现请求包括的是对跨域业务分发服务的调用指示、以及修改后的分流策略。在一个实施例中，上述跨子域服务发现请求是由跨域服务发现服务接收的。

另外，在一个实施例中，上述跨子域服务发现请求包括以下中的至少一种：

业务流描述符，如IP地址信息；

业务统一资源定位符信息；

业务提供商标识信息。

上述信息实质上是对边缘云分流策略针对哪一种业务进行分流的指示。跨域服务发现服务接收到该信息后，才能够知道对哪一种业务进行分流。

在该实施例中，所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务分发服务的调用指示，确定该跨子域服务发现请求对应于跨域业务分发服务。由于该跨子域服务发现请求包含对跨域业务分发服务的调用指示，因此，所述跨域服务发现服务可以明确地知道该调用指示是要调用跨域业务分发服务。

在一个实施例中，对跨域业务分发服务的调用指示也要包括以下中的至少一种：

业务流描述符，如IP地址信息；

业务统一资源定位符信息；

业务提供商标识信息。

如上所述，上述信息的作用是为了区别是对哪一种业务进行分流。

在该实施例中，所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务分发服务发送对跨域业务分发服务的调用请求，所述调用请求中包括修改后的分流策略和对应的运维服务器标识，以便跨域业务分发服务将修改后的分流策略向对应的运维服务器标识的运维服务器分发。

跨域服务发现服务向跨域业务分发服务发送的对跨域业务分发服务的调用请求要包括修改后的分流策略，这样，才能够让跨域业务分发服务将修改后的分流策略进行分发，从而实现分流策略的更新的目的。另外，分发要有一个分发到的对象，即负责进行这种分流策略更新执行的核心网子域运维服务器。一个核心网子域运维服务器可能负责多个边缘云子域运维服务器上的流量的分流。跨域业务分发服务可以存储着一个边缘云子域运维服务器标识与核心网子域运维服务器标识的对应关系表。跨域业务分发服务根据发出该跨子域服务发现请求的边缘云子域运维服务器的标识，查找该对应关系表，得到负责其流量运维的核心网子域运维服务器标识，从而将修改后的分流策略向对应的运维服务器标识的运维服务器分发。

另外，在一个实施例中，所述对跨域业务分发服务的调用请求中也应当含有以下中的至少一种：

业务流描述符，如IP地址信息；

业务统一资源定位符信息；

业务提供商标识信息。

通过上述信息，使得跨域业务分发服务能够知道对哪一种业务进行分流，从而能够指示核心网子域运维服务器进行正确的分流策略更新。

图16示出了边缘云分流策略更新的应用中各设备或模块交互流程图。在步骤220中，边缘云子域运维服务器向跨域服务发现服务发送跨子域服务发现请求，其中该请求包含对跨域业务分发服务的调用指示、修改后的分流策略。在步骤235中，跨域服务发现服务向跨域业务分发服务发送对跨域业务分发服务的调用请求，所述调用请求中包括修改后的分流策略和对应的运维服务器标识。在步骤420中，跨域业务分发服务将修改后的分流策略分发给核心网子域运维服务器。在步骤601中，核心网子域运维服务器将修改后的分流策略下发到核心网网元PCF。PCF根据修改后的分流策略，进行该边缘云平台上流量的调整。

该实施例的好处是，边缘云平台可以通过跨域运维系统，间接控制接入该平台的分流策略。

业务访问控制的实时控制是指对边缘云平台业务访问的实时流量进行控制，根据实时流量动态调节允许其实时接入的业务访问量。

在一个实施例中，步骤220包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云业务访问信息和访问管控业务的业务协议。

边缘云业务访问信息是有关访问该边缘云平台的状况的信息。在一个实施例中，它包括以下中的至少一个：

业务流量描述符；

对应于业务的访问失败率；

在特定时间段内对应于业务的访问失败率；

对应于业务的访问失败的用户设备标识。

业务流量描述符是指描述访问边缘云平台的业务流量的符号，其数值代表边缘云平台的业务信息。

跨子域服务发现请求包括边缘云业务访问信息的目的在于，如上所述，使得总运维服务器根据该访问信息，确定该边缘云访问量是否需要调整、以及调整后的分流策略。跨子域服务发现请求包括访问管控业务的业务协议的目的在于，如果根据边缘云访问量确定需要管控，确定采用什么样的分流策略需要一个访问管控业务来执行，而如果该业务目前还不存在的话，就需要进行编排，而访问管控业务的业务协议是编排所需要的。

总运维服务器接收到该跨子域服务发现请求后，由于目前尚无这种流量管控业务，其会确定出该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息都不对应，这样，执行步骤236，即获取该请求中的业务协议。本实施例中，所述获取该跨子域服务发现请求中的业务协议，包括：如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。在步骤241中，所述将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，包括：将边缘云业务访问信息和业务访问管控业务的业务协议一起放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。这是因为，管控业务的编排不仅与访问管控业务的业务协议有关，还与边缘云业务访问信息有关。同样一种业务协议，由于其面临的访问状况不同，其需要管控的做法可能不同。

然后，在步骤320中，跨域业务编排服务开始拆解业务单元。在该步骤中，根据所述业务协议，将业务拆解成业务单元，包括：根据所述业务协议和边缘云业务访问信息，将业务拆解成业务单元。

在上述实施例中，步骤320包括：

查找与所述业务协议中的每个模板协议段标识对应的协议段程序；

根据用户在业务协议模板中填写的参数、以及边缘云业务访问信息，按照与所述参数和边缘云业务访问信息对应的预定规则，修改相应模板协议段标识对应的协议段程序，得到相应协议段的业务单元。

由于业务协议模板包括多个模板协议段，每个协议段对应的协议段程序预先编写好，与协议段标识对应存储。由于业务协议模板上要在预定位置填写相应参数才能得到业务协议，因此，要对预先编写好的协议段程序按照这些参数进行修改。另外，由于边缘云业务访问信息不同，即目前边缘云访问量的状况不同，对其的修改方式也不应该相同。因此，实现针对每种所述参数和边缘云业务访问信息，设置对应的预定规则，这样，就可以根据用户在业务协议模板中填写的参数、以及边缘云业务访问信息，按照与所述参数和边缘云业务访问信息对应的预定规则，修改相应模板协议段标识对应的协议段程序，得到相应协议段的业务单元。业务单元就是业务的运行程序中一个单独存在的程序代码段。

图17示出了在边缘云业务访问控制的应用下各设备或模块交互的流程图。

在步骤220中，边缘云子域运维服务器向总运维服务器发送跨子域服务发现请求，该请求包含边缘云业务访问信息和访问管控业务的业务协议。跨域服务发现服务接收到该请求。在步骤241中，跨域服务发现服务将边缘云业务访问信息和业务协议一起放置在对跨域业务编排服务的调用请求中发送。在步骤320中，跨域业务编排服务根据业务协议获得边缘云业务访问信息，将业务拆解成业务单元。在步骤330中，跨域业务编排服务确定与拆解成的各业务单元对应的运维服务器标识。在步骤410中，跨域业务编排服务向跨域业务分发服务发送对跨域业务分发服务的调用请求。在步骤420中，跨域业务分发服务将拆解成的业务单元分发给核心网子域运维服务器。在步骤601中，核心网子域运维服务器将该业务单元下发到核心网网元PCF，PCF会修改业务分流策略，对边缘云的访问状况进行控制，例如减少业务访问失败情况的发生，提高业务命中率。

另外，在业务协议不放入请求中发送，而是与业务类型对应存储在总运维服务器中的实施例中，步骤220可以包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云业务访问信息和业务访问管控业务的业务类型。所述将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，包括：将边缘云业务访问信息和业务访问管控业务的业务类型一起放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，以便跨域业务编排服务在总运维服务器中找到与所述业务类型对应存储的业务协议。

本公开实施例实现了移动网络中跨域跨层的运维管理，实现业务的跨域编排能力和跨域的分析能力，提升网络运维效率和管理能力。此外，该跨域运维系统通过服务化的方式来实现，对于该系统的后续升级改造具备很大的灵活性，同时也可以实现对于海量服务的运维管理。最后，基于该架构提出了对于边缘云平台智能运维的实现方案，有效解决了边缘云的规则配置，规则动态更新等有关边缘云与核心云的交互等问题。

根据本公开的一个实施例，还提供了一种总运维服务器，所述总运维服务器用于各子域之间的通信运维，各子域中分别具有运维服务器，所述总运维服务器包括：

子域服务注册信息接收单元710，用于接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；

跨子域服务发现请求接收单元720，用于接收跨子域服务发现请求；

子域服务调用请求发送单元730，用于如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

在一个实施例中，所述总运维服务器还包括：

跨域服务注册信息生成单元，用于响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储；

跨域服务调用单元，用于如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，调用该跨域服务注册信息对应的跨域服务。

在一个实施例中，所述子域服务注册信息中含有子域服务调用权限信息。所述子域服务调用请求发送单元进一步用于：

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，但该跨子域服务发现请求不符合该匹配的子域服务注册信息中的子域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，且该跨子域服务发现请求符合该匹配的子域服务注册信息中的子域服务调用权限信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

在一个实施例中，所述跨域服务注册信息中含有跨域服务调用权限信息。所述跨域服务调用单元进一步用于：

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，但该跨子域服务发现请求不符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，且该跨子域服务发现请求符合该匹配的跨域服务注册信息中的跨域服务调用权限信息，调用该跨域服务注册信息对应的跨域服务。

在一个实施例中，所述跨域服务注册信息具有跨域服务标识。所述调用该跨域服务注册信息对应的跨域服务，包括：调用所述跨域服务注册信息中的跨域服务标识代表的跨域服务。

在一个实施例中，所述跨域服务包含跨域注册管理服务和跨域服务发现服务。所述子域服务注册信息接收单元是所述跨域注册管理服务的执行模块，所述跨子域服务发现请求接收单元、子域服务调用请求发送单元是所述跨域服务发现服务的执行模块。

在一个实施例中，所述跨域服务还包含跨域业务编排服务，用于执行以下过程：

接收对跨域业务编排服务的调用请求，所述调用请求中包含业务协议；

根据所述业务协议，将业务拆解成业务单元；

查找业务单元与运维服务器标识对应关系表，确定与拆解成的各业务单元对应的运维服务器标识。

在一个实施例中，所述跨域服务还包含跨域业务分发服务，用于执行以下过程：

接收对可以业务分发服务的调用请求，所述调用请求中包含业务拆解成的业务单元和对应的运维服务器标识；

将业务拆解成的业务单元向对应的运维服务器标识的运维服务器分发。

在一个实施例中，所述跨域服务还包含跨域业务故障定位服务，用于执行以下过程：

接收对跨域故障定位服务的调用请求，所述调用请求中包含针对业务的故障描述；

从所述跨域业务编排服务中，获取与该业务对应的业务单元和对应的运维服务器标识；

基于所述故障描述、获取的业务单元和对应的运维服务器标识，确定产生故障的运维服务器标识和维护措施；

将确定的维护措施发送给确定的运维服务器标识的运维服务器。

在一个实施例中，所述总运维服务器还包括：

子域服务合并请求接收单元，用于接收子域中的运维服务器发出的对已注册的该子域内的多个子域服务的合并请求；

子域服务注册信息合并单元，用于将所述多个子域服务的子域服务注册信息合并成合并后子域服务注册信息，替换所述多个子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

在一个实施例中，所述总运维服务器还包括：

跨域服务合并请求接收单元，用于接收总运维服务器生成的对已注册的多个跨域服务的合并请求；

跨域服务注册信息合并单元，用于将所述多个跨域服务的跨域服务注册信息合并成合并后跨域服务注册信息，替换所述多个跨域服务的跨域服务注册信息，与该运维服务器的标识对应存储。

在一个实施例中，所述总运维服务器还包括：

子域服务拆分请求接收单元，用于接收子域中的运维服务器发出的对已注册的该子域内的子域服务的拆分请求；

子域服务注册信息拆分单元，用于按照所述拆分请求，将所述子域服务的子域服务注册信息拆分成拆分后的多个子域服务注册信息，替换所述子域服务的子域服务注册信息，与该运维服务器的标识对应存储。

在一个实施例中，所述总运维服务器还包括：

跨域服务拆分请求接收单元，用于接收总运维服务器生成的对已注册的跨域服务的拆分请求；

跨域服务注册信息拆分单元，用于按照所述拆分请求，将所述跨域服务的跨域服务注册信息拆分成拆分后的多个跨域服务注册信息，替换所述跨域服务的跨域服务注册信息存储。

在一个实施例中，所述总运维服务器还包括：

业务协议获取单元，用于如果确定该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息中的任一个都不对应，获取该跨子域服务发现请求中的业务协议；

调用请求发送单元，用于将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。

在一个实施例中，各子域中的运维服务器包括边缘云运维服务器。所述跨子域服务发现请求接收单元进一步用于：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云流量指标信息和流量管控业务的业务协议。所述业务协议获取单元进一步用于：如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。

在一个实施例中，各子域中的运维服务器包括边缘云运维服务器。所述跨子域服务发现请求接收单元进一步用于：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务故障定位服务的调用指示、发生故障的业务标识。所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务故障定位服务的调用指示，确定该跨子域服务发现请求对应于跨域业务故障定位服务。所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务故障定位服务发送对跨域故障定位服务的调用请求，所述调用请求中包括发生故障的业务标识，以便跨域业务故障定位服务确定该业务标识对应的产生故障的运维服务器标识和维护措施，将确定的维护措施发送给确定的运维服务器标识的运维服务器。

在一个实施例中，各子域中的运维服务器包括边缘云运维服务器。所述跨子域服务发现请求接收单元进一步用于：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务分发服务的调用指示、修改后的分流策略。所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务分发服务的调用指示，确定该跨子域服务发现请求对应于跨域业务分发服务。所述跨域服务调用单元进一步用于：向跨域业务分发服务发送对跨域业务分发服务的调用请求，所述调用请求中包括修改后的分流策略和对应的运维服务器标识，以便跨域业务分发服务将修改后的分流策略向对应的运维服务器标识的运维服务器分发。

在一个实施例中，各子域中的运维服务器包括边缘云运维服务器。所述跨子域服务发现请求接收单元进一步用于：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云业务访问信息和访问管控业务的业务协议。所述调用请求发送单元进一步用于：将边缘云业务访问信息和访问管控业务的业务协议一起放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。所述根据所述业务协议，将业务拆解成业务单元，包括：根据所述业务协议和边缘云业务访问信息，将业务拆解成业务单元。

根据本公开实施例的数字资产凭证继承转移中的信息处理方法可以由图19的总运维服务器101实现。

如图19所示，总运维服务器101以通用计算设备的形式表现。总运维服务器101的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图3中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：社交操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

总运维服务器101也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该总运维服务器101交互的设备通信，和/或与使得该总运维服务器101能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，总运维服务器101还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与总运维服务器101的其它模块通信。应当明白，尽管图中未示出，可以结合总运维服务器101使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (15)

1.一种跨子域通信运维方法，其特征在于，各子域中分别具有运维服务器，所述方法应用于总运维服务器，总运维服务器用于各子域之间的通信运维，所述方法包括：

接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；

接收跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

2.根据权利要求1所述的方法，其特征在于，在接收跨子域服务发现请求之前，所述方法还包括：响应于总运维服务器生成的跨域服务，生成跨域服务注册信息并存储；

在接收跨子域服务发现请求之后，所述方法还包括：如果确定该跨子域服务发现请求对应于一个存储的跨域服务注册信息，调用该跨域服务注册信息对应的跨域服务。

3.根据权利要求1所述的方法，其特征在于，所述子域服务注册信息中含有子域服务调用权限信息；

所述如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求，包括：

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，但该跨子域服务发现请求不符合该匹配的子域服务注册信息中的子域服务调用权限信息，拒绝所述跨子域服务发现请求；

如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，且该跨子域服务发现请求符合该匹配的子域服务注册信息中的子域服务调用权限信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

4.根据权利要求2所述的方法，其特征在于，所述跨域服务包含跨域注册管理服务和跨域服务发现服务，所述接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储的步骤是由所述跨域注册管理服务执行的，所述接收跨子域服务发现请求、发送子域服务调用请求的步骤是由所述跨域服务发现服务执行的。

5.根据权利要求4所述的方法，其特征在于，所述跨域服务还包含跨域业务编排服务，用于执行以下过程：

接收对跨域业务编排服务的调用请求，所述调用请求中包含业务协议；

根据所述业务协议，将业务拆解成业务单元；

查找业务单元与运维服务器标识对应关系表，确定与拆解成的各业务单元对应的运维服务器标识。

6.根据权利要求5所述的方法，其特征在于，所述跨域服务还包含跨域业务分发服务，用于执行以下过程：

接收对跨域业务分发服务的调用请求，所述调用请求中包含业务拆解成的业务单元和对应的运维服务器标识；

将业务拆解成的业务单元向对应的运维服务器标识的运维服务器分发。

7.根据权利要求5所述的方法，其特征在于，所述跨域服务还包含跨域业务故障定位服务，用于执行以下过程：

接收对跨域故障定位服务的调用请求，所述调用请求中包含针对业务的故障描述；

从所述跨域业务编排服务中，获取与该业务对应的业务单元和对应的运维服务器标识；

基于所述故障描述、获取的业务单元和对应的运维服务器标识，确定产生故障的运维服务器标识和维护措施；

将确定的维护措施发送给确定的运维服务器标识的运维服务器。

8.根据权利要求5所述的方法，其特征在于，在接收跨子域服务发现请求之后，所述方法还包括：

如果确定该跨子域服务发现请求与存储的子域服务注册信息和跨域服务注册信息中的任一个都不对应，获取该跨子域服务发现请求中的业务协议；

将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务。

9.根据权利要求8所述的方法，其特征在于，各子域中的运维服务器包括边缘云运维服务器；

所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云流量指标信息和流量管控业务的业务协议；

所述获取该跨子域服务发现请求中的业务协议，包括：

如果确定所述边缘云流量指标信息符合预定流量指标信息标准，获取该跨子域服务发现请求中的业务协议。

10.根据权利要求7所述的方法，其特征在于，各子域中的运维服务器包括边缘云运维服务器；

所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务故障定位服务的调用指示、发生故障的业务标识；

所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务故障定位服务的调用指示，确定该跨子域服务发现请求对应于跨域业务故障定位服务；

所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务故障定位服务发送对跨域故障定位服务的调用请求，所述调用请求中包括发生故障的业务标识，以便跨域业务故障定位服务确定该业务标识对应的产生故障的运维服务器标识和维护措施，将确定的维护措施发送给确定的运维服务器标识的运维服务器。

11.根据权利要求6所述的方法，其特征在于，各子域中的运维服务器包括边缘云运维服务器；

所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括对跨域业务分发服务的调用指示、修改后的分流策略；

所述确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，包括：根据所述对跨域业务分发服务的调用指示，确定该跨子域服务发现请求对应于跨域业务分发服务；

所述调用该跨域服务注册信息对应的跨域服务，包括：向跨域业务分发服务发送对跨域业务分发服务的调用请求，所述调用请求中包括修改后的分流策略和对应的运维服务器标识，以便跨域业务分发服务将修改后的分流策略向对应的运维服务器标识的运维服务器分发。

12.根据权利要求8所述的方法，其特征在于，各子域中的运维服务器包括边缘云运维服务器；

所述接收跨子域服务发现请求，包括：从边缘云运维服务器接收跨子域服务发现请求，所述跨子域服务发现请求包括边缘云业务访问信息和业务访问管控业务的业务协议；

所述将获取的业务协议放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务，包括：将边缘云业务访问信息和业务访问管控业务的业务协议一起放置于对跨域业务编排服务的调用请求中，发送给所述跨域业务编排服务；

所述根据所述业务协议，将业务拆解成业务单元，包括：根据所述业务协议和边缘云业务访问信息，将业务拆解成业务单元。

13.一种总运维服务器，其特征在于，所述总运维服务器用于各子域之间的通信运维，各子域中分别具有运维服务器，所述总运维服务器包括：

子域服务注册信息接收单元，用于接收各子域中的运维服务器在子域内生成子域服务后发送的子域服务注册信息并与该运维服务器的标识对应存储；

跨子域服务发现请求接收单元，用于接收跨子域服务发现请求；

子域服务调用请求发送单元，用于如果确定该跨子域服务发现请求对应于一个存储的子域服务注册信息，向具有与该子域服务注册信息对应的该运维服务器的标识的运维服务器，发送子域服务调用请求。

14.一种总运维服务器，其特征在于，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-12中任一所述的方法。

15.一种计算机可读程序介质，其特征在于，其存储有计算机可读指令，当所述计算机可读指令被处理器执行时，使计算机执行权利要求1-12中任一所述的方法。