CN115134408B - 一种应用服务实现方法、装置、系统、介质和设备 - Google Patents

Abstract

本公开涉及一种应用服务实现方法、装置、系统、介质和设备，应用服务器基于相同的应用服务配置文件启动部署的同一种应用服务时，可以基于其中包括的访问路径信息，从配置中心服务器获取数据存储服务配置文件，实现对该应用服务对应的每个数据存储服务的信息的获取。使得后续可以针对该应用服务，实现对数据存储服务的访问。由于无需通过代理服务实现应用服务对数据存储服务的访问，可以有效降低开发成本，避免应用服务实现过程中，系统整体性能与可靠性的下降，并可以有效降低运维难度。可以保证对数据存储服务的任意操作，对于应用服务的透明性，避免对数据存储服务可伸缩性的制约。并可以保证跨IDC的数据存储服务访问的灵活性。

Description

一种应用服务实现方法、装置、系统、介质和设备

技术领域

本公开涉及互联网技术领域，特别涉及一种应用服务实现方法、装置、系统、介质和设备。

背景技术

本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

拥有全球性业务的互联网企业通常需要在多个不同物理地域之间同时提供应用服务，以做到异地的应用服务多活，因此，应用服务需要针对不同互联网数据存储与流通中心(IDC)进行部署。

为了可靠高效地运作，应用服务一般通过所在应用服务器优先访问与自身位于同一IDC中的数据存储服务，数据存储服务可以是任意类型，如可以是通过远程字典服务(redis)实现的数据缓存服务，也可以是通过关系型数据库MySQL实现的数据存储服务等。一个IDC中的数据存储服务可以理解为通过一个数据存储服务器集合提供，一个数据存储服务器集合可以理解为包括至少一个数据存储服务器。

目前数据存储服务通常采用业界成熟的开源方案实现，因此存在无法快速对接到互联网企业内部的名字服务系统中，实现应用服务对其的访问的问题。

为了便于应用服务访问数据存储服务，可以通过针对部署在不同IDC中的应用服务，分别管理对应的应用服务配置文件来实现应用服务。应用服务配置文件中包含应用服务所在IDC中各种类型的数据存储服务的信息，例如，包括但不限于网络地址、端口号、账户和密码等，应用服务基于所在IDC对应的应用服务配置文件，访问所在IDC上的数据存储服务。

但是在上述应用服务实现方案下，随着应用服务需要部署的IDC数量越来越多，应用服务配置文件数量也越来越多，各应用服务配置文件无法统一维护，对应用服务配置文件管理难度也越来越大。且对应用服务扩容，容器化部署(如Kubernetes)等也带来了不便。

而如果针对一个IDC进行了数据存储服务的扩缩容、移植、权值调整等操作后，需要对该IDC对应的应用服务配置文件中关于数据存储服务的信息进行更新，并需要应用服务重新加载应用服务配置文件。这样的操作流程效率低而且有一定的风险，严重制约了数据存储服务的可伸缩性。

此外，随着跨IDC的数据同步技术的落地，使得同区域(可以理解为，提供的数据存储服务相同的多个IDC组成一个区域)跨IDC实现数据存储服务的容灾成为可能。也就是说，当应用服务访问本IDC中的数据存储服务失败后，可以按一定的容灾策略访问其他IDC中的数据存储服务以达到整个应用服务系统的高可用。而在上述应用服务实现方案下，只能根据应用服务配置文件上的内容，直接访问有限的数据存储服务，无法灵活地实现跨IDC的数据存储服务访问。

为了克服上述方案的缺点所提出的改进方案为，针对数据存储服务构造一个第七层的代理服务。应用服务可以通过代理层(可以理解为代理服务所在的代理服务器)接入数据存储服务器集合。由于代理服务的存在，应用服务无须感知数据存储服务的信息，通过内部的名字服务系统获取代理服务的地址信息即可。代理服务可帮助应用服务完成鉴权认证、负载均衡、读写分离、请求代理等操作。在进行了数据存储服务的扩缩容、移植、权值调整等操作后，只需要更新代理服务中保存的数据存储服务的信息即可，并可以基于代理服务实现跨IDC的数据存储服务的容灾。

但是，多了一层转发意味着开发成本的增加，系统整体性能与可靠性的下降，以及运维难度的提升。此外，不同类型的数据存储服务需要有各自对应的代理服务，进一步增加了代理服务的开发成本，并进一步增加了运维难度。

发明内容

本公开实施例提供一种应用服务实现方法、装置、系统、介质和设备，用于解决应用服务实现时，成本高，系统整体性能和可靠性较差，且运维难度较大的问题。

第一方面，本公开提供了一种应用服务实现方法，所述方法应用于包括配置中心服务器和至少一个应用服务器的系统中，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，所述方法包括：

应用服务器响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件，基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；

根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务。

第二方面，本公开还提供了一种应用服务实现装置，所述装置应用于包括配置中心服务器和至少一个应用服务器的系统中，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，所述装置包括：

确定模块，用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件；

启动模块，用于基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；

获取模块，用于根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务。

第三方面，本公开还提供了一种应用服务实现系统，所述系统包括配置中心服务器和至少一个应用服务器，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，其中：

所述应用服务器，用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件，基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务；

所述配置中心服务器，用于保存所述数据存储服务配置文件。

第四方面，本公开还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，该可执行程序被处理器执行实现如上所述的方法。

第五方面，本公开还提供了一种应用服务实现设备，包括处理器、通信接口、存储器和通信总线，其中，所述处理器，所述通信接口，所述存储器通过所述通信总线完成相互间的通信；

所述存储器，用于存放计算机程序；

所述处理器，用于执行所述存储器上所存储的程序时，实现如上所述的方法步骤。

根据本公开实施例提供的方案，在涉及跨IDC数据同步技术的应用服务实现场景中，可以设置配置中心服务器来保存每个应用服务对应的数据存储服务配置文件。由于数据存储服务配置文件可以提供全量的，各IDC提供的数据存储服务的信息，因此不同IDC中的应用服务可以共用同一个数据存储服务配置文件，相同的应用服务配置文件可以对不同IDC中的同一应用服务实现通用。针对部署在任意IDC的应用服务器上的一个应用服务，可以统一设置应用服务配置文件，该应用服务配置文件包括访问配置中心服务器中保存的、该应用服务对应的数据存储服务配置文件的路径的访问路径信息。

