一种软件即服务平台的制作方法

文档序号:15099237发布日期:2018-08-04 15:19阅读:216来源:国知局

本发明涉及云计算应用技术领域,尤其涉及一种软件即服务平台。



背景技术:

软件即服务(Software-as-a-Service,SaaS),是一种通过互联网提供软件的模式。提供商将应用软件统一部署在自己的服务器上,客户根据自己的实际需求,通过互联网向提供商定购,相应获得所需的应用软件服务。

随着互联网技术的发展和应用软件的成熟,软件即服务这种全新的软件应用模式的兴起,使得用户不再像传统模式那样花费大量投资用于硬件、软件研发人员,而只需要支出一定的租赁服务费用,通过互联网便可以享受到相应的硬件、软件和维护服务,享有软件使用权和不断升级。

目前,国内较成熟的软件即服务平台,例如淘宝的开放平台和腾讯的微信开发者平台等,都能够提供软件应用的服务,客户可以根据自己实际需求,通过互联网向这些厂商定购所需的应用软件服务。然而上述软件即服务平台,都是由软件提供商来搭建一台平台集群。整个集群,需要软件提供商进行维护、更新,需要大量的时间和精力。

与此同时,随着电脑的更新换代和人们工作节奏的加快,越来越多的家用电脑处于闲置的状态,造成了大量的资源浪费。



技术实现要素:

本发明为解决现有技术中存在的问题,提供了一种软件及服务平台。

本发明提出一种软件即服务平台,包括应用管理层和核心调度层;所述应用管理层用于提供应用容器,以使得用户能够通过所述应用容器将所述平台提供的应用部署在任一主机上;所述应用容器为含有所述平台提供的应用和依赖包的可移植容器;所述核心调度层包括审核单元、查询单元和调度单元;所述审核单元用于审核完成部署的主机,并将审核通过的主机作为所述平台的节点;所述查询单元用于查询任一节点的节点状态;所述调度单元用于根据客户请求和各节点的节点状态为所述客户请求分配节点。

优选地,所述审核单元进一步用于:若完成部署的主机的物理资源符合预先设定的审核要求,则确认所述主机通过审核;所述物理资源包括处理器参数、内存容量和硬盘容量中的至少一种;将审核通过的主机作为所述平台的节点,并将所述节点加入负载列表。

优选地,所述查询单元进一步用于:向所述负载列表中的任一节点发送心跳包,并接收所述任一节点返回的节点状态,更新所述任一节点的节点状态;若在预设时间内未接收到所述任一节点返回的节点状态,则认为所述任一节点已关闭。

优选地,所述调度单元进一步用于:从所述客户请求中提取应用程序编程接口,从所述负载列表的各节点的节点状态中提取各节点的负载和资源使用情况;根据所述应用程序编程接口和各节点的负载和资源使用情况,从所述负载列表中选取所述应用程序编程接口对应的节点,并将应用所述节点执行所述客户请求。

优选地,还包括客户层,所述客户层与所述核心调度层电连接;所述客户层以应用程序编程接口的形式展示所述平台提供的应用,接收客户端发送的客户请求。

优选地,还包括计费层,所述计费层分别与所述客户层和核心调度层电连接;所述计费层对所述客户请求进行计费,并根据计费结果计算所述客户请求对应的节点的奖励金。

优选地,应用Docker将所述平台提供的应用和依赖包打包到所述应用容器中。

优选地,若所述查询单元向所述负载列表中的任一节点发送心跳包,连续预设次数在预设时间内未接收到所述任一节点返回的节点状态,则将所述任一节点从所述负载列表中移动到待激活列表。

优选地,所述审核单元还用于接收所述待激活列表中的节点发送的激活请求,审核所述节点,并将审核通过的节点从所述待激活列表移动到所述负载列表。

优选地,所述客户层根据历史分配记录将客户请求发送给对应的节点;所述历史分配记录中含有所述核心调度层根据所述客户请求分配的节点的记录。

本发明提供的一种软件即服务平台,主机通过下载应用容器部署应用并经过核心调度层审核后成为软件及服务平台的节点,通过对闲散主机资源的整合为平台提供大量节点,节省了平台的资金投入,同时,分布式节点将维护工作转移给申请人,降低了平台的时间和精力损耗,避免了闲置电脑的资源浪费。

附图说明

图1为本发明具体实施例的一种软件即服务平台的结构示意图;

图2为本发明具体实施例的一种软件即服务平台的结构示意图。

具体实施方式

下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。

