CN109889575B - 一种边缘环境下的协同计算平台系统及方法 - Google Patents

Abstract

本发明涉及一种边缘环境下的协同计算平台系统及方法，包括请求解析模块、中心节点和边缘节点控制模块、数据处理服务模块。系统和方法基于边缘环境下的计算模型，由负责计算任务分发的中心节点和多个负责计算任务执行的边缘节点协同完成计算。本发明实现了边缘环境下的流式数据和非流式数据处理，相比传统基于中心化模型的计算平台拥有更高的计算效率，且满足了数据提供方数据隐私保护的诉求。

Description

一种边缘环境下的协同计算平台系统及方法

技术领域

本发明涉及一种边缘环境下的协同计算平台系统及方法，属于大数据分析领域。

背景技术

随着物联网设备节点部署数量的急剧增加，云计算的集中式任务处理方式已经难以满足爆炸式增长的数据存储与计算需求。为了打破集中处理任务所带来的巨大瓶颈，研究者提出了一类新的计算模型“边缘模型(Edge Paradigm)”，由中心节点和边缘节点协同完成计算过程，通过将云计算中心的数据存储及计算任务分散到网络的边缘，从而充分利用网络中各设备的资源，减小中心节点的压力。在这类计算模型中，最具有代表性的是雾计算(Fog Computing)和边缘计算(Edge Computing)。雾计算是思科公司于2012年提出的概念，和云计算相比，雾计算在云和物联网设备之间添加了雾层(Fog Layer)，这一层分布着许多雾节点(Fog Node)，这些雾节点能够代替云中心进行分布式的计算和资源存储，同时根据物联网设备的地理位置就近为用户提供服务。边缘计算则是在雾计算之后产生的、在网络边缘执行计算的一种新计算模型。和雾计算相比，边缘计算计算任务的执行位置更加靠近网络边缘，前者的计算任务分布在雾节点上，而后者在云和边缘物联网设备间并没有一个中间层，计算任务均在物联网设备上完成。而随着物联网设备硬件性能的提升，其计算能力也会逐步增加，几乎不需要进行源数据传输即可进行计算处理的边缘计算模型将会拥有更好的发展前景。

以云计算为基础计算模型的数据分析平台中，数据通常由数据中心统一保管。数据源头(例如手机APP、道路监控摄像头、传感器等)产生的原始数据将会通过网络发送至云平台，云平台会将其统一保存至数据中心中进行长期存储。然而，如果数据拥有者的业务系统之间并未形成完整的数据交换与共享机制，将无法建立统一的数据中心；除此之外，数据拥有者出于商业考量和隐私保护的原因，通常拒绝将全量原始数据传送到数据分析平台上进行数据分析。即使数据拥有者间能够进行完全的数据交换与共享，面对数量庞大的数据源头所持续产生的海量数据，将数据实时传送至云中心、完全由云中心提供数据分析计算也是不现实的。在此过程中，数据拥有者的业务系统和数据分析平台之间的网络带宽将会被大量占用，在计算量巨大的情况下云平台也无法及时返回计算结果。在现实中，这种数据源分散分布在各地理位置的数据分析场景并不少见，这为数据分析工作带来了巨大的困难。

云计算等中心化的计算模型无法适用于上述场景下的计算，而边缘环境下计算模型的提出为其带来了新的转机。一方面，将计算和数据存储任务迁移到网络边缘各协同计算节点后，云中心的计算压力大大减小，同时也不需要占用大量带宽并花费大量时间将采集的数据发送至云中心进行统一处理，系统响应速度有很大的提升。另一方面，对于无法提供全量原始数据或尚未建立数据共享机制的数据拥有者业务系统，通过在边缘本地进行某个结果的计算、再统一将计算结果或中间结果发送到云中心进一步合并，可以避免原始数据流出业务系统，暴露在网络中。一些涉及到商业秘密、个人隐私而不便公开的敏感数据(如家庭监控摄像头记录的视频内容)在本地进行计算处理后，再将无敏感信息的计算结果发送至云中心，相较将隐私数据全部传送至云中心处理的方式，用户的隐私安全得到了保护。

作为一个新兴的研究领域，边缘环境下的计算现有研究成果主要集中于场景为移动网络的移动边缘计算(Mobile Edge Computing)上，对于其他场景还鲜有普适的系统架构方案。除此之外，现有边缘环境下的计算模型面临许多问题，例如，缺乏轻量级的任务分解与分发方法等等。针对这一问题，可以基于服务组合技术提出一种解决方案。任务分解与分发过程从自底向上的角度可以等价于将原子服务进行组合、直到满足用户的计算需求的过程。因此，执行计算任务相当于执行多个原子服务，将子结果合并后得到最终结果的过程。在服务组合技术领域，能够适用于边缘环境下的服务组合方法数量较少。Zhang Y等人提出了一种适用于边缘环境下的服务组合技术，但在该技术中复合服务的生成和执行过程分开进行，并行程度较低，其运行效率还有待改进。

