一种处理资源申请的方法及系统与流程

本申请涉及计算机领域，尤其涉及一种处理资源申请的方法及系统。

背景技术：

信息技术(informationtechnology,it)部门在进行研发过程中通常需要大量的资源申请，相应地，需要对这些资源进行管理。目前，当某个部门的研发人员需要申请使用服务器，研发人员需要手填申请表或者发邮件给部门经理来获得批准，然后再发送到系统管理员处进行相应处理，该审批流程复杂，耗费大量时间。并且，由于各部门或项目组是分散管理，所以从整个企业的角度而言，线下资源信息申请导致各部门掌握的信息过于碎片化，无法对分配后的资源进行有效数据整合与管理，也不利于企业进行进一步的资源配置优化及业务延伸。

技术实现要素：

本申请提供了一种处理资源申请的方法及系统，能够实现在线资源申请、在线资源入库以及在线资源信息管理。

第一方面，提供了一种处理资源申请的方法，所述方法包括以下步骤：

前端页面将第一用户触发的第一资源访问请求发送至接口层，所述第一资源访问请求包括所述第一用户的基本信息和第一资源申请信息；

所述接口层在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，其中，所述第一资源申请信息与所述第一资源服务模块存在对应关系，所述后端服务层是使用与前端页面不同的微服务技术体系构建的；

所述后端服务层中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中，其中，所述第一服务模块与所述第一资源数据库存在对应关系。

可选地，所述后端服务层还包括业务组件，所述业务组件包括多个独立处理不同业务逻辑的服务模块，所述基础组件包括基础数据组件、邮件服务组件、工作流服务组件和文件服务组件。

可选地，所述后端服务层中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务包括：

所述第一服务模块根据所述第一资源申请信息调用后端服务层中的工作流服务组件、文件服务组件、邮件服务组件和基础数据组件中的一种或者多种，执行第一资源申请的审批流程；

所述第一服务模块在所述第一资源申请审批流程通过的情况下，确认后端资源层第一数据库的第一资源状态；

在所述第一资源状态为可调用的情况下，从后端资源层调用所述第一资源，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。

可选地，所述第一服务模块从后端资源层调用所述第一资源之后，所述方法还包括：

所述第一服务模块调用基础组件中的邮件组件，将所述第一资源信息发送至所述第一用户邮箱；或者，

所述第一服务模块发送所述第一资源信息至所述接口层；

所述接口层将所述第一资源信息发送至所述前端页面；

所述前端页面向所述第一用户展示所述第一资源信息。

可选地，所述后端服务层还包括服务管理组件，所述服务管理组件包含多个管理模块，所述多个管理模块用于对后端资源层中的业务组件和基础组件进行配置管理、注册管理与组件间的相互调用管理。

第二方面，提供了一种处理资源申请的系统，所述系统包括前端页面、接口层、后端服务层以及后端资源层：

所述前端页面用于将用户访问前端页面触发的第一资源访问请求发送至接口层；

所述接口层用于在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，其中，所述第一资源申请信息与所述第一资源服务模块存在对应关系，所述后端服务层是使用与前端页面不同的微服务技术体系构建的；

所述后端服务层用于使用第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中，其中，所述第一服务模块与所述第一资源数据库存在对应关系；

所述后端资源层用于提供和存储数据。

可选地，所述后端服务层还包括业务组件，所述业务组件包括多个独立处理不同业务逻辑的服务模块，所述基础组件包括基础数据组件、邮件服务组件、工作流服务组件和文件服务组件。

可选地，所述后端服务层具体用于使用所述第一服务模块根据所述第一资源申请信息调用后端服务层中的工作流服务组件、文件服务组件、邮件服务组件和基础数据组件中的一种或者多种，执行第一资源申请的审批流程；

所述后端服务层具体用于使用所述第一服务模块在所述第一资源申请审批流程通过的情况下，确认后端资源层第一数据库的第一资源状态；

所述后端服务层具体用于在所述第一资源状态为可调用的情况下，从后端资源层调用所述第一资源，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。