图1为本发明具体实施例的一种软件即服务平台的结构示意图,如图1所示,一种软件即服务平台,包括应用管理层和核心调度层;所述应用管理层用于提供应用容器,以使得用户能够通过所述应用容器将所述平台提供的应用部署在任一主机上;所述应用容器为含有所述平台提供的应用和依赖包的可移植容器;所述核心调度层包括审核单元、查询单元和调度单元;所述审核单元用于审核完成部署的主机,并将审核通过的主机作为所述平台的节点;所述查询单元用于查询任一节点的节点状态;所述调度单元用于根据客户请求和各节点的节点状态为所述客户请求分配节点。

具体地,所述软件即服务平台,包括应用管理层和核心调度层。

其中,所述应用管理层用于提供应用容器,所述应用容器是含有所述软件即服务平台提供的应用以及相关依赖包的可移植容器。任一主机能够通过所述应用管理层下载所述应用容器,并通过所述应用容器快速部署所述软件即服务平台提供的应用。

所述任一主机完成部署后,向所述核心调度层的审核单元发出加入所述软件即服务平台的申请。所述审核单元接收到所述申请后,对所述任一主机进行审核,审核通过则将所述任一主机作为所述软件即服务平台的节点。

此外,所述核心调度层还包括查询单元和调度单元,所述查询单元用于对所述软件即服务平台下的各个节点的节点状态进行查询,此处的节点包括通过审核单元审核后加入所述软件即服务平台的主机。

所述调度单元接收到客户端发送的客户请求后,根据所述客户请求和查询获取的各个节点的节点状态,为所述客户请求分配对应的节点,并向所述客户请求对应的节点发送命令,以使得所述节点执行所述客户请求。

本发明具体实施例中,主机通过下载应用容器部署应用并经过核心调度层审核后成为软件及服务平台的节点,通过对闲散主机资源的整合为平台提供大量节点,节省了平台的资金投入,同时,分布式节点将维护工作转移给申请人,降低了平台的时间和精力损耗,避免了闲置电脑的资源浪费。

基于上述具体实施例,一种软件即服务平台,所述审核单元进一步用于:若完成部署的主机的物理资源符合预先设定的审核要求,则确认所述主机通过审核;所述物理资源包括处理器参数、内存容量和硬盘容量中的至少一种;将审核通过的主机作为所述平台的节点,并将所述节点加入负载列表。

具体地,任一主机完成部署后,向所述审核单元发出加入所述软件即服务平台的申请。

所述审核单元接收到所述申请后,采集所述任一主机的物理资源,并判断所述任一主机的物理资源是否符合预先设定的审核要求:

若所述任一主机的物理资源符合所述审核要求,则认为所述任一主机通过审核,将所述任一主机作为所述软件即服务平台的节点,并将所述节点计入负载列表,并记录所述节点的节点状态;

否则,认为所述任一主机未通过审核,将审核结果返回所述任一主机,拒绝所述任一主机加入所述软件即服务平台的请求。

此处,所述物理资源包括处理器参数、内存容量和硬盘容量中的至少一种。

本发明具体实施例中,通过对申请加入平台的主机的物理资源进行审核,避免了平台纳入物理资源较差的主机导致拖慢平台运行效率,保证了平台的高效运行。

基于上述任一具体实施例,一种软件即服务平台,所述查询单元进一步用于:向所述负载列表中的任一节点发送心跳包,并接收所述任一节点返回的节点状态,更新所述任一节点的节点状态;若在预设时间内未接收到所述任一节点返回的节点状态,则认为所述任一节点已关闭。

具体地,所述查询单元对所述软件即服务平台下的任一节点的节点状态进行查询,进一步包括:

首先,所述查询单元向所述负载列表中的任一节点发送心跳包;所述心跳包通常用于在客户端和服务器间,定时通知对方自己状态的一个自定义的命令字,按照一定的时间间隔发送。本发明具体实施例中,所述查询单元按照一定的时间间隔向所述任一节点发送心跳包。

所述任一节点接收到所述查询单元发送的心跳包后,向所述查询单元返回所述任一节点的节点状态。

所述查询单元接收到所述任一节点返回的节点状态后,更新所述任一节点的节点状态。

若所述查询单元向任一节点发送心跳包后,在预设时间内没有接收到所述任一节点返回的节点状态,则认为所述任一节点已断开,处于关闭状态。

上述方法为所述查询单元查询任一节点的节点状态,所述查询单元可以同时向各个节点发送心跳包,也可以对各个节点的节点状态进行轮询,但不限于此。

本发明具体实施例中,通过向任一节点发送心跳包查询所述任一节点的节点状态,获取平台中各个节点的节点状态,实现了平台对各个节点的节点状态的监测,保证了平台运行的稳定。

基于上述任一具体实施例,一种软件即服务平台,所述调度单元进一步用于:从所述客户请求中提取应用程序编程接口,从所述负载列表的各节点的节点状态中提取各节点的负载和资源使用情况;根据所述应用程序编程接口和各节点的负载和资源使用情况,从所述负载列表中选取所述应用程序编程接口对应的节点,并将应用所述节点执行所述客户请求。

