中间件的设计方法、系统、电子设备及可读存储介质

技术领域

本申请涉及容器监控技术领域，尤其涉及中间件的设计方法、系统、电子设备及可读存储介质。

背景技术

随着企业的发展，企业对线上服务的稳定性要求越来越高，如果线上的服务出现故障，会造成巨大的损失。尤其是在容器环境中，因为容器的特殊性，需要我们更加全面的，精准的了解集群的状态，对集群状态作出分析和预判。伴随业务的发展，对监控系统的要求也越来越高，监控系统不但要监控全面，更要容易配置，容易管理。优秀的监控系统可以更加便捷的让一些未发生的问题尽早的暴露出来。随着业务变的越来越复杂，监控系统为了适配业务的变化也越变的复杂。在现有的方案中我们通常使用prometheus+alertmanager实现监控和报警的功能，为了让这些服务更利于维护，我们把监控和报警的服务制作的镜像，运行在k8集群中。这使得的这两种服务更加稳定。把配置文件制作成configmap，挂在到pod中，可以让配置实时生效，但是这对运维人员就有了更高的要求，需要因为人员能够熟练的配置k8s中方的各种资源，现有技术应用框架图如图2所示。如图2所示，运维人员如果需要更改监控系统的配置先需要能够熟练的配置k8s集群，并且还要熟练掌握prometheus查询语句，才能完成配置监控，这无形中就提升了运维人员的熟练成本。且在实际的生产中，所有的监控规则都写入同一个文件中。使配置文件越来越大，这并不方便日常维护，容易产生认为错误。

因此，针对以上现状，本发明提出中间件的设计方法、系统、电子设备及可读存储介质，本发明通过proal系统能够让运维人员脱离k8s系统去配置监控规则，报警规则，而且也不需要运维人员去深入的了解查询语句，只需要简单的配置就能实现快速的完成对监控规则和报警规则的配置，准对各个业务的不同而制定可以是被该业务的监控规则和报警规则，使得监控系统更灵活。并且减少了人为直接更改的可能，可以降低人工成本，学习成本低，更加高效，同时，便于维护，不需要维护一个很大的配置文件，从而降低了人工出错的风险。

发明内容

本申请实施例提供了本发明提出中间件的设计方法、系统、电子设备及可读存储介质，以至少解决相关技术中主观因素影响的问题。

本发明提供了一种中间件的设计方法，包括：

配置步骤：通过proal的前端界面配置系统规则；

输出步骤：所述proal将所述系统规则输出到系统中，并将所述系统规则同步存储到proal数据库中。

上述的中间件的设计方法，所述系统包括监控系统与报警系统，所述系统规则包括监控规则与报警规则。

上述的中间件的设计方法，所述配置步骤包括，通过所述proal的所述前端界面配置所述监控规则与所述报警规则。

上述的中间件的设计方法，所述输出步骤包括，所述proal将所述监控规则与所述报警规则同步存储到所述proal数据库，并将所述监控规则与所述报警规则输出到所述监控系统以及所述报警系统中，若所述监控系统与所述报警系统无法正常使用，只需提供其他可用的监控系统与报警系统的endpoint，并与所述proal连接后，所述proal读取所述proal数据库中存储的所述监控规则与所述报警规则，并将所述监控规则与所述报警规则输出到可用的所述监控系统与所述报警系统中。

本发明还提供一种中间件的设计系统，其中，适用于上述所述的中间件的设计方法，所述中间件的设计系统包括：

配置单元：通过proal的前端界面配置系统规则；

输出单元：所述proal将所述系统规则输出到系统中，并将所述系统规则同步存储到proal数据库中。

上述的中间件的设计系统，所述系统包括监控系统与报警系统，所述系统规则包括监控规则与报警规则。

上述的中间件的设计系统，通过所述配置单元中所述proal的所述前端界面配置所述监控规则与所述报警规则。

上述的中间件的设计系统，所述proal将所述监控规则与所述报警规则同步存储到所述proal数据库，并通过输出单元输出到所述监控系统以及所述报警系统中，若所述所述监控系统与所述报警系统无法正常使用，只需提供其他可用的监控系统与报警系统的endpoint，与所述proal连接后，所述proal读取所述proal数据库中存储的所述监控规则与所述报警规则，并将所述监控规则与所述报警规则输出到可用的所述监控系统与所述报警系统中。