可选地，所述第一服务模块从后端资源层调用所述第一资源之后还用于调用基础组件中的邮件组件，将所述第一资源信息发送至所述第一用户邮箱；或者，所述第一服务模块还用于发送所述第一资源信息至所述接口层；

所述接口层还用于将所述第一资源信息发送至所述前端页面；

所述前端页面还用于向所述第一用户展示所述第一资源信息。

可选地，所述后端服务层还包括服务管理组件，所述服务管理组件包含多个管理模块，所述多个管理模块用于对后端资源层中的多个组件和模块进行配置管理、注册管理与组件间的相互调用管理。

上述方法中，通过前端页面将第一用户触发的第一资源访问请求发送至接口层，接口层在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，从而使得后端服务层中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。通过上述方案，将用户在前端页面触发的资源访问请求发送至对应资源的服务模块进行处理，每个服务模块使用基础组件各自完成相应的业务，在资源层调取相应的资源，使得it部门的各种资源得到集成化管理，保证了数据的隔离，也解决了线下流程申请混乱和数据管理碎片化的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的一种处理资源申请的方法的流程示意图；

图2是本申请提供的一种后端服务层中的服务模块与资源层中的数据库之间的对应关系示意图；

图3是本申请提供的一种后端服务层完成系统运维资源申请业务的流程示意图；

图4是本申请提供的一种工作流组件执行系统运维资源业务逻辑的流程示意图；

图5是本申请提供的一种处理资源申请的系统结构示意图。

具体实施方式

下面通过具体实施方式结合附图对本申请作进一步详细说明。在以下的实施方式中，很多细节描述是为了使得本申请能被更好的理解。然而，本领域技术人员可以毫不费力的认识到，其中部分特征在不同情况下是可以省略的，或者可以由其他方法所替代。在某些情况下，本申请相关的一些操作并没有在说明书中显示或描述，这是为了避免本申请的核心部分被过多的描述所淹没。对于本领域技术人员而言，详细描述这些相关操作并不是必要的，他们根据说明书中的描述以及本领域的一般技术知识即可完整了解相关操作。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

需要说明的是，在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

本申请实施例提供的处理资源申请的方法及系统可以应用在消费品行业、制造业、电信服务业、银证险等金融服务业、物流服务业、物业服务业、物业管理、大中型进出口贸易公司、政府事业机构、研究院所以及教育服务业等等，可以具体用于：

(1)关键业务流程：例如资源信息管理、资源申请管理、订单、报价处理、采购处理、合同审核、客户电话处理、供应链管理等等；

(2)行政管理类:出差申请、加班申请、请假申请、用车申请、各种办公用品申请、购买申请、日报周报等；

(3)人事管理类：员工培训安排、绩效考评、职位变动处理、员工档案信息管理等；

(4)财务相关类：付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等；

(5)客户服务类：客户信息管理、客户投诉、请求处理、售后服务管理等；

(6)特殊服务类：iso系列对应流程、质量管理对应流程、产品数据信息管理、贸易公司报关处理、物流公司货物跟踪处理等，此处不作具体限定。

图1是本申请提供的一种处理资源申请的方法的流程示意图，如图1所示，本申请提供的处理资源申请的方法包括如下步骤：

s101：将用户访问前端页面触发的第一资源访问请求发送至接口层。

在本申请实施例中，所述第一资源访问请求包括所述用户的基本信息和第一资源申请信息。其中，用户的基本信息可以是用户的账户名和密码等校验信息，还可以是用户的基本资料信息，例如：用户姓名、所属部门、职位等等。第一资源申请信息可以是软件资源申请、软件资源管理申请、硬件资源申请、硬件资源管理申请、版本发布信息管理申请、数据权限申请、数据权限管理申请、消息队列(messagequeue,mq)账号申请、mq账号管理等等，此处不作具体限定。

