CN103647811A

CN103647811A - 一种实现应用访问后台服务的方法和装置

Info

Publication number: CN103647811A
Application number: CN201310626471.9A
Authority: CN
Inventors: 左文建; 曲文庆
Original assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Current assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Priority date: 2013-11-28
Filing date: 2013-11-28
Publication date: 2014-03-19
Anticipated expiration: 2033-11-28
Also published as: CN103647811B

Abstract

本发明公开了一种实现应用访问后台服务的方法和装置。所述方法包括：在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件，当接收到来自应用的访问指定服务的请求时，先查看缓存中是否存在该指定服务的数据，如果存在，则将缓存中的该指定服务的数据返回给应用，如果不存在，则根据缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给应用，并在缓存中保存该指定服务的数据。本发明的技术方案，避免了传输资源的存储资源的浪费，以及避免了被动等待推送导致的实时性差的问题。

Description

一种实现应用访问后台服务的方法和装置

技术领域

本发明涉及网络应用技术领域，具体涉及一种实现应用访问后台服务的方法和装置。

背景技术

REST描述了一个架构样式的互联系统（如Web应用程序）。REST约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过HTTP直接传输数据的特性，RESTfulWeb服务成为基于SOAP服务的一个最有前途的替代方案，称为REST服务。在大型的WEB系统中，由于集成不同数据和高并发处理的要求，一个应用将依赖多个REST服务。但随着依赖的服务个数的增加，应用的稳定性能将下降。例如，应用A依赖于B、C服务。B和C的可用性均为90％。那么A在自身没有问题的情况下，其可用性只有90％×90％＝81％。

对此，现有技术中，通常将应用所依赖的服务的数据，静态地定时推送到应用所在的设备上，这样可以避免服务故障或网络不可用的情况下应用不能使用服务的数据的情况。

但是这种服务的数据定时推送的方案，应用所在设备上的服务数据的更新存在固定的延时，有实时性需求的应用（如用户个性化数据的应用）不能采用此方案。并且，并不是推动的每个服务的数据都会有应用使用，因此也造成的传输资源和存储资源的浪费。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种实现应用访问后台服务的方法和装置。

依据本发明的一个方面，提供了一种实现应用访问后台服务的方法，该方法包括：

在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件；

当接收到来自应用的访问指定服务的请求时，先查看所述缓存中是否存在该指定服务的数据；

如果存在，则将所述缓存中的该指定服务的数据返回给所述应用；

如果不存在，则根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在所述缓存中保存该指定服务的数据。

可选地，该方法进一步包括：

为所述缓存中保存的服务的数据设置过期时间；

当接收到来自应用的访问指定服务的请求时，如果所述缓存中有该指定服务的数据，进一步查看所述缓存中的该指定服务的数据是否过期，没有过期时才将所述缓存中的该指定服务的数据返回给所述应用。

可选地，所述指定服务包括部署在后台服务器上的多个实例；

所述指定服务的配置文件中包括所述多个实例的访问地址信息；

所述根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务包括：根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息，根据该访问地址信息访问后台服务器上的该选择的实例。

可选地，该方法进一步包括：监测后台服务器上部署的服务的各个实例是否出现故障；

所述根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息包括：排除已经故障的实例，不选择其访问地址信息。

可选地，该方法进一步包括：

如果所述指定服务的所有实例都故障，则将所述缓存中的该指定服务的已过期数据返回给所述应用。

可选地，该方法进一步包括：提供配置文件管理接口，根据来自该配置文件管理接口的指令，在所述缓存中添加、更新或修改配置文件。

可选地，在应用所在的设备上部署代理服务，由该代理服务执行该方法的操作。

可选地，基于Varnish建立所述代理服务。

依据本发明的另一个方面，提供了一种实现应用访问后台服务的装置，该装置包括：缓存单元和代理服务单元，其中：

缓存单元，适于保存应用所依赖的部署在后台服务器上的服务的配置文件；