具体地,调度单元接收到客户请求后,从所述客户请求中提取客户需要调用的应用程序编程接口。其中,所述应用程序编程接口(ApplicationProgrammingInterface,API)是一些预先定义的函数,其目的在于提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。

与此同时,所述调度单元从所述负载列表中的各节点的节点状态中对应提取各节点的负载和资源使用情况,其中,所述节点的负载是指节点的最大负荷量。根据各节点的负载和资源使用情况可以计算对应获取各节点当前可用的资源量。

所述调度单元根据客户需要调用的应用程序编程接口和各节点当前可用的资源量,通过计算获取所述负载列表中与所述应用程序编程接口对应的节点,并向所述节点发送命令,以使得所述节点执行所述客户请求。

本发明具体实施例中,根据客户请求和各节点的节点状态为所述客户请求分配对应的节点,避免了节点超负荷工作的问题,提供了平台的工作效率。

基于上述任一具体实施例,一种软件即服务平台,还包括客户层,所述客户层与所述核心调度层电连接;所述客户层以应用程序编程接口的形式展示所述平台提供的应用,接收客户端发送的客户请求。

具体地,所述软件即服务平台还包括客户层。客户可通过客户端或者其他第三方工具直接访问所述客户层。所述客户层直接面向客户,以应用程序编程接口的形式向客户展示所述软件即服务平台提供的应用,并接收客户端发送的客户请求,将所述客户请求发送给核心调度层。

基于上述任一具体实施例,一种软件即服务平台,还包括计费层,所述计费层分别与所述客户层和核心调度层电连接;所述计费层对所述客户请求进行计费,并根据计费结果计算所述客户请求对应的节点的奖励金。

具体地,所述软件即服务平台还包括计费层。所述计费层用于实现对客户请求的计费和对服务于所述客户请求的节点的奖励金的计算。

首先,计费层接收客户层发送的客户请求,对所述客户请求计费,并将计费结果返回提出所述客户请求的客户端。

随后,计费层通过核心调度层获取执行所述客户请求的节点,根据所述客户请求的计费结果计算所述节点对应的奖励金,并将所述奖励金发送给所述节点对应的账户。

本发明具体实施例中,通过计费层对所述客户请求计费并将相应的奖励金下发到节点,使得加入平台的主机不仅避免了闲置资源的浪费,还能够得到有效的回馈,有助于吸引更多的闲置资源加入软件即服务平台。

基于上述任一具体实施例,一种软件即服务平台,应用Docker将所述平台提供的应用和依赖包打包到所述应用容器中。

具体地,所述应用管理层提供的应用容器是含有所述软件即服务平台提供的应用以及相关依赖包的可移植容器。本发明具体实施例中,应用Docker将所述平台提供的应用和依赖包打包到所述应用容器中。

其中,Docker是一个开源的应用容器引擎,让开发者可以打包其应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。

本发明具体实施例中,所述应用容器为docker镜像,任一主机通过下载打包好的docker镜像,来实现应用的快速部署。

基于上述任一具体实施例,一种软件即服务平台,若所述查询单元向所述负载列表中的任一节点发送心跳包,连续预设次数在预设时间内未接收到所述任一节点返回的节点状态,则将所述任一节点从所述负载列表中移动到待激活列表。

具体地,若所述查询单元向任一节点发送心跳包后,在预设时间内没有接收到所述任一节点返回的节点状态,则认为所述任一节点已断开,处于关闭状态。一定时间间隔后,所述查询单元再次向所述任一节点发送心跳包。

假设预测次数为N,若所述查询单元连续N次向所述任一节点发送心跳包,且所述N次均未在预设时间内接收到所述任一节点返回的节点状态,则将所述任一节点从负载列表中移动到待激活列表。

本发明具体实施例中,将多次未返回信息的节点移动到待激活列表,进一步加强了核心调度层对节点的监控,避免了反复向已经掉线或关闭的节点发送信息造成的资源浪费。

基于上述任一具体实施例,一种软件即服务平台,所述审核单元还接收所述待激活列表中的节点发送的激活请求,审核所述节点,并将审核通过的节点从所述待激活列表移动到所述负载列表。

具体地,若所述待激活列表中的节点重新与平台连接,则审核单元还能够接收所述待激活列表中的节点发送的激活请求。

所述审核单元接收所述激活请求后,重新对所述节点进行审核,如果审核通过,则将所述节点从待激活列表再移动到负载列表中。

本发明具体实施例中,通过重新审核待激活的节点,进一步加强了核心调度层对于节点状态的监控。