在本申请实施例中，前端页面可以向用户展示资源申请系统界面并与用户进行交互，用户可以通过访问前端页面开始进行资源的申请流程，其中，所述前端页面可以是web页面、app页面等等，所述用户访问前端页面的方式可以是通过pc、移动设备或是其他终端，此处不作具体限定。其中，前端页面的开发可以使用前台代码实现，例如：超文本标记语言(hypertextmarkuplanguage,html)、级联样式表(cascadingstylesheet,css)、javascript、html5、可缩放矢量图形(scalablevectorgraphics,svg)等等，此处不作具体限定。

在本申请实施例中，将第一资源访问请求发送至接口层可以通过有线或者无线的方式进行发送。其中，无线的方式包括通用分组无线服务技术(generalpacketradioservice,gprs)、无线局域网(wirelesslocalareanetworks,wlan)、紫蜂(zigbee)、蓝牙(bluetooth)、近场通信(nearfieldcommunication,nfc)等等，有线的方式包括网线、铜线、rs232、rs458等等。应理解，上述通讯方式的举例仅仅是用于进行说明，不应构成具体限定。

s102：所述接口层在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块。

在本申请实施例中，所述后端服务层包括业务组件和基础组件，所述业务组件包括多个独立处理不同业务逻辑的服务模块，所述基础组件包括基础数据组件、邮件服务组件、工作流服务组件和文件服务组件。其中，所述业务组件中的服务模块可以是系统运维申请单服务模块、基础运维申请单服务模块、数据库管理(databaseadministrator,dba)申请单服务模块、资源管理(configurationmanagementdatabase,cmdb)服务模块等等，此处不作具体限定。将业务组件分为多个服务模块可以避免资源类别复杂情况下信息的混乱，保证了底层数据的清晰，也有利用系统的维护性和可延展性。可以理解的是，所述服务模块可以根据企业资源申请需求进行修改，例如，根据业务需求新建服务器申请服务模块，或者删除基础运维申请单服务模块，此处不作具体限定。

在本申请实施例中，所述第一资源申请信息与所述第一资源服务模块存在对应关系。也就是说，所述接口层根据所述第一资源访问请求中的第一资源申请信息确定服务层中相应的服务模块为第一资源服务模块后，将所述第一资源申请信息发送至第一资源服务模块。例如：a用户需要申请系统运维，b用户需要申请基础运维，前端页面将a用户触发的系统运维服务申请、b用户触发的基础运维服务申请发送至接口层，接口层将所述a用户的系统运维服务申请发送至后端服务层中的系统运维申请单服务模块，将b用户的基础运维服务申请发送至后端服务层中的基础运维服务模块。应理解，以上举例仅用于具体说明，并不能构成具体限定。

在本申请实施例中，所述后端服务层是使用与前端页面不同的微服务技术体系构建的。也就是说，在系统开发过程中使得前端和后端架构分离，前端构架集中考虑页面表现、浏览速度、浏览器兼容性以及用户体验等等，后端构架集中考虑业务逻辑、数据安全和存储的问题，从而保证前后端开发、部署完全解耦的目的。

在本申请实施例中，所述接口层可以是网关(gateway)，用于实现系统前端和后端的网络互连，所述接口层可以用于广域网互连，也可以用于局域网互连，此处不作具体限定。可以理解的是，所述接口层是唯一的，也就是说，所有前端和后端的数据通过统一的网关进行交互，从而方便了网关进行统一的风险拦截和用户权限校验等等相关业务的处理。

s103：所述第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。

在本申请实施例中，所述第一服务模块与所述第一资源数据库存在对应关系。所述后端资源层包括缓存库、工作流数据库、业务信息数据库、cmdb数据库以及文件存储数据库。其中，所述缓存库存放后端资源层中各个组件之间的公共信息；所述文件存储数据库存放上传文件；所述工作流数据库与工作流服务组件存在对应关系，所述工作流数据库中的数据包括工作流模型信息、工作流申请记录、审批信息以及工作流权限中的一种或者多种。所述业务信息数据库与后端服务层业务组件中的多个服务模块存在对应关系，所述业务信息数据库中的数据包括申请单明细、资源详细属性中的一种或者多种；所述cmdb数据库与cmdb模块存在对应关系，所述cmdb数据库用于存放所有入库的资源，是资源入库后的唯一存放位置。图2显示了所述后端服务层中的服务模块与资源层中的数据库之间的对应关系。应理解，图2仅仅用于举例说明，并不能构成具体限定，本申请提供的资源申请处理系统中可以拥有更多的服务模块和数据库。拥有多个服务模块，多个与服务模块对应的数据库可以使得不同业务的模块在保证独立处理服务的同时，实现申请信息和资源信息的有效隔离，也保证了资源信息之间的有效隔离，并且可以及时了解资源的分配情况，快速定位系统错误进行处理。