发明内容

本发明技术解决问题：克服现有技术的不足，提供了一种边缘环境下的协同计算平台系统及方法，由中心节点和边缘节点协同完成边缘环境下的流式数据和非流式数据处理，相比传统基于中心化模型的计算平台拥有更高的计算效率，且满足了数据提供方数据隐私保护的诉求。

本发明技术解决方案：一种边缘环境下的协同计算平台系统，采用自底向上的服务组合技术来完成自顶向下的任务分解过程，解决计算任务分解与分发的难题。在平台的使用过程中，由请求计算的平台使用者提出数据处理需求，然后由具有相关专业领域知识的应用开发者对其进行分析并将计算子任务转化成应用程序的形式，事先部署到位于数据源内网的边缘节点上。在此基础上，计算任务分解与分发的过程就转化为了服务组合以及调用复合服务中每一个原子服务的过程，子任务执行过程转化为了原子服务运行过程，而最终的子结果合并过程也属于复合服务执行过程的一部分。通过上述过程，就能够实现任务调度以及结果融合。平台包括：请求解析模块、中心节点和边缘节点控制模块和数据处理服务模块，其中：

请求解析模块：负责处理计算请求、应用注册请求和服务部署/注册请求。对于计算请求，首先解析该计算请求并将所述计算请求转化对一个或多个服务调用请求，然后将每个服务调用请求发送到中心节点控制模块；根据用户提交的计算请求类型不同，该模块有不同的行为，若用户的计算请求中仅涉及一个流式或非流式计算服务，则需要等待用户发送结果获取请求，通过计算请求的唯一ID向中心节点控制模块查询结果；如果计算请求中含有多个非流式计算服务，则由请求解析模块进行子结果的合并后，直接将结果返回至用户；对于应用注册请求，将应用的详细描述信息和应用可执行程序分别存入数据库和文件系统中；除此之外，还负责接收用户的服务部署和服务注册请求并传递给中心节点控制模块，接收中心节点控制模块的处理结果，以向数据处理服务模块加入新的计算服务；上文所述流式计算服务即接收流式数据作为输入的数据处理计算服务，非流式计算服务即接收静态数据作为输入的数据处理计算服务；

中心节点控制模块：负责处理请求解析模块发送的服务调用、服务部署、服务注册和应用注册请求。对于服务调用请求，生成服务调用任务发布到任务池中，等待各边缘节点的控制模块获取，同时接收各边缘节点控制模块返回的计算结果并存入中心节点的结果数据库中等待请求解析模块的获取；对于服务部署和服务注册请求，将其转化为服务部署和服务注册任务后发布到任务池中等待各边缘节点的控制模块获取，并接收各边缘节点控制模块返回的处理结果，将其发送至请求解析模块；

边缘节点控制模块：通过轮询的方式从中心节点控制模块中的任务池中获取和本节点相关的服务调用任务、服务部署任务和服务注册任务。对于服务调用请求，需要向数据处理服务模块发送相关服务的执行请求，并接收数据处理服务模块生成的计算结果，转发至中心节点控制模块；对于服务部署任务，需要应用安装程序解压到指定的部署位置，并以制定的部署端口运行；对于服务注册任务，将其中的服务详细信息存入数据库中；

数据处理服务模块：位于边缘节点上，含有多种具有不同功能的数据处理服务，对本节点的流式和非流式数据进行处理，该模块的服务接收边缘节点控制模块的服务调用请求进行相应的数据处理工作，并将结果返回至边缘节点控制模块。

本发明的一种边缘环境下的协同计算方法，实现步骤为：

(1)计算请求解析。请求解析模块根据用户发来的计算请求，选择需要调用的服务，计算请求的形式有两种：一种是用户直接指定一个服务进行调用；对于可能涉及到多个服务的计算请求，用户需要描述抽象数据处理过程，由本模块自动进行服务组合和子结果合并。在确定了所有需要调用的服务后，按照服务之间的依赖关系依次调用服务；

(2)服务调用任务的生成与发布。中心节点控制模块接收到请求解析模块的服务调用请求后，将每个服务调用的服务ID、边缘节点ID、输入参数等信息包装成服务调用任务并发布到任务池中等待获取，每个任务都有唯一的请求ID，用于定位服务调用的来源以及结果的返回去向；

(3)服务调用任务的获取与执行。边缘节点控制模块每隔时间t(默认t＝1s)向中心节点控制模块查询一次任务，获取和本边缘节点ID一致的任务，并调用本节点数据处理服务模块的相应服务；