这样，任意一个应用服务器基于相同的应用服务配置文件启动该应用服务时，可以基于应用服务配置文件包括的访问路径信息，访问配置中心服务器，从配置中心服务器获取数据存储服务配置文件，实现对该应用服务对应的每个数据存储服务的信息的获取。使得后续可以基于获取的数据存储服务的信息，针对该应用服务，实现对数据存储服务的访问。

本公开实施例提供的方案，由于无需通过代理服务实现应用服务对数据存储服务的访问，可以有效降低开发成本，避免应用服务实现过程中，系统整体性能与可靠性的下降，并可以有效降低运维难度。

当然，由于本公开实施例提供的方案，可以基于统一设置的应用服务配置文件，来实现一个应用服务，还可以减少应用服务配置文件数量，降低应用服务配置文件管理难度，减少对应用服务扩容，容器化部署等带来的不便。而由于通过配置中心服务器来保存数据存储服务配置文件，可以保证对数据存储服务的任意操作，对于应用服务的透明性，避免对数据存储服务可伸缩性的制约。并可以基于配置中心服务器保存的信息全面的数据存储服务配置文件，保证跨IDC的数据存储服务访问的灵活性。

本公开的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开而了解。本公开的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为本公开实施例提供的应用服务实现过程示意图；

图2为本公开实施例提供的应用服务实现过程示意图；

图3为本公开实施例提供的应用服务实现系统的结构示意图；

图4为本公开实施例提供的应用服务实现方法的步骤流程图；

图5(a)～图5(d)为本公开实施例提供的子数据存储服务配置文件以及映射关系表的示意图；

图6(a)～图6(b)为本公开实施例提供的子数据存储服务配置文件的示意图；

图7为本公开实施例提供的数据存储服务配置文件的处理过程示意图；

图8为本公开实施例提供的应用服务实现装置的结构示意图；

图9为本公开实施例提供的应用服务实现设备的结构示意图。

具体实施方式

为了使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开作进一步地详细描述，显然，所描述的实施例仅仅是本公开的一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

需要说明的是，在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面，先对本公开各实施例中涉及的几个概念进行简单说明。

互联网数据存储与流通中心：IDC，可以但不限于理解为提供网络服务的服务器托管机房；

应用服务配置文件：可以理解为业务方开发的应用服务，在启动时所依赖的、包括应用服务各种配置信息的配置文件；

数据存储服务配置文件：可以理解为保存在配置中心服务器中，包括应用服务对应的每个数据存储服务的信息的文件。可以理解为需要获取数据存储服务配置文件，即，需要获取应用服务对应的每个数据存储服务的信息，以完成应用服务根据应用服务配置文件的初始化。

相关技术方案中，通过针对部署在不同IDC中的应用服务，负责人员分别管理对应的应用服务配置文件，来实现应用服务的过程示意图可以如图1所示。

如图1所示，针对部署在IDC1中的应用服务(为了更好地示意，可以假设应用服务器1和应用服务器2均提供该应用服务)，需要生成IDC1对应的应用服务配置文件1，应用服务可以基于应用服务配置文件1启动。由于应用服务配置文件1中，包含IDC1中的数据存储服务器集合1提供的各种类型的数据存储服务的信息，应用服务可以基于应用服务配置文件1，针对指定类型的数据存储服务，访问IDC1中的数据存储服务器集合1，实现对数据存储服务的访问。

而针对部署在IDC2中的同一种应用服务(为了更好地示意，可以假设应用服务器3和应用服务器4均提供该应用服务)，需要生成IDC2对应的应用服务配置文件2，应用服务可以基于应用服务配置文件2启动。由于应用服务配置文件2中，包含IDC2中的数据存储服务器集合2提供的各种类型的数据存储服务的信息，应用服务可以基于应用服务配置文件2，针对指定类型的数据存储服务，访问IDC2中的数据存储服务器集合2，实现对数据存储服务的访问。

而除了应用服务配置文件管理难度较大，应用服务扩容，容器化部署不便，数据存储服务的可伸缩性受限之外，在如图1所示的方案中，即使数据存储服务器集合1和数据存储服务器集合2实现了跨IDC的数据同步，位于不同IDC中的应用服务根据其对应的应用服务配置文件上的内容，也只能直接访问有限的数据存储服务，并不能灵活地实现跨IDC的数据存储服务访问。

相关技术方案中，基于应用服务通过代理层(可以理解为代理服务所在的代理服务器)接入数据存储服务器集合，来实现应用服务的过程示意图可以如图2所示。在实现应用服务的过程中，负责人员根据对数据存储服务的操作，如部署、移植或扩缩容等，对代理服务器中保存的数据存储服务的信息进行更新。

如图2所示，部署在IDC1中的应用服务(与图1相同，仍假设应用服务器1和应用服务器2提供该应用服务)可以通过代理服务所在的代理服务器1访问数据存储服务器集合1。如果数据存储服务器集合1和数据存储服务器集合2实现了跨IDC的数据同步，还可以基于代理服务器1访问数据存储服务器集合2。

部署在IDC2中的同一种应用服务(与图1相同，仍假设应用服务器3和应用服务器4提供该应用服务)可以通过代理服务所在的代理服务器2访问数据存储服务器集合2。如果数据存储服务器集合1和数据存储服务器集合2实现了跨IDC的数据同步，还可以基于代理服务器2访问数据存储服务器集合1。

但是这种方案不可避免地存在开发成本高，系统整体性能与可靠性下降，运维难度较大的问题。

为了解决应用服务实现过程中，存在的开发成本高，系统整体性能与可靠性下降，运维难度较大的问题，同时保证应用服务可以快速可靠地发现多IDC部署的多类型开源数据存储服务，还能对应用服务透明地操作，如部署、扩缩容、迁移数据存储服务，并降低应用服务配置文件管理难度，减少应用服务扩容，容器化部署的不便，本公开实施例提供一种应用服务实现系统。

所述系统包括配置中心服务器01和至少一个应用服务器02，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，以图3为例，可以假设所述系统包括4个应用服务器02(分别记为应用服务器02-1～02-4)，应用服务器02-1～02-2位于IDC1，应用服务器02-3～02-4位于IDC2，其中：