在本申请实施例中，所述后端服务层中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务的具体步骤如下：所述第一服务模块根据所述第一资源申请信息调用后端服务层中的工作流服务组件、文件服务组件、邮件服务组件和基础数据组件中的一种或者多种，执行第一资源申请的审批流程；所述第一服务模块在所述第一资源申请审批流程通过的情况下，确认后端资源层第一数据库的第一资源状态；在所述第一资源状态为可调用的情况下，从后端资源层调用所述第一资源，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。

在本申请实施例中，所述第一服务模块从后端资源层调用所述第一资源之后，所述方法还包括：所述第一服务模块调用基础组件中的邮件组件，将所述第一资源信息发送至所述第一用户邮箱；或者，所述第一服务模块发送所述第一资源信息至所述接口层；所述接口层将所述第一资源信息发送至所述前端页面；所述前端页面向所述第一用户展示所述第一资源信息。可以理解的是，当所述第一资源是某项服务资源，比如某用户a申请系统运维服务，审批成功后的第一资源信息可以是申请成功，等待运维服务处理的信息；当所述第一资源是某项数据申请，比如某用户a申请使用管理员权限，审批成功后的第一资源信息可以是管理员账户密码等等，应理解，以上举例仅用于具体说明，不能构成具体限定。

例如，图3是本申请提供的后端服务层完成系统运维资源申请业务的流程图。如图3所示，此时的第一资源申请为系统运维资源申请，第一服务模块为系统运维服务模块，因此当系统运维服务模块接收到接口层发送的系统运维资源申请后，系统运维服务模块调用基础数据组件和工作流组件自动执行审批流程，在审批流程通过后，确认业务数据库中的系统运维资源状态为可调用的情况下，从后端资源层的业务数据库中调取所述系统运维资源，完成系统运维资源申请业务。可以理解的是，在审批流程未通过，或者系统运维资源状态为不可调用时，发送申请失败的信息至接口层，所述接口层将申请失败信息返回至前端页面，前端页面向用户显示申请失败的信息，或者后端服务层直接调用邮件组件发送申请失败信息至用户邮箱。应理解，图3所示的流程图仅用于举例说明，并不能构成具体限定。

在本申请实施例中，第一资源服务模块在调用工作流服务组件时，工作流组件按照预先定义的流程自动执行第一资源业务逻辑，并且在工作流流程中的每一个活动完成后，将完成数据存储在资源层中的工作流数据库中，再进行下一个活动，从而实现工作流的全流程追踪、审批、统计。同时，工作流服务组件可以加入自定义权限体系，根据业务需求灵活的改变工作流的权限控制。下面以图4为例，对本申请的工作流组件进行进一步的说明，图4是本申请提供的工作流组件执行系统运维资源业务逻辑的流程示意图，如图4所示，后端服务层接收到系统运维资源申请后，调用基础数据组件以及工作流组件对所述系统运维资源申请进行处理，工作流组件按照预先定义的流程自动执行系统运维服务的业务逻辑，并将每个流程活动的结果存储在资源层中的工作流数据库中，图4所示的工作流流程仅用于举例说明，在实际的系统运维服务流程中，可以拥有更多的审批流程或者确认流程。

下面以用户a为例，对本申请实施例进行进一步的说明，假设用户a需要申请系统运维资源，那么用户a首先需要在前端页面登录账户名与密码，验证通过后，用户a可以在前端页面点击系统运维申请的链接，接下来用户a可以等待审核完成后，获得所述系统运维资源。其中，用户a系统运维申请流程过程中，有相应权限的用户(例如用户a的部门经理b、系统运维负责人c)会相应地收到对应该申请的审核通知邮件，部门经理b和系统运维负责人c点击邮件中的链接，则可直接通过资源服务申请系统对该申请进行审核。应理解，以上举例仅用于具体说明，并不能构成具体限定。

