一种基于云边协同的电力边缘异构部署方法与流程

1.本发明涉及电力物联网技术领域，尤其涉及一种基于云边协同的电力边缘异构部署方法。


背景技术：

2.物联网相对于互联网，强调物的连接，物的连接离不开运行于物之上的应用，当大量的物连接到网络上后，应对爆炸式的业务需求及需求变化，要求物上运行多应用，并能快速方便的部署和升级，对物及运行于物上的应用的管理包括部署、更新升级成为难点；传统单个单个设备人工现场升级成本高，且对于沙漠戈壁甚至国外的设备进行现场软件升级费时费力，为解决这些问题，统一基于云边协同的异构部署方案孕育而生；电力行业对于不同的边缘应用有不同的部署要求，有些要求运行于宿主机，而有些应用要求更好的独立性和隔离性，要求运行于容器中，而有些应用关联性较大，要求运行于同一容器中，故需要一套支持各种部署方式的异构部署方案。随着电网公司对电力物联网建设的推进，电力物联网基于云-边-端整体架构的电力系统的发展为边缘计算的兴起提供了机会，同时将电网服务上升到更高的一个层次，就近并快速的解决原来无法解决的问题。电力物联网所要求实现状态全面感知、信息快速高效处理、应用便捷灵活部署更新等需求的增强，必将造成连接到电力物联网的终端设备以及数据量呈指数级的增长，这就要求有新的架构来适应大量数据获取及处理，要求方案中能支持集群并行处理这些大量的管理监控数据。电力物联网数据上可分为两类，业务数据和管理数据；业务需求多变，而管理数据是单一固定的，故可对边缘终端的管理统一平台化；现有业务数据和管理数据未分离，还在使用规约对边缘终端进行升级，业务数据和管理混杂在一起，难以管理维护，架构也不清晰；实现这些通用的功能，要求业务数据通道和边缘终端设备的管理通道分离，相互独立，相互不影响。让处理业务需求时，可以关注业务本身，而无需关注业务app的部署、升级、监控等通用需求，加快业务需求的实现。现有各大云厂商的物联网平台，其边缘组件部署步骤如下：购买边缘节点-》开通iot边缘服务-》开通设备接入服务-》部署iot边缘应用-》设备接入边缘节点，它支持边缘应用的两种部署方式：一种是容器化部署，一种是安装包部署，但安装包部署未做到隔离，且业务数据和管理数据混杂在一起，且云厂商的服务都是标准服务，无法满足电网的定制化需求，而且上公有云的成本高且有安全风险。
3.电力行业的审计要求高，且当发现问题后，须快速定位和解决问题，而现有技术方案未做到代码和边缘应用的构建打包和运行的关联，无法实现快速定位和解决问题。电网系统涉及到民生用电的安全、稳定及可靠要求，安全级别要求高，现有技术方案都是基于公有云的方案，数据上云有安全风险，一旦出现安全问题后果不堪设想。电网独有的部署需求，要求边缘应用能部署于宿主机及容器，同时还要求边缘应用能附加至已有容器中运行，即一个容器中运行多个边缘应用，同一类或相关的应用运行于同一容器中，现有技术方案
只能做到容器级别的管理，无法做到容器内边缘应用的管理。


技术实现要素：