本发明还提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述任一项所述的中间件的设计方法。

本发明还提供一种电子设备可读存储介质，所述电子设备可读存储介质上存储有计算机程序指令，所述计算机程序指令被所述处理器执行时实现上述任一项所述的中间件的设计方法。

相比于相关技术，本发明提出中间件的设计方法、系统、电子设备及可读存储介质，本发明通过proal系统能够让运维人员脱离k8s系统去配置监控规则，报警规则，而且也不需要运维人员去深入的了解查询语句，只需要简单的配置就能实现快速的完成对监控规则和报警规则的配置，准对各个业务的不同而制定可以是被该业务的监控规则和报警规则，使得监控系统更灵活。并且减少了人为直接更改的可能，可以降低人工成本，学习成本低，更加高效，同时，便于维护，不需要维护一个很大的配置文件，从而降低了人工出错的风险。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的中间件的设计方法流程图；

图2是根据本申请实施例的现有技术应用框架图；

图3是根据本申请实施例的架构框架图；

图4是根据本申请实施例的规则空间框架图；

图5为本发明的中间件的设计系统的结构示意图；

图6是根据本申请实施例的电子设备的框架图。

其中，附图标记为：

配置单元：51；

输出单元：52；

81：处理器；

82：存储器；

83：通信接口；

80：总线。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本发明基于proal的容器监控平台，下面进行简要的介绍。

kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署，规划，更新，维护的一种机制。传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。Kubernetes有以下特点，可移植:支持公有云，私有云，混合云，多重云(multi-cloud)；可扩展:模块化，插件化，可挂载，可组；自动部署，自动重启，自动复制，自动伸缩/扩展。Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

容器是应用服务器中位于组件和平台之间的接口集合。容器是伴随着瘦客户端系统的发展而诞生的。在开发瘦客户端系统时，开发人员要花费大量的精力去关注线程安全、事务、网络、资源等等细节，从而降低了开发效率。由于这些对这些细节的解决方法一般是固定不变，或者只有参数改变的，所以从代码重用和设计模式的角度出发，开发人员将这些底层细节提取出来，做成平台，并提供一定的接口。这样，业务开发人员就不需要在关注与这些底层细节的实现，而专注于业务逻辑的实现。容器一般位于应用服务器之内，由应用服务器负责加载和维护。一个容器只能存在于一个应用服务器之内，一个应用服务器可以建立和维护多个容器。容器一般遵守可配置的原则，即容器的使用者可以通过对容器参数的配置，来达到自己的使用需求，而不需要修改容器的代码。容器是用来存储和组织其他对象的对象。实现链表的类就是一个容器的示例。如C++编程vectormydata；//创建存储double类型值的容器mydata可以在容器中存储基本类型或任何类类型的条目。如果STL容器模板的类型实参是一个类类型，那么容器可以存储该类型的对象或者任何派生类类型的对象。通常，容器存储我们存储在其中的对象的副本，它们自动分配和管理对象占用的内存。当销毁某个容器的对象时，容器会负责销毁它包含的对象并释放它们占用的内存。使用STL容器存储对象的一个优点是我们不用费心管理它们的内存。在实际的开发过程中，数据结构本身的重要性不会逊于操作于数据结构的算法的重要性，当程序中存在着对时间要求很高的部分时，数据结构的选择就显得更加重要。经典的数据结构数量有限，但是我们常常重复着一些为了实现向量、链表等结构而编写的代码，这些代码都十分相似，只是为了适应不同数据的变化而在细节上有所出入。STL容器就为我们提供了这样的方便，它允许我们重复利用已有的实现构造自己的特定类型下的数据结构，通过设置一些模版类，STL容器对最常用的数据结构提供了支持，这些模板的参数允许我们指定容器中元素的数据类型，可以将我们许多重复而乏味的工作简化。