所述应用服务器02，用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件，基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务；

所述配置中心服务器01，用于保存所述数据存储服务配置文件。

以图3为例，在一种可能的实现方式中，配置中心服务器01可以部署于IDC1和IDC2之外。

在一种可能的实现方式中，所述系统还包括配置中心代理服务器03：

所述应用服务器02，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，包括：向所述配置中心代理服务器发送配置文件订阅请求，该配置文件订阅请求携带所述访问路径信息；并从所述配置中心代理服务器获取所述数据存储服务配置文件；

所述配置中心代理服务器03，用于根据所述访问路径信息，访问所述配置中心服务器，从所述配置中心服务器拉取所述数据存储服务配置文件。

以图3为例，在一种可能的实现方式中，可以针对IDC1和IDC2分别部署一个配置中心代理服务器03(可以分别记为配置中心代理服务器03-1和配置中心代理服务器03-2)，针对每个IDC部署的配置中心代理服务器03可以部署于该IDC中。

且在图3中，以应用服务器02-1直接访问配置中心服务器01，从配置中心服务器获取数据存储服务配置文件，应用服务器02-2通过配置中心代理服务器03-1，从配置中心服务器01获取数据存储服务配置文件，应用服务器02-3和02-4均分别通过配置中心代理服务器03-2，从配置中心服务器01获取数据存储服务配置文件为例进行了示意。

进一步的，在一种可能的实现方式中，所述配置中心服务器01，还用于更新所述数据存储服务配置文件；并，

将更新后的数据存储服务配置文件推送至所述应用服务器，或者，根据所述应用服务器的定时访问，提供更新后的数据存储服务配置文件。

需要说明的是，在一种可能的实现方式中，所述系统还可以包括至少一个数据存储服务器集合04；

所述至少一个数据存储服务器集合04，用于提供所述数据存储服务配置文件对应的数据存储服务；

所述应用服务器02，还用于响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，根据查找出的数据存储服务的信息，访问所述至少一个数据存储服务器集合提供的数据存储服务，其中，所述数据存储服务信息列表为根据所述数据存储服务配置文件格式，解析所述数据存储服务配置文件获得的。

以图3为例，所述系统还可以包括IDC1中的数据存储服务器集合04-1，以及IDC2中的数据存储服务器集合04-2，应用服务器02-1～02-4可以通过数据存储服务器集合04-1以及数据存储服务器集合04-2，实现对数据存储服务的访问。

另外，在一种可能的实现方式中，所述配置中心服务器01还保存有针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系；

若预先配置的路由策略包括对与应用服务属于同一区域内的数据存储服务的访问，则，所述应用服务器02，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，包括：

根据所在的互联网数据存储与流通中心以及获取的所述对应关系，确定针对每一种类型的数据存储服务，所述应用服务所在的区域；

针对每一种类型的数据存储服务，根据确定出的所述应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

在一种可能的实现方式中，所述配置中心服务器01保存针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系，包括：

针对每种类型的数据存储服务，保存一个互联网数据存储与流通中心与区域的映射关系表；或者，将数据存储服务所在区域信息，作为数据存储服务配置文件包括的数据存储服务的信息中的一部分。

在通过如图3所示系统实现应用服务的过程中，应用服务负责人员可以对应用服务配置文件进行管理，数据存储服务负责人员可以在数据存储服务器集合04-1和04-2上，对数据存储服务执行任意操作，并根据对数据存储服务执行的操作，来在配置中心服务器中生成或更新数据存储服务配置文件。例如，如果针对一个应用服务进行了数据存储服务部署，则可以在配置中心服务器中生成数据存储服务配置文件，如果对已经部署的数据存储服务进行了移植，或者进行了数据存储服务的扩缩容，那么可以在配置中心服务器中更新数据存储服务配置文件。

基于同一发明构思，本公开实施例提供一种应用服务实现方法。所述方法可以应用于上述系统中的应用服务器中，该方法的步骤流程可以如图4所示，包括：

步骤101、应用服务器响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件。

可以理解为，在本步骤中，应用服务器可以对携带应用服务标识的应用服务启动请求进行响应，确定该请求中携带的应用服务标识对应的应用服务配置文件。

可以理解为，一个应用服务配置文件与一个应用服务标识对应，即与一个应用服务对应。该应用服务部署在任意一个IDC的任意一个应用服务器中，应用服务器都可以响应于该应用服务对应的启动请求，确定出相同的应用服务配置文件。

也就是说，针对不同IDC，同一应用服务对应的应用服务配置文件是相同的。从而可以有效减少应用服务配置文件数量，实现针对同一应用服务的应用服务配置文件的统一维护，降低应用服务配置文件管理难度，并减少应用服务扩容，容器化部署的不便。

为了保证针对不同IDC，同一应用服务对应的应用服务配置文件唯一性，并保证多IDC部署的多类型开源数据存储服务可以快速可靠地被应用服务发现，同时实现操作数据存储服务对于应用服务的透明性，在本实施例中，可以利用配置中心服务器保存数据存储服务配置文件，而将访问配置中心服务器中保存的数据存储服务配置文件的路径的访问路径信息写入应用服务配置文件。

也就是说，在本实施例中，应用服务配置文件中可以包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息。访问路径信息可以根据需要设置，例如，若配置中心服务器采用etcd分布式数据库，那么访问路径信息可以为数据存储服务配置文件在etcd上的键值(key)。而若配置中心服务器采用开源分布式配置中心阿波罗(Apollo)，那么访问路径信息可以为数据存储服务配置文件在Apollo上相应的配置文件名(namespace)。

另外，可以理解为，数据存储服务配置文件对应的数据存储服务，是实现跨IDC的数据同步的每个数据存储服务器集合提供的。数据存储服务配置文件可以提供全量的，各实现数据同步的IDC提供的数据存储服务的信息，以使得不同IDC中的应用服务可以共用同一份数据存储服务配置文件，也就使得相同的应用服务配置文件可以对不同IDC中的同一应用服务实现通用。

即，数据存储服务配置文件包括应用服务对应的每个数据存储服务的信息，数据存储服务配置文件对应的数据存储服务，为实现跨IDC的数据同步的每个数据存储服务器集合提供的(每个数据存储服务器集合分别对应一个IDC)。