代理服务单元，适于在接收到来自应用的访问指定服务的请求时，先查看缓存单元中是否存在该指定服务的数据；如果存在，则将缓存单元中的该指定服务的数据返回给所述应用；如果不存在，则根据缓存单元中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在缓存单元中保存该指定服务的数据。

可选地，所述代理服务单元，进一步适于为缓存单元中保存的服务的数据设置过期时间，当接收到来自应用的访问指定服务的请求时，如果缓存单元中有该指定服务的数据，进一步查看缓存单元中的该指定服务的数据是否过期，没有过期时才将缓存单元中的该指定服务的数据返回给所述应用。

所述代理服务单元，适于根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息，根据该访问地址信息访问后台服务器上的该选择的实例。

可选地，该装置进一步包括：

监测单元，适于监测后台服务器上部署的服务的各个实例是否出现故障；

所述代理服务单元，适于在根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息时，排除已经故障的实例，不选择其访问地址信息。

可选地，所述代理服务单元，进一步适于在所述指定服务的所有实例都故障时，将缓存单元中的该指定服务的已过期数据返回给所述应用。

可选地，该装置进一步包括：配置文件管理单元，适于接收配置文件管理指令；

所述代理服务单元，进一步适于根据所述配置文件管理指令，在缓存单元中添加、更新或修改配置文件。

可选地，该装置部署在应用所在的设备上。

可选地，该装置是基于Varnish建立的。

根据本发明的这种在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件，当接收到来自应用的访问指定服务的请求时，先查看所述缓存中是否存在该指定服务的数据，如果存在，则将所述缓存中的该指定服务的数据返回给所述应用，如果不存在，则根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在所述缓存中保存该指定服务的数据的技术方案，由于只有应用需要访问的服务的数据，才会去后台服务器获取并保存到缓存中，因此避免了传输资源的存储资源的浪费，另外由于是主动去后台服务器获取，因此可以避免被动等待推送导致的实时性差的问题。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的一种实现应用访问后台服务的方法的流程图;

图2示出了根据本发明一个实施例的实现应用访问后台服务的举例说明示意图；

图3示出了根据本发明一个实施例的Local_Proxy的组织结构示意图；

图4示出了根据本发明一个实施例的应用访问MySvc服务的流程示意图；

图5示出了根据本发明一个实施例的一种实现应用访问后台服务的装置的结构示意图；

图6示出了根据本发明又一个实施例的一种实现应用访问后台服务的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的一种实现应用访问后台服务的方法的流程图。如图1所示，该方法包括：

步骤S110，在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件。

步骤S120，当接收到来自应用的访问指定服务的请求时执行步骤S130。

步骤S130，先查看所述缓存中是否存在该指定服务的数据，是则执行步骤S140，否则执行步骤S150。

步骤S140，将所述缓存中的该指定服务的数据返回给所述应用。

步骤S150，根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在所述缓存中保存该指定服务的数据。

图1所示的方法中，由于只有应用需要访问的服务的数据，才会去后台服务器获取并保存到缓存中，因此避免了传输资源的存储资源的浪费，另外由于是主动去后台服务器获取，因此可以避免被动等待推送导致的实时性差的问题。

在本发明的一个实施例中，图1所示的方法进一步包括：为所述缓存中保存的服务的数据设置过期时间；当接收到来自应用的访问指定服务的请求时，如果所述缓存中有该指定服务的数据，进一步查看所述缓存中的该指定服务的数据是否过期，没有过期时才将所述缓存中的该指定服务的数据返回给所述应用。这样，可以定期对缓存中的数据进行更新，对于实时性要求较高的应用，可以将缓存中的该应用的服务数据的过期时间设置的较短一些。