监控平台软件是基于网络的全数字化的信息传输和管理系统，属于第三代开放式技术的综合网络监控产品。它结合了现代音、视频压缩技术、网络通讯技术、计算机控制技术、流媒体传输技术，采用模块化的软件设计理念，将不同客户的需求以组件模块的方式实现；以网络集中管理和网络传输为核心，完成信息采集、传输、控制、管理和储存的全过程，能够架构在各种专网/局域网/城域网/广域网之上，超视科技与市场主流硬件厂商配合，兼容多种品牌硬件产品。真正实现了监控联网、集中管理，授权用户可在网络的任何计算机上对监控现场实时监控，提供了强大的、灵活的网络集中监控综合解决方案。监控平台分为四大模块：管理服务模块是系统的核心，是整个系统的主服务器，桥接了其他的各个服务模块。主要用于管理系统平台所有的设备和与其它的管理服务器进行通讯和同步。可以实现对远程数字视频设备的机构、人员、设备、任务、报警、日志等的配置、设备巡检和实时访问权限控制等管理。当多个客户端需要同时查看某监控点的相同画面时，势必会造成在一条通讯网络线路上的数据拥堵，严重浪费网络资源。流媒体服务器支持视音频流的转发，当有多个客户端需要同时访问同一远程画面时，可以通过流媒体服务器进行转发，在转发服务与前端视频通道之间只占用一个通道带宽的网络资源，再由转发服务器将数据分发给多个客户端。流媒体服务模块分为实时流媒体服务模块和回放流媒体服务模块。实时流媒体服务模块用于对本地的实时视频流进行转发。回放流媒体服务模块用于对本地的回放视频流进行转发。可对霍尼韦尔、C&K、博世、时刻、等所有能使用Vista和CK键盘的报警主机品牌进行管理。通过串口或网络通讯的方式，将分散在各个地方的独立的报警子系统进行联网，报警管理中心可对任何一个子系统进行报警控制，如：报警布防、撤防、旁路、清除报警、报警输出的打开、关闭等。当任何一个报警子系统有报警发生时，报警管理中心能快速准确的显示出报警的详细信息，如：报警地点、名称、类型、子系统号、防区号等，并会自动根据预先设置的报警预案进行联动操作，如：视频弹出播放、播放指定声音、视频群组播放、视频群组沦陷、联动报警输出、报警布撤防、电视墙切换、联动云台预置位、巡航、发送手机短信、LED屏显示、打印机打印等。客户端模块是最终呈现在用户面前，供用户操作使用的模块，客户端通过与各个服务组件进行通讯，用于实现电子地图、显示实时视频和回放录像、控制云台镜头动作、控制报警输入输出等监控操作，以及配置电子地图、外部设备及用户权限等管理功能。

本发明提出中间件的设计方法、系统、电子设备及可读存储介质，本发明通过proal系统能够让运维人员脱离k8s系统去配置监控规则，报警规则，而且也不需要运维人员去深入的了解查询语句，只需要简单的配置就能实现快速的完成对监控规则和报警规则的配置，准对各个业务的不同而制定可以是被该业务的监控规则和报警规则，使得监控系统更灵活。并且减少了人为直接更改的可能，可以降低人工成本，学习成本低，更加高效，同时，便于维护，不需要维护一个很大的配置文件，从而降低了人工出错的风险。下面将中间件的设计为例对本申请实施例进行说明。

实施例一

本实施例提供了中间件的设计方法。请参照图1至图4，图1是根据本申请实施例的中间件的设计方法流程图；图2是根据本申请实施例的现有技术应用框架图；图3是根据本申请实施例的架构框架图；

图4是根据本申请实施例的规则空间框架图，如图所示，中间件的设计方法包括如下步骤：

配置步骤S1：通过proal的前端界面配置系统规则；

输出步骤S2：所述proal将所述系统规则输出到系统中，并将所述系统规则同步存储到proal数据库中。

实施例中，所述系统包括监控系统与报警系统，所述系统规则包括监控规则与报警规则。

实施例中，所述配置步骤S1包括，通过所述proal的所述前端界面配置所述监控规则与所述报警规则。

具体实施中，从图3、图4中可以看到proql独立于k8s之外，是一套单独的配置。用户可以直接操作proal的前段界面，直接更改监控系统和报警系统，这让用户脱离了直接操作k8s，实现了通过页面触点的方式配置报警和监控规则。并且如果像只针对某一个业务定制专属的规则，proql系统存在了一个空间的概念。规则属于哪个业务组，用户只需要配置这个空间下的规则，这样就可以把空间和业务组绑定起来，实现只属于这个业务的专属规则。在用户配置了一条规则之后，proal会把规则写入监控系统或者报警系统。并且为了避免数据丢失，也方便数据复盘，会同步写入到数据库中。这样方便其他人员查找，也起到了备份的作用。