这样，可以通过配置中心服务器实现应用服务和数据存储服务的合理解耦。可以由配置中心服务器提供对数据存储服务的相关信息的集中管理、存储、更新与发布服务。在通过配置中心服务器提供信息全面的数据存储服务配置文件，保证多IDC部署的多类型开源数据存储服务可以快速可靠地被应用服务发现的情况下，还可以使得对数据存储服务的任意操作，都可以保证对于应用服务的透明性。

步骤102、基于应用服务配置文件启动应用服务标识对应的应用服务。

由于应用服务配置文件包括应用服务各种配置信息，在本步骤中，应用服务器可以基于应用服务配置文件启动应用服务标识对应的应用服务。并可以在启动应用服务后，可以继续执行步骤103，以完成应用服务的初始化。

步骤103、根据应用服务配置文件包括的访问路径信息，访问配置中心服务器，从配置中心服务器获取数据存储服务配置文件。

由于应用服务的初始化还需要获得该应用服务对应的每个数据存储服务的信息，因此在本步骤中，应用服务器可以根据应用服务配置文件包括的访问路径信息，访问配置中心服务器，从配置中心服务器获取数据存储服务配置文件，以完成应用服务的初始化。使得后续可以针对应用服务，根据获取的数据存储服务配置文件访问数据存储服务，以实现应用服务。

需要说明的是，在本实施例中，应用服务器根据应用服务配置文件包括的访问路径信息，可以直接访问配置中心服务器，也可以通过配置中心代理服务器，实现对配置中心服务器的访问。

应用服务器根据应用服务配置文件包括的访问路径信息，直接访问配置中心服务器，可以理解为应用服务器中包括相应的配置中心服务器应用程序接口(API)，以实现对配置中心服务器的访问。

如果应用服务器中缺少相应的配置中心服务器API，或者需要分散配置中心服务器的访问压力，此时可以通过配置中心代理服务器，实现对配置中心服务器的访问。

此时可以理解为，在一种可能的实现方式中，应用服务器可以根据应用服务配置文件包括的访问路径信息，访问配置中心服务器，可以包括：

向配置中心代理服务器发送配置文件订阅请求，该配置文件订阅请求携带访问路径信息；并从配置中心代理服务器获取数据存储服务配置文件，该数据存储服务配置文件为配置中心代理服务器根据访问路径信息，访问配置中心服务器，从配置中心服务器拉取的。

也就是说，应用服务器可以通过配置中心代理服务器，建立对数据存储服务配置文件的订阅，配置中心代理服务器可以代理应用服务器对配置中心服务器发起访问，请求获取相应的数据存储服务配置文件。

当然，无论应用服务器是直接访问配置中心服务器，还是通过配置中心代理服务器访问配置中心服务器，其最终获得的数据存储服务配置文件是相同的，均包括应用服务对应的全量的、各IDC对应的数据存储服务的信息。

另外需要说明的是，在一种可能的实现方式中，针对每个应用服务，配置中心服务器可以提供同一个数据存储服务配置文件，使得每个应用服务配置文件中包括的访问路径信息可以相同，简化对应用服务配置文件的配置。此时，数据存储服务配置文件可以包括跨IDC数据同步的每个数据存储服务器集合所提供的每个数据存储服务的信息。

考虑到数据存储服务配置文件数据量过大，会导致应用服务器获取不便，且考虑到每个应用服务需要访问的数据存储服务可能存在不同，会存在数据冗余，因此，可以针对不同的应用服务，来分别保存数据存储服务配置文件。

也就是说，在一种可能的实现方式中，配置中心服务器可以针对每个应用服务，分别提供一个数据存储服务配置文件。此时，一个应用服务对应的数据存储服务配置文件，可以仅包括该应用服务对应的、跨IDC数据同步的每个数据存储服务器集合提供的、每个数据存储服务的信息。

而进一步地，考虑到应用服务需要按照数据存储服务的类型来访问数据存储服务，为了更加便于针对数据存储服务的类型来查找数据存储服务，加快数据存储服务查找速度，因此，可以进一步根据数据存储服务的类型，来保存数据存储服务配置文件。

也就是说，在一种可能的实现方式中，配置中心服务器针对每个应用服务提供的数据存储服务配置文件，可以包括至少一个子数据存储服务配置文件。此时，一个应用服务对应的一个子数据存储服务配置文件，可以仅包括该应用服务对应的、跨IDC数据同步的每个数据存储服务器集合提供的、同一类型的数据存储服务的信息。

另外需要说明的是，若针对一个应用服务初始部署数据存储服务(也可以记为数据存储服务实例)，需要将相应的数据存储服务的信息记录在相应的数据存储服务配置文件上，以保证每个应用服务对应的数据存储服务配置文件的信息全面性。数据存储服务配置文件中保存的数据存储服务的信息，可以按照设定，包括数据存储服务的任意信息，例如，可以但不限于包括数据存储服务对应的互联网协议(IP)地址、端口号、服务账号与鉴权信息、所在区域、所在IDC和状态信息等等中的至少一种。

当然，若在初始部署之后，对应用服务对应的数据存储服务进行了其它操作，例如，扩缩容后，需要更新相应的数据存储服务配置文件，以保证每个应用服务对应的数据存储服务配置文件的信息准确性。

例如，若需要对数据存储服务进行扩容，可以部署新的数据存储服务，并可以登录配置中心服务器，例如，登录配置中心页面，修改相应的数据存储服务配置文件，增加新部署的数据存储服务的信息并发布，以实现对数据存储服务配置文件的更新。

若需要对数据存储服务进行缩容，可以登录配置中心服务器，例如，登录配置中心页面，修改相应的数据存储服务配置文件，删除需要下线的数据存储服务的信息并发布，以实现对数据存储服务配置文件的更新。并可以进一步下线相应的数据存储服务。

数据存储服务配置文件更新后，可以基于配置中心服务器的推送功能或者应用服务器的定时拉取功能，使得应用服务器可以获取更新后的数据存储服务配置文件。由此也可以看出，由于通过配置中心服务器对应用服务和数据存储服务进行了解耦，数据存储服务可以对应用服务透明地实现扩缩容。