在本申请实施例中，所述后端服务层还包括服务管理组件，所述服务管理组件包含多个管理模块，所述多个管理模块用于对后端资源层中的业务组件和基础组件进行配置管理、注册管理与组件间的相互调用管理。所述服务管理模块可以是注册发现模块、网关服务模块、配置管理模块等等，此处不作具体限定。例如，使用服务管理组件中的配置管理模块根据业务需求新建服务器申请服务模块，或者删除基础运维申请单服务模块等等；例如，使用服务管理组件中的网关管理对接口层网关进行自定义修改等等，应理解，以上举例仅用于具体说明，并不能构成具体限定。

上述方法中，通过前端页面将第一用户触发的第一资源访问请求发送至接口层，接口层在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，从而使得后端服务层中的第一资源服务模块根据所述第一资源访问请求调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。通过上述方案，将用户在前端页面触发的资源访问请求发送至对应资源的服务模块进行处理，每个服务模块使用基础组件各自完成相应的业务，在资源层调取相应的资源，使得it部门的各种资源得到集成化管理，保证了数据的隔离，也解决了线下流程申请混乱和数据管理碎片化的问题。

图5是本申请提供的一种处理资源申请系统的结构示意图，如图5所示，本申请提供的处理资源申请系统包括前端页面510、接口层520、后端服务层530以及后端资源层540,

所述前端页面510用于将用户访问前端页面触发的第一资源访问请求发送至接口层520。

所述接口层520用于在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，其中，所述第一资源申请信息与所述第一资源服务模块存在对应关系，所述后端服务层是使用与前端页面不同的微服务技术体系构建的。

所述后端服务层530用于使用第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件532完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中，其中，所述第一服务模块与所述第一资源数据库存在对应关系。

在本申请实施例中，所述第一资源访问请求包括所述用户的基本信息和第一资源申请信息。其中，用户的基本信息可以是用户的账户名和密码等校验信息，还可以是用户的基本资料信息，例如：用户姓名、所属部门、职位等等。第一资源申请信息可以是软件资源申请、软件资源管理申请、硬件资源申请、硬件资源管理申请、版本发布信息管理申请、数据权限申请、数据权限管理申请、mq账号申请、mq账号管理等等，此处不作具体限定。

在本申请实施例中，前端页面510可以向用户展示资源申请系统界面并与用户进行交互，用户可以通过访问前端页面开始进行资源的申请流程，其中，所述前端页面可以是web页面、app页面等等，所述用户访问前端页面的方式可以是通过pc、移动设备或是其他终端，此处不作具体限定。其中，前端页面的开发可以使用前台代码实现，例如：html、css、javascript、html5、可svg等等，此处不作具体限定。

在本申请实施例中，将第一资源访问请求发送至接口层520可以通过有线或者无线的方式进行发送。其中，无线的方式包括gprs、wlan、zigbee、bluetooth、nfc等等，有线的方式包括网线、铜线、rs232、rs458等等。应理解，上述通讯方式的举例仅仅是用于进行说明，不应构成具体限定。

在本申请实施例中，所述后端服务层包括业务组件531和基础组件532，所述业务组件包括多个独立处理不同业务逻辑的服务模块，所述基础组件包括基础数据组件、邮件服务组件、工作流服务组件和文件服务组件。其中，所述业务组件中的服务模块可以是系统运维申请单服务模块、基础运维申请单服务模块、dba申请单服务模块、cmdb服务模块等等，此处不作具体限定。将业务组件分为多个服务模块可以避免资源类别复杂情况下信息的混乱，保证了底层数据的清晰，也有利用系统的维护性和可延展性。可以理解的是，所述服务模块可以根据企业资源申请需求进行修改，例如，根据业务需求新建服务器申请服务模块，或者删除基础运维申请单服务模块，此处不作具体限定。