实施例中，所述输出步骤S2包括，所述proal将所述监控规则与所述报警规则同步存储到所述proal数据库，并将所述监控规则与所述报警规则输出到所述监控系统以及所述报警系统中，若所述监控系统与所述报警系统无法正常使用，只需提供其他可用的监控系统与报警系统的endpoint，并与所述proal连接后，所述proal读取所述proal数据库中存储的所述监控规则与所述报警规则，并将所述监控规则与所述报警规则输出到可用的所述监控系统与所述报警系统中。

具体实施中，若监控系统与报警系统无法正常使用，只需提供其他可用的监控系统与报警系统的endpoint，并与proal连接后，proal读取proal数据库中存储的监控规则与报警规则，并将监控规则与报警规则输出到可用的监控系统与报警系统中，即可快速的部署一套完整的可用的系统。

由此，本发明提出中间件的设计方法、系统、电子设备及可读存储介质，本发明通过proal系统能够让运维人员脱离k8s系统去配置监控规则，报警规则，而且也不需要运维人员去深入的了解查询语句，只需要简单的配置就能实现快速的完成对监控规则和报警规则的配置，准对各个业务的不同而制定可以是被该业务的监控规则和报警规则，使得监控系统更灵活。并且减少了人为直接更改的可能，可以降低人工成本，学习成本低，更加高效，同时，便于维护，不需要维护一个很大的配置文件，从而降低了人工出错的风险。

实施例二

请参照图5，图5为本发明的中间件的设计系统的结构示意图。如图5所示，发明的中间件的设计系统，适用于上述的中间件的设计方法，中间件的设计系统包括：

配置单元51：通过proal的前端界面配置系统规则；

输出单元52：所述proal将所述系统规则输出到系统中，并将所述系统规则同步存储到proal数据库中。

在本实施例中，所述系统包括监控系统与报警系统，所述系统规则包括监控规则与报警规则。

在本实施例中，通过所述配置单元51中所述proal的所述前端界面配置所述监控规则与所述报警规则。

在本实施例中，所述proal将所述监控规则与所述报警规则同步存储到所述proal数据库，并通过输出单元52输出到所述监控系统以及所述报警系统中，若所述所述监控系统与所述报警系统无法正常使用，只需提供其他可用的监控系统与报警系统的endpoint，与所述proal连接后，所述proal读取所述proal数据库中存储的所述监控规则与所述报警规则，并将所述监控规则与所述报警规则输出到可用的所述监控系统与所述报警系统中。

实施例四

结合图6所示，本实施例揭示了一种电子设备的一种具体实施方式。电子设备可以包括处理器81以及存储有计算机程序指令的存储器82。

具体地，上述处理器81可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器82可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器82可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器82可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器82可在数据处理装置的内部或外部。在特定实施例中，存储器82是非易失性(Non-Volatile)存储器。在特定实施例中，存储器82包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(RandomAccess Memory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为FPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EFPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器82可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器81所执行的可能的计算机程序指令。

处理器81通过读取并执行存储器82中存储的计算机程序指令，以实现上述实施例中的任意中间件的设计方法。

在其中一些实施例中，电子设备还可包括通信接口83和总线80。其中，如图6所示，处理器81、存储器82、通信接口83通过总线80连接并完成相互间的通信。

通信接口83用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。通信端口83还可以实现与其他部件例如：外接设备、图像/中间件的设计设备、数据库、外部存储以及图像/数据处理工作站等之间进行数据通信。

总线80包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。总线80包括但不限于以下至少之一：数据总线(Data Bus)、地址总线(Address Bus)、控制总线(ControlBus)、扩展总线(Expansion Bus)、局部总线(Local Bus)。举例来说而非限制，总线80可包括图形加速接口(Accelerated Graphics Port，简称为AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，简称为EISA)总线、前端总线(FrontSide Bus，简称为FSB)、超传输(Hyper Transport，简称为HT)互连、工业标准架构(Industry Standard Architecture，简称为ISA)总线、无线带宽(InfiniBand)互连、低引脚数(Low Pin Count，简称为LPC)总线、存储器总线、微信道架构(Micro ChannelArchitecture，简称为MCA)总线、外围组件互连(Peripheral Component Interconnect，简称为PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial AdvancedTechnology Attachment，简称为SATA)总线、视频电子标准协会局部(Video ElectronicsStandards Association Local Bus，简称为VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线80可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

电子设备可连接中间件的设计系统，从而实现结合图1至图4描述的方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。