在本发明的一个实施例中，图1所示方法的所述指定服务包括部署在后台服务器上的多个实例；所述指定服务的配置文件中包括所述多个实例的访问地址信息；所述根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务包括：根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息，根据该访问地址信息访问后台服务器上的该选择的实例。该方法还可以进一步包括：监测后台服务器上部署的服务的各个实例是否出现故障；所述根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息包括：排除已经故障的实例，不选择其访问地址信息。如果所述指定服务的所有实例都故障，则将所述缓存中的该指定服务的已过期数据返回给所述应用。

在本发明的一个实施例中，图1所示的方法进一步包括：提供配置文件管理接口，根据来自该配置文件管理接口的指令，在所述缓存中添加、更新或修改配置文件。

在本发明的一个实施例中，在应用所在的设备上部署代理服务，由该代理服务执行图1所示方法的上述操作。

在本发明的一个实施例中，基于Varnish建立所述代理服务。

以下给出本发明的一个具体实施例，对上述方案进行进一步的说明。

图2示出了根据本发明一个实施例的实现应用访问后台服务的举例说明示意图。如图2所示，在应用所在的设备上，基于Varnish建立具有缓存能力的代理服务Local_Proxy，其他部分的说明如下：

Svc.MySvc 名为MySvc的服务

A:Svc.MySvc MySvc的实例A

B:Svc.MySvc MySvc的实例B

Sdk.MySvc MySvc服务的SDK

MyAppSys 应用系统;

其中，SDK是Software Development Kit的缩写，即软件开发工具包。MyAppSys通过Sdk.mysvc来访问名为MySvc服务，这是现有技术，在本发明中不涉及，因此不做过多介绍。

在本实施例中，应用系统中的应用访问后台服务器上的服务，通过本地的代理服务进行调用。图3示出了根据本发明一个实施例的Local_Proxy的组织结构示意图。参见图3，代理服务Local_Proxy包括：缓存、代理进程和配置文件管理接口。配置文件管理接口用于控制代理进程的启动和关闭以及配置文件的添加、修改和更新。基于内存的缓存中保存代理进程已获取的服务数据以及服务的配置文件（sdk_vcls）。

在本发明的一个实施例中，MySvc服务的配置文件MySvc.vcl的一个示例如下：

图4示出了根据本发明一个实施例的应用访问MySvc服务的流程示意图。参见图4，包括：

步骤401，代理服务Local_Proxy中的代理进程接收到应用系统中的应用访问MySvc服务的请求。

来自MyAppSys的请求都通过Sdk.MySvc发送，以及返回给MyAppSys的服务数据也通过Sdk.MySvc发送，后续不再说明。

步骤402，代理进程先查看缓存中是否存在MySvc服务的数据且没有过期，是则执行步骤403，否则缓存中没有MySvc服务的数据或者有MySvc服务的数据但已过期则执行步骤404～406。

步骤403，代理进程将缓存中的MySvc服务的数据返回给发送请求的应用。

步骤404，代理进程查看缓存中的MySvc服务的配置文件MySvc.vcl，配置文件MySvc.vcl中保存有MySvc服务的两个实例（A:Svc.MySvc和B:Svc.MySvc）的访问地址信息，代理进程根据预定的策略从MySvc.vcl中选择MySvc服务的一个实例的访问地址信息，

步骤405，代理进程根据该访问地址信息访问后台服务器上的该选择的实例（A:Svc.MySvc或B:Svc.MySvc）。

本步骤中，可以按照轮循的方式从多个实例中的选择一个，即如果上次选择了实例A，那么本次选择实例B。

步骤406，代理进程从所访问的实例（A:Svc.MySvc或B:Svc.MySvc）获取MySvc服务的数据。

步骤407，代理进程将获取的MySvc服务的数据返回给发送请求的应用，以及将所获取的MySvc服务的数据存入缓存中，为期设置过期时间，以备后续有应用访问时使用。

通过上述的建立本机的动态的具有缓存能力的代理服务，访问后端的

REST服务的技术方案，有效提高了应用系统的可靠性，缩减了应用系统的整体响应时间。

图5示出了根据本发明一个实施例的一种实现应用访问后台服务的装置的结构示意图。如图5所示，该实现应用访问后台服务的装置500包括：缓存单元501和代理服务单元502，其中：