(4)服务的运行，数据处理服务模块的相应服务接收到边缘节点控制模块的服务调用请求后，开始数据处理过程；提供了流式和非流式两种数据处理服务，对于非流式服务，完成数据处理后将结果返回至边缘节点控制模块；而对于流式服务，在启动数据处理服务中的数据处理程序时会同时启动一个结果收集模块，该程序(基于storm编写)从Kafka分布式发布订阅消息系统中获取原始数据，将计算结果再返回至Kafka中或将中间计算结果存储在Redis中，结果收集模块会配合数据处理程序的逻辑定期从Kafka的相应队列或从Redis数据库中获取当前处理结果，返回至边缘节点控制模块；两种数据处理服务返回的结果格式均为json格式的三元组<服务请求ID,结果产生时间,结果内容>，其中服务请求ID表明了结果的去向，即对应哪一次服务调用；结果产生时间主要用于将流式计算服务的计算结果按时间顺序整理成一个序列；结果内容是已转化为json字符串形式的计算结果；

(5)服务运行结果的转发。边缘节点控制模块接收到服务计算结果后不经过任何修改将其转发到中心节点控制模块；

(6)服务运行结果的保存。中心节点控制模块将接收到的计算结果存储到MongoDB中的结果数据库中；

(7)子结果的合并与计算结果的获取。根据用户发送的计算请求形式的不同，计算结果的获取方式也有所不同，对于直接调用单个服务的计算请求，无论是非流式计算服务还是流式计算服务都需要用户通过中心节点控制模块主动获取结果；对于涉及到多个服务的计算请求，由请求解析模块自动获取服务执行结果并进行子结果合并，然后直接返回给用户。

本发明与现有技术相比的优点在于：

(1)能够支持流式和非流式两种数据在边缘环境下的计算过程。本发明除了能够支持常规的静态非流式数据的处理，还提供了动态流式数据的处理功能，在平台内部为流式和非流式数据处理设计并部署了两种技术解决方案，非流式数据通过MapReduce或普通的数据分析程序、流式数据通过Storm或Spark等技术完成分析过程；

(2)平台具有较强的可扩展性。在硬件可扩展性方面，能够在不重新启动平台的情况下，将新的边缘节点加入平台中，以提供新的计算设施和原始数据；在软件可扩展性方面，应用开发者能够不断的将新的计算应用加入到平台中，同时边缘节点管理员能够通过服务自动部署功能将其部署并应用于本节点的数据集上，为系统使用者提供更加完善的数据处理功能；

(3)保证了数据的安全。本发明在设计与实现的过程中重点考虑了如何保障数据安全。一方面，系统使用者访问边缘节点的数据都是通过数据分析程序完成的，数据分析程序都是来源于可以信赖的应用提供者，且每一个数据分析应用都经过平台管理员的审核才能够部署到边缘节点，而边缘节点管理员也会对应用进行进一步的考量才会部署到本节点上，因此不会出现数据被窃取的情况；另一方面，边缘节点和中心节点间采用单向的通信机制，中心节点无法得知边缘节点的具体访问地址，因此攻击者无法通过伪造计算请求的方式绕开中心节点直接对边缘节点进行攻击；

(4)服务组合技术的执行效率更高。相比现有研究中适用于边缘环境下的服务组合技术，本发明的服务组合技术将复合服务的生成(即服务组合过程)和复合服务执行过程进行了融合，以工作流中每一个活动作为单元，每完成对一个活动从抽象过程到可执行复合服务的转化后即开始复合服务的执行，并在等待结果产生的过程中立即进行下一个活动的转化，这一过程具有更高的并行程度，服务组合技术的执行效率更高。

附图说明

图1为直接调用单个服务的平台执行流程；

图2为通过描述抽象数据处理逻辑请求计算的平台执行流程；

图3为平台模块交互过程；

图4为中心节点结构；

图5为边缘节点结构；

图6为使用Kafka存储计算结果的流式计算服务结构；

图7为使用Redis存储中间计算结果的流式计算服务结构；

图8为非流式计算服务结构。

具体实施方式

下面结合说明书附图，对本发明的具体实施方式做详细描述。

用户使用不同方式提交计算请求时，本发明的边缘环境下的协同计算方法实现步骤分别如图1和图2所示。当直接指定单个服务调用时(调用的服务可为流式或非流式计算服务)，实现步骤如下：

(1)计算请求解析。用户通过计算请求页面直接指定一个计算服务并指定参数(步骤①)，请求解析模块据此生成原子服务调用任务发送到中心节点控制模块的服务执行任务调度子模块(步骤②)；

