一种超融合架构下的异构GIS平台服务中控***
技术领域
本发明涉及服务中控领域,更具体地说,涉及一种超融合架构下的异构GIS平台服务中控***。
背景技术
伴随着互联网技术的飞速发展,大量的应用相继涌出,并且都是以交互式、大用户量的应用为主,其主要模型一般是B/S、C/S,面对大用户量所带来的承载压力,由数量众多的高性能服务器组成的大规模服务器集群成为承载***的关键。目前,大规模服务器集群所包含的服务器数量成千上万,随着应用的复杂化,大规模服务器集群已经向混杂模式发展,即单一服务器有可能提供了多个不同的服务,不同的服务器也有可能采用了不同的操作***。然而,在现阶段,仍然是通过SSH、VNC等方式对大规模服务器集群进行控制,这种传统的控制方法通过VNC远程连接或者通过SSH进入目标主机,然后输入控制指令实现对目标主机的控制,其主要的不足是:不能屏蔽服务器之间操作***的差异,移植性差;对服务器进行单独控制,效率极低。即在一个项目中会存在多套GIS服务引擎,但是实际每家GIS都有自己擅长的领域,在项目中存在特定业务的优势,目前的技术没有考虑适配多个GIS引擎,兼顾众家所长,构建统一的管理能力。
发明内容
本发明要解决的技术问题在于,针对现有技术未能实现同一套服务中控接口适配所有已知GIS服务厂商的接口和功能的缺陷,提供一种超融合架构下的异构GIS平台服务中控***。
本发明解决其技术问题所采用的技术方案是:构造一种超融合架构下的异构GIS平台服务中控***,包括多个用于调用服务中控***进行GIS服务运维管理的业务应用***,所述异构GIS平台服务中控***还包括:
服务中控***,用于设置多种GIS服务接入方式,进行GIS服务引擎***的接入,包括在第一接入方式下根据服务中控***提供的GIS服务模板包进行服务包的构建,待构建得到的服务包上传到服务中控***进行相应服务类型的注册后,从而完成服务包的接入;或者在第二接入方式下,基于接收到的服务中控接入申请,调用Server服务器进行接口验证,从而完成Server服务器的接入;其中,由所述服务中控***完成了相应类型的GIS服务接入后,还包括进行GIS服务的运维管理;
所述异构GIS平台服务中控***还包括GIS服务引擎***,所述GIS服务引擎***包括多个GIS服务引擎,用于为所述异构GIS平台服务中控***提供底层GIS服务的构建。
进一步的,所述GIS服务的运维管理包括:
由所述服务中控***对接入的GIS服务进行发布、管理、监控和统计。
进一步的,在第一接入方式下所述根据服务中控***提供的GIS服务模板包进行服务包的构建,待构建得到的服务包上传到服务中控***进行相应服务类型的注册具体为:
由GIS服务引擎***根据服务中控***提供的GIS服务模板包,进行服务包的定制开发或改造,使得对应服务类型能够被服务中控识别到;
构建得到的服务包通过服务中控的API接口进行注册,从而完成定制服务包的接入。
进一步的,第一接入方式下当根据预先设置的涉密数据和涉密操作判断标准,判断当前接入的GIS服务包括涉密数据或涉密操作时,通过镜像构建工具将第一接入方式下生成的服务包制作成Docker容器镜像;其中,生成的Docker容器镜像将注册到镜像仓库,进行统一管理;
当由服务中控***发起包括涉密数据或涉密操作服务的指令时,由服务中控***直接调用容器管理软件的通讯接口,后续由容器管理软件来调用镜像仓库中对应的容器镜像,完成容器的投递并生成服务即完成了服务镜像的接入。
进一步的,在第二接入方式下,所述调用Server服务器进行接口验证,从而完成Server服务器的接入具体为:
当所述服务中控***接收到服务中控接入请求后,通过获取访问权限参数来验证请求的合法性,在准许接入Server服务器的情况下,调用Server服务器的Rest-API接口并配置接入信息所必须的参数,完成Server服务器的接入。
进一步的,当准许接入的情况下,所述调用Server服务器的Rest-API接口具体为:
根据接口接入规范,对待接入Server服务器的manage接口进行改造;
通过服务中控***的API接口,将改造所得manage接口注册到服务中控***;
当完成manage接口的注册和验证后,进行服务中控***的Server Manage接口层关联;其中,当服务中控***接收到发布服务的指令后,首先调用manage接口实现对第三方Server服务器的调用,然后再完成对相关类型的服务发布。
进一步的,完成了相关类型的服务发布后还包括:
生成的服务将注册到API网关,由API网关进行反向代理、负载均衡和
监控。
进一步的,注册的接口类型包括:
用于提供GIS服务发布或更新GIS服务操作的服务发布类接口;
用于提供GIS服务管理的服务管理类接口;
用于提供服务运行状态、服务器状态和集群节点监控的服务监控类接口;
用于提供记录Server服务器管理操作日志的管理日志类接口。
进一步的,所述服务中控***下以微服务的形态,将不同类别的GIS服务引擎注册到服务中控***,实现各GIS服务引擎的独立部署以及服务器资源有效隔离。
进一步的,基于JavaWeb对各GIS服务引擎的底层接口差异化和功能底层差异化进行适配,以及统一了对外访问的服务地址,所述服务地址包含两级标识服务地址,其结构具体为:http://IP:端口/地方标识/服务引擎标识/服务名字/;其中:服务引擎标识为服务中控***控制,由枚举产生。
实施本发明的一种超融合架构下的异构GIS平台服务中控***,具有以下有益效果:
1、采用微服务架构,实现各GIS服务引擎的独立部署、灵活扩展,以微服务的形态注册到服务中控***,从而实现各GIS服务引擎的服务器资源有效隔离,且通过服务治理又可统一调度、管理、弹性伸缩等能力;
2、服务运行所需服务器资源由平台统一管理,提供智能分配和弹性伸缩的能力;且,当某个服务引擎崩溃或宕机,服务中控可立即实现弹性扩展该节点的负载均衡节点,以达到保障平台正常运行;
3、设置了基于服务模板包、服务镜像、服务器Server三种方式的接入标准,各大GIS服务厂商可根据自身的实际情况选择最合适的方式接入平台。
附图说明
下面将结合附图及实施例对本发明作进一步说明,附图中:
图1是本发明的一种超融合架构下的异构GIS平台服务中控***的***结构图;
图2是本发明的一种超融合架构下的异构GIS平台服务中控***的功能结构图;
图3是第一接入方式的执行流程图;
图4是第二接入方式的执行流程图;
图5是注册接口类型的列表示意图;
图6是不同接入方式对应的应用场景以及优势的列表示意图。
具体实施方式
为了对本发明的技术特征、目的和效果有更加清楚的理解,现对照附图详细说明本发明的具体实施方式。
本发明的一个实施例,如图1所示,一种超融合架构下的异构GIS平台服务中控***包括:
(1)多个用于调用服务中控***进行GIS服务运维管理的业务应用系
统;具体的,业务***的执行功能也可理解为现实生活中对于的业务处理工作,比如房地产确权登记流程处理、武汉市气象预警分析等等。需要说明的是,当相应类型的服务已经完成发布的情况下,由对应的业务应用***调用服务中控***中已经发布、共享出来的服务进行业务集成,其中,由图1所示,一实施例中可采用统一服务发布管理和统一运维管理***,进行服务的发布和运维管理。
服务中控***,其用于设置多种GIS服务接入方式,进行GIS服务引擎***的接入,包括在第一接入方式下根据服务中控***提供的GIS服务模板包进行服务包的构建,待构建得到的服务包上传到服务中控***进行相应服务类型的注册后,从而完成服务包的接入;或者在第二接入方式下,基于接收到的服务中控接入申请,调用Server服务器进行接口验证,从而完成Server服务器的接入;其中,由所述服务中控***完成了相应类型的GIS服务接入后,还包括进行GIS服务的运维管理;一实施例中,前述的运维管理,具体为由服务中控***对接入的GIS服务进行发布、管理、监控和统计。
需要说明的是,由于每一个第三方服务注册到服务中控***是有对应的注册类型,例如地图服务、专题图服务类型,现以一个具体的实例进行说明:
顺丰的GIS服务注册到服务中控***,其对应的注册类型就是地名、地址类服务,后续在进行GIS服务的运维管理时,都是会根据注册类型进行专项管理。
请参考图3,其为第一接入方式的执行流程图,在第一接入方式下通过定制服务模板包进行服务包的接入具体为:
首先,由GIS服务引擎***根据服务中控***提供的GIS服务模板包,进行服务包的定制开发或改造,使得对应服务类型能够被服务中控识别到;
其次,待生成的服务包通过服务中控的API接口上传到服务中控***,完成相应服务类型的注册后,从而完成定制服务包的接入,最终在进行GIS运维管理的时候,将由服务中控***完成对该类服务所有的发布、管理、负载均衡及运维监控等事宜。
如图4所示,其为第二接入方式的执行流程图,在调用Server服务器进行接口验证,从而完成Server服务器接入的时候包括:
首先,当所述服务中控***接收到服务中控接入请求(需说明的是,接入申请是由第三方用户向服务中控***发起的)后,获取访问权限参数,一实施例中,由于现在很多基于restful的api接口都有个登录的设计,也就是在发起正式的请求之前先通过一个登录的请求接口,申请一个叫做token的权限参数。申请成功后,后面其他的请求都需要带上这个token后缀,服务端通过获取这个token参数即可验证请求的合法性,因此,本实施例考虑获取“sc_token”,来确定请求的合法性;
其次,经服务中控***审核通过,在准许GIS服务接入的情况下,调用server服务器的Rest-API接口并配置接入信息所必须的参数,从而完成Server服务器的接入。其中,当准许接入的情况下,根据接口接入规范(一实施例中,可为《Manage API接入规范》),对待接入Server服务器的manage接口进行定制开发或改造;接着,通过服务中控***的API接口,将改造所得manage接口注册到服务中控***;需要说明的是,注册的接口类型可参考图5,具体包括:
(21)用于提供GIS服务发布前的前置操作和条件验证的服务前置类接口,一实施例中,前置操作包括文件上传、数据源的查询、判断服务器资源是否充足;
(22)用于提供GIS服务发布或更新GIS服务操作的服务发布类接口;
(23)用于提供GIS服务的编辑、启动、停止、删除和克隆等操作的服务管理类接口;
(24)用于提供服务运行状态、服务器状态和集群节点监控的服务监控类接口;需要说明的是,当前的服务器可以理解为硬件服务器,比如A服务运行在甲服务器上,前述的服务器状态监控即监控甲服务器的CPU、内存、磁盘占用等情况,进一步为服务中控***的弹性伸缩、负载均衡等能力提供阀值判断的参考依据;
(25)用于提供server 服务器操作权限控制的安全验证类接口;
(26)用于记录服务运行时日志信息(非访问日志)的服务日志类接口;
(27)用于记录server服务器管理操作的管理日志类接口。
需要说明的是,在进行接口注册的时候,服务发布类、服务管理类、服务监控类和管理日志类的接口是必须的,其余的接口可选择性的选择其中的一个或多个进行注册。
当完成manage接口的注册和验证后,还需要进行服务中控***的Server Manage接口层关联;可参考图2,整个***的功能结构分为三层,分别为:
API层,该层下包括服务监控、服务发布、服务权限、服务管理和统一运维这几个功能模块,其主要用于对外提供REST-API能力。其中,对外提供的REST API能力分为:服务的发布、管理、权限、监控和运维;因此,前述的进行GIS服务的运维管理即在这一层实现。
适配层,该功能层下包括注册中心、集约化中心、治理中心、网关中心和***配置这几个功能模块,其一方面用于解决与第三方GIS服务引擎的适配问题,具体的,包含注册接入的适配和接口集约化的适配,其中,基于JavaWeb对各GIS服务引擎的底层接口差异化和功能底层差异化进行适配,以及统一了对外访问的服务地址,所述服务地址包含两级标识服务地址,其结构具体为:http://IP:端口/地方标识/服务引擎标识/服务名字/...;其中:服务引擎标识为服务中控***控制,由枚举产生,如吉奥服务引擎为S1、ESRI服务引擎为S2、顺丰的服务引擎为S3、自定义服务(手机信令服务)为S4等等枚举得来,当前从URL层面实现了差异化屏蔽。需要说明的是,底层接口差异化和功能差异化的适配是通过规范文档,并结合市场现有的主流结构,本方案按照这个标准去接入调用,从而实现由服务中控***控制第三方服务的发布和管理等操作。另一方面用于提供服务治理、服务网关及***配置相关的功能;其中,由注册中心来实现第三方GIS服务引擎的注册、卸载和授权等接入功能(即前述的第一接入方式下的服务包接入和第一接入方式下的Server服务器接入都是在这一层实现的);由集约化中心将配置发布的服务类型匹配到对应的Server服务器,如将地图服务配置成GeoGlobe Server,则在进行地图服务发布时候,都是基于GeoGlobe Server进行地图服务而定发布;治理中心用于对外提供整合后的服务统一发布、管理、监控、授权、熔断、限流等功能;网关中心即为服务网关;***配置用于针对***本身的一些单点登录、权限等***内置相关级别的配置。
容器层,该层下包括反向代理、负载均衡、容器编排、镜像管理和弹性伸缩这几个功能模块,其主要用于提供各第三方服务引擎的服务运行环境管理和托管的能力(即后述的第二实施例下容器生成及镜像管理都是在这一层实现的)。
具体的,第二接入方式下,可理解为用户通过平台发起服务中控接入申请,经平台审核通过后,获取sc_token参数(即访问权限参数),在获准接入的情况下,再调用Rest-API接口和配置接入信息的必须参数,该种方案必须满足集成Server服务器接口规范;或可以考虑基于Server服务器对中控服务平台暴露的发布、管理接口,进行Server服务器的接入。最后,由中控服务平台对服务Server服务器通过接口调用实现服务的发布和管理。
在图2所示的功能架构下,当服务中控***接收到发布GIS服务的指令后,包括:
首先,调用manage接口实现对第三方Server 服务器的调用;
然后,再完成对相关类型的服务发布;
最后,生成的服务将注册到API网关,由API网关进行反向代理、负载
均衡和监控,这样第三方服务从发布、管理、监控、容灾完全托管于服务中控***,有效的提供了完整的管理、监控、运维等能力。另外,第二接入方式下,Server服务器是独立运行,不占用***资源。
(2)GIS服务引擎***,如图1所示,本发明公开的GIS服务引擎***
由多个GIS服务引擎构成,例如图1中所示的GeoGlobe服务引擎、ArcGIS服务引擎(需要说明的是,GeoGlobe服务引擎是武大吉奥信息技术有限公司研发的在网络环境下全球海量无缝空间数据组织、管理与可视化软件,ArcGIS服务引擎是ESRI公司的服务引擎),该引擎***的主要功能是为异构GIS平台服务中控***提供底层GIS服务的构建。
实施例2:
请参考图3,当根据预先设置的涉密数据和涉密操作判断标准,判断当前接入的GIS服务包括涉密数据或涉密操作时,通过镜像构建工具将第一接入方式下生成的服务包制作成Docker容器镜像,一实施例中,基于Dockerfile生成容器镜像,需要说明的是:Dockerfile是一个用来构建镜像的文本文件,文件中包括的文本内容为一条条构建镜像所需的指令和说明;其中,生成的Docker容器镜像将注册到镜像仓库,由镜像仓库进行统一管理;最后,当由服务中控***发起包括涉密数据或涉密操作服务的指令时,由服务中控***直接调用容器管理软件的通讯接口(需要说明的是基于当前的通讯接口,进行服务中控***与容器管理软件之间的集成调用,比如创建GIS服务运行所需的docker容器、容器集群等容器编排的能力接口),后续由容器管理软件来调用镜像仓库中对应的容器镜像,完成容器的投递并生成服务即完成了服务镜像的接入,一实施例中,采用K8S容器管理软件,该软件是一个全新的基于容器技术的分布式架构软件,在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。
具体的,在生成镜像服务的时候,由服务中控***直接调用K8S软件的通讯接入接口,后续由K8S软件来调用镜像仓库中预先注册好的镜像来完成容器的投递和服务的生成,其中,服务生成后将由API网关发现并自动注册代理和治理模块,进行反向代理、负载均衡、监控及治理等事宜。
请参考图6,其为不同接入方式对应的应用场景以及所具优势的列表示意图,在第一种接入方式即定制服务包接入方式下,其应用场景无限制,其优势在于和***的兼容性最高,且服务器资源统一由服务中控***进行管理,其提供了智能分配和弹性伸缩的能力。在制作服务镜像接入方式下,其应用场景对应含有产品授权的服务或含有涉密数据或涉密操作的服务,其优势在于,镜像内容为“黑盒”模式,可充分保护服务内涉密数据和涉密操作。集成Serve服务器的接入方式,其应用场景对应着完整的Server服务器体系且具有独立的服务编排机制或拥有10个以上的服务类型,其优势在于,Server服务器独立运行,且不占用服务中控***资源。
本发明的公开一种超融合架构下的异构GIS平台服务中控***,采用微服务架构,实现各GIS服务引擎的独立部署、灵活扩展,以微服务的形态注册到服务中控***,从而实现各GIS服务引擎的服务器资源有效隔离,且通过服务治理又可统一调度、管理、弹性伸缩等能力;服务运行所需服务器资源由平台统一管理,提供智能分配和弹性伸缩的能力;且,当某个服务引擎崩溃或宕机,服务中控可立即实现弹性扩展该节点的负载均衡节点,以达到保障平台正常运行;设置了基于服务模板包、服务镜像、服务器Server三种方式的接入标准,各大GIS服务厂商可根据自身的实际情况选择最合适的方式接入平台。
上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本发明的保护之内。