基于上述任一具体实施例,一种软件即服务平台,所述客户层根据历史分配记录将客户请求发送给对应的节点;所述历史分配记录中含有所述核心调度层根据所述客户请求分配的节点的记录。

具体地,在核心调度层根据客户请求和各节点的节点状态为所述客户请求分配节点的同时,客户层还能够根据历史分配记录直接为客户请求分配对应的节点。

此处,所述历史分配记录包括在客户层分配节点前,所述核心调度层根据客户请求分配的节点的记录。

例如,所述历史分配记录中包括客户请求A及其对应的节点C,则客户层能够不通过核心调度层,直接根据上述历史分配记录直接将客户请求A分配给节点C进行处理。

本发明具体实施例中,给出了根据历史分配记录为客户请求分配节点的方法,进一步提高了平台效率。

为了更好地理解与应用本发明提出的一种软件即服务平台,本发明进行以下示例,且本发明不仅局限于以下示例。

图2为本发明具体实施例的一种软件即服务平台的结构示意图,如图2所示,所述软件即服务平台包括核心调度层、客户层、计费层和应用管理层。

其中,所述应用管理层用于提供应用容器,所述应用容器是通过Docker将所述平台提供的应用和依赖包打包的可移植容器。任一主机能够通过所述应用管理层下载所述应用容器,并通过所述应用容器快速部署所述软件即服务平台提供的应用。

任一主机完成部署后,向所述核心调度层的审核单元发出加入所述软件即服务平台的申请。

所述审核单元接收到所述申请后,采集所述任一主机的物理资源,并判断所述任一主机的物理资源是否符合预先设定的审核要求:

若所述任一主机的物理资源符合所述审核要求,则认为所述任一主机通过审核,将所述任一主机作为所述软件即服务平台的节点,并将所述节点计入负载列表,并记录所述节点的节点状态;

所述核心调度层的查询单元对所述软件即服务平台下的任一节点的节点状态进行查询:

首先,所述查询单元向所述负载列表中的任一节点发送心跳包,所述任一节点接收到所述查询单元发送的心跳包后,向所述查询单元返回所述任一节点的节点状态。所述查询单元接收到所述任一节点返回的节点状态后,更新所述任一节点的节点状态。

若所述查询单元向任一节点发送心跳包后,在预设时间内没有接收到所述任一节点返回的节点状态,则认为所述任一节点已断开,处于关闭状态。一定时间间隔后,所述查询单元再次向所述任一节点发送心跳包。

若所述查询单元连续预测次数次向所述任一节点发送心跳包,且均未在预设时间内接收到所述任一节点返回的节点状态,则将所述任一节点从负载列表中移动到待激活列表。

若所述待激活列表中的节点重新与平台连接,则审核单元还能够接收所述待激活列表中的节点发送的激活请求。所述审核单元接收所述激活请求后,重新对所述节点进行审核,如果审核通过,则将所述节点从待激活列表再移动到负载列表中。

当客户需要应用所述软件即服务平台时,可通过客户端或者其他第三方工具直接访问所述客户层。所述客户层直接面向客户,以应用程序编程接口的形式向客户展示所述软件即服务平台提供的应用,并接收客户端发送的客户请求,将所述客户请求发送给核心调度层的调度单元。

调度单元接收到客户请求后,从所述客户请求中提取客户需要调用的应用程序编程接口。与此同时,所述调度单元从所述负载列表中的各节点的节点状态中对应提取各节点的负载和资源使用情况,根据各节点的负载和资源使用情况可以计算对应获取各节点当前可用的资源量。

所述调度单元根据客户需要调用的应用程序编程接口和各节点当前可用的资源量,通过计算获取所述负载列表中与所述应用程序编程接口对应的节点,并向所述节点发送命令,以使得所述节点执行所述客户请求。

除此以外,客户层还能够根据历史分配记录直接为客户请求分配对应的节点。此处,所述历史分配记录包括在客户层分配节点前,所述核心调度层根据客户请求分配的节点的记录。

在核心调度层或客户层为客户请求分配对应的节点后,计费层对客户请求计费,并计算服务于所述客户请求的节点的奖励金:

首先,计费层接收客户层发送的客户请求,对所述客户请求计费,并将计费结果返回提出所述客户请求的客户端。

随后,计费层通过核心调度层获取执行所述客户请求的节点,根据所述客户请求的计费结果计算所述节点对应的奖励金,并将所述奖励金发送给所述节点对应的账户。

本示例中,主机通过下载应用容器部署应用并经过核心调度层审核后成为软件及服务平台的节点,通过对闲散主机资源的整合为平台提供大量节点,节省了平台的资金投入,同时,分布式节点将维护工作转移给申请人,降低了平台的时间和精力损耗,避免了闲置电脑的资源浪费。

最后,本申请的方法仅为较佳的实施方案,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1