(2)服务调用任务的生成与发布。服务执行任务调度子模块接收到请求解析模块的服务调用后，将每个服务调用的服务ID、边缘节点ID、输入参数等信息包装成服务调用任务并发布到任务池中等待获取(步骤③)，每个任务都有唯一的请求ID，用于定位服务调用的来源以及结果的返回去向，生成任务后同时向计算请求页面返回结果查询地址(步骤④)；

(3)服务调用任务的获取与执行。边缘节点控制模块的服务执行任务响应子模块每隔时间t(默认t＝1s)向服务执行任务调度查询一次任务(步骤⑤、步骤⑥、步骤⑦)，获取和本边缘节点ID一致的任务(步骤⑧)，并调用本节点数据处理服务模块的相应服务(步骤⑨)；

(4)服务的运行。数据处理服务模块的相应服务接收到边缘节点控制模块的服务调用请求后，开始数据处理过程。该模块提供了流式和非流式两种数据处理服务，对于非流式服务，完成数据处理后将结果返回至边缘节点控制模块；而对于流式服务，在启动数据处理程序时会同时启动一个结果收集模块，数据处理程序(基于storm编写)从Kafka中获取原始数据，将计算结果再返回至Kafka中或将中间计算结果存储在Redis中，结果收集模块会配合数据处理程序的逻辑定期从Kafka的相应队列或从Redis中获取当前处理结果，返回至边缘节点控制模块(步骤⑩)。两种数据处理服务返回的结果格式均为json格式的三元组<服务请求ID,结果产生时间,结果内容>，其中服务请求ID表明了结果的去向，即对应哪一次服务调用；结果产生时间主要用于将流式计算服务的计算结果按时间顺序整理成一个序列；结果内容是已转化为json字符串形式的计算结果；

(5)服务运行结果的转发。边缘节点控制模块接收到服务计算结果后不经过任何修改将其转发到中心节点控制模块(步骤

)；

(6)服务运行结果的保存。中心节点控制模块将接收到的计算结果存储到MongoDB中的结果数据库中(步骤

)；

(7)计算结果的获取。无论是非流式计算服务还是流式计算服务都需要用户通过中心节点控制模块主动获取结果，用户可以访问结果查询地址查询当前生成的结果(步骤

步骤

步骤

步骤

)。

当用户提交抽象过程模型提交计算请求时(涉及的服务只能是非流式计算服务)，实现步骤如下：

(1)计算请求解析。用户通过计算请求页面编写描述了复杂数据处理逻辑的抽象过程模型并提交(步骤①)，请求解析模块首先进行服务组合，将抽象过程模型转化成由多个位于不同边缘节点上的可执行原子服务组成的复合服务，然后再针对每一个原子服务生成原子服务调用任务发送到中心节点控制模块的服务执行任务调度子模块(步骤②)；

(2)服务调用任务的生成与发布。服务执行任务调度子模块接收到请求解析模块的服务调用后，将每个服务调用的服务ID、边缘节点ID、输入参数等信息包装成服务调用任务并发布到任务池中等待获取(步骤③)，每个任务都有唯一的请求ID，用于定位服务调用的来源以及结果的返回去向，生成任务后同时向计算请求页面返回结果查询地址(步骤④)；

(3)服务调用任务的获取与执行。边缘节点控制模块的服务执行任务响应子模块每隔时间t(默认t＝1s)向服务执行任务调度查询一次任务(步骤⑤、步骤⑥、步骤⑦)，获取和本边缘节点ID一致的任务(步骤⑧)，并调用本节点数据处理服务模块的相应服务(步骤⑨)；

(4)服务的运行。数据处理服务模块的相应服务接收到边缘节点控制模块的服务调用请求后，开始数据处理过程。该模块提供了流式和非流式两种数据处理服务，对于非流式服务，完成数据处理后将结果返回至边缘节点控制模块；而对于流式服务，在启动数据处理程序时会同时启动一个结果收集模块，数据处理程序(基于storm编写)从Kafka中获取原始数据，将计算结果再返回至Kafka中或将中间计算结果存储在Redis中，结果收集模块会配合数据处理程序的逻辑定期从Kafka的相应队列或从Redis中获取当前处理结果，返回至边缘节点控制模块(步骤⑩)。两种数据处理服务返回的结果格式均为json格式的三元组<服务请求ID,结果产生时间,结果内容>，其中服务请求ID表明了结果的去向，即对应哪一次服务调用；结果产生时间主要用于将流式计算服务的计算结果按时间顺序整理成一个序列；结果内容是已转化为json字符串形式的计算结果；

(5)服务运行结果的转发。边缘节点控制模块接收到服务计算结果后不经过任何修改将其转发到中心节点控制模块(步骤

)；