在本申请实施例中，所述第一资源申请信息与第一资源服务模块存在对应关系。也就是说，所述接口层根据所述第一资源申请信息确定服务层中相应的服务模块为第一资源服务模块后，将所述第一资源申请信息发送至第一资源服务模块。例如：a用户需要申请系统运维，b用户需要申请基础运维，前端页面将a用户触发的系统运维服务申请、b用户触发的基础运维服务申请发送至接口层，接口层将所述a用户的系统运维服务申请发送至后端服务层中的系统运维申请单服务模块，将b用户的基础运维服务申请发送至后端服务层中的基础运维服务模块。应理解，以上举例仅用于具体说明，并不能构成具体限定。

在本申请实施例中，所述后端服务层是使用与前端页面不同的微服务技术体系构建的。也就是说，系统开发过程中使得前端和后端架构分离，前端构架集中考虑页面表现、浏览速度、浏览器兼容性以及用户体验等等，后端构架集中考虑业务逻辑、数据安全和存储的问题，从而保证前后端开发、部署完全解耦的目的。

在本申请实施例中，所述接口层520可以是网关(gateway)，用于实现系统前端和后端的网络互连，所述接口层可以用于广域网互连，也可以用于局域网互连，此处不作具体限定。可以理解的是，所述接口层是唯一的，也就是说，所有前端和后端的数据通过统一的网关进行交互，从而方便了网关进行统一的风险拦截和用户权限校验等等相关业务的处理。

在本申请实施例中，所述第一服务模块与所述第一资源数据库存在对应关系。所述后端资源层包括缓存库、工作流数据库、业务信息数据库、cmdb数据库以及文件存储数据库。其中，所述缓存库存放后端资源层中各个组件之间的公共信息；所述文件存储数据库存放上传文件；所述工作流数据库与工作流服务组件存在对应关系，所述工作流数据库中的数据包括工作流模型信息、工作流申请记录、审批信息以及工作流权限中的一种或者多种。所述业务信息数据库与后端服务层业务组件中的多个服务模块存在对应关系，所述业务信息数据库中的数据包括申请单明细、资源详细属性中的一种或者多种；所述cmdb数据库与cmdb模块存在对应关系，所述cmdb数据库用于存放所有入库的资源，是资源入库后的唯一存放位置。图2显示了所述后端服务层中的服务模块与资源层中的数据库之间的对应关系。应理解，图2仅仅用于举例说明，并不能构成具体限定，本申请提供的资源申请处理系统中可以拥有更多的服务模块和数据库。拥有多个服务模块，多个与服务模块对应的数据库可以使得不同业务的模块在保证独立处理服务的同时，实现申请信息和资源信息的有效隔离，也保证了资源信息之间的有效隔离，并且可以及时了解资源的分配情况，快速定位系统错误进行处理。

在本申请实施例中，所述后端服务层530中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件532完成第一资源申请业务的具体步骤如下：所述第一服务模块根据所述第一资源申请信息调用后端服务层中的工作流服务组件、文件服务组件、邮件服务组件和基础数据组件中的一种或者多种，执行第一资源申请的审批流程；所述第一服务模块在所述第一资源申请审批流程通过的情况下，确认后端资源层第一数据库的第一资源状态；在所述第一资源状态为可调用的情况下，从后端资源层调用所述第一资源，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。

在本申请实施例中，所述第一服务模块从后端资源层调用所述第一资源之后，所述方法还包括：所述第一服务模块调用基础组件532中的邮件组件，将所述第一资源信息发送至所述第一用户邮箱；或者，所述第一服务模块发送所述第一资源信息至所述接口层；所述接口层将所述第一资源信息发送至所述前端页面；所述前端页面向所述第一用户展示所述第一资源信息。可以理解的是，当所述第一资源是某项服务资源，比如某用户a申请系统运维服务，审批成功后的第一资源信息可以是申请成功，等待运维服务处理的信息；当所述第一资源是某项数据申请，比如某用户a申请使用管理员权限，审批成功后的第一资源信息可以是管理员账户密码等等，应理解，以上举例仅用于具体说明，不能构成具体限定。