综合上述内容可以理解为，在一种可能的方式中，应用服务器可以接收配置中心服务器响应于更新数据存储服务配置文件，推送的更新后的数据存储服务配置文件；或者，定时访问配置中心服务器，从配置中心服务器获取更新后的数据存储服务配置文件。

此外，应用服务器针对一个应用服务，获取相应的数据存储服务配置文件之后，本实施例还可以进一步包括以下步骤：

步骤104、响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息。

需要说明的是，应用服务器针对一个应用服务，获取相应的数据存储服务配置文件之后，可以根据数据存储服务配置文件格式，解析数据存储服务配置文件获得数据存储服务信息列表，以便于后续可以根据数据存储服务信息列表来查找数据存储服务的信息，实现对数据存储服务的访问。

在本步骤中，可以根据应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息。

需要说明的是，本公开对获取数据存储服务信息列表的时机不做限定，在一种可能的实现方式中，可以是在获取数据存储服务配置文件之后，立即解析数据存储服务配置文件，获取数据存储服务信息列表。在另一种可能的实现方式中，也可以是在接收到应用服务对应的数据存储服务访问请求时，解析数据存储服务配置文件，获取数据存储服务信息列表。

预先配置的路由策略可以是任意的路由策略。例如，可以但不限于为访问与应用服务位于同一IDC的数据存储服务，访问与应用服务位于同一区域的数据存储服务，或者，优先访问与应用服务位于同一IDC的数据存储服务，并在访问失败后，访问与应用服务位于同一区域的其它数据存储服务等中的任意一种。

需要说明的是，若预先配置的路由策略包括对与应用服务属于同一区域内的数据存储服务的访问，由于针对每种类型的数据存储服务，区域的组成可能不同，此时，配置中心服务器还可以保存有针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系。

此时，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，可以包括：

根据所在的互联网数据存储与流通中心以及获取的对应关系，确定针对每一种类型的数据存储服务，应用服务所在的区域；

针对每一种类型的数据存储服务，根据确定出的应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

配置中心服务器保存针对每一种类型的数据存储服务，建立的每个互联网数据存储与流通中心与区域的对应关系，可以通过任意方式实现。例如，可以但不限于通过以下两种方式实现：

方式一、在配置中心服务器中，针对每种类型的数据存储服务，均保存一个IDC与区域的映射关系表。

例如，假设针对通过redis实现的数据存储服务，应用服务A对应的子数据存储服务配置文件如图5(a)所示，该子数据存储服务配置文件可以记为Redis for ProjectA。

该子数据存储服务配置文件可以理解为记录了应用服务A对应的、通过redis实现的每个数据存储服务(分别记为Node1、Node2、Node3、Node4、Node5……)的信息(该信息包括IP、端口号和所在IDC标识)。

此时在配置中心服务器中，还可以包括针对应用服务A如图5(a)所示的子数据存储服务配置文件，配置的IDC与区域的映射关系表，该映射关系表可以如图5(b)所示，可以记为Redis’s IDC to Region Map。

该映射关系表可以理解为记录了标识为HK-01的IDC，对应标识为HK的区域，标识为HK-02的IDC，也对应标识为HK的区域，标识为SG-01的IDC，对应标识为SG的区域，标识为SG-02的IDC，也对应标识为SG的区域，并可以记录应用服务A对应的、通过redis实现的数据存储服务涉及的其他IDC与区域的对应关系。

假设针对通过MySQL实现的数据存储服务，应用服务A对应的子数据存储服务配置文件如图5(c)所示，该子数据存储服务配置文件可以记为MySQL for ProjectA。

该子数据存储服务配置文件可以理解为记录了应用服务A对应的、通过MySQL实现的每个数据存储服务(分别记为Node1、Node2、Node3、Node4、Node5……)的信息(该信息包括IP、端口号和所在IDC标识)。

此时在配置中心服务器中，还可以包括针对应用服务A如图5(c)所示的子数据存储服务配置文件，配置的IDC与区域的映射关系表，该映射关系表可以如图5(d)所示，可以记为MySQL’s IDC to Region Map。

该映射关系表可以理解为记录了标识为HK-01的IDC，标识为HK-02的IDC，标识为SG-01的IDC以及标识为SG-02的IDC，均对应标识为Asis_Pacific的区域，并可以记录应用服务A对应的、通过MySQL实现的数据存储服务涉及的其他IDC与区域的对应关系。

应用服务A所在的一个应用服务器，获取如图5(a)和图5(c)所示的子数据存储服务配置文件，并获取如图5(b)和图5(d)所示的每张映射关系表之后，可以根据获取的映射关系表，来获取针对每一种类型的数据存储服务，IDC与区域的对应关系。

在对应用服务A的初始化阶段，可以根据自身所在的IDC(也就是该应用服务器上部署的应用服务A所在的IDC)以及获取的对应关系，索引出针对通过redis实现的数据缓存服务，以及针对通过MySQL实现的数据存储服务，该应用服务器上部署的应用服务A所在的区域。

例如，假设应用服务A所在的一个应用服务器所在IDC标识为HK-01，那么应用服务A通过该应用服务器发起redis类型数据存储服务访问请求时，其所在的区域标识为HK。而若应用服务A通过该应用服务器发起MySQL类型数据存储服务访问请求，其所在的区域标识为Asis_Pacific。

确定出应用服务A所在的区域之后，即可以针对redis类型和MySQL类型的数据存储服务，根据确定出的应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

当然，与应用服务A对应的每张映射关系表类似的，其它应用服务，例如应用服务B、应用服务C也可以分别对应类似的映射关系表。

需要说明的是，除了针对每个应用服务，分别针对每一种类型的数据存储服务，建立IDC与区域的映射关系表，以便于针对一个应用服务，可以更加迅速地查找IDC与区域的映射关系之外，也可以针对所有应用服务，统一针对每一种类型的数据存储服务，建立IDC与区域的映射关系表，使得可以减少映射关系表的数量，便于对映射关系表的管理。

另外，需要说明的是，针对同一种类型的数据存储服务，例如，通过redis实现的数据存储服务，或者，通过MySQL实现的数据存储服务，共用同一个子数据存储服务配置文件可以统一区域的概念，而针对每一种类型的数据存储服务分别配置一张映射关系表，可以解决不同类型的数据存储服务对于区域组成的差异化问题。

方式二、将数据存储服务所在区域信息，作为数据存储服务配置文件包括的数据存储服务的信息中的一部分。