(6)服务运行结果的保存。中心节点控制模块将接收到的计算结果存储到MongoDB中的结果数据库中(步骤

)；

(7)计算结果的合成。服务组合模块获取每一个原子服务的运行结果(步骤

步骤

步骤

步骤

)，并按照抽象过程模型中描述的服务间关系进行结果的合并，最终将结果返回至用户提交计算请求的页面(步骤

)。

如图3所示，本发明包括请求解析模块、中心节点控制模块、边缘节点控制模块和数据处理服务模块。下面详细介绍各个模块的实现：

(1)请求解析模块

中心节点的结构如图4所示，其中请求解析层即为请求解析模块。该模块能够解析用户发来的应用注册、服务部署、服务注册和计算等多种请求，并调用中心节点控制模块使中心节点能够对请求做出相应的反应。对于应用注册请求，模块需要解析请求中的应用名称、应用参数、应用描述等信息存入数据库中，并将程序和源代码存储到文件系统中；对于服务注册请求，模块解析其中的服务名称、服务类型、服务参数、数据源等信息存入数据库中，并将访问地址、边缘节点ID等具体服务访问信息传输给中心节点，由其包装成服务注册任务发布到任务池中；对于服务部署请求，模块解析其中的部署位置、部署端口、数据源等信息传输给中心节点，由其包装成服务部署任务发布到任务池中。对于计算请求，如果是以直接指定单个服务的方式提交的计算请求，则直接向中心节点控制模块发送该服务的调用请求；如果是以抽象数据处理过程的提交的计算请求，其具体执行过程如下：

步骤1：解析抽象数据处理过程，从最后的结果输出节点开始向前进行回溯，梳理抽象数据处理过程中每一个活动运行结果之间的依赖关系；

步骤2：执行复合服务，将输入节点作为当前节点层次；

步骤3：从当前节点层次开始逐渐推进，寻找目前能够执行、不依赖其他计算结果的活动，并为其寻找可以执行的原子服务，向中心节点控制模块发送服务调用请求；如果当前节点层次已达到输出节点，则表示复合服务执行完毕，将输出节点的输入值作为最终结果返回给用户；

步骤4：通过轮询的方式向中心节点的结果查询模块请求相应的服务执行结果，并根据抽象数据处理过程中的逻辑进行子结果合并，将目前所执行的节点层次作为当前节点层次，将目前的计算结果输入到相应的节点，并返回步骤3。

(2)中心节点控制模块

中心节点的结构如图4所示，其中节点控制层即为中心节点控制模块。该模块提供了服务结果获取、服务执行任务调度、服务部署任务调度和服务注册任务调度等多个功能。其中，服务执行任务调度、服务部署任务调度和服务注册任务调度模块的功能均为从请求解析模块接收信息并将其包装成任务发布到任务池中，以服务执行任务调度模块为例，其生成服务执行任务的具体执行过程如下：

步骤1：接收到请求解析模块发送的服务调用请求后，查询该服务所在的边缘节点ID；

步骤2：将计算服务请求记录ID、边缘节点ID、服务ID和参数等信息包装成一个任务，并将任务状态置为0(未获取)；

步骤3：将上述任务发布到任务池中，等待边缘节点获取；

步骤4：当边缘节点获取该任务时，将任务状态置为1(已获取，未完成)；

步骤5：若边缘节点发来任务执行成功的信息，则删除该任务；若边缘节点发来任务失败信息，则将任务状态置为0，等待下一轮获取和执行过程，返回步骤4。

服务结果获取模块能够将边缘节点控制模块转发的服务计算结果存储到中心节点的结果数据库中，考虑到流式计算服务产生的结果数据量较大，当用户量大、正在运行的服务较多时，MySQL可能会出现性能瓶颈，因此中心节点使用MongoDB存储服务执行结果。

对于用户不同的计算请求提交方法，需要使用不同的方式获取计算结果。如果用户指定了单个服务进行调用，则需要将提交请求后平台返回的计算请求ID发送到服务结果获取模块，由该模块查找相应计算结果后返回。如果调用的是非流式服务，则用户可以取出一条结果；如果调用的是流式服务，只要用户不手动停止服务或服务的租用期限未到，则可以一直通过该模块获取到计算结果。如果用户通过描述抽象数据处理逻辑提交计算请求，则无需从服务结果获取模块主动查询结果，请求处理模块将会自动进行子结果合并，并将处理后的最终结果直接呈现给用户。

(3)边缘节点控制模块