缓存单元501，适于保存应用所依赖的部署在后台服务器上的服务的配置文件；

代理服务单元502，适于在接收到来自应用的访问指定服务的请求时，先查看缓存单元501中是否存在该指定服务的数据；如果存在，则将缓存单元501中的该指定服务的数据返回给所述应用；如果不存在，则根据缓存单元501中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在缓存单元501中保存该指定服务的数据。

图6示出了根据本发明又一个实施例的一种实现应用访问后台服务的装置的结构示意图。如图6所示，该实现应用访问后台服务的装置600包括：缓存单元601和代理服务单元602，其中：

缓存单元601，适于保存应用所依赖的部署在后台服务器上的服务的配置文件；

代理服务单元602，适于在接收到来自应用的访问指定服务的请求时，先查看缓存单元601中是否存在该指定服务的数据；如果存在，则将缓存单元601中的该指定服务的数据返回给所述应用；如果不存在，则根据缓存单元601中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在缓存单元601中保存该指定服务的数据。

在本发明的一个实施例中，代理服务单元602，进一步适于为缓存单元601中保存的服务的数据设置过期时间，当接收到来自应用的访问指定服务的请求时，如果缓存单元601中有该指定服务的数据，进一步查看缓存单元中601的该指定服务的数据是否过期，没有过期时才将缓存单元601中的该指定服务的数据返回给所述应用。

在本发明的一个实施例中，所述指定服务包括部署在后台服务器上的多个实例；所述指定服务的配置文件中包括所述多个实例的访问地址信息；

所述代理服务单元602，适于根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息，根据该访问地址信息访问后台服务器上的该选择的实例。

在本发明的一个实施例中，该装置600进一步包括：

监测单元604，适于监测后台服务器上部署的服务的各个实例是否出现故障；

所述代理服务单元602，适于在根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息时，排除已经故障的实例，不选择其访问地址信息。

在本发明的一个实施例中，所述代理服务单元602，进一步适于在所述指定服务的所有实例都故障时，将缓存单元601中的该指定服务的已过期数据返回给所述应用。

在本发明的一个实施例中，该装置600进一步包括：配置文件管理单元603，适于接收配置文件管理指令以及启动或关闭代理服务单元的命令；

所述代理服务单元602，进一步适于根据所述配置文件管理指令，在缓存单元601中添加、更新或修改配置文件，以及适于根据启动或关闭代理服务单元的命令，启动或关闭代理服务单元。

在本发明的一个实施例中，该装置600部署在应用所在的设备上。

在本发明的一个实施例中，该装置600是基于Varnish建立的。

综上所述，本发明的这种在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件，当接收到来自应用的访问指定服务的请求时，先查看所述缓存中是否存在该指定服务的数据，如果存在，则将所述缓存中的该指定服务的数据返回给所述应用，如果不存在，则根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在所述缓存中保存该指定服务的数据的技术方案，由于只有应用需要访问的服务的数据，才会去后台服务器获取并保存到缓存中，因此避免了传输资源的存储资源的浪费，另外由于是主动去后台服务器获取，因此可以避免被动等待推送导致的实时性差的问题。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的实现应用访问后台服务的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了A1、一种实现应用访问后台服务的方法，其中，该方法包括：在应用所在设备的缓存中保存应用所依赖的部署在后台服务器上的服务的配置文件；当接收到来自应用的访问指定服务的请求时，先查看所述缓存中是否存在该指定服务的数据；如果存在，则将所述缓存中的该指定服务的数据返回给所述应用；如果不存在，则根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务，获取该指定服务的数据返回给所述应用，并在所述缓存中保存该指定服务的数据。

A2、如A1所述的方法，其中，该方法进一步包括：

为所述缓存中保存的服务的数据设置过期时间；当接收到来自应用的访问指定服务的请求时，如果所述缓存中有该指定服务的数据，进一步查看所述缓存中的该指定服务的数据是否过期，没有过期时才将所述缓存中的该指定服务的数据返回给所述应用。

