应用程序的云资源管理系统和方法

文档序号:6634065阅读:232来源:国知局
应用程序的云资源管理系统和方法
【专利摘要】本发明提出一种应用程序的云资源管理系统和方法。其中,该系统包括应用程序云资源管理子系统、用户空间文件子系统、接入子系统和开发者客户端,其中,用户空间文件子系统为应用程序云资源管理子系统的接口的文件映射,其中,开发者客户端,用于向接入子系统发送请求消息;接入子系统,用于将请求消息发送至用户空间文件子系统;用户空间文件子系统,用于执行请求消息,并将执行结果反馈至应用程序云资源管理子系统;以及应用程序云资源管理子系统,用于根据执行结果对开发者对应的云资源进行管理。本发明实施例的应用程序的云资源管理系统,降低了用户的使用门槛,尤其是方便了用户对应用程序日志的查看和分析,提高了用户使用体验。
【专利说明】应用程序的云资源管理系统和方法

【技术领域】
[0001]本发明涉及互联网【技术领域】,尤其涉及一种应用程序的云资源管理系统和方法。

【背景技术】
[0002]当前,云计算中关于代码的运行环境有两个代表性方案,一个是以Google AppEngine为代表的App Engine (Google App Engine是一种在Google的基础架构上运行的网络应用程序),一个是以Amazon AWS为代表的虚拟机方案(Amazon AWS是亚马逊提供的专业云计算服务)。这两种方案各有优缺点,App Engine的方案能够做到真正的按需分配,AppEngine集群每台物理机器的极限取决于应用的流量而不是应用个数。而虚拟机的方案能够支持的应用个数,取决于I台物理机可以虚拟化成多少台虚拟机,实际上I台物理机虚拟化成200台虚拟机基本已经是极限。因此,I台物理机最多只能提供200个应用程序的执行,如果这些应用程序完全没有流量,那么这台物理机的资源利用率基本为0,而App Engine方案在处理这个长尾的时候,基本上一台物理机就能够管理十万个静默的无流量App。
[0003]目前,以Google AppEngine为代表的国内外App Engine的运行环境都是以网站和自带专业脚本作为管理工具,管理App Engine的。然而现有的App Engine的管理方式非常麻烦,不够灵活,不能有效的通过Linux强大的脚本来管理App Engine的逻辑,尤其对于日志,查看起来非常不方便。


【发明内容】

[0004]本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
[0005]为此,本发明的第一个目的在于提出一种应用程序的云资源管理系统,该系统降低了开发者的使用门槛,尤其是方便了开发者对应用程序日志的查看和分析,提高了用户使用体验。
[0006]本发明的第二个目的在于提出一种应用程序的云资源管理方法。
[0007]为达上述目的,本发明第一方面实施例提出了一种应用程序的云资源管理系统,包括应用程序云资源管理子系统、用户空间文件子系统、接入子系统和开发者客户端,其中,所述用户空间文件子系统为所述应用程序云资源管理子系统的接口的文件映射,其中,所述开发者客户端,用于向接入子系统发送请求消息;所述接入子系统,用于将所述请求消息发送至所述用户空间文件子系统;所述用户空间文件子系统,用于执行所述请求消息,并将执行结果反馈至所述应用程序云资源管理子系统;以及所述应用程序云资源管理子系统,用于根据所述执行结果对开发者对应的云资源进行管理。
[0008]本发明实施例的应用程序的云资源管理系统,通过将App Engine抽象成传统的虚拟机接口提供给开发者访问,开发者通过开发者客户端连接到App Engine,通过SSH和通用命令行参数管理App Engine的数据和代码资源,降低了开发者的使用门槛,尤其是方便了开发者对应用程序日志的查看和分析,提高了用户使用体验。
[0009]为达上述目的,本发明第二方面实施例提出了一种应用程序的云资源管理方法,包括:用户空间文件子系统接收开发者客户端通过接入子系统发送的请求消息,其中,所述用户空间文件子系统为应用程序云资源管理子系统的接口的文件映射;以及所述用户空间文件子系统执行所述请求消息,并将执行结果反馈至所述应用程序云资源管理子系统,以使所述应用程序云资源管理子系统根据所述执行结果对开发者对应的云资源进行管理。
[0010]本发明实施例的应用程序的云资源管理方法,通过将App Engine抽象成传统的虚拟机接口提供给开发者访问,开发者通过开发者客户端连接到App Engine,通过SSH和通用命令行参数管理App Engine的数据和代码资源,降低了开发者的使用门槛,尤其是方便了开发者对应用程序日志的查看和分析,提高了用户使用体验。
[0011]本发明附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。