边缘节点由业务系统和边缘服务器两部分组成，其结构如图5所示。边缘服务器为执行中心分配的计算任务提供软硬件计算资源，其上部署了许多和本节点所拥有的数据相关的流式和非流式计算服务。边缘服务器可能仅是一台服务器，也可能是一个服务器集群。在边缘服务器(或服务器集群的主节点)上运行着一系列边缘节点管理程序，即边缘节点控制模块。该程序主要包含以下3个子模块：

·服务执行任务响应模块：通过轮询的方式从中心节点不断获取和本节点相关的服务调用需求，调用服务并将结果发送到中心节点；

·服务部署任务响应模块：通过轮询的方式从中心节点不断获取和本节点相关的服务部署需求，从中心获取应用程序后将用户指定的数据源等参数写入配置文件中并启动Web程序；

·服务注册任务响应模块：通过轮询的方式从中心节点不断获取和本节点相关的服务注册需求，并将用户指定的服务信息存储在数据库中。

其中，服务部署任务响应模块的具体运行过程如下：

步骤1：向中心节点控制模块查询是否有和本节点相关的服务部署任务，如果有则取回任务；否则等待下一次轮询，重复步骤1；

步骤2：从取回的任务中选择一个执行，如果已没有需要执行的任务，则返回步骤1；否则，解析任务中的应用ID、部署位置、部署端口、数据源ID等信息；

步骤3：向中心节点控制模块请求下载相应的应用程序，并在用户指定的部署位置解压安装；

步骤4：根据数据源ID查询数据源信息，将其(MySQL访问方式、Kafka访问方式等)写入服务的配置文件中；

步骤5：启动数据处理服务；

步骤6：告知中心节点控制模块该任务已执行成功，返回步骤2；

服务执行任务响应模块的具体运行过程如下：

步骤1：向中心节点控制模块查询是否有和本节点相关的服务执行任务，如果有则取回任务；否则等待下一次轮询，重复步骤1；

步骤2：从取回的任务中选择一个执行，如果已没有需要执行的任务，则返回步骤1；否则，解析任务中任务类型字段，如果是服务调用任务，则进一步解析服务ID、执行时间(仅流式计算服务有)、参数、计算请求ID等信息，如果是服务停止任务，则解析服务ID和计算请求ID；

步骤3：根据服务ID从本地数据库中查询服务的具体访问方式，如果是服务调用任务，则向该服务发送计算执行请求并传入参数、计算请求等相关信息；如果是服务停止任务，则向该服务发送停止计算请求并传入计算请求ID；

步骤4：如果步骤3中服务并未返回执行成功的信息，则告知中心节点控制模块任务失败，返回步骤2；

(4)数据处理服务模块

数据处理服务模块由一个或多个流式及非流式计算服务组成，除此之外，它还负责保存目前服务的调用情况。为了配合平台的运行方式，模块中的流式计算服务和非流式计算服务都需要按照一定的结构进行封装。流式计算服务的结构如图6和图7所示，两种方案采用了不同的方式存放计算结果。流式计算服务程序主要分为四个部分：Web服务程序、流式数据处理程序、结果收集线程和计时器。其中，Web服务程序在服务部署过程中启动，它为边缘节点控制模块启动和停止计算过程提供了接口，并负责其他三个部分的启动与停止过程；流式数据处理程序负责从Kafka中获取数据执行流式数据处理过程，并将不断得出的计算结果放入Kafka或将中间结果放入Redis中；结果收集程序从Kafka或Redis中读取结果，并将其发送至边缘节点控制模块的服务执行任务响应子模块；计时器根据用户规定的运行时长，自流式处理程序运行开始计算，到达规定时间时自动停止结果收集线程和流式数据处理程序。

通常，带参数的计算服务随着参数的变化可能会产生不同的计算结果，而不带参数的服务在同一时间、同等条件下调用会产生相同的结果。对于带参数的计算服务，需要根据不同用户在调用时传入的参数执行多次计算过程；而对于不带参数的服务，当不同用户在同一时间调用时，可以仅执行一次计算过程，并将结果发送给所有用户。因此可以将流式计算服务可以分为两种：带参数的流式计算服务和不带参数的流式计算服务。下面将以Kafka作为结果存储技术、使用Storm技术实现的流式计算服务为例分析这一过程。

带参数的流式计算服务运行过程如下：

步骤1：从服务所在目录下的配置文件中读取Storm程序的绝对路径(这一程序也位于服务所在目录下)；

步骤2：运行一段程序，使用bash启动Storm程序，这一过程主要分为五步：

1.从配置文件中读取数据源信息，即Kafka访问地址、topic名称，作为参数传入Storm程序；

2.查看当前topic下是否有数据，如果没有数据则说明数据接口未开启，需要从配置文件中读取数据接口的访问地址并开启数据接口；

3.生成一个唯一的topic(保证不和Kafka中的任何现有topic重复)，作为Storm结果输出到Kafka时的topic，作为参数传入Storm程序；

