具体实施方式
下面将详细描述本发明的各个方面的特征和示例性实施例,为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细描述。应理解,此处所描述的具体实施例仅被配置为解释本发明,并不被配置为限定本发明。对于本领域技术人员来说,本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括……”限定的要素,并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
首先,针对本发明实施例中提及的云计算和边缘计算,说明如下。
云计算是利用虚拟化整合零散分布的各种IT资源,包括网络、计算、存储、应用软件以及服务。其中,云计算使计算分布在大量的分布式计算机上,而非本地计算机或远程服务器中。
边缘计算起源于传媒领域,是指在靠近物或数据源头的一侧,采用网络、计算、存储、应用核心能力为一体的开放平台,就近提供最近端服务。
云计算和边缘计算各有所长,云计算擅长全局性、非实时、长周期的大数据处理与分析,能够在长周期维护、业务决策支撑等领域发挥优势。边缘计算更适用局部性、实时、短周期数据的处理与分析,能更好地支撑本地业务的实时智能化决策与执行。
在一些场景中,需要云计算和边缘计算进行信息协同。云计算与边缘计算需要通过紧密协同才能更好的满足各种需求场景的匹配,从而放大云计算和边缘计算的应用价值。由边缘计算产业联盟和工业互联网产业联盟于2018年11月联合发布的《边缘计算与云计算协同白皮书》对云边协同进行了详细的阐述。由此,云计算与边缘计算的协同融合发展成为当前业界关注的焦点。云边协同成为推动边缘计算落地的重要力量。
作一个示例,当前大多数企业上云的首选方案是异构混合云。混合云融合了公有云和私有云,是近年来云计算的主要模式和发展方向。异构是指企业通常会采购多家云服务提供商的云产品,并通过统一的多云管理平台进行各种云环境中运行的应用程序和资源的管理。其次,由于每种边缘计算平台针对的问题不同,所以它们的设计多种多样,没有统一的标准。在同一企业、工厂、城市、交通的场景中部署多种边缘计算平台的情况也必将存在。针对此种场景,如何解决混合异构的云计算平台和边缘计算平台之间的协同问题,将变得十分重要,这也正是本提案要解决的问题。
因此,本发明实施例提供了一种能够实现云计算平台和边缘计算平台之间的信息协同的方案。
为了便于理解本发明,下述部分先介绍两种云边协同方案。
第一种方案:基于Kubernetes(即一种开源的、用于管理云平台中多个主机上的容器化的应用)的边缘计算平台的云边协同方案。示例性的,基于Kubernetes的边缘计算平台可以是某为的KubeEdge和Rancher的K3S。
基于Kubernetes的边缘计算平台,可以依托Kubernetes的容器编排和调度能力,实现云边协同、计算下沉、海量设备接入等功能。然而,依靠此类平台实现云边协同的话,不仅要求云计算平台是基于Kubernetes构建的,也要求边缘计算平台提供对Kubernetes和容器技术的支持。
第二种方案:基于云计算服务提供商提供的面向云边融合的边缘计算平台的云边协同方案。示例性的,面向云边融合的边缘计算平台可以是亚某逊公司的AWS Greengrass,某软公司的Azure IoT Edge,某云公司的物联网边缘计算平台LinkIoT Edge等。
云计算服务提供商提供的面向云边融合的边缘计算平台,是一种混合云和边缘的边缘计算框架,旨在将云功能拓展至如路由器和交换机等具备计算能力的边缘设备上。然而,此类平台实现的边缘计算框架将云边协同的功能限定在自家特定的云计算平台之上,不便于扩展到混合异构云的使用场景。
综上,两种协同方案均需要满足特定的条件才能实现边缘计算和云计算的协同,具有一定的局限性。
为了更好的理解本发明,下面将结合附图,详细描述根据本发明实施例的云边协同方法、装置、系统、设备和介质,应注意,这些实施例并不用来限制本发明公开的范围。
图1是本发明实施例提供的一种云边协同系统的框架示意图。如图1所示,云边协同系统10包括第一待协同平台的管理平台11、云边协同平台12和第二待协同平台的管理平台13。
其中,第一待协同平台的管理平台11可以与m个第一协同平台21至2m交互连接。第二待协同平台的管理平台13可以与n个第二协同平台31至3n交互连接。m、n均为正整数。
第一协同平台是协同消息的发送方,当m个第一协同平台21至2m中的一个或多个平台需要发送协同消息时,可以将需要发送消息的第一协同平台作为第一待协同平台。第二协同平台是协同消息的接收方,当n个第二协同平台31至3n中的一个或多个平台需要接收协同消息时,可以将需要接受消息的第二协同平台作为第二待协同平台。
具体地,第一待协同平台是云计算平台和边缘计算平台两者中的一者,第二待协同平台是云计算平台和边缘计算平台两者中的另一者。具体地,可以根据协同消息的传输方向确定第一待协同平台和第二待协同平台,即,若协同消息需要从云计算平台传输至边缘计算平台,则第一协同平台为云计算平台,第二协同平台是边缘计算平台。与之相反的是,若协同消息需要从边缘计算平台传输至云计算平台,则第一协同平台为边缘计算平台,第二协同平台是云计算平台。
首先,针对第一待协同平台的管理平台11,云边协同平台12需要借助第一待协同平台的管理平台11与第一待协同平台进行信息交互。相应地,考虑到云边协同平台12所支持的协同信息格式与第一待协同平台所支持的协同信息格式可能不同,第一待协同平台的管理平台11至少具备下述两个功能。
(1)、接收第一待协同平台的第一协同消息,并将所接收的第一协同消息转换为标准协同消息后发送至云边协同平台12。
(2)、接收第一待协同平台的标准协同消息,并将所接收的标准协同消息转换为第一协同消息后发送至对应的第一待协同平台。
需要说明的是,第一协同消息为第一待协同平台能够支持的协同消息。考虑到不同的第一待协同平台可以支持不同格式的协同消息,不同的第一待协同平台所支持的第一协同消息不同。
在一些实施例中,第一待协同平台的管理平台11具有多个插件,m个第一待协同平台21至2m可以通过上述多个插件与第一待协同平台的管理平台11进行信息交互。具体地,上述多个插件具备特定的功能,上述多个插件可以是统一的接口的基础上实现的。也就是说,统一的接口可以视为标准插件模板,通过对统一的接口进行具象化,可以得到具备特定功能的插件。
此外,在一些实施例中,上述插件除了信息交互的连接功能外,第一待协同平台的管理平台11的上述功能(1)和功能(2)可以由上述插件实现。
其次,针对第二待协同平台的管理平台13,云边协同平台12需要借助第二待协同平台的管理平台13与第二待协同平台进行信息交互。相应地,考虑到云边协同平台12所支持的协同信息格式与第二待协同平台所支持的协同信息格式可能不同,第二待协同平台的管理平台13至少具备下述两个功能。
(1)、接收第二待协同平台的第二协同消息,并将所接收的第一协同消息转换为标准协同消息后发送至云边协同平台12。
(2)、接收第二待协同平台的标准协同消息,并将所接收的标准协同消息转换为第二协同消息后发送至对应的第二待协同平台。
需要说明的是,第二协同消息为第二待协同平台能够支持的协同消息。考虑到不同的第二待协同平台可以支持不同格式的协同消息,不同的第二待协同平台所支持的第二协同消息不同。
在一些实施例中,第二待协同平台的管理平台13具有多个插件,n个第二待协同平台31至3n可以通过上述多个插件与第二待协同平台的管理平台13进行信息交互。具体地,第二待协同平台的管理平台13的插件的功能与第一待协同平台的管理平台11的插件的功能类似,在此不再赘述。
此外,在一些实施例中,第二待协同平台的管理平台13的多个插件除了信息交互的连接功能外,第二待协同平台的管理平台13的上述功能(1)和功能(2)可以由第二待协同平台的管理平台13的插件实现。
最后,针对云边协同平台12。云边协同平台12可以转发在第一待协同平台的管理平台11和第二待协同平台的管理平台13之间传输的标准协同消息。
此外,在一些实施例中,云边协同平台12还具备定义标准协同消息的格式的作用。
具体地,标准协同消息可以具体包括:标准协同消息的传输方向信息、第一待协同平台的标识信息、第二待协同平台的标识信息、标准协同消息的类型和标准协同消息的数据内容。
作一个示例,以json格式为例,标准协同消息的模板可以如下。
其中,标准协同消息的模板定义了标准协同消息包括下述五个字段。五个字段的具体含义如下。
第一个字段、标准协同消息的传输方向信息字段,即direction字段。具体地,标准协同消息的传输方向信息可以是表征由云计算平台传输至边缘计算平台的第一方向标识。或者,标准协同消息的传输方向信息可以是表征由边缘计算平台传输至云计算平台的第二方向标识。第一方向标识和第二方向标识可以根据具体情况和实际需求进行自主选择,对此不作具体限定。示例性地,direction字段的赋值可以是0或1。如果赋值为0,则表示标准协同消息是从云计算平台下发到边缘计算平台的信息。如果赋值为1,则表示标准协同消息是从边缘计算平台上传给云计算平台的信息。
第二个字段、云计算平台的标识信息字段,即cloudID字段。cloudID字段的赋值可以是云计算平台的唯一标识。示例性的,cloudID字段的赋值可以是在注册云计算平台插件时自动生成的32位通用唯一识别码(Universally Unique Identifier,UUID)。例如,d0b67b83-adc8-4acc-b42a-634sdd97232e。
第三个字段、边缘计算平台的标识信息字段,即edgeID字段。edgeID字段的赋值可以是边缘计算平台的唯一标识。示例性的,edgeID字段的赋值可以是注册边缘计算平台插件时自动生成的32位UUID。例如,c0c67b8e-ada8-4acc-a42a-154add97542d。
第四个字段、标准协同消息的类型字段,即type字段。可以用type字段携带协同信息的类型信息。具体地,可以具体定义有下述六种类型的标准协同消息:资源协同消息、数据协同消息、智能协同消息、应用管理协同消息、业务管理协同消息和服务协同消息。在type字段,可以用resources表示资源协同消息,用data表示数据协同消息,intelligence表示智能协同消息,用app_management表示应用管理协同消息,用business_management表示业务管理协同消息,用service表示服务协同消息。此外,在后续过程中,如有需要,可以对上述协同类型信息进一步细分,也支持对上述协同类型信息进行扩展,对此不作限定。
第五个字段、标准协同消息的数据内容字段,即data字段。该字段可以携带云边协同交互中传输的具体信息。由于每类协同信息差异较大,本发明实施例不对该字段进行详细列举。可以根据具体的协同需要,在该字段写入数据。
在详细介绍了云边协同系统、标准协同消息的具体内容之后,本发明实施例下述部分对如何进行云边协同的具体实施方式展开具体描述。
图2是示出根据本发明实施例的云边协同方法的示意流程图。如图2所示,本实施例中的云边协同方法200可以包括以下步骤S210至S:
S210,第一待协同平台的管理平台11接收第一待协同平台2i发送的第一协同消息,并将第一协同消息转换为标准协同消息。其中,第一待协同平台可以是图1示出的m个第一协同平台21至2m中的任意一个或任意多个。第一待协同消息的具体内容可参见本发明上述实施例的相关说明,在此不再赘述。
在一个实施例中,第一待协同平台的管理平台11包括与第一待协同平台对应的插件,并由与第一待协同平台对应的插件执行S210。
在一个实施例中,第一待协同平台的管理平台11在将第一协同消息转换为标准协同消息的过程中,若转换出错,则可以返回表征转换失败的错误信息至第一待协同平台2i。可选的,为了简化处理流程,在确定转换出错之后,可以结束云边协同方法200的执行。
相应地,第一待协同平台的管理平台11在将第一协同消息转换为标准协同消息的过程中,若转换成功,则可以返回表征转换成功的响应成功信息至第一待协同平台2i。并继续向后执行S220。
S220,第一待协同平台的管理平台11将标准协同消息发送至云边协同平台12。具体地,可以借助用于与云边协同平台12进行信息交互的插件发送标准协同消息。
S230,云边协同平台12将标准协同消息发送至第二待协同平台的管理平台13。
在一些实施例中,为了保证标准协同消息的准确度,云边协同平台12可以判断标准协同消息格式是否符合格式要求。相应地,S230的具体实施方式可以包括下述两个步骤。
第一步骤、云边协同平台12校验第一待协同平台的管理平台11发送的标准协同消息是否符合预先定义的标准协同消息的格式。其中,标准协同消息的格式可以参见本发明上述实施例的相关说明,在此不再赘述。
第二步骤、若校验结果为标准协同消息符合预先定义的标准协同消息的格式,云边协同平台12将标准协同消息发送至第二待协同平台的管理平台13。
可选的,在确定校验结果之后,云边协同平台12可以向第一待协同平台的管理平台11返回校验结果。例如,如果校验失败,即标准协同消息不符合预先定义的标准协同消息的格式,则返回校验失败信息,且整个云边协同流程结束。如果校验成功,即标准协同消息符合预先定义的标准协同消息的格式,返回校验成功信息,并继续向后执行S240。
S240,第二待协同平台的管理平台13接收标准协同消息,并将接收到的标准协同消息转换为第二协同消息。具体地,第二待协同平台的管理平台13可以借助用于与云边协同平台12进行信息交互的插件接收标准协同消息。
S250,第二待协同平台的管理平台13将转换得到的第二协同消息发送至第二待协同平台3j。
在一个实施例中,第二待协同平台的管理平台13在将标准协同消息转换为第二协同消息的过程中,若转换出错,则可以返回表征转换失败的错误信息至第二待协同平台3j。可选的,为了简化处理流程,在确定转换出错之后,可以结束云边协同方法200的执行。
相应地,若第二待协同平台的管理平台13转换成功,则可以返回表征转换成功的响应成功信息至第二待协同平台3j。并继续向后执行S220。
根据本发明实施例中的云边协同方法,在第一待协同平台与第二待协同平台进行云边协同的过程中,可以通过第一待协同平台的管理平台将第一待协同平台支持的第一协同消息转换为标准协同消息,并通过云边协同平台将标准协同消息发送至第二待协同平台的管理平台。第二待协同平台的管理平台可以将标准协同消息转换为第二待协同平台支持的第二协同消息。通过本发明实施例提供的方案,可以将不同第一待协同平台支持的不同的第一协同消息转换为标准协同消息,以及将标准协同消息转换为不同第二待协同平台支持的不同的第二协同消息。从而,实现了第一待协同平台与第二待协同平台进行云边协同。并且,由于第一协同平台为云计算平台和边缘计算平台中的一者,第二协同平台是两者中的另一者,实现了云计算平和边缘计算平台之间的信息协同。
此外,由于可以将各式各样的第一协同消息转换为统一格式的标准协同消息,且能够将统一格式的标准协同消息转换为不同类型的第二待协同平台能够识别的第二协同消息,提高了协同的适用性。
在一些实施例中,由于标准协同消息中包括第一待协同平台的标识信息。具体地,第一待协同平台的标识信息可以包括与第一待协同平台对应的插件的标识信息。而插件的标识信息可以在插件启动过程中获取。
相应地,云边匹配方法200还包括第一待协同平台的标识信息的获取步骤,即下述第一步骤和第二步骤。
第一步骤、与第一待协同平台对应的插件在自身程序启动后向第一待协同平台的管理平台11的处理模块发送注册请求。
第二步骤、第一待协同平台的管理平台11的处理模块生成该插件对应的第一待协同平台的标识信息,并将第一待协同平台的标识信息发送至该插件。
在一个实施例中,为了提高安全性,第一待协同平台的管理平台11的处理模块在发送第一待协同平台的标识信息之前,会先标识校验该插件发送的注册请求是否具备合法性。若校验结果为具备合法性,则发送第一待协同平台的标识信息。否则,结束整个流程。
此外,标准协同消息中还包括第二待协同平台的标识信息。具体地,第二待协同平台的标识信息可以包括与第二待协同平台对应的插件的标识信息。而插件的标识信息可以在插件启动过程中获取。
相应地,云边匹配方法200还包括第一待协同平台的标识信息的获取步骤,即下述第三步骤和第四步骤。
第三步骤、与第二待协同平台对应的插件在自身程序启动后向第二待协同平台的管理平台13的处理模块发送注册请求。
第二步骤、第二待协同平台的管理平台13的处理模块生成该插件对应的第二待协同平台的标识信息,并将第二待协同平台的标识信息发送至该插件。
在一个实施例中,为了提高安全性,第二待协同平台的管理平台13的处理模块在发送第一待协同平台的标识信息之前,会先标识校验该插件发送的注册请求是否具备合法性。若校验结果为具备合法性,则发送第二待协同平台的标识信息。否则,结束整个流程。
下面结合附图,详细介绍根据本发明实施例的装置。
基于相同的发明构思,本发明实施例提供了一种第一待协同平台的管理平台。图3示出了本发明实施例提供的一种第一待协同平台的管理平台的结构示意图。如图3所示,第一待协同平台的管理平台11包括消息接收模块111、消息转换模块112和消息发送模块113。
消息接收模块111,用于接收第一待协同平台发送的第一协同消息。
消息转换模块112,用于将第一协同消息转换为标准协同消息。
消息发送模块113,用于将标准协同消息发送至云边协同平台,以使云边协同平台将标准协同消息转发至第二待协同平台的管理平台,从而使第二待协同平台的管理平台将标准协同消息转换为第二协同消息,并将第二协同消息发送至第二待协同平台。
在一些实施例中,第一待协同平台的管理平台包括与第一待协同平台对应的插件,第一待协同消息由插件接收并转换为标准协同消息。
在一些实施例中,第一待协同平台的管理平台11包括处理模块和与第一待协同平台对应的插件。
其中,插件用于在自身程序启动后向处理模块发送注册请求。
处理模块用于校验注册请求是否具备合法性。以及,处理模块还用于若校验结果为具备合法性,则生成与插件对应的第一待协同平台的标识信息,并将标识信息发送至插件。
根据本发明实施例的第一待协同平台的管理平台的其他细节,与以上结合图2所示实例描述的云边协同方法类似,并能达到其相应的技术效果,为简洁描述,在此不再赘述。
基于相同的发明构思,本发明实施例提供了一种云边协同平台。图4示出了本发明实施例提供的一种云边协同平台的结构示意图。如图4所示,云边协同平台12包括消息接收模块121和消息发送模块122。
消息接收模块121,用于接收第一待协同平台的管理平台发送的标准协同消息,标准协同消息是第一待协同平台的管理平台基于第一待协同平台发送的第一协同消息生成的。
消息发送模块122,用于将标准协同消息发送至第二待协同平台的管理平台,以使第二待协同平台的管理平台将标准协同消息转换为第二协同消息,并将第二协同消息发送至第二待协同平台。
在一些实施例中,标准协同消息包括:标准协同消息的传输方向信息、第一待协同平台的标识信息、第二待协同平台的标识信息、标准协同消息的类型和标准协同消息的数据内容。
在一些实施例中,消息发送模块122具体用于:校验第一待协同平台的管理平台发送的标准协同消息是否符合预先定义的标准协同消息的格式。若校验结果为符合,将标准协同消息发送至第二待协同平台的管理平台。
根据本发明实施例的云边协同平台的其他细节,与以上结合图2所示实例描述的云边协同方法类似,并能达到其相应的技术效果,为简洁描述,在此不再赘述。
基于相同的发明构思,本发明实施例提供了一种第二待协同平台的管理平台。图5示出了本发明实施例提供的一种第二待协同平台的管理平台的结构示意图。如图5所示,第二待协同平台的管理平台13包括消息接收模块131、消息转换模块132和消息发送模块133。
消息接收模块131,用于接收云边协同平台发送的标准协同消息,并将标准协同消息转换为第二协同消息,其中,标准协同消息由第一待协同平台的管理平台基于第一待协同平台发送的第一协同消息生成并发送至云边协同平台。
消息转换模块132,用于将标准协同消息转换为第二协同消息。
消息发送模块133,用于将标准协同消息转换为第二协同消息,并将第二协同消息发送至第二待协同平台。
在一些实施例中,第二待协同平台的管理平台包括与第二待协同平台对应的插件,标准协同消息由插件接收并转换为第二待协同消息。
在一些实施例中,第二待协同平台的管理平台包括处理模块和与第二待协同平台对应的插件。
其中,插件用于在自身插件程序启动后向处理模块发送注册请求。
处理模块用于校验注册请求是否具备合法性。以及,若校验结果为具备合法性,则处理模块还用于生成与插件对应的第二待协同平台的标识信息,并将标识信息发送至插件。
根据本发明实施例的第二待协同平台的管理平台的其他细节,与以上结合图2所示实例描述的云边协同方法类似,并能达到其相应的技术效果,为简洁描述,在此不再赘述。
图6是本发明实施例中云边协同设备的示例性硬件架构的结构图。
如图6所示,云边协同设备600包括输入设备601、输入插件602、中央处理器603、存储器604、输出插件605、以及输出设备606。其中,输入插件602、中央处理器603、存储器604、以及输出插件605通过总线610相互连接,输入设备601和输出设备606分别通过输入插件602和输出插件605与总线610连接,进而与云边协同设备600的其他组件连接。
具体地,输入设备601接收来自外部的输入信息,并通过输入插件602将输入信息传送到中央处理器603;中央处理器603基于存储器604中存储的计算机可执行指令对输入信息进行处理以生成输出信息,将输出信息临时或者永久地存储在存储器604中,然后通过输出插件605将输出信息传送到输出设备606;输出设备606将输出信息输出到云边协同设备600的外部供用户使用。
也就是说,图6所示的云边协同设备也可以被实现为包括:存储有计算机可执行指令的存储器;以及处理器,该处理器在执行计算机可执行指令时可以实现图2描述的云边协同设备的方法。
在一个实施例中,图6所示的云边协同设备600可以被实现为一种设备,该设备可以包括:存储器,用于存储程序;处理器,用于运行存储器中存储的程序,以执行本发明实施例的云边协同方法。
本发明实施例还提供了一种计算机存储介质,计算机存储介质上存储有计算机程序指令,计算机程序指令被处理器执行时实现本发明实施例的云边协同方法。
需要明确的是,本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见,这里省略了对已知方法的详细描述。在上述实施例中,描述和示出了若干具体的步骤作为示例。但是,本发明的方法过程并不限于所描述和示出的具体步骤,本领域的技术人员可以在领会本发明的精神后,作出各种改变、修改和添加,或者改变步骤之间的顺序。
以上的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时,其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时,本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中,或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路,等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
以上,仅为本发明的具体实施方式,所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、模块和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。