例如，假设针对通过redis实现的数据存储服务，应用服务A对应的子数据存储服务配置文件如图6(a)所示，与图5(a)类似的，该子数据存储服务配置文件可以记为Redisfor ProjectA。

假设针对通过MySQL实现的数据存储服务，应用服务A对应的子数据存储服务配置文件如图6(b)所示，与图5(b)类似的，该子数据存储服务配置文件可以记为MySQL forProjectA。

可以理解为，在一种可能的实现方式中，可以在每个子数据存储服务配置文件中，按照区域来记录每个数据存储服务(Node1、Node2、Node3、Node4、Node5……)的其他信息。

如图6(a)所示，可以按照区域(Region：HK)来记录每个数据存储服务(Node1、Node2、Node3)的其他信息(包括IP、端口号和所在IDC)，并可以按照区域(Region：SG)来记录每个数据存储服务(Node4、Node5)的其他信息。

如图6(b)所示，可以按照区域(Region：Asis_Pacific)来记录每个数据存储服务(Node1、Node2、Node3、Node4、Node5……)的其他信息(包括IP、端口号和所在IDC)。

应用服务A所在的一个应用服务器，获取如图6(a)和图6(b)所示的子数据存储服务配置文件之后，可以通过子数据存储服务配置文件的解析，获取IDC与区域的对应关系。

在对应用服务A的初始化阶段，可以根据自身所在的IDC(也就是该应用服务器上部署的应用服务A所在的IDC)以及获取的对应关系，索引出针对通过redis实现的数据缓存服务，以及针对通过MySQL实现的数据存储服务，该应用服务器上部署的应用服务A所在的区域。

例如，假设应用服务A所在的一个应用服务器所在IDC标识为HK-01，那么应用服务A通过该应用服务器发起redis类型数据存储服务访问请求时，其所在的区域标识为HK。

若预先配置的路由策略为优先访问与应用服务位于同一IDC的数据存储服务，并在访问失败后，访问与应用服务位于同一区域的其它数据存储服务，那么，由于Node1和Node2与该应用服务器上部署的应用服务A属于同一IDC，可以该应用服务器可以针对应用服务A，优先访问Node1和Node2，并在访问失败后，访问与应用服务A均属于HK区域的Node3，通过Node3实现容灾访问。

也就是说，确定出应用服务A所在的区域之后，即可以针对redis类型和MySQL类型的数据存储服务，根据确定出的应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

可以理解为，根据配置中心服务器保存针对每一种类型的数据存储服务，建立的IDC与区域的对应关系的方式的不同，应用服务器从配置中心服务器获取IDC与区域的对应关系，也可以通过不同方式来实现。

例如，若在配置中心服务器中，针对每种类型的数据存储服务，均配置一个IDC与区域的映射关系表，那么可以基于获取的映射关系表，获取IDC与区域的对应关系。

而获取映射关系表，在一种可能的实现方式中，可以是在获取数据存储服务配置文件的同时，获取映射关系表。在另一种可能的实现方式中，也可以是分别获取数据存储服务配置文件和映射关系表，此时，可以理解为，应用服务配置文件还包括获取映射关系表的访问路径信息。

又如，若在配置中心服务器中，将区域信息作为数据存储服务配置文件包括的数据存储服务的信息中的一部分，那么可以通过对数据存储服务配置文件的解析获取IDC与区域的对应关系。

步骤105、根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的数据存储服务。

在本步骤中，应用服务器可以根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的数据存储服务，以实现应用功能。

根据预先配置的路由策略不同，在本步骤中，可以理解为可以实现对数据存储服务的访问，并可以实现对数据存储服务的容灾访问。

需要进一步说明的是，对数据存储服务配置文件进行解析来获得数据存储服务信息列表，可以是通过配置分析器(Config Parser)来实现的。

最新的数据存储服务配置文件在配置中心服务器发布后，应用服务器可以通过配置中心客户端，利用配置中心服务器相应的API，获取最新的数据存储服务配置文件(当然，如果是通过配置中心代理服务器从配置中心服务器获取最新的数据存储服务配置文件，那么应用服务器可以通过配置中心客户端，利用配置中心代理服务器相应的API，获取最新的数据存储服务配置文件)。并可以通过Config Parser来解析获取的数据存储服务配置文件。不同格式的数据存储服务配置文件需要开发不同的Config Parser来实现解析。

如果一个数据存储服务配置文件包括针对数据存储服务的不同类型的多个子数据存储服务配置文件，那么针对每个子数据存储服务配置文件，如果格式不同，需要开发不同的Config Parser来分别实现解析。

假设数据存储服务的类型包括通过redis实现的数据存储服务、通过MySQL实现的数据存储服务以及通过New DB实现的数据存储服务(用于统一标识通过其他方式实现的数据存储服务)，针对上述每个类型的数据存储服务，数据存储服务配置文件均包括一个对应的子数据存储服务配置文件，每个子数据存储服务配置文件的格式不同，那么需要针对每种格式的子数据存储服务配置文件，分别开发一个对应的Config Parser来实现解析，在本实施例中，分别开发的Config Parser可以记为Redis Config Parser、MySQL ConfigParser以及New Config Parser。通过相应的Config Parser解析子数据存储服务配置文件得到的数据存储服务信息列表可以分别记为Redis实例列表(Instance List)、MySQL实例列表以及New DB实例列表。

为了进一步降低开发成本，保证Config Parser的通用性，并增强系统的可扩展性，可以将每个子数据存储服务配置文件的格式设置为相同。这样，通过一个ConfigParser即可以实现对每个子数据存储服务配置文件的解析。

通过开发的Config Parser对数据存储服务配置文件的解析，可以获得全网全量的数据存储服务信息列表，可以用于实现访问数据存储服务时的寻址。

应用服务器响应于应用服务对应的数据存储服务访问请求，如果该访问请求需要访问redis类型的数据存储服务，那么可以通过相应的访问模块(可以记为Redis Caller)来访问预先配置的路由策略(Routing strategy)，并根据预先配置的路由策略，从Redis实例列表中查找redis类型的数据存储服务的信息，根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的redis类型的数据存储服务，提供redis类型的数据存储服务的数据存储服务器可以记为Redis Server。