4.生成一个唯一的topology名称，将这一名称作为参数传入Storm程序，Storm程序将以此topology名称提交至Hadoop平台运行；

5.将用户提供的参数传入Storm程序；

6.将Storm程序提交运行；

步骤3：启动结果收集程序，使用第二步中生成的唯一topic名称通过轮询的方式从Kafka中读取流式数据处理程序的计算结果，读取的结果将会发送到服务执行任务响应模块；

步骤4：启动计时器；

步骤5：执行一段时间后，计时器发现该用户对该服务的租用期已满，因此停止Storm和结果收集程序的执行；

步骤6：Web服务退出运行。

对于不带参数的流式计算服务，不同用户可以共用同一个流式数据处理程序，由不同的结果收集程序为不同的用户收集计算结果(实质上结果是相同的，但需要返回给不同用户所以需要多个拷贝)。通过复用流式数据处理程序，可以减少边缘服务器上执行的流式数据处理程序数量，防止对计算资源的浪费，提高边缘服务器的计算执行效率。边缘服务器上是否已有相应的流式数据处理程序运行将会影响流式计算服务的行为，因此下面将分别介绍两种情况下的服务运行过程。当边缘服务器上没有相应流式数据处理程序运行时，服务运行过程如下：

步骤1：从服务所在目录下的配置文件中读取Storm程序的绝对路径(这一程序也位于服务所在目录下)和topology名称，检测是否有同名的topology运行(由于前提条件是没有相应流式数据处理程序运行，因此是没有同名topology的)；

步骤2：运行一段程序，使用bash启动Storm程序，这一过程主要分为五步：

1.从配置文件中读取数据源信息，即Kafka访问地址、topic名称，作为参数传入Storm程序；

2.查看当前topic下是否有数据，如果没有数据则说明数据接口未开启，需要从配置文件中读取数据接口的访问地址并开启数据接口；

3.生成一个唯一的topic(保证不和Kafka中的任何现有topic重复)，作为Storm结果输出到Kafka时的topic，并作为参数传入Storm程序，同时写入配置文件中；

4.将用户提供的参数传入Storm程序；

5.将Storm程序提交运行；

6.向数据库中添加本服务的使用情况，并设置正在使用该服务的人数(count字段)为1；

步骤3：启动结果收集程序，使用第二步中生成的唯一topic名称通过轮询的方式从Kafka中读取流式数据处理程序的计算结果，读取的结果将会发送到服务执行任务响应模块；

步骤4：启动计时器；

步骤5：执行一段时间后，计时器发现该用户对该服务的租用期已满，因此停止结果收集程序的执行，并在数据库中为本服务的使用人数减1，如果此时使用人数大于0，则无需停止Storm程序，否则应停止它；

步骤6：Web服务退出运行。

当边缘服务器上已有相应流式数据处理程序运行时，服务运行过程如下：

步骤1：从服务所在目录下的配置文件中读取Storm程序的绝对路径(这一程序也位于服务所在目录下)和topology名称，检测是否有同名的topology运行(由于前提条件是已经有相应流式数据处理程序运行，因此时有同名topology的)；

步骤2：查询数据库中该服务的使用情况，并将正在使用该服务的人数(count字段)加1；

步骤3：启动结果收集程序，从配置文件中读取Storm程序生成的结果在Kafka中的相应的topic名称，通过轮询的方式从Kafka中读取流式数据处理程序的计算结果，读取的结果将会发送到服务执行任务响应模块；

步骤4：启动计时器；

步骤5：执行一段时间后，计时器发现该用户对该服务的租用期已满，因此停止结果收集程序的执行，并在数据库中为本服务的使用人数减1，如果此时使用人数大于0，则无需停止Storm程序，否则应停止它；

步骤6：Web服务退出运行。

对于非流式计算服务，其结构和运行过程较为简单。图8为非流式计算服务的结构，包含Web服务程序和非流式数据处理程序两部分。当接收到计算程序运行的指令后，Web服务程序启动非流式数据处理程序，计算完成后再由后者将计算结果返回至边缘节点控制模块。

以上所述，仅为本发明中的具体实施方式，但本发明的保护范围并不局限于此。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。

Claims (2)

1.一种边缘环境下的协同计算平台系统，其特征在于：包括请求解析模块、中心节点和边缘节点控制模块和数据处理服务模块，其中：