4.本发明要解决的技术问题是，提供一种能够实现边缘应用的全链路管理、扩展及更新，边缘设备的快速恢复、远程运维的电力边缘异构部署方法。
5.为解决上述技术问题，本发明提供一种云边协同的电力边缘异构部署方法，包括以下步骤：步骤s1，管理应用包，上传写好的应用包至系统；步骤s2，将应用包构建成镜像放入容器镜像仓库；步骤s3，将应用包直接注册成边缘组件或将构建好的容器镜像注册为边缘应用，供边缘设备使用；步骤s4，设备注册，创建数字化的边缘设备，并配置需要运行于其中的边缘组件，在服务器端存储边缘设备中运行的应用清单及配置；步骤s5，将配置好的边缘应用清单下发至边缘代理模块，边缘代理模块依据配置进行部署及更新：当组件为原生应用组件时，进行宿主机部署及更新或附加至容器部署及更新；当组件为镜像组件时，则进行容器化部署及更新；步骤s6，管理平台对边缘设备及运行于其中的应用进行监控。更进一步，步骤s2中所述将应用包构建成镜像的步骤包括：步骤s21，获取应用程序包文件；步骤s22，创建dockerfile文件；步骤s23，生成docker build命令，并在docker环境下执行；步骤s24，将生成的镜像推送到执行的harbor镜像仓库；步骤s25，若构建过程过慢则采用异步处理，收到构建命令后立即返回“处理中”，然后再轮询构建进度，错误时返回对应的错误信息。更进一步，步骤s5中所述附加至容器部署及更新包含以下步骤：步骤s501，管理平台前端向管理平台后端发送附加至容器部署请求，部署请求中包含文件的下载地址以及下载文件的临时授权码，不包含实际文件流；步骤s502，管理平台后端进行参数组装并将附加至容器部署请求经文件服务器转发至边缘代理模块；步骤s503，边缘代理模块向管理平台前端返回处理状态，并向文件服务器发出应用及配置文件下载请求；步骤s504，文件服务器向边缘代理模块返回应用及配置文件流；步骤s505，边缘代理模块将应用及配置文件存至指定目录，进行文件签名验证，并向管理平台后端上报处理状态；步骤s506，边缘代理模块准备应用执行环境；步骤s507，边缘代理模块启动/重启应用流程并记录进度；步骤s508，边缘代理模块轮询请求部署进度信息并上报部署进度至文件服务器，文件服务器转发部署进度至管理平台后端；步骤s509，管理平台后端记录进度；
步骤s510，管理平台前端向管理平台后端轮询请求部署进度，管理平台后端向管理平台前端返回部署进度信息。更进一步，步骤s506中所述边缘代理模块准备应用执行环境包含以下步骤：步骤s5061，若不是热加载，则合并应用容器运行参数，备份容器内原应用及数据，并重建容器，否则直接执行下一步；步骤s5062，生成应用的容器配置文件；步骤s5063，复制包括容器内原应用及数据文件的所有应用及其容器配置文件至容器内；步骤s5064，若为应用组件容器内更新则通知容器内管理程序停止并删除旧应用，否则执行下一步；步骤s5065，容器内管理程序重新加载应用配置；步骤s5061中所述热加载为加载应用仅涉及环境变量、资源限制以及cmd参数，无需重建宿主容器即可实现应用的部署和更新。更进一步，步骤s5中所述宿主机部署及更新包含以下步骤：步骤s511，管理平台前端向管理平台后端发送宿主机部署请求，部署请求中包含文件的下载地址以及下载文件的临时授权码，不包含实际文件流；步骤s512，管理平台后端进行参数组装并将宿主机部署请求经文件服务器转发至边缘代理模块；步骤s513，边缘代理模块向管理平台前端返回处理状态，并向文件服务器发出应用及配置文件下载请求；步骤s514，文件服务器向边缘代理模块返回应用及配置文件流；步骤s515，边缘代理模块将应用及配置文件存至指定目录；步骤s516，若应用压缩包md5值未变则需更新配置文件后执行步骤s518中重启应用，否则进行文件签名验证，并向管理平台后端上报处理状态；步骤s517，边缘代理模块准备应用执行环境，同时管理平台后端记录进度；步骤s518，边缘代理模块启动/重启应用，记录进度；步骤s519，边缘代理模块轮询请求部署进度信息并上报部署进度至管理平台后端，同时管理平台后端记录进度；步骤s520，管理平台前端向管理平台后端轮询请求部署进度，管理平台后端向管理平台前端返回部署进度信息。更进一步，步骤s517中所述边缘代理模块准备应用执行环境包含以下步骤：步骤s5171，解压缩到制定目录；步骤s5172，若进行宿主机更新则停止原应用并删除原应用。更进一步，步骤s504或步骤s514所述文件服务器向边缘代理模块返回应用及配置文件流为边缘代理模块从文件服务器下载文件包，包括以下步骤：步骤s531，边缘代理模块读取下载的临时文件，获取已下载字节数；步骤s532，边缘代理模块向文件服务器请求带下载起始位置的文件下载；步骤s533，文件服务器从指定起始位开始向边缘代理模块传输文件流；步骤s534，边缘代理模块保存文件流至临时文件；
步骤s535，若文件流下载中断则返回步骤s531，否则下载完成后将临时文件重命名。更进一步，还包括所述容器/应用的启动/停止，其步骤为：步骤s81，管理平台前端向管理平台后端发送容器/应用的启动/停止请求；步骤s82，管理平台后端进行参数组装，向边缘代理模块发送容器/应用的启动/停止请求；步骤s83，边缘代理模块启动/停止宿主机应用或容器，边缘代理模块经管理平台后端向管理平台前端返回处理状态；步骤s84，管理平台后端记录进度；步骤s85，边缘代理模块轮询请求执行进度信息，并向管理平台后端发送执行进度；步骤s86，管理平台后端记录进度；步骤s87，管理平台前端向管理平台后端轮询请求执行进度；步骤s88，管理平台后端向管理平台前端返回执行进度信息。更进一步，步骤s6所述管理平台对边缘设备及运行于其中的应用进行监控的步骤包括：步骤s61，边缘代理模块轮询获取设备软硬件信息；步骤s62，边缘代理模块检查数据是否有变化，若有则通过边缘数据接收服务器更新数据库；步骤s63，管理平台前端向管理平台后端发送设备软硬件信息查询命令；步骤s64，管理平台后端通过数据库查询向管理平台前端返回设备软硬件信息；步骤s65，管理平台前端向管理平台后端发送设备时间查询命令；步骤s66，管理平台后端向边缘代理模块发送设备时间查询命令；步骤s67，边缘代理模块获取当前时间并通过管理平台后端向管理平台前端返回时间信息。更进一步，引入jenkins软件与gitlab做集成，实现所述应用包开发和部署的持续集成和持续交付：其中，jenkins流水线配置及执行步骤为：步骤s901，添加凭据，凭据包括访问gitlab的账号密码凭据，以及ssh访问执行节点的账号密码凭据；步骤s902，添加任务执行节点，执行节点是用于执行流水线的服务器；步骤s903，添加任务配置流水线；步骤s904，手动执行或者gitlab触发执行，其中当采用gitlab触发执行时，需在gitlab中将jenkins构建触发地址配置进去，且gitlab需管理员允许钩子操作；步骤s905，节点执行流水线；服务端程序流水线步骤为：从gitlab中拉取代码，构建应用包并归档，生成应用对应的镜像并推送到harbor仓库，邮件通知执行结果。
7.本发明的有益效果在于：本发明公开了一种适合边缘设备中异构部署边缘计算应用的云-边架构，不同于
传统的应用部署方式，此架构支持多种部署方式，包括宿主机应用部署，容器部署以及应用附加至容器中部署(单容器多应用)的混合部署模式。既兼容传统的宿主机部署方式，同时也支持新型的容器化部署方式，采用容器技术和cgroup技术对应用实现隔离及应用资源使用限制：对于有限资源无法运行容器的边缘设备，可以采用传统的宿主机部署方式，对于资源较丰富且能运行容器的边缘设备，可以采用容器部署方式，将应用的执行环境用镜像的方式管理，免去为每个边缘设备准备应用执行环境的繁琐易出错的操作；对于部分相互关联的应用，可以将其部署到同一容器中，让其可以相互访问，同时保证云端统一配置边缘设备中运行的应用以及部署参数，采用同一套配置按不同的方式解析，边缘设备中运行的应用清单及配置在云端统一存储，即使整个边缘设备硬件完全损坏，也可依据本系统内的配置快速恢复；云端远程应用部署及升级，设备安装好后初始化后，无需本地部署操作，即可实现界面化远程在线配置部署应用，大大简化了操作难度，降低了对专业知识的需求。
附图说明
8.图1是本发明基于云边协同的电力边缘异构部署方法实施方式的流程图。
9.图2是异构部署流程图。
10.图3是图2中自动构建镜像流程图。
11.图4是图2中附加至已有容器部署流程图。
12.图5是图2中宿主机部署流程图。
13.图6是文件下载时序流程图。
14.图7是应用/容器启停时序流程图。
15.图8是边缘设备信息查询时序流程图。
具体实施方式
16.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
17.应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
18.还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
19.如图1所示，一种基于云边协同的电力边缘异构部署方法，步骤包括：s101，应用包管理，上传写好的应用包至系统中；s102，将应用包构建成镜像放入容器镜像仓库；s103，将应用包直接注册成边缘组件或将构建好的容器镜像注册为边缘应用，构建组件仓库供边缘设备使用；s104，边缘节点管理，包括设备注册，创建数字化的边缘设备，并配置需要运行于其中的边缘组件；
s105，将配置好的边缘应用清单下发至边缘，边缘依据配置进行部署和更新；s106，边缘管理云平台对边缘设备及运行于其中的应用进行监控。如图2所示，通过应用包管理(原生app包)开发构建完成app(应用)后，可直接注册为app组件，也可通过dockerfile自动构建镜像或人工手动构建镜像并注册镜像组件，app组件可配置到边缘节点宿主机部署或附加值已有容器部署，镜像组件则配置到边缘节点容器部署。步骤s102中，应用包管理实现对app文件包的管理，包括app文件包的上传下载、增删改查及版本管理。应用清单上可下载对应的应用包以及签名后的应用包，并可进行编辑，历史版本查看，及删除操作，当应用包已被使用后不允许删除。若进行新增/编辑，上传后后台从文件名中解析出应用名称和应用版本，对文件包的md5值进行签名，并存入数据库中，上传的应用包名称必须为应用名称@版本号.tar，且只能包含字母/数字/下划线/中划线/小数点；当应用未被使用，则允许在新增/编辑中做覆盖操作，已使用后则提示用户不允许修改。若进行历史版本查看及下载，则当应用已被使用后则不允许删除。应用包文件结构如下：应用包文件结构如下：步骤s102中，应用镜像构建功能放置于镜像仓库模块，对应构建记录是可编辑的，编辑后可重新进行构建操作，构建成功的记录不允许删除。镜像构建流程如下：
1)选择需要将镜像构建到哪个镜像仓库及产品；2)选择需要构建的应用包及版本，在镜像构建文件中用变量app_package表示应用文件包名，用app_name表示应用的名称(解压后为文件夹名)；3)选择镜像构建使用的基础镜像，在镜像构建文件中用变量base_image表示；4)镜像构建文件中自动带出默认模板，用户可基于默认模板进行修改；5)信息填写完成后，可执行构建动作。例如，使用docker build命令：sudo docker build-t jizhi:1.0
‑‑
build-arg app_package＝app01.tar
‑‑
build-argbase_image＝192.168.0.2:8000/base/alpine-armv7-cplus:1.0
‑‑
build-argapp_name＝app01
‑‑
no-cache.需要传递3个构建参数app_package,app_name,base_image(从选择的信息得出)基于基础镜像构建，将应用的文件拷贝到镜像内，在容器内自动执行应用指定的启动程序，执行文件名在app.cfg文件中binname字段有声明。如图3所示，镜像自动构建流程如下：1)获取应用程序包文件；2)创建dockerfile文件；3)生成docker build命令，并在docker环境下执行；4)将生成的镜像推送到执行的harbor镜像仓库；5)如果构建过程过慢，则采用异步处理，收到构建命令后立即返回“处理中”，然后再轮询构建进度，错误时返回对应的错误信息。步骤s103中，原生应用注册成组件并管理步骤如下：1)选择应用和应用版本，默认选择最新的版本；如果是镜像组件则是选择镜像及镜像版本；2)选择应用适合的操作系统及cpu架构，并设置其类别；3)填写运行参数，参数的设置格式同镜像的运行参数格式，共用一套，方便管理和切换部署方式；4)保存。步骤s104中，边缘节点组件管理包括：在服务器端存储边缘设备中运行的应用清单及配置，即使整个边缘设备硬件完全损坏，也可依据本系统内的配置快速恢复。支持在线操作，设备安装好后初始化后，无需本地部署操作，即可实现界面化远程在线配置部署应用，大大简化了操作难度，降低了对专业知识的需求。同时支持对边缘应用的更新操作，包括执行程序的更新和运行配置的更新，实现界面化远程配置升级和扩展应用，简化了操作难度，降低了扩展升级的成本。将应用组件附加到边缘节点的容器，或将应用组件直接添加到边缘节点，并配置它的运行参数和挂载的文件，实现在线部署。当选择的组件为原生应用组件时，可选择部署方式宿主机部署或附加容器部署，当选择附加容器部署时则会需要选择附加至的容器；当选择的组件为镜像组件是，则只能选择容器化部署。容器运行、附加至容器运行、宿主机运行3种部署方式的运行参数配置的数据结构保持一套，3种运行方式对各配置项的支持情况如下：
配置项\部署方式容器运行附加至容器运行宿主机运行环境变量支持支持支持端口暴露支持重建容器支持不涉及重启策略支持继承宿主容器支持(定制)文件挂载支持重建容器支持支持(定制，考虑软链接方式)资源限制支持待研究待研究hostname指定支持重建容器支持不支持(出于安全考虑)特权模式支持重建容器支持不支持串口映射支持重建容器支持不涉及启动参数设置支持支持(定制)支持日志配置支持继承宿主容器支持(定制)cmd参数支持支持(定制)支持(定制)宿主机运行模式可将cmd参数解析为程序的运行参数，文件挂载配置可通过软链接的方式将配置文件链接到指定执行程序目录；部署完成后，如需更新应用及其配置，可重新修改设备组件清单，再次执行部署动作即可，比对本地部署的组件是否有变动，支持增量部署，只下发有变动的组件(包括组件的新增、更新、删除、启停)。如图4所示，附加至已有容器部署流程如下：1)管理平台前端向管理平台后端发送附加至容器部署请求，部署请求中包含文件的下载地址以及下载文件的临时授权码，不包含实际文件流；2)管理平台后端进行参数组装并将附加至容器部署请求经文件服务器转发至边缘代理模块；3)边缘代理模块向管理平台前端返回处理状态，并向文件服务器发出应用及配置文件下载请求；4)文件服务器向边缘代理模块返回应用及配置文件流；5)边缘代理模块将应用及配置文件存至指定目录，进行文件签名验证，并向管理平台后端上报处理状态；6)边缘代理模块准备应用执行环境：61)若不是热加载，则合并应用容器运行参数，备份容器内原应用及数据，并重建容器，否则直接执行下一步；所述热加载为加载应用仅涉及环境变量、资源限制以及cmd参数，无需重建宿主容器即可实现应用的部署和更新。62)生成应用的容器配置文件；63)复制包括容器内原应用及数据文件的所有应用及其容器配置文件至容器内；64)若为应用组件容器内更新则通知容器内管理程序停止并删除旧应用，否则执行下一步；65)容器内管理程序重新加载应用配置；7)边缘代理模块启动/重启应用流程并记录进度；8)边缘代理模块轮询请求部署进度信息并上报部署进度至文件服务器，文件服务器转发部署进度至管理平台后端；9)管理平台后端记录进度；
10)管理平台前端向管理平台后端轮询请求部署进度，管理平台后端向管理平台前端返回部署进度信息。其中，应用及其配置文件需放入指定文件夹内，供容器内管理程序读取。每个应用都有单独的应用容器配置文件，将环境变量、资源限制、cmd参数配置写入其内。对于不能采用热加载的参数：端口暴露，文件挂载，hostname，特权模式及串口映射配置，需将其与宿主容器的运行参数合并，再使用合并后的参数重建容器。只允许将应用附加至基于基础镜像构建的容器中运行(其他容器内无应用管理程序)。附加至容器运行时，需检查容器是否是基于基础镜像构建的，否则报异常。容器异常重启时(如断电,设备升级)，需保证容器内所有应用能正常启动
‑‑‑
故应用程序文件、应用配置、应用容器配置文件都必须放入容器内，容器重启时，容器内管理程序会重新加载所有配置并运行所有应用。容器不满足热加载时会重建容器。作为优化方案，开发一个容器内部部署服务程序，宿主机程序通过docker exec{containername}appctl start{appname}，docker exec{containername}appctl restart{appname}命令调用该程序来启动应用；通过docker cp命令来复制文件到容器内部。如图5所示，宿主机部署步骤包括：1)管理平台前端向管理平台后端发送宿主机部署请求，部署请求中包含文件的下载地址以及下载文件的临时授权码，不包含实际文件流；2)管理平台后端进行参数组装并将宿主机部署请求经文件服务器转发至边缘代理模块；3)边缘代理模块向管理平台前端返回处理状态，并向文件服务器发出应用及配置文件下载请求；4)文件服务器向边缘代理模块返回应用及配置文件流；5)边缘代理模块将应用及配置文件存至指定目录；6)若应用压缩包md5值未变则需更新配置文件后执行步骤s518中重启应用，否则进行文件签名验证，并向管理平台后端上报处理状态；7)边缘代理模块准备应用执行环境，同时管理平台后端记录进度：71)解压缩到制定目录；72)若进行宿主机更新则停止原应用并删除原应用。8)边缘代理模块启动/重启应用，记录进度；9)边缘代理模块轮询请求部署进度信息并上报部署进度至管理平台后端，同时管理平台后端记录进度；10)管理平台前端向管理平台后端轮询请求部署进度，管理平台后端向管理平台前端返回部署进度信息。其中，应用及其配置文件需放入指定文件夹内。每个应用都有单独的运行配置文件，将环境变量、资源限制、cmd参数配置写入其内。设备或应用异常重启时(如断电,设备升级)，需保证宿主机内所有应用能正常启动，应用重启时，部署升级模块会重新加载所有配置并运行所有应用。整个容器镜像和应用包发布版本后不允许修改，当镜像或应用包修改后会形成新
的版本；部署至不同的终端中要求运行参数不一样时，通过以下3中方式传给应用：1)文件挂载方式，将配置文件挂载至应用内。2)环境变量传入，应用在运行中通过读取环境变量获取其运行参数。3)应用命令行参数传入，通过在执行应用时传入运行参数。应用在部署或升级过程中，需要从文件服务器中下载文件包，下载过程失败时，支持断点续传。如图6所示，文件下载时序流程如下：1)边缘代理模块读取下载的临时文件，获取已下载字节数；2)边缘代理模块向文件服务器请求带下载起始位置的文件下载；3)文件服务器从指定起始位开始向边缘代理模块传输文件流；4)边缘代理模块保存文件流至临时文件；5)若文件流下载中断则返回步骤1)，否则下载完成后将临时文件重命名。如图7所示，在配置边缘节点的组件清单时，指定是否启动容器/应用；边缘组件是否启动配置后，不会立即生效，需要执行部署操作，重新部署才会生效。组件停止操作时应提示可能会影响到的相关依赖组件，以及容器中受影响的所有应用，最后执行的应用部署。下发至边缘的停止及启动请求和部署请求是同一个请求，其通过请求参数来声明哪个应用需求启动，哪个应用需要停止，执行时序如下：1)管理平台前端向管理平台后端发送容器/应用的启动/停止请求；2)管理平台后端进行参数组装，向边缘代理模块发送容器/应用的启动/停止请求；3)边缘代理模块启动/停止宿主机应用或容器，边缘代理模块经管理平台后端向管理平台前端返回处理状态；4)管理平台后端记录进度；5)边缘代理模块轮询请求执行进度信息，并向管理平台后端发送执行进度；6)管理平台后端记录进度；7)管理平台前端向管理平台后端轮询请求执行进度；8)管理平台后端向管理平台前端返回执行进度信息。容器内对应用的启动或停止操作，通过docker exec{containername}appctl start{appname}，docker exec{containername}appctl stop{appname}命令进行操作。为实现现场日志查看、排查问题，需远程查看及导出日志，方便快速排查问题，节省运维成本，查看日志包括内核日志，系统日志、用户日志、权限日志、边缘管理本身的日志，边缘应用日志。由于日志文件可能过大，故采用异步处理，避免页面等待响应超时。远程监控查看设备信息包括：设备类型、设备名称、电子标签、厂商信息、设备状态、mac地址、设备当前时间、设备启动时间、设备运行时长、平台版本及补丁版本信息、硬件版本信息、设备上行通讯接口信息、设备内存使用情况、设备内部存储使用情况。数据获取策略如下：对于不会经常变的设备软硬件信息，采用信息变化时上报的策略，上报数据存储在服务端数据库，仅保留最后一条数据。当前时间及启动时间，边缘提供查询接口，进入页面时实时调用查询。设备状态、cpu、内存、内部存储使用情况采用定时上报的策略(1分钟上报一次，可配置)，上报数据存储在服务端数据库，保留一段时间的数据看趋势(定期清理历史数据)。
如图8所示，设备软硬件信息查询和时间信息查询流程如下：1)边缘代理模块轮询获取设备软硬件信息；2)边缘代理模块检查数据是否有变化，若有则通过边缘数据接收服务器更新数据库；3)管理平台前端向管理平台后端发送设备软硬件信息查询命令；4)管理平台后端通过数据库查询向管理平台前端返回设备软硬件信息；5)管理平台前端向管理平台后端发送设备时间查询命令；6)管理平台后端向边缘代理模块发送设备时间查询命令；7)边缘代理模块获取当前时间并通过管理平台后端向管理平台前端返回时间信息。日志查询时，直接请求响应式返回日志信息展示于页面；日志导出时，先发送日志导出请求(带上唯一请求id)至边缘日志模块，日志模块收到请
·
求后返回处理中，并异步上传日志文件至文件服务器，上传成功后，管理平台前端可请求文件服务器下载日志文件。引入jenkins软件与gitlab做集成，实现所述应用包开发和部署的持续集成和持续交付(cicd)：其中，jenkins流水线配置及执行步骤为：1)添加凭据，凭据包括访问gitlab的账号密码凭据，以及ssh访问执行节点的账号密码凭据；2)添加任务执行节点，执行节点是用于执行流水线的服务器；3)添加任务配置流水线；4)手动执行或者gitlab触发执行，其中当采用gitlab触发执行时，需在gitlab中将jenkins构建触发地址配置进去，且gitlab需管理员允许钩子操作；5)节点执行流水线；服务端程序流水线步骤为：从gitlab中拉取代码，构建应用包并归档，生成应用对应的镜像并推送到harbor仓库，邮件通知执行结果。边缘镜像组件流水线步骤为：集成gitlab(用于管理应用源代码的工具)、jenkins(实现cicd的工具),harbor仓库(用于管理容器镜像的工具)以及本系统，实现从代码提交开始至应用镜像的边缘部署全流程管理。
20.本发明实施例可以根据实际需要进行顺序调整、合并和删减。
21.实施例对本方案进行了详细的介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。