如果该访问请求需要访问MySQL类型的数据存储服务，那么可以通过相应的访问模块(可以记为MySQL Caller)来访问预先配置的路由策略(Routing strategy)，并根据预先配置的路由策略，从MySQL实例列表中查找MySQL类型的数据存储服务的信息，根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的MySQL类型的数据存储服务，提供MySQL类型的数据存储服务的数据存储服务器可以记为MySQL Server。

如果该访问请求需要访问New DB类型的数据存储服务，那么可以通过相应的访问模块(可以记为New DB Caller)来访问预先配置的路由策略(Routing strategy)，并根据预先配置的路由策略，从New DB实例列表中查找New DB类型的数据存储服务的信息，根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的New DB类型的数据存储服务，提供New DB类型的数据存储服务的数据存储服务器可以记为New DB Server。数据存储服务配置文件的处理过程示意图可以如图7所示。

而相比于基于应用服务通过代理层接入数据存储服务器集合，来实现应用服务，在增加了新的类型的数据存储服务之后，无需开发与部署相应的代理服务，只需要在配置中心服务器保存的数据存储服务配置文件中，增加保存该种类型的数据存储服务的信息，即可以通过对数据存储服务配置文件的解析，发现该种类型的数据存储服务并发起访问，实现新类型的数据存储服务的快速接入和容灾访问。

根据本公开实施例提供的方案，可以在应用服务器中嵌入相应的API来对接配置中心服务器或者配置中心代理服务器，拉取全量的、各IDC对应的数据存储服务配置信息，再根据可配置的路由策略访问数据存储服务。该方案可采用开源的配置中心服务器方案，实现成本低。

一方面，应用服务负责人只需在统一的应用服务配置文件中写入数据存储服务配置文件的访问路径信息，无论哪个IDC内的应用服务都依赖同样的应用服务配置文件启动。另一方面，数据存储服务负责人(如，DBA)只需在数据存储服务扩容升级后，更新配置中心服务器上的数据存储服务配置文件，即可以使得应用服务动态地感知存储服务的变化，及时地调整访问对象。

此外，数据存储服务配置文件中可以包括各数据存储服务所在IDC、区域等信息，可以基于这些信息实现应用服务跨IDC访问数据存储服务，以此达到对数据存储服务的容灾访问。

另外，本公开仅需要引入配置中心服务器作为数据存储服务的配置管理系统，统一拉取全网全量的数据存储服务信息与IDC-区域对应关系，就可以解决部署在不同IDC的不同类型开源数据存储服务的接入问题，降低应用服务配置文件的管理成本，快速实现对数据存储服务的跨区域容灾访问。在保证最低的开发与运维成本的基础上，提升整个系统的可用性与可扩展性。

本公开通过引入配置中心服务器实现了应用服务与数据存储服务的解耦，配置中心服务器记录了全网全量的数据存储服务信息，有效解决了对基于开源方案的数据存储服务的发现问题，可以帮助应用服务统一配置文件，有助于应用服务扩容以及容器化部署，也方便了数据存储服务的移植、变更与扩缩容。

随着跨IDC的数据同步技术的落地，由于可以提供全量的数据存储服务信息，并可以提供兼容不同类型数据存储服务的区域定位方法，应用服务可以根据路由容灾策略选择合适的访问对象，实现跨IDC的数据存储服务访问。

相较于目前的通过代理层接入数据存储服务器集合的技术方案，本公开无需针对不同类型的数据存储服务单独研发与运维一个代理服务，提供一种更通用的接入方案-只需在配置中心服务器上传该类型数据存储服务的全量实例配置文件，即可以通过开发的Config Parser，发现该类型的数据存储服务，发起访问以及容灾访问，实现新类型的数据存储服务的快速接入，增加系统的可扩展能力。

与提供的方法对应的，进一步提供以下的装置。

本公开实施例提供一种应用服务实现装置，该装置可以集成在应用服务器中，所述装置应用于包括配置中心服务器和至少一个应用服务器的系统中，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，该装置的结构可以如图8所示，包括：

确定模块11用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件；

启动模块12用于基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；

获取模块13用于根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务。

在一种可能的实现方式中，所述获取模块13访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，包括：向配置中心代理服务器发送配置文件订阅请求，该配置文件订阅请求携带所述访问路径信息；并从所述配置中心代理服务器获取所述数据存储服务配置文件，该数据存储服务配置文件为所述配置中心代理服务器根据所述访问路径信息，访问所述配置中心服务器，从所述配置中心服务器拉取的。

在一种可能的实现方式中，所述获取模块13还用于接收所述配置中心服务器响应于更新所述数据存储服务配置文件，推送的更新后的数据存储服务配置文件；或者，定时访问所述配置中心服务器，从所述配置中心服务器获取更新后的数据存储服务配置文件。

在一种可能的实现方式中，所述装置还包括解析模块14、查找模块15和访问模块16，其中：

所述解析模块14，用于根据所述数据存储服务配置文件格式，解析所述数据存储服务配置文件获得数据存储服务信息列表；

所述查找模块15，用于响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息；

所述访问模块16，用于根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的数据存储服务。

在一种可能的实现方式中，所述配置中心服务器还保存有针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系；

若预先配置的路由策略包括对与应用服务属于同一区域内的数据存储服务的访问，所述查找模块15，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，包括：

根据所在的互联网数据存储与流通中心以及获取的所述对应关系，确定针对每一种类型的数据存储服务，所述应用服务所在的区域；

针对每一种类型的数据存储服务，根据确定出的所述应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

在一种可能的实现方式中，所述配置中心服务器保存针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系，包括：

在配置中心服务器中，针对每种类型的数据存储服务，保存一个互联网数据存储与流通中心与区域的映射关系表；或者，将数据存储服务所在区域信息，作为数据存储服务配置文件包括的数据存储服务的信息中的一部分。

本公开上述实施例提供的各装置的各功能单元的功能，可以通过上述对应的各方法的步骤来实现，因此，本公开实施例提供的各装置中的各个功能单元的可能的工作过程和有益效果，在此不复赘述。

基于同一发明构思，本公开实施例提供以下的设备和介质。

本公开实施例提供一种应用服务实现设备，该设备的结构可以如图9所示，包括处理器21、通信接口22、存储器23和通信总线24，其中，所述处理器21，所述通信接口22，所述存储器23通过所述通信总线24完成相互间的通信；