A3、如A2所述的方法，其中，所述指定服务包括部署在后台服务器上的多个实例；所述指定服务的配置文件中包括所述多个实例的访问地址信息；所述根据所述缓存中的该指定服务的配置文件访问后台服务器上的该指定服务包括：根据预定的策略从配置文件中选择该指定服务的一个实例的访问地址信息，根据该访问地址信息访问后台服务器上的该选择的实例。

A4、如A3所述的方法，其中，该方法进一步包括：监测后台服务器上部署的服务的各个实例是否出现故障；

A5、如A4所述的方法，其中，该方法进一步包括：如果所述指定服务的所有实例都故障，则将所述缓存中的该指定服务的已过期数据返回给所述应用。

A6、如A1所述的方法，其中，该方法进一步包括：提供配置文件管理接口，根据来自该配置文件管理接口的指令，在所述缓存中添加、更新或修改配置文件。

A7、如A1至A6中任一项所述的方法，其中，在应用所在的设备上部署代理服务，由该代理服务执行该方法的操作。

A8、如A7所述的方法，其中，基于Varnish建立所述代理服务。

本发明还公开了B9、一种实现应用访问后台服务的装置，该装置包括：缓存单元和代理服务单元，其中：

B10、如B9所述的装置，其中，所述代理服务单元，进一步适于为缓存单元中保存的服务的数据设置过期时间，当接收到来自应用的访问指定服务的请求时，如果缓存单元中有该指定服务的数据，进一步查看缓存单元中的该指定服务的数据是否过期，没有过期时才将缓存单元中的该指定服务的数据返回给所述应用。

B11、如B10所述的装置，其中，所述指定服务包括部署在后台服务器上的多个实例；所述指定服务的配置文件中包括所述多个实例的访问地址信息；

B12、如B11所述的装置，其中，该装置进一步包括：监测单元，适于监测后台服务器上部署的服务的各个实例是否出现故障；

B13、如B12所述的装置，其中，所述代理服务单元，进一步适于在所述指定服务的所有实例都故障时，将缓存单元中的该指定服务的已过期数据返回给所述应用。

B14、如B9所述的装置，其中，该装置进一步包括：配置文件管理单元，适于接收配置文件管理指令；

B15、如B9至B14中任一项所述的装置，其中，该装置部署在应用所在的设备上。

B16、如B15所述的装置，其中，该装置是基于Varnish建立的。

Claims

1.一种实现应用访问后台服务的方法，其中，该方法包括：

2.如权利要求1所述的方法，其中，该方法进一步包括：

为所述缓存中保存的服务的数据设置过期时间；

3.如权利要求2所述的方法，其中，

所述指定服务包括部署在后台服务器上的多个实例；

4.如权利要求3所述的方法，其中，

该方法进一步包括：监测后台服务器上部署的服务的各个实例是否出现故障；

5.如权利要求4所述的方法，其中，该方法进一步包括：

6.如权利要求1所述的方法，其中，该方法进一步包括：提供配置文件管理接口，根据来自该配置文件管理接口的指令，在所述缓存中添加、更新或修改配置文件。

7.如权利要求1至6中任一项所述的方法，其中，

在应用所在的设备上部署代理服务，由该代理服务执行该方法的操作。

8.如权利要求7所述的方法，其中，

基于Varnish建立所述代理服务。

9.一种实现应用访问后台服务的装置，其中，该装置包括：缓存单元和代理服务单元，其中：

10.如权利要求9所述的装置，其中，

所述代理服务单元，进一步适于为缓存单元中保存的服务的数据设置过期时间，当接收到来自应用的访问指定服务的请求时，如果缓存单元中有该指定服务的数据，进一步查看缓存单元中的该指定服务的数据是否过期，没有过期时才将缓存单元中的该指定服务的数据返回给所述应用。