例如，图3是本申请提供的后端服务层完成系统运维资源申请业务的流程图。如图3所示，此时的第一资源申请为系统运维资源申请，第一服务模块为系统运维服务模块，因此当系统运维服务模块接收到接口层发送的系统运维资源申请后，系统运维服务模块调用基础数据组件和工作流组件自动执行审批流程，在审批流程通过后，确认业务数据库中的系统运维资源状态为可调用的情况下，从后端资源层的业务数据库中调取所述系统运维资源，完成系统运维资源申请业务。可以理解的是，在审批流程未通过，或者系统运维资源状态为不可调用时，发送申请失败的信息至接口层，所述接口层将申请失败信息返回至前端页面，前端页面向用户显示申请失败的信息，或者后端服务层直接调用邮件组件发送申请失败信息至用户邮箱。应理解，图3所示的流程图仅用于举例说明，并不能构成具体限定。

在本申请实施例中，第一资源服务模块在调用工作流服务组件时，工作流组件按照预先定义的流程自动执行第一资源业务逻辑，并且在工作流流程中的每一个活动完成后，将完成数据存储在资源层中的工作流数据库中，再进行下一个活动，从而实现工作流的全流程追踪、审批、统计。同时，工作流服务组件可以加入自定义权限体系，根据业务需求灵活的改变工作流的权限控制。下面以图4为例，对本申请的工作流组件作出进一步的说明，图4是本申请提供的工作流组件执行系统运维资源业务逻辑的流程示意图，如图4所示，后端服务层接收到系统运维资源申请后，调用基础数据组件以及工作流组件对所述系统运维资源申请进行处理，工作流组件按照预先定义的流程自动执行系统运维服务的业务逻辑，并将每个流程活动的结果存储在资源层中的工作流数据库中，图4所示的工作流流程仅用于举例说明，在实际的系统运维服务流程中，可以拥有更多的审批流程或者确认流程。

下面以用户a为例，对本申请实施例进行进一步的说明，假设用户a需要申请系统运维资源，那么用户a首先需要在前端页面登录账户名与密码，验证通过后，用户a可以在前端页面点击系统运维申请的链接，接下来用户a可以等待审核完成后，获得所述系统运维资源。其中，用户a系统运维申请流程过程中，有相应权限的用户(例如用户a的部门经理b、系统运维负责人c)会相应地收到对应该申请的审核通知邮件，部门经理b和系统运维负责人c点击邮件中的链接，则可直接通过资源服务申请系统对该申请进行审核。应理解，以上举例仅用于具体说明，并不能构成具体限定。

在本申请实施例中，所述后端服务层还包括服务管理组件533，所述服务管理组件包含多个管理模块，所述多个管理模块用于对后端资源层中的业务组件和基础组件进行配置管理、注册管理与组件间的相互调用管理。所述服务管理模块可以是注册发现模块、网关服务模块、配置管理模块等等，此处不作具体限定。例如，使用服务管理组件中的配置管理模块根据业务需求新建服务器申请服务模块，或者删除基础运维申请单服务模块等等；例如，使用服务管理组件中的网关管理对接口层网关进行自定义修改等等，应理解，以上举例仅用于具体说明，并不能构成具体限定。

上述方法中，通过前端页面将第一用户触发的第一资源访问请求发送至接口层，接口层在所述第一用户的基本信息校验通过的情况下，将所述第一资源申请信息发送至后端服务层中的第一资源服务模块，从而使得后端服务层中的第一资源服务模块根据所述第一资源申请信息调用后端服务层中的一个或多个基础组件完成第一资源申请业务，并将所述第一资源申请业务完成数据发送至后端资源层的第一资源数据库中。通过上述方案，将用户在前端页面触发的资源访问请求发送至对应资源的服务模块进行处理，每个服务模块使用基础组件各自完成相应的业务，在资源层调取相应的资源，使得it部门的各种资源得到集成化管理，保证了数据的隔离，也解决了线下流程申请混乱和数据管理碎片化的问题。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法及系统，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、系统或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上，可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。