拓扑创建管控的方法、装置及存储介质与流程

文档序号:15357792发布日期:2018-09-05 00:12阅读:134来源:国知局
本发明涉及拓扑创建
技术领域
:,尤其涉及一种拓扑创建管控的方法、装置及存储介质。
背景技术
::目前,apache-storm分布式实时处理框架技术因其实时处理性能出众而在大数据领域被广泛使用。从逻辑上看,storm作为一个集群,而用户能够在该集群提交一系列拓扑(topology)计算资源达到实时处理业务数据的能力。现有技术中,在向storm集群进行拓扑提交时,其拓扑的创建都是由业务方维护,而storm集群管理人员则需要耗费更多的精力管控拓扑在持久化过程中对敏感数据的读写。这样一来,当多个不同领域的业务方向大数据平台提交拓扑时,则会导致storm集群的拓扑难以管理,需要人工登记拓扑对哪些数据进行读写。同时,由于拓扑的提交过程极其简单,并无中间过程拦截,业务方能够通过隐秘的方式修改拓扑的代码避开管理员的管控从而获取企业或机构的商业信息。另外,由于分布式的远程过程调用(distributedremoteprocedurecall,drpc)在storm中被广泛应用,已经与storm对实时持久化的查询形成了密不可分的联系。当提交一个带有drpc组件的拓扑任务需要给drpc组件一个标识,该标识在storm中是可以无障碍的被所有业务方访问,即业务方可以访问其他业务的数据。该过程大数据平台管理员是无法直接介入管理。这对于企业或机构的敏感数据及商业数据,造成极大的安全隐患。技术实现要素:本发明的主要目的在于提出一种拓扑创建管控的方法、装置、服务器及存储介质,旨在应用于拓扑创建时,能够在拓扑提交前就进行数据权限管理,且相比于原生storm模式中,拓扑由业务方控制,其能够将拓扑创建从storm集群分离出来,使管理员能够充分管控业务方的配置项和参数,保证了storm集群的稳定性以及不同业务方之间的数据安全性。为实现上述目的,本发明提供的一种storm权限管控的方法,所述方法包括以下步骤:提供唯一的数据接入方式供业务方进行拓扑的前期创建;在所述拓扑的前期创建完成后,进一步对所述拓扑的配置参数进行规范化管理,以在所述配置参数规范化后提交所述拓扑;在对所述拓扑进行提交时,对所述拓扑进行权限验证,仅在所述拓扑通过权限验证后成功提交所述拓扑。可选地,所述提供唯一的数据接入方式供业务方进行拓扑的前期创建的步骤具体包括:接受业务方通过唯一的数据入口创建所述拓扑的框架;对创建得到的所述拓扑的框架进行参数解析,以完成所述拓扑的前期创建。可选地,所述提供唯一的数据接入方式供业务方进行拓扑的前期创建的步骤具体还包括:接受业务方传入所述拓扑的远程过程调用drpc标识。可选地,所述提供唯一的数据接入方式供业务方进行拓扑的前期创建的步骤具体还包括:对所述拓扑进行drpc检查,以确认所述drpc标识的名称是否为空以及所述拓扑是否包含drpc入口。可选地,所述在所述拓扑的前期创建完成后,进一步对所述拓扑的配置参数进行规范化管理,以在所述配置参数规范化后提交所述拓扑的步骤具体包括:在所述拓扑的前期创建完成后,按分配给所述拓扑的业务空间名进一步对所述拓扑的拓扑名称及drpc标识进行规范化调整;使用所述业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成所述拓扑的持久化工具封装。可选地,所述在对所述拓扑进行提交时,对所述拓扑进行权限验证,仅在所述拓扑通过权限验证后成功提交所述拓扑的步骤具体包括:从缓存中取出与所述拓扑对应的所述业务空间名,以及所述数据库名或所述缓存的键名进行匹配,仅在所述匹配通过后通过管理员授权,成功提交所述拓扑。可选地,所述在对所述拓扑进行提交时,对所述拓扑进行权限验证,仅在所述拓扑通过权限验证后成功提交所述拓扑的步骤之后,还包括:对所述拓扑进行drpc封装,使所述拓扑激活drpc实时查询功能。可选地,所述对所述拓扑进行drpc封装,使所述拓扑激活drpc实时查询功能的步骤之后,还包括:接受所述业务方使用应用程序编程接口api发出drpc请求,查询相应的所述拓扑,并实时计算反馈请求结果。此外,为实现上述目的,本发明还提出一种服务器,所述服务器包括存储器、处理器、存储在所述存储器上并可在所述处理器上运行的程序以及用于实现所述处理器和所述存储器之间的连接通信的数据总线,所述程序被所述处理器执行时实现上述的方法的步骤。此外,为实现上述目的,本发明还提出一种存储介质,用于计算机可读存储,所述存储介质存储有一个或者多个程序,所述一个或者多个程序可被一个或者多个处理器执行,以实现上述的方法的步骤。本发明提出的一种拓扑创建管控的方法、装置及存储介质,其提供唯一的数据接入方式供业务方进行拓扑的前期创建,并在拓扑的前期创建完成后,进一步对拓扑的配置参数进行规范化管理,以在配置参数规范化后提交拓扑,最后,在对拓扑进行提交时,对拓扑进行权限验证,仅在拓扑通过权限验证后成功提交拓扑。这样一来,其通过强制业务方必须使用提供的软件开发工具包sdk进行数据访问,以在拓扑提交前就进行数据权限管理,且相比于原生storm模式中,拓扑由业务方控制,其能够将拓扑创建从storm集群分离出来,使管理员能够充分管控业务方的配置项和参数,保证了storm集群的稳定性以及不同业务方之间的数据安全性。附图说明图1为实现本发明各个实施例的移动终端的硬件结构示意图。图2为如图1所示的移动终端所基于的通信网络系统架构图。图3为本发明实施例一storm权限管控的系统的数据交互关系图。图4为本发明拓扑创建的流程框图。图5为本发明drpc查询的流程框图。图6为本发明实施例二拓扑创建管控的方法的流程框图。图7为图3所示拓扑创建管控的方法步骤s110的具体流程框图。图8为图3所示拓扑创建管控的方法步骤s120的具体流程框图。图9为本发明实施例二拓扑创建管控的方法的又一流程框图。图10为本发明实施例三拓扑创建管控的装置的结构框图。本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。具体实施方式应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。在后续的描述中,使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明,其本身没有特定的意义。因此,“模块”、“部件”或“单元”可以混合地使用。终端可以各种形式来实施。例如,本发明中描述的终端可以包括诸如手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(personaldigitalassistant,pda)、便捷式媒体播放器(portablemediaplayer,pmp)、导航装置、可穿戴设备、智能手环、计步器等移动终端,以及诸如数字tv、台式计算机等固定终端。后续描述中将以移动终端为例进行说明,本领域技术人员将理解的是,除了特别用于移动目的的元件之外,根据本发明的实施方式的构造也能够应用于固定类型的终端。请参阅图1,其为实现本发明各个实施例的一种移动终端的硬件结构示意图,该移动终端100可以包括:rf(radiofrequency,射频)单元101、wifi模块102、音频输出单元103、a/v(音频/视频)输入单元104、传感器105、显示单元106、用户输入单元107、接口单元108、存储器109、处理器110、以及电源111等部件。本领域技术人员可以理解,图1中示出的移动终端结构并不构成对移动终端的限定,移动终端可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。下面结合图1对移动终端的各个部件进行具体的介绍:射频单元101可用于收发消息或通话过程中,信号的接收和发送,具体的,将基站的下行消息接收后,给处理器110处理;另外,将上行的数据发送给基站。通常,射频单元101包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外,射频单元101还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议,包括但不限于gsm(globalsystemofmobilecommunication,全球移动通讯系统)、gprs(generalpacketradioservice,通用分组无线服务)、cdma2000(codedivisionmultipleaccess2000,码分多址2000)、wcdma(widebandcodedivisionmultipleaccess,宽带码分多址)、td-scdma(timedivision-synchronouscodedivisionmultipleaccess,时分同步码分多址)、fdd-lte(frequencydivisionduplexing-longtermevolution,频分双工长期演进)和tdd-lte(timedivisionduplexing-longtermevolution,分时双工长期演进)等。wifi属于短距离无线传输技术,移动终端通过wifi模块102可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。虽然图1示出了wifi模块102,但是可以理解的是,其并不属于移动终端的必须构成,完全可以根据需要在不改变发明的本质的范围内而省略。音频输出单元103可以在移动终端100处于呼叫信号接收模式、通话模式、记录模式、语音识别模式、广播接收模式等等模式下时,将射频单元101或wifi模块102接收的或者在存储器109中存储的音频数据转换成音频信号并且输出为声音。而且,音频输出单元103还可以提供与移动终端100执行的特定功能相关的音频输出(例如,呼叫信号接收声音、消息接收声音等等)。音频输出单元103可以包括扬声器、蜂鸣器等等。a/v输入单元104用于接收音频或视频信号。a/v输入单元104可以包括图形处理器(graphicsprocessingunit,gpu)1041和麦克风1042,图形处理器1041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示单元106上。经图形处理器1041处理后的图像帧可以存储在存储器109(或其它存储介质)中或者经由射频单元101或wifi模块102进行发送。麦克风1042可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风1042接收声音(音频数据),并且能够将这样的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可经由射频单元101发送到移动通信基站的格式输出。麦克风1042可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。移动终端100还包括至少一种传感器105,比如光传感器、运动传感器以及其他传感器。具体地,光传感器包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板1061的亮度,接近传感器可在移动终端100移动到耳边时,关闭显示面板1061和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等;至于手机还可配置的指纹传感器、压力传感器、虹膜传感器、分子传感器、陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器,在此不再赘述。显示单元106用于显示由用户输入的消息或提供给用户的消息。显示单元106可包括显示面板1061,可以采用液晶显示器(liquidcrystaldisplay,lcd)、有机发光二极管(organiclight-emittingdiode,oled)等形式来配置显示面板1061。用户输入单元107可用于接收输入的数字或字符消息,以及产生与移动终端的用户设置以及功能控制有关的键信号输入。具体地,用户输入单元107可包括触控面板1071以及其他输入设备1072。触控面板1071,也称为触摸屏,可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1071上或在触控面板1071附近的操作),并根据预先设定的程式驱动相应的连接装置。触控面板1071可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸消息,并将它转换成触点坐标,再送给处理器110,并能接收处理器110发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1071。除了触控面板1071,用户输入单元107还可以包括其他输入设备1072。具体地,其他输入设备1072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种,具体此处不做限定。进一步的,触控面板1071可覆盖显示面板1061,当触控面板1071检测到在其上或附近的触摸操作后,传送给处理器110以确定触摸事件的类型,随后处理器110根据触摸事件的类型在显示面板1061上提供相应的视觉输出。虽然在图1中,触控面板1071与显示面板1061是作为两个独立的部件来实现移动终端的输入和输出功能,但是在某些实施例中,可以将触控面板1071与显示面板1061集成而实现移动终端的输入和输出功能,具体此处不做限定。接口单元108用作至少一个外部装置与移动终端100连接可以通过的接口。例如,外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(i/o)端口、视频i/o端口、耳机端口等等。接口单元108可以用于接收来自外部装置的输入(例如,数据消息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端100和外部装置之间传输数据。存储器109可用于存储软件程序以及各种数据。存储器109可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外,存储器109可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。处理器110是移动终端的控制中心,利用各种接口和线路连接整个移动终端的各个部分,通过运行或执行存储在存储器109内的软件程序和/或模块,以及调用存储在存储器109内的数据,执行移动终端的各种功能和处理数据,从而对移动终端进行整体监控。处理器110可包括一个或多个处理单元;优选的,处理器110可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器110中。移动终端100还可以包括给各个部件供电的电源111(比如电池),优选的,电源111可以通过电源管理系统与处理器110逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。尽管图1未示出,移动终端100还可以包括蓝牙模块等,在此不再赘述。为了便于理解本发明实施例,下面对本发明的移动终端所基于的通信网络系统进行描述。请参阅图2,图2为本发明实施例提供的一种通信网络系统架构图,该通信网络系统为通用移动通信技术的lte系统,该lte系统包括依次通讯连接的ue(userequipment,用户设备)201,e-utran(evolvedumtsterrestrialradioaccessnetwork,演进式umts陆地无线接入网)202,epc(evolvedpacketcore,演进式分组核心网)203和运营商的ip业务204。具体地,ue201可以是上述终端100,此处不再赘述。e-utran202包括enodeb2021和其它enodeb2022等。其中,enodeb2021可以通过回程(backhaul)(例如x2接口)与其它enodeb2022连接,enodeb2021连接到epc203,enodeb2021可以提供ue201到epc203的接入。epc203可以包括mme(mobilitymanagemententity,移动性管理实体)2031,hss(homesubscriberserver,归属用户服务器)2032,其它mme2033,sgw(servinggateway,服务网关)2034,pgw(pdngateway,分组数据网络网关)2035和pcrf(policyandchargingrulesfunction,政策和资费功能实体)2036等。其中,mme2031是处理ue201和epc203之间信令的控制节点,提供承载和连接管理。hss2032用于提供一些寄存器来管理诸如归属位置寄存器(图中未示)之类的功能,并且保存有一些有关服务特征、数据速率等用户专用的消息。所有用户数据都可以通过sgw2034进行发送,pgw2035可以提供ue201的ip地址分配以及其它功能,pcrf2036是业务数据流和ip承载资源的策略与计费控制策略决策点,它为策略与计费执行功能单元(图中未示)选择及提供可用的策略和计费控制决策。ip业务204可以包括因特网、内联网、ims(ipmultimediasubsystem,ip多媒体子系统)或其它ip业务等。虽然上述以lte系统为例进行了介绍,但本领域技术人员应当知晓,本发明不仅仅适用于lte系统,也可以适用于其他无线通信系统,例如gsm、cdma2000、wcdma、td-scdma以及未来新的网络系统等,此处不做限定。基于上述移动终端硬件结构以及通信网络系统,提出本发明方法各个实施例。实施例一如图3所示,本发明实施例一提出一种storm权限管控的系统,该系统包括sdk管控组件110、调度中心(dispatchcenter,dc)组件120以及拓扑管控(topologycontrolplatform,tcp)组件130以及api查询组件140。其中,sdk管控组件110主要用于接受业务方使用软件开发工具包sdk进行拓扑的创建,并在业务方创建拓扑时对拓扑的配置参数进行统一管理,主要包括拓扑名称、drpc标识、持久化时的数据库表名或高速缓存的键名以及拓扑对象,更具体地将实现如图4所示的流程:节点201:main方法统一化;只提供唯一的入口方法供业务方使用,并用于对接调度中心组件120;main方法需要接受一个json字符串参数,传入调度中心组件120的业务空间参数。节点202:参数解析;负责解析main入口的json字符串以及业务方输入的参数,再将各值赋给sdk内置参数,drpc标识可以由用户选择是否传入。节点203:drpc检查;当要使用drpc服务时,确认drpc名称不为空,且spout(拓扑组件)必须包含drpcspout。节点204:组件名称规范化;对于业务方创建的拓扑的拓扑名称和drpc标识按照调度中心组件120的业务空间的具体格式统一规范化调整。节点205:持久化工具封装;对用户配置的持久化工具的库名或缓存的键名进行约束,使用调度中心组件120给定的业务空间名称字段值。节点206:权限验证;在拓扑提交时进行权限验证,该验证过程是从拓扑管控组件130的缓存中取出对应的业务空间名和数据库名或缓存的键名进行匹配,必须是经过管理员授权,才能在调度中心组件120中正常提交拓扑,否则直接抛出运行时错误。节点207:drpc封装:为减小storm集群负担,使drpc实现实时查询功能。业务方直接调用该封装工具,无需编码。调度中心组件120主要用于向storm集群打包上传该拓扑,并为该拓扑分配独立的业务空间。具体体现为:向storm集群提交拓扑资源,具有业务空间属性,能在界面上配置拓扑的参数,能够向拓扑管控组件130的相应领域空间传递实时计算资源。更具体地将实现以下功能:1.业务空间管理功能:业务空间指为具体业务所开辟的隔离空间,不同业务之间在未得到tcp授权时无法互相访问。其中包含了拓扑的创建、编辑与删除等任务操作、可用的数据库资源和缓存资源以及业务方提交的拓扑资源;2.拓扑参数配置功能:用户自定义拓扑构建类在打成jar包中的位置,拓扑名,drpc标识名以及用户自定义参数,这些参数会根据具体所在的业务空间进行重新命名;3.实时计算资源传递功能:将重新命名后的拓扑名,drpc标识名在拓扑提交成功时作为实时计算资源传递到拓扑管控组件130。拓扑管控组件130主要用于为该业务方分配相应的业务空间的操作权限,并接受该业务方在业务空间中对空间内资源进行相应的权限操作。具体体现为:管控业务方是否具有对业务空间中资源操作权限,是否具有drpc查询权限以及领域管理。更具体地将实现以下功能:1.业务空间资源管控功能:当业务方需要使用对应业务空间的数据库、缓存、文件等资源时,需要由管理员授予操作权限,其权限包括增、删、改、查。其操作将形成操作日志进入监控供管理员查看。2.drpc查询权限管控功能:管理员具备所有包含有drpcspout组件的拓扑的密钥,当业务方需要进行drpc查询时,管理员将在拓扑管控组件130中与调度中心组件120的业务空间对应的领域创建桥接服务,并填入私钥,公钥则交给业务方,业务方使用桥接服务来访问能够公私钥配对的drpc查询服务。另外,管理员能够删除领域中的桥接服务。3.领域管理功能:领域是与dc的业务空间对应的一个集合,其中存有业务方提交的拓扑、关联数据库、关联缓存、关联文件、拓扑状态、日志监控、访问峰值等信息。管理员能够根据实际情况通知dc修改拓扑状态(激活、冻结、重新分配资源和杀死)。api查询组件140主要用于接受业务方使用应用程序编程接口api发出drpc请求,查询相应的拓扑,并实时计算反馈请求结果。具体体现为:查询用户提交的带有drpcspout组件的拓扑,具有业务空间属性,缓存有drpc连接对象,能够在业务方请求时进行业务隔离。更具体地将实现如图5所示的流程:节点301:drpc标识业务化;对于不同的业务空间,具有其唯一的标识方式,因此将业务方用于请求的drpc按照业务空间唯一标识进行业务化,即重新命名后再对该drpc标识授予业务空间权限。不同业务空间无法互相访问,而相同业务空间的业务需要管理员授权才能被业务方访问。节点302:权限验证;主要是验证业务方是否具有请求某drpc标识对应的拓扑的权限。节点303:检查缓存中是否存在drpc连接对象:根据drpc标识从缓存中查找是否存在匹配的drcp连接对象。存在则进入节点305,能够快速实现drpc请求;不存在则进入节点304,创建一个新的连接。节点304:创建drpc连接对象放入缓存:将较为耗时的创建drpc连接作为一次性任务放入缓存中。如果创建成功则进入节点306;如果storm集群的drpc服务未启动,或网络原因导致超时等造成的创建失败则直接抛出error错误。节点305:判断连通性:由于storm集群存在被重启的可能性,也即drpc服务重启后缓存中保存的drpc连接对象则失效了。当其失效即管道破损时应该迅速重建连接,到步骤节点304;否则,进入节点306。节点306:向drpc服务发送请求:将http请求中的参数传递给带有具体drpc标识的拓扑。由于drpc主要优点是实时请求,当请求等待超过指定时间,则需要释放占用的资源,即抛出error错误;否则正常响应,并给出请求结果。这样一来,从整体上贯穿sdk管控组件110、调度中心组件120、拓扑管控组件130以及api查询组件140之间的数据交互关系,具体如图3所示:图示箭头1:权限验证;该过程对应图6中的节点206,业务方当需要对调度中心组件120的业务空间的数据库、缓存或文件等资源进行操作时,需要向拓扑管控组件130提出权限验证。图示箭头2:授权标志;该过程是拓扑管控组件130对业务方进行权限验证,具体验证方式是视管理定义的规则而定,当管理员允许业务方操作业务空间资源时则进行授权并返回授权标志为true,否则授权标志位false。图示箭头3:打包上传;当业务方使用sdk创建了拓扑后则将拓扑打包为jar文件上传至调度中心组件120的业务空间,并在调度中心组件120的交互界面上填写拓扑参数,最终触发执行该jar文件。调度中心组件120对业务方传入的拓扑参数进行配置,对应调度中心组件120的拓扑参数配置功能,进而将配置好的拓扑参数传递给sdk形成完整的拓扑。图示箭头4:提交拓扑;在业务方触发执行jar文件后,仅当授权标志位true时,调度中心组件120才将jar提交至storm集群,storm集群会解析拓扑参数。否则抛出运行时错误。图示箭头5:提交标志;storm在解析完拓扑参数后将会返回拓扑是否正常提交的提交标志,正常提交返回true,错误返回false。图示箭头6:传递实时计算资源;该过程对应调度中心组件120的实时计算资源传递功能,只有提交标识为true才能够进行传递实时计算资源。图示箭头7:修改拓扑;该过程对应拓扑管控组件130的领域管理功能,由于tcp领域是映射到调度中心组件120的业务空间。因此拓扑管控组件130进行领域管理实际上是对调度中心组件120的业务空间资源进行操作。图示箭头8:http请求;业务方以http请求的方式向api查询组件140发起请求服务。图示箭头9:权限验证;该过程对应api查询组件140的权限验证功能,业务方仅能够向一种业务空间的一个拓扑资源进行请求,因此拓扑管控组件130需要验证该业务空间是否具有该拓扑资源的操作权限。图示箭头10:权限标志;拓扑管控组件130验证业务方具备请求的拓扑资源权限,则允许api查询组件140发送drpc请求到storm集群。图示箭头11:drpc查询;api查询组件140发送drpc请求到storm集群,由集群的drpc服务进行处理。图示箭头12:返回结果;无论drpc服务处理成功与否,都将返回结果信息给业务方。如图6所示,本发明实施例二提出一种拓扑创建管控的方法,该方法具体包括以下步骤:步骤s110:提供唯一的数据接入方式供业务方进行拓扑的前期创建。具体地,本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上进行实现,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,业务方在拓扑创建(编码)阶段,必须使用系统提供的软件开发工具包(softwaredevelopmentkit,sdk)进行数据访问,该sdk能够获取业务方的配置信息,并提供统一的业务数据库,同时,根据不同的业务对拓扑名称和drpc标识进行规范化管理。这样一来,整个步骤流程如图7所示,包括:步骤s111:接受业务方通过唯一的数据入口创建拓扑的框架。具体地,在拓扑创建(编码)阶段,业务方必须使用提供的软件开发工具包sdk进行行数据访问,此时,软件开发工具包sdk提供唯一的数据入口供业务方进行拓扑的框架创建。即提供唯一的入口方法供业务方使用,整个拓扑的框架创建流程对应图4所示节点201:main方法统一化;详情见实施例一中的相关表述。步骤s112:对创建得到的拓扑的框架进行参数解析,以完成该拓扑的前期创建。具体地,当业务方通过sdk提供的唯一数据入口将拓扑的框架创建完成后,需对创建得到的拓扑的框架进行参数解析,才可完成该拓扑的前期创建。即解析数据入口的字符串以及用户输入的参数,再将各值赋给sdk内置参数。整个参数解析流程对应图4所示节点202:参数解析;详情见实施例一中的相关表述。通过参数解析,将拓扑的配置参数写入拓扑的框架中,完成拓扑的前期创建。步骤s113:接受业务方传入拓扑的远程过程调用drpc标识。具体地,根据实际情况,drpc标识可以由业务方选择是否传入。而为了便于后期对该拓扑进行分布式的远程过程调用(distributedremoteprocedurecall,drpc),业务方则需在对创建得到的拓扑的框架进行参数解析后,传入拓扑的远程过程调用drpc标识。步骤s114:对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。具体地,当业务方后期要对该拓扑要使用drpc服务时,需确认drpc名称不为空,且该拓扑必须包含drpc入口(drpcspout)。因而,需对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。整个drpc检查流程对应图4所示节点203:drpc检查;详情见实施例一中的相关表述。步骤s120:在该拓扑的前期创建完成后,进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,调度中心组件120会在该拓扑的前期创建完成后,给该拓扑分配相应的业务空间,业务方提交拓扑仅能在相应的业务空间进行提交。因而,在该拓扑的前期创建完成后,需进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。整个流程具体如图8所示,包括:步骤s121:在该拓扑的前期创建完成后,按分配给该拓扑的业务空间名进一步对所述拓扑的拓扑名称及drpc标识进行规范化调整。具体地,在该拓扑的前期创建完成后,调度中心组件120会给该拓扑分配相应的业务空间,该业务空间具有特定的业务空间名,然后,按分配给该拓扑的业务空间名进一步对该拓扑的拓扑名称及drpc标识进行规范化调整。整个规范化流程对应图4所示节点204:组件名称规范化;详情见实施例一中的相关表述。步骤s122:使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。具体地,使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。整个持久化工具封装流程对应图4所示节点205:持久化工具封装;详情见实施例一中的相关表述。步骤s130:在对该拓扑进行提交时,对该拓扑进行权限验证,仅在该拓扑通过权限验证后成功提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,整个权限验证流程如下:从(拓扑管控组件130)缓存中取出与该拓扑对应的该业务空间名,以及该数据库名或该缓存的键名进行匹配,仅在匹配通过后通过管理员授权,成功(在调度中心组件120上)提交该拓扑。该流程对应图4所示节点206:权限验证;详情见实施例一中的相关表述。另外,如图9所示,该拓扑创建管控的方法还包括以下步骤:步骤s140:对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。具体地,当业务方在前述步骤中,给该拓扑传入drpc标识,则此时,在该拓扑成功提交后,还需对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。即业务方此时方可使用drpc服务。这样一来,通过drpc实现实时查询功能,可减小storm集群负担。drpc封装时,业务方只需直接调用相应的封装工具,无需编码。步骤s150:接受业务方使用应用程序编程接口api发出drpc请求,查询相应的该拓扑,并实时计算反馈请求结果。具体地,业务方使用应用程序编程接口(applicationprogramminginterface,api)发出drpc请求,整个流程具体如3所示的箭头8-12以及图5所示,主要查询用户提交的带有drpcspout组件的拓扑,具有业务空间属性,缓存有drpc连接对象,能够在业务方请求时进行业务隔离。具体过程包括:验证业务方是否具有请求某drpc标识对应的拓扑的权限;将较为耗时的创建drpc连接作为一次性任务放入缓存中;将http请求中的参数传递给带有具体drpc标识的拓扑。由于drpc主要优点是实时请求,当请求等待超过指定时间,则需要释放占用的资源,即抛出error错误;否则正常响应,并给出请求结果。实施例三如图10所示,本发明实施例三提出一种服务器20,该服务器20包括存储器21、处理器22、存储在该存储器上并可在该处理器上运行的程序以及用于实现处理器21和存储器22之间的连接通信的数据总线23,该程序被该处理器执行时,以实现以下如图6所示的具体步骤:步骤s110:提供唯一的数据接入方式供业务方进行拓扑的前期创建。具体地,本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上进行实现,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,业务方在拓扑创建(编码)阶段,必须使用系统提供的软件开发工具包(softwaredevelopmentkit,sdk)进行数据访问,该sdk能够获取业务方的配置信息,并提供统一的业务数据库,同时,根据不同的业务对拓扑名称和drpc标识进行规范化管理。这样一来,整个步骤流程如图7所示,包括:步骤s111:接受业务方通过唯一的数据入口创建拓扑的框架。具体地,在拓扑创建(编码)阶段,业务方必须使用提供的软件开发工具包sdk进行行数据访问,此时,软件开发工具包sdk提供唯一的数据入口供业务方进行拓扑的框架创建。即提供唯一的入口方法供业务方使用,整个拓扑的框架创建流程对应图4所示节点201:main方法统一化;详情见实施例一中的相关表述。步骤s112:对创建得到的拓扑的框架进行参数解析,以完成该拓扑的前期创建。具体地,当业务方通过sdk提供的唯一数据入口将拓扑的框架创建完成后,需对创建得到的拓扑的框架进行参数解析,才可完成该拓扑的前期创建。即解析数据入口的字符串以及用户输入的参数,再将各值赋给sdk内置参数。整个参数解析流程对应图4所示节点202:参数解析;详情见实施例一中的相关表述。通过参数解析,将拓扑的配置参数写入拓扑的框架中,完成拓扑的前期创建。步骤s113:接受业务方传入拓扑的远程过程调用drpc标识。具体地,根据实际情况,drpc标识可以由业务方选择是否传入。而为了便于后期对该拓扑进行分布式的远程过程调用(distributedremoteprocedurecall,drpc),业务方则需在对创建得到的拓扑的框架进行参数解析后,传入拓扑的远程过程调用drpc标识。步骤s114:对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。具体地,当业务方后期要对该拓扑要使用drpc服务时,需确认drpc名称不为空,且该拓扑必须包含drpc入口(drpcspout)。因而,需对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。整个drpc检查流程对应图4所示节点203:drpc检查;详情见实施例一中的相关表述。步骤s120:在该拓扑的前期创建完成后,进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,调度中心组件120会在该拓扑的前期创建完成后,给该拓扑分配相应的业务空间,业务方提交拓扑仅能在相应的业务空间进行提交。因而,在该拓扑的前期创建完成后,需进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。整个流程具体如图8所示,包括:步骤s121:在该拓扑的前期创建完成后,按分配给该拓扑的业务空间名进一步对所述拓扑的拓扑名称及drpc标识进行规范化调整。具体地,在该拓扑的前期创建完成后,调度中心组件120会在,给该拓扑分配相应的业务空间,该业务空间具有特定的业务空间名,然后,按分配给该拓扑的业务空间名进一步对该拓扑的拓扑名称及drpc标识进行规范化调整。整个规范化流程对应图4所示节点204:组件名称规范化;详情见实施例一中的相关表述。步骤s122:使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。具体地,使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。整个持久化工具封装流程对应图4所示节点205:持久化工具封装;详情见实施例一中的相关表述。步骤s130:在对该拓扑进行提交时,对该拓扑进行权限验证,仅在该拓扑通过权限验证后成功提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,整个权限验证流程如下:从(拓扑管控组件130)缓存中取出与该拓扑对应的该业务空间名,以及该数据库名或该缓存的键名进行匹配,仅在匹配通过后通过管理员授权,成功(在调度中心组件120上)提交该拓扑。该流程对应图4所示节点206:权限验证;详情见实施例一中的相关表述。另外,如图9所示,该拓扑创建管控的方法还包括以下步骤:步骤s140:对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。具体地,当业务方在前述步骤中,给该拓扑传入drpc标识,则此时,在该拓扑成功提交后,还需对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。即业务方此时方可使用drpc服务。这样一来,通过drpc实现实时查询功能,可减小storm集群负担。drpc封装时,业务方只需直接调用相应的封装工具,无需编码。步骤s150:接受业务方使用应用程序编程接口api发出drpc请求,查询相应的该拓扑,并实时计算反馈请求结果。具体地,业务方使用应用程序编程接口(applicationprogramminginterface,api)发出drpc请求,整个流程具体如3所示的箭头8-12以及图5所示,主要查询用户提交的带有drpcspout组件的拓扑,具有业务空间属性,缓存有drpc连接对象,能够在业务方请求时进行业务隔离。具体过程包括:验证业务方是否具有请求某drpc标识对应的拓扑的权限;将较为耗时的创建drpc连接作为一次性任务放入缓存中;将http请求中的参数传递给带有具体drpc标识的拓扑。由于drpc主要优点是实时请求,当请求等待超过指定时间,则需要释放占用的资源,即抛出error错误;否则正常响应,并给出请求结果。实施例四本发明实施例四提出一种计算机可读存储介质,该计算机可读存储介质存储有一个或者多个程序,该一个或者多个程序可被一个或者多个处理器执行,以实现以下如图6所示的具体步骤:步骤s110:提供唯一的数据接入方式供业务方进行拓扑的前期创建。具体地,本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上进行实现,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,业务方在拓扑创建(编码)阶段,必须使用系统提供的软件开发工具包(softwaredevelopmentkit,sdk)进行数据访问,该sdk能够获取业务方的配置信息,并提供统一的业务数据库,同时,根据不同的业务对拓扑名称和drpc标识进行规范化管理。这样一来,整个步骤流程如图7所示,包括:步骤s111:接受业务方通过唯一的数据入口创建拓扑的框架。具体地,在拓扑创建(编码)阶段,业务方必须使用提供的软件开发工具包sdk进行行数据访问,此时,软件开发工具包sdk提供唯一的数据入口供业务方进行拓扑的框架创建。即提供唯一的入口方法供业务方使用,整个拓扑的框架创建流程对应图4所示节点201:main方法统一化;详情见实施例一中的相关表述。步骤s112:对创建得到的拓扑的框架进行参数解析,以完成该拓扑的前期创建。具体地,当业务方通过sdk提供的唯一数据入口将拓扑的框架创建完成后,需对创建得到的拓扑的框架进行参数解析,才可完成该拓扑的前期创建。即解析数据入口的字符串以及用户输入的参数,再将各值赋给sdk内置参数。整个参数解析流程对应图4所示节点202:参数解析;详情见实施例一中的相关表述。通过参数解析,将拓扑的配置参数写入拓扑的框架中,完成拓扑的前期创建。步骤s113:接受业务方传入拓扑的远程过程调用drpc标识。具体地,根据实际情况,drpc标识可以由业务方选择是否传入。而为了便于后期对该拓扑进行分布式的远程过程调用(distributedremoteprocedurecall,drpc),业务方则需在对创建得到的拓扑的框架进行参数解析后,传入拓扑的远程过程调用drpc标识。步骤s114:对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。具体地,当业务方后期要对该拓扑要使用drpc服务时,需确认drpc名称不为空,且该拓扑必须包含drpc入口(drpcspout)。因而,需对该拓扑进行drpc检查,以确认drpc标识的名称是否为空以及该拓扑是否包含drpc入口。整个drpc检查流程对应图4所示节点203:drpc检查;详情见实施例一中的相关表述。步骤s120:在该拓扑的前期创建完成后,进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,调度中心组件120会在该拓扑的前期创建完成后,给该拓扑分配相应的业务空间,业务方提交拓扑仅能在相应的业务空间进行提交。因而,在该拓扑的前期创建完成后,需进一步对该拓扑的配置参数进行规范化管理,以在该配置参数规范化后提交该拓扑。整个流程具体如图8所示,包括:步骤s121:在该拓扑的前期创建完成后,按分配给该拓扑的业务空间名进一步对所述拓扑的拓扑名称及drpc标识进行规范化调整。具体地,在该拓扑的前期创建完成后,调度中心组件120会在,给该拓扑分配相应的业务空间,该业务空间具有特定的业务空间名,然后,按分配给该拓扑的业务空间名进一步对该拓扑的拓扑名称及drpc标识进行规范化调整。整个规范化流程对应图4所示节点204:组件名称规范化;详情见实施例一中的相关表述。步骤s122:使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。具体地,使用该业务空间名给定的名称字段值,对业务方配置的持久化工具的数据库名或缓存的键名进行约束,完成该拓扑的持久化工具封装。整个持久化工具封装流程对应图4所示节点205:持久化工具封装;详情见实施例一中的相关表述。步骤s130:在对该拓扑进行提交时,对该拓扑进行权限验证,仅在该拓扑通过权限验证后成功提交该拓扑。具体地,由于本实施例中的拓扑创建管控的方法,其主要是在实施一中的storm权限管控的系统的基础上来实现的,由实施例一的描述可知,该系统包括sdk管控组件110、调度中心组件120,拓扑管控组件130以及api查询组件140。基于上面提到的系统,整个权限验证流程如下:从(拓扑管控组件130)缓存中取出与该拓扑对应的该业务空间名,以及该数据库名或该缓存的键名进行匹配,仅在匹配通过后通过管理员授权,成功(在调度中心组件120上)提交该拓扑。该流程对应图4所示节点206:权限验证;详情见实施例一中的相关表述。另外,如图9所示,该拓扑创建管控的方法还包括以下步骤:步骤s140:对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。具体地,当业务方在前述步骤中,给该拓扑传入drpc标识,则此时,在该拓扑成功提交后,还需对该拓扑进行drpc封装,使该拓扑激活drpc实时查询功能。即业务方此时方可使用drpc服务。这样一来,通过drpc实现实时查询功能,可减小storm集群负担。drpc封装时,业务方只需直接调用相应的封装工具,无需编码。步骤s150:接受业务方使用应用程序编程接口api发出drpc请求,查询相应的该拓扑,并实时计算反馈请求结果。具体地,业务方使用应用程序编程接口(applicationprogramminginterface,api)发出drpc请求,整个流程具体如3所示的箭头8-12以及图5所示,主要查询用户提交的带有drpcspout组件的拓扑,具有业务空间属性,缓存有drpc连接对象,能够在业务方请求时进行业务隔离。具体过程包括:验证业务方是否具有请求某drpc标识对应的拓扑的权限;将较为耗时的创建drpc连接作为一次性任务放入缓存中;将http请求中的参数传递给带有具体drpc标识的拓扑。由于drpc主要优点是实时请求,当请求等待超过指定时间,则需要释放占用的资源,即抛出error错误;否则正常响应,并给出请求结果。本发明实施例提出的一种拓扑创建管控的方法、装置及存储介质,其提供唯一的数据接入方式供业务方进行拓扑的前期创建,并在拓扑的前期创建完成后,进一步对拓扑的配置参数进行规范化管理,以在配置参数规范化后提交拓扑,最后,在对拓扑进行提交时,对拓扑进行权限验证,仅在拓扑通过权限验证后成功提交拓扑。这样一来,其通过强制业务方必须使用提供的软件开发工具包sdk进行数据访问,以在拓扑提交前就进行数据权限管理,且相比于原生storm模式中,拓扑由业务方控制,其能够将拓扑创建从storm集群分离出来,使管理员能够充分管控业务方的配置项和参数,保证了storm集群的稳定性以及不同业务方之间的数据安全性。需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的
技术领域
:,均同理包括在本发明的专利保护范围内。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1