所述存储器23，用于存放计算机程序；

所述处理器21，用于执行所述存储器上所存储的程序时，实现本公开上述方法实施例所述的步骤。

可选的，所述处理器21可以包括中央处理器(CPU)、特定应用集成电路(ASIC，Application Specific Integrated Circuit)，可以是一个或多个用于控制程序执行的集成电路，可以是使用现场可编程门阵列(FPGA，Field Programmable Gate Array)开发的硬件电路，可以是基带处理器。

可选的，所述处理器21可以包括至少一个处理核心。

可选的，所述存储器23可以包括只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)和磁盘存储器。存储器23用于存储至少一个处理器21运行时所需的数据。存储器23的数量可以为一个或多个。

本公开实施例还提供一种非易失性计算机存储介质，所述计算机存储介质存储有可执行程序，当可执行程序被处理器执行时，实现本公开上述方法实施例提供的方法。

在可能的实施过程中，计算机存储介质可以包括：通用串行总线闪存盘(USB，Universal Serial Bus Flash Drive)、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的存储介质。

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

在本公开实施例中的各功能单元可以集成在一个处理单元中，或者各个单元也可以均是独立的物理模块。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开实施例的技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备，例如可以是个人计算机，服务器，或者网络设备等，或处理器(processor)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(Universal Serial Bus Flash Drive)、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本公开的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本公开范围的所有变更和修改。

显然，本领域的技术人员可以对本公开进行各种改动和变型而不脱离本公开的精神和范围。这样，倘若本公开的这些修改和变型属于本公开权利要求及其等同技术的范围之内，则本公开也意图包含这些改动和变型在内。

Claims (9)

1.一种应用服务实现方法，其特征在于，所述方法应用于包括配置中心服务器和至少一个应用服务器的系统中，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，所述方法包括：

应用服务器响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件，基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；

根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务；

所述方法还包括：

响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的数据存储服务，其中，所述数据存储服务信息列表为根据所述数据存储服务配置文件格式，解析所述数据存储服务配置文件获得的。

2.如权利要求1所述的方法，其特征在于，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，包括：向配置中心代理服务器发送配置文件订阅请求，该配置文件订阅请求携带所述访问路径信息；并从所述配置中心代理服务器获取所述数据存储服务配置文件，该数据存储服务配置文件为所述配置中心代理服务器根据所述访问路径信息，访问所述配置中心服务器，从所述配置中心服务器拉取的。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述配置中心服务器响应于更新所述数据存储服务配置文件，推送的更新后的数据存储服务配置文件；或者，定时访问所述配置中心服务器，从所述配置中心服务器获取更新后的数据存储服务配置文件。

4.如权利要求1所述的方法，其特征在于，所述配置中心服务器还保存有针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系；

若预先配置的路由策略包括对与应用服务属于同一区域内的数据存储服务的访问，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，包括：

根据所在的互联网数据存储与流通中心以及获取的所述对应关系，确定针对每一种类型的数据存储服务，所述应用服务所在的区域；

针对每一种类型的数据存储服务，根据确定出的所述应用服务所在的区域，从数据存储服务信息列表中查找属于同一区域的数据存储服务的信息。

5.如权利要求4所述的方法，其特征在于，所述配置中心服务器保存针对每一种类型的数据存储服务，建立的互联网数据存储与流通中心与区域的对应关系，包括：

在配置中心服务器中，针对每种类型的数据存储服务，保存一个互联网数据存储与流通中心与区域的映射关系表；或者，将数据存储服务所在区域信息，作为数据存储服务配置文件包括的数据存储服务的信息中的一部分。

6.一种应用服务实现装置，其特征在于，所述装置应用于包括配置中心服务器和至少一个应用服务器的系统中，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，所述装置包括：

确定模块，用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件；

启动模块，用于基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；

获取模块，用于根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务；

所述装置还包括解析模块、查找模块和访问模块，其中：

所述解析模块，用于根据所述数据存储服务配置文件格式，解析所述数据存储服务配置文件获得数据存储服务信息列表；

所述查找模块，用于响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从所述数据存储服务信息列表中查找数据存储服务的信息；

所述访问模块，用于根据查找出的数据存储服务的信息，访问数据存储服务器集合提供的数据存储服务。

7.一种应用服务实现系统，其特征在于，所述系统包括配置中心服务器和至少一个应用服务器，所述至少一个应用服务器对应至少一个互联网数据存储与流通中心，部署在所述至少一个应用服务器上的相同的应用服务对应同一个应用服务配置文件，其中：

所述应用服务器，用于响应于应用服务启动请求，确定该请求中携带的应用服务标识对应的应用服务配置文件，基于所述应用服务配置文件启动所述应用服务标识对应的应用服务，所述应用服务配置文件包括访问路径信息，所述访问路径信息为访问配置中心服务器中保存的数据存储服务配置文件的路径的信息；根据所述应用服务配置文件包括的访问路径信息，访问所述配置中心服务器，从所述配置中心服务器获取所述数据存储服务配置文件，所述数据存储服务配置文件包括所述应用服务对应的每个数据存储服务的信息，以便针对所述应用服务，根据所述数据存储服务配置文件访问数据存储服务；

所述配置中心服务器，用于保存所述数据存储服务配置文件；

所述应用服务器，还用于响应于所述应用服务对应的数据存储服务访问请求，根据预先配置的路由策略，从数据存储服务信息列表中查找数据存储服务的信息，根据查找出的数据存储服务的信息，访问所述至少一个数据存储服务器集合提供的数据存储服务，其中，所述数据存储服务信息列表为根据所述数据存储服务配置文件格式，解析所述数据存储服务配置文件获得的。

8.一种非易失性计算机存储介质，其特征在于，所述计算机存储介质存储有可执行程序，该可执行程序被处理器执行实现权利要求1～5任一所述的方法。

9.一种应用服务实现设备，其特征在于，所述设备包括处理器、通信接口、存储器和通信总线，其中，所述处理器，所述通信接口，所述存储器通过所述通信总线完成相互间的通信；

所述存储器，用于存放计算机程序；

所述处理器，用于执行所述存储器上所存储的程序时，实现权利要求1～5任一所述的方法步骤。