【专利附图】

【附图说明】
[0012]本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
[0013]图1是本发明一个实施例的应用程序的云资源管理系统的结构示意图;
[0014]图2是本发明一个实施例的应用程序的云资源管理系统示意图;以及
[0015]图3是本发明一个实施例的应用程序的云资源管理方法的流程图。

【具体实施方式】
[0016]下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本发明,而不能理解为对本发明的限制。
[0017]此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
[0018]流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本发明的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本发明的实施例所属【技术领域】的技术人员所理解。
[0019]针对现有的App Engine的管理方式麻烦,不够灵活的缺点,本发明将App Engine提供给应用程序开发者的资源抽象成一台机器,并通过传统Linux程序员最容易接受的SSH(Secure Shell,建立在应用层和传输层基础上的安全协议)和通用命令行参数,来管理App Engine的数据和代码资源,由此,降低了开发者的使用门槛。图1是本发明一个实施例的应用程序的云资源管理系统的结构示意图。
[0020]如图1所示,应用程序的云资源管理系统包括应用程序云资源管理子系统10、用户空间文件子系统20、接入子系统30、开发者客户端40和资源采集子系统50,其中,接入子系统30包括负载均衡装置31,用户空间文件子系统20为应用程序云资源管理子系统10的接口的文件映射。
[0021]具体地,开发者客户端40用于向接入子系统30发送请求消息。其中,开发者客户端40和接入子系统30均为Linux系统。具体而言,开发者客户端40可为SSH客户端,SSH客户端是一个通用的客户端,例如,Putty (Putty是一个基于Linux系统管理的SSH连接软件),开发者通过客户端40填写IP(Internet Protocol,网络之间互连的协议)、用户名、密码等信息,即可在开发者客户端40中登录。其中,用户名和密码是开发者在App Engine中的账号。在开发者在开发者客户端40中登录之后,开发者客户端40向接入子系统30发送SSH请求消息。
[0022]接入子系统30用于将请求消息发送至用户空间文件子系统20。
[0023]在本发明的一个实施例中,用户空间文件子系统20包括多个服务器,接入子系统30包括负载均衡装置31。负载均衡装置31用于为请求消息分配用户空间文件子系统30中的一个服务器。具体而言,当开发者在开发者客户端40登陆之后,开发者客户端40将SSH请求消息发送至负载均衡装置31,负载均衡装置31将SSH请求消息分配到一台适合的服务器上,即负载均衡装置31将SSH请求消息发送至空间文件子系统20。其中,负载均衡装置31分配方式可以根据实际情况设计,例如,分配方式为随机。
[0024]用户空间文件子系统20用于执行请求消息,并将执行结果反馈至应用程序云资源管理子系统10。其中,用户空间文件子系统20中包括开发者对应的根目录,根目录中包括多个文件,多个文件分别与应用程序云资源管理子系统10的接口的多个元素对应。应用程序云资源管理子系统10的接口的多个元素包括代码、配置信息、数据存储信息、日志和资源监控信息,根目录中包括多个文件包括代码目录、配合目录、数据目录、日志目录和资源目录。
[0025]在本发明的一个实施例中,应用程序的云资源管理系统还包括资源采集子系统50。资源采集子系统50用于采集开发者对应的资源使用情况,并根据资源使用情况生成资源目录。
[0026]具体而言,首先,需要抽象App Engine的接口,将App Engine抽象成传统的虚拟机接口供开发者访问,使其适合管理。App Engine的执行单元。即应用程序云资源管理子系统10,主要由以下几个元素构成:1、代码;2、网站服务器的配置;3、数据存储;4、日志;5、资源监控。进一步而言,根据Linux系统的特点,可以将上述5个元素通过文件的形式表示。也就是说,每个在App Engine上运行的应用程序,都具有不同的根目录,每个根目录下具有5个文件夹,每个文件分别与构成程序云资源管理子系统10的5个元素对应。5个文件夹分别是:a)WWW目录,用于存储开发者的应用程序的代码;b)config目录,用于存储开发者对网站服务器的配置;c)data目录,用于存储云端服务器存储的数据;d)log目录,用于存储应用程序运行时产生的日志;e)pr0C目录,用于存储应用程序运行时消耗的资源。然后,通过FUSE (Filesystem in Userspace,用户空间文件系统)技术,将上述5个目录映射成应用程序云资源管理子系统10的接口。
[0027]进一步而言,首先,配置一个用户空间文件子系统20,其中,用户空间文件子系统20可采用开源的搭建或者自主的研发,用户空间文件子系统20为每个应用程序设置一个根目录,根目录中涵盖了 WWW目录、config目录、data目录、log目录以及proc目录。用户空间文件子系统20对开发者提供网络文件系统的访问接口。为了方便开发者通过操作系统本地操作用户空间文件子系统20,FUSE技术可将网络访问接口直接转化为操作系统支持的本地文件系统,相当于在服务器中增加了一块磁盘。而对于新增加的磁盘的操作,所有的Linux Shell命令都是支持的,由此,大大提高了对本地文件系统的数据管理的易用性。其中,proc目录中的数据不是文件数据,而是通过资源采集子系统50实时采集的结构化数据,为了将proc目录中的数据转换为本地文件系统可以访问的数据,可以将采集到的数据结构化,然后再写入到网络文件中。
[0028]应用程序云资源管理子系统10用于根据执行结果对开发者对应的云资源进行管理。
[0029]下面结合图2说明一下本发明实施例的应用程序的云资源管理系统。在完成将AppEngine的数据管理抽象为应用程序云资源管理子系统10的接口之后,开发者在开发者客户端40上登录,登录后直接访问映射后的文件目录。例如,开发者创建一个账户opengl,开发者的账户opengl有2个应用程序分别是hello和word,开发者通过Putty登录至应用程序云资源管理子系统10之后,可以看到如图2所示的操作界面。其中,为了方便开发者管理,从App Engine中获取该用户能够管理的所有的应用程序,将这些应用程序映射在该开发者的登录目录之下。然后,开发者可以安装自己的工具,并对目录下的文件中的数据进行分析和操作,例如,grep (global search regular express1n and print out the line,全面搜索正则表达式并把行打印出来)日志等。
[0030]本发明实施例的应用程序的云资源管理系统,通过将App Engine抽象成传统的虚拟机接口提供给开发者访问,开发者通过开发者客户端连接到App Engine,通过SSH和通用命令行参数管理App Engine的数据和代码资源,降低了开发者的使用门槛,尤其是方便了开发者对应用程序日志的查看和分析,提高了用户使用体验。
[0031]为了实现上述实施例,本发明还提出一种应用程序的云资源管理方法。
[0032]图3是本发明一个实施例的应用程序的云资源管理方法的流程图。
[0033]如图3所示,应用程序的云资源管理方法包括:
[0034]S301,用户空间文件子系统接收开发者客户端通过接入子系统发送的请求消息,其中,用户空间文件子系统为应用程序云资源管理子系统的接口的文件映射。
[0035]在本发明的一个实施例中,开发者客户端和接入子系统均为Linux系统。具体地,开发者客户端可为SSH客户端,SSH客户端是一个通用的客户端,例如,Putty (Putty是一个基于Linux系统管理的SSH连接软件),开发者通过客户端填写IP (Internet Protocol,网络之间互连的协议)、用户名、密码等信息,即可在开发者客户端中登录。其中,用户名和密码是用户在App Engine中的账号。在开发者在开发者客户端中登录之后,开发者客户端向接入子系统发送SSH请求消息。
[0036]在本发明的一个实施例中,用户空间文件子系统包括多个服务器,负载均衡装置为请求消息分配用户空间文件子系统中的一个服务器。具体地,当开发者在开发者客户端登陆之后,开发者客户端将SSH请求消息发送至负载均衡装置,负载均衡装置将SSH请求消息分配到一台适合的服务器上,即负载均衡装置将SSH请求消息发送至空间文件子系统。其中,负载均衡装置分配方式可以根据实际情况设计,例如,分配方式为随机。
[0037]S302,用户空间文件子系统执行请求消息,并将执行结果反馈至应用程序云资源管理子系统,以使应用程序云资源管理子系统根据执行结果对开发者对应的云资源进行管理。
[0038]在本发明的一个实施例中,用户空间文件子系统中包括开发者对应的根目录,根目录中包括多个文件,多个文件分别与应用程序云资源管理子系统的接口的多个元素对应。应用程序云资源管理子系统的接口的多个元素包括代码、配置信息、数据存储信息、日志和资源监控信息,根目录中包括多个文件包括代码目录、配合目录、数据目录、日志目录和资源目录。
[0039]在本发明的一个实施例中,资源采集子系统采集开发者对应的资源使用情况,并根据资源使用情况生成资源目录。具体而言,首先,需要抽象App Engine的接口,将AppEngine抽象成传统的虚拟机接口供开发者访问,使其适合管理。App Engine的执行单元。即应用程序云资源管理子系统,主要由以下几个元素构成:1、代码;2、网站服务器的配置;
3、数据存储;4、日志;5、资源监控。进一步而言,根据Linux系统的特点,可以将上述5个元素通过文件的形式表示。也就是说,每个在App Engine上运行的应用程序,都具有不同的根目录,每个根目录下具有5个文件夹,每个文件分别与构成程序云资源管理子系统的5个元素对应。5个文件夹分别是:a)WWW目录,用于存储开发者的应用程序的代码;b)config目录,用于存储开发者对网站服务器的配置;c)data目录,用于存储云端服务器存储的数据;d)log目录,用于存储应用程序运行时产生的日志;e)pr0C目录,用于存储应用程序运行时消耗的资源。然后,通过FUSE (Filesystem in Userspace,用户空间文件系统)技术,将上述5个目录映射成应用程序云资源管理子系统的接口。
[0040]进一步而言,首先,配置一个用户空间文件子系统,其中,用户空间文件子系统可采用开源的搭建或者自主的研发,用户空间文件子系统为每个应用程序设置一个根目录,根目录中涵盖了 WWW目录、config目录、data目录、log目录以及proc目录。用户空间文件子系统对开发者提供网络文件系统的访问接口。为了方便开发者通过操作系统本地操作用户空间文件子系统,FUSE技术可将网络访问接口直接转化为操作系统支持的本地文件系统,相当于在服务器中增加了一块磁盘。而对于新增加的磁盘的操作,所有的Linux Shell命令都是支持的,由此,大大提高了对本地文件系统的数据管理的易用性。其中,proc目录中的数据不是文件数据,而是通过资源采集子系统实时采集的结构化数据,为了将proc目录中的数据转换为本地文件系统可以访问的数据,可以将采集到的数据结构化,然后再写入到网络文件中。
[0041]下面结合图2说明一下本发明实施例的应用程序的云资源管理系统。在完成将App Engine的数据管理抽象为应用程序云资源管理子系统的接口之后,开发者在开发者客户端上登录,登录后直接访问映射后的文件目录。例如,开发者创建一个账户opengl,开发者的账户opengl有2个应用程序分别是hello和word,开发者通过Putty登录至应用程序云资源管理子系统之后,可以看到如图2所示的操作界面。其中,为了方便开发者管理,从App Engine中获取该开发者能够管理的所有的应用程序,将这些应用程序映射在该开发者的登录目录之下。然后,开发者可以安装自己的工具,并对目录下的文件中的数据进行分析和操作,例如,grep (global search regular express1n and print out the line,全面搜索正则表达式并把行打印出来)日志等。
[0042]本发明实施例的应用程序的云资源管理方法,通过将App Engine抽象成传统的虚拟机接口提供给开发者访问,开发者通过开发者客户端连接到App Engine,通过SSH和通用命令行参数管理App Engine的数据和代码资源,降低了开发者的使用门槛,尤其是方便了开发者对应用程序日志的查看和分析,提高了用户使用体验。
[0043]应当理解,本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。
[0044]在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
[0045]尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。
【权利要求】
1.一种应用程序的云资源管理系统,其特征在于,包括应用程序云资源管理子系统、用户空间文件子系统、接入子系统和开发者客户端,其中,所述用户空间文件子系统为所述应用程序云资源管理子系统的接口的文件映射,其中, 所述开发者客户端,用于向接入子系统发送请求消息; 所述接入子系统,用于将所述请求消息发送至所述用户空间文件子系统; 所述用户空间文件子系统,用于执行所述请求消息,并将执行结果反馈至所述应用程序云资源管理子系统;以及 所述应用程序云资源管理子系统,用于根据所述执行结果对开发者对应的云资源进行管理。
2.如权利要求1所述的应用程序的云资源管理系统,其特征在于,所述用户空间文件子系统中包括所述开发者对应的根目录,所述根目录中包括多个文件,所述多个文件分别与所述应用程序云资源管理子系统的接口的多个元素对应。
3.如权利要求2所述的应用程序的云资源管理系统,其特征在于,所述应用程序云资源管理子系统的接口的多个元素包括代码、配置信息、数据存储信息、日志和资源监控信息,所述根目录中包括多个文件包括代码目录、配合目录、数据目录、日志目录和资源目录。
4.如权利要求3所述的应用程序的云资源管理系统,其特征在于,还包括: 资源采集子系统,用于采集所述开发者对应的资源使用情况,并根据所述资源使用情况生成所述资源目录。
5.如权利要求1所述的应用程序的云资源管理系统,其特征在于,所述开发者客户端和所述接入子系统均为Linux系统。
6.如权利要求1所述的应用程序的云资源管理系统,其特征在于,所述用户空间文件子系统包括多个服务器,所述接入子系统包括: 负载均衡装置,用于为所述请求消息分配所述用户空间文件子系统中的一个服务器。
7.一种应用程序的云资源管理方法,其特征在于,包括以下步骤: 用户空间文件子系统接收开发者客户端通过接入子系统发送的请求消息,其中,所述用户空间文件子系统为应用程序云资源管理子系统的接口的文件映射;以及 所述用户空间文件子系统执行所述请求消息,并将执行结果反馈至所述应用程序云资源管理子系统,以使所述应用程序云资源管理子系统根据所述执行结果对开发者对应的云资源进行管理。
8.如权利要求7所述的应用程序的云资源管理方法,其特征在于,所述用户空间文件子系统中包括所述开发者对应的根目录,所述根目录中包括多个文件,所述多个文件分别与所述应用程序云资源管理子系统的接口的多个元素对应。
9.如权利要求8所述的应用程序的云资源管理方法,其特征在于,所述应用程序云资源管理子系统的接口的多个元素包括代码、配置信息、数据存储信息、日志和资源监控信息,所述根目录中包括多个文件包括代码目录、配合目录、数据目录、日志目录和资源目录。
10.如权利要求9所述的应用程序的云资源管理方法,其特征在于,还包括: 资源采集子系统采集所述开发者对应的资源使用情况,并根据所述资源使用情况生成所述资源目录。
11.如权利要求7所述的应用程序的云资源管理方法,其特征在于,所述开发者客户端和所述接入子系统均为Linux系统。
12.如权利要求7所述的应用程序的云资源管理方法,其特征在于,所述用户空间文件子系统包括多个服务器,所述用户空间文件子系统接收开发者客户端通过接入子系统发送的请求消息具体包括: 负载均衡装置为所述请求消息分配所述用户空间文件子系统中的一个服务器。
【文档编号】G06F9/44GK104391697SQ201410642026
【公开日】2015年3月4日 申请日期:2014年11月11日 优先权日:2014年11月11日
【发明者】肖伟 申请人:百度在线网络技术(北京)有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1