请求解析模块：负责处理计算请求、应用注册请求和服务部署/注册请求；对于计算请求，首先解析该计算请求并将所述计算请求转化对一个或多个服务调用请求，然后将每个服务调用请求发送到中心节点控制模块；根据用户提交的计算请求类型不同，该模块有不同的行为，若用户的计算请求中仅涉及一个流式或非流式计算服务，则需要等待用户发送结果获取请求，通过计算请求的唯一ID向中心节点控制模块查询结果；如果计算请求中含有多个非流式计算服务，则由请求解析模块进行子结果的合并后，直接将结果返回至用户；对于应用注册请求，将应用的详细描述信息和应用可执行程序分别存入数据库和文件系统中；除此之外，还负责接收用户的服务部署和服务注册请求并传递给中心节点控制模块，接收中心节点控制模块的处理结果，以向数据处理服务模块加入新的计算服务；上文所述流式计算服务即接收流式数据作为输入的数据处理计算服务，非流式计算服务即接收静态数据作为输入的数据处理计算服务；

中心节点控制模块：负责处理请求解析模块发送的服务调用、服务部署、服务注册和应用注册请求；对于服务调用请求，生成服务调用任务发布到任务池中，等待各边缘节点的控制模块获取，同时接收各边缘节点控制模块返回的计算结果并存入中心节点的结果数据库中等待请求解析模块的获取；对于服务部署和服务注册请求，将其转化为服务部署和服务注册任务后发布到任务池中等待各边缘节点的控制模块获取，并接收各边缘节点控制模块返回的处理结果，将其发送至请求解析模块；

边缘节点控制模块：通过轮询的方式从中心节点控制模块中的任务池中获取和本节点相关的服务调用任务、服务部署任务和服务注册任务；对于服务调用请求，需要向数据处理服务模块发送相关服务的执行请求，并接收数据处理服务模块生成的计算结果，转发至中心节点控制模块；对于服务部署任务，需要应用安装程序解压到指定的部署位置，并以制定的部署端口运行；对于服务注册任务，将其中的服务详细信息存入数据库中；

数据处理服务模块：位于边缘节点上，含有多种具有不同功能的数据处理服务，对本节点的流式和非流式数据进行处理，该模块的服务接收边缘节点控制模块的服务调用请求进行相应的数据处理工作，并将结果返回至边缘节点控制模块。

2.一种边缘环境下的协同计算方法，其特征在于：实现步骤如下：

(1)计算请求解析，请求解析模块根据用户发来的计算请求，选择需要调用的服务，计算请求的形式有两种：一种是用户直接指定一个服务进行调用；对于可能涉及到多个服务的计算请求，用户需要描述抽象数据处理过程，自动进行服务组合和子结果合并，在确定了所有需要调用的服务后，按照服务之间的依赖关系依次调用服务；

(2)服务调用任务的生成与发布，中心节点控制模块接收到请求解析模块的服务调用请求后，将每个服务调用的服务ID、边缘节点ID、输入参数信息包装成服务调用任务并发布到任务池中等待获取，每个任务都有唯一的请求ID，用于定位服务调用的来源以及结果的返回去向；

(3)服务调用任务的获取与执行，边缘节点控制模块每隔时间t向中心节点控制模块查询一次任务，获取和本边缘节点ID一致的任务，并调用本节点数据处理服务模块的相应服务；

(4)服务的运行，数据处理服务模块的相应服务接收到边缘节点控制模块的服务调用请求后，开始数据处理过程；提供了流式和非流式两种数据处理服务，对于非流式服务，完成数据处理后将结果返回至边缘节点控制模块；而对于流式服务，在启动数据处理服务中的数据处理程序时会同时启动一个结果收集模块，该数据处理程序从Kafka分布式发布订阅消息系统中获取原始数据，将计算结果再返回至Kafka中或将中间计算结果存储在Redis中，结果收集模块会配合数据处理程序的逻辑定期从Kafka的相应队列或从Redis数据库中获取当前处理结果，返回至边缘节点控制模块；两种数据处理服务返回的结果格式均为json格式的三元组<服务请求ID,结果产生时间,结果内容>，其中服务请求ID表明了结果的去向，即对应哪一次服务调用；结果产生时间主要用于将流式计算服务的计算结果按时间顺序整理成一个序列；结果内容是已转化为json字符串形式的计算结果；

(5)服务运行结果的转发，边缘节点控制模块接收到服务计算结果后不经过任何修改将其转发到中心节点控制模块；

(6)服务运行结果的保存，中心节点控制模块将接收到的计算结果存储到MongoDB中的结果数据库中；

(7)子结果的合并与计算结果的获取，根据用户发送的计算请求形式的不同，计算结果的获取方式也有所不同，对于直接调用单个服务的计算请求，无论是非流式计算服务还是流式计算服务都需要用户通过中心节点控制模块主动获取结果；对于涉及到多个服务的计算请求，由请求解析模块自动获取服务执行结果并进行子结果合并，然后直接返回给用户。

Images