CN112492060A - 一种服务资源处理方法及系统、代理设备、请求设备 - Google Patents

Abstract

本申请中一个或多个实施例提供一种服务资源处理方法及系统、代理设备、请求设备，包括：接收访问请求；基于路由规则根据访问请求匹配目标服务应用；获取目标服务应用的访问地址并发送至请求设备；请求设备位于域内或域外。通过代理设备实现请求设备和目标服务应用的交互，去除总线设计，降低系统去中心化门槛，准确定位目标服务应用，从而避免了服务应用需要通过服务总线被访问，而服务总线一旦出现故障便会造成服务应用全部瘫痪的问题。

Description

一种服务资源处理方法及系统、代理设备、请求设备

技术领域

本申请中一个或多个实施例涉及信息技术领域，尤其涉及一种服务资源处理方法及系统、代理设备、请求设备。

背景技术

现有技术中，最普遍的ServiceMesh架构是Istio服务网络架构，运行平台为K8S。Istio本身并不实现服务发现逻辑，而是将其交予容器平台，目前K8S中使用CoreDNS服务。在Istio1.0版本中增加了对Consul+虚拟机环境的支持，但仍是基于DNS服务器完成服务解析。针对这种情况，对于Istio，应用服务必须是部署在K8S环境中，无法运行在Docker容器中或者虚拟机中；而如果选用Consul+虚拟机环境，则需要使用DNS服务器对服务名进行解析，这就存在服务名缓存更新不及时，且无法准确定位目标服务应用的问题，以及服务应用需要通过服务总线被访问，而服务总线一旦故障，则服务应用全部瘫痪的问题。

发明内容

有鉴于此，本申请中一个或多个实施例的目的在于提出一种服务资源处理方法及系统、代理设备、请求设备，以解决现有技术存在的上述至少一个问题。

基于上述目的，本申请中一个或多个实施例提供了一种服务资源处理方法，应用于代理设备，包括：

接收访问请求；

基于路由规则根据所述访问请求匹配目标服务应用；

获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。

可选的，所述获取所述目标服务应用的访问地址，之后还包括：

存储并更新所述目标服务应用的访问地址。

可选的，所述存储并更新所述目标服务应用的访问地址，之后还包括：

关联所述目标服务应用；

检测并更新所述目标服务应用的运行状态；所述目标服务应用的运行状态，包括：正常状态和故障状态。

可选的，所述检测并更新所述目标服务应用的运行状态，之后还包括：

判断所述目标服务应用的运行状态是否为所述故障状态；

若是，则根据所述目标服务应用的访问地址访问并修复所述目标服务应用。

可选的，所述基于路由规则根据所述访问请求匹配目标服务应用，之前还包括：

获取服务应用库；所述服务应用库是域内所有服务应用的集合，至少包括：所述目标服务引用；

根据所述服务应用库生成服务配置文件；

根据所述服务配置文件配置所述路由规则。

基于同一发明构思，本申请中一个或多个实施例还提出了一种服务资源处理方法，应用于请求设备，包括：

发送访问请求至代理设备；

接收目标服务应用的访问地址；所述目标服务应用的访问地址由所述代理设备根据目标服务应用获取；所述目标服务应用由所述代理设备基于路由规则根据所述访问请求匹配确定。

可选的，所述访问请求，包括：域内访问请求和/或域外访问请求；

所述发送访问请求至代理设备，具体包括：

发送所述域内访问请求至所述代理设备；

和/或

通过预设的边缘代理模块将所述域外访问请求发送至所述代理设备。

基于同一发明构思，本申请中一个或多个实施例还提出了一种代理设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现上述任意一项应用于代理设备的服务资源处理方法。

基于同一发明构思，本申请中一个或多个实施例还提出了一种请求设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现上述任意一项应用于请求设备的服务资源处理方法。

基于同一发明构思，本申请中一个或多个实施例还提出了一种服务资源处理系统，包括：至少一个上述代理设备以及至少一个上述请求设备。

从上面所述可以看出，本申请中一个或多个实施例提供的一种服务资源处理方法，应用于代理设备，包括：接收访问请求；基于路由规则根据所述访问请求匹配目标服务应用；获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。本申请能够通过代理设备实现请求设备和目标服务应用的交互，去除总线，实现设备与服务间的交互无中心瓶颈点，降低系统去中心化门槛，及时更新服务名缓存，准确定位目标服务应用，从而避免了服务应用需要通过服务总线被访问，而服务总线一旦故障，则服务应用全部瘫痪的问题。

附图说明

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

图1为本申请中一个或多个实施例中一种应用于代理设备的服务资源处理方法的流程图；

图2为本申请中一个或多个实施例中一种应用于请求设备的服务资源处理方法的流程图；

图3为本申请中一个或多个实施例中一种代理设备的示意图；

图4为本申请中一个或多个实施例中一种请求设备的示意图；

图5为本申请中一个或多个实施例中一种服务资源处理系统的示意图；

图6为本申请中一个或多个实施例中一种服务资源处理系统中代理设备实现热加载的流程图；

图7为本申请中一个或多个实施例中一种服务资源处理系统的一个具体实施方式的架构图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本申请中一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本申请中一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

为了便于理解，本申请涉及的一些名词解释如下：

ServiceMesh：服务网格；

SideCar：边车模式；

K8S(也可称为kubernetes)：一个可移植容器的编排管理工具；

DNS(也可称为Domain Name System)：域名系统；

NFS(也可称为Network File System)：网络文件系统；

ESB(也可称为Enterprise Service Bus)：企业服务总线。

申请人通过研究发现现有技术中，最流行和最普遍的ServiceMesh架构是Istio服务网格架构，其运行平台为K8S，Istio是由Google的CNCF基金发起的，从战略上看也是服务于Google云计算的。而Google在云上主推的是K8S。因此目前Istio集成最好的平台为K8S。同时Istio本身并不实现服务发现逻辑，而是将其交予容器平台，目前K8S中使用CoreDNS服务。在Istio1.0版本中增加了对Consul+虚拟机环境的支持，但仍是基于DNS服务器完成服务解析。但是对于Istio而言，应用服务必须部署在K8S环境中，而不能够运行在Docker容器中或者虚拟机中，限制了应用服务的运行环境，缺乏普适性。而如果Istio选用虚拟机环境，则需要使用DNS服务器对服务名进行解析，这就存在服务名缓存更新不及时的问题。即当应用IP变化时，DNS服务器并不能实时的刷新IP的更新。而且现有技术中的ServiceMesh架构中各个服务应用通过ESB连接，这就存在当ESB故障时，各个服务应用无法调用的问题。正因如此，本申请提供的方法使得代理设备和请求设备不通过ESB，而是直联互通，消除服务交互瓶颈点，代理设备接收到请求设备法搜时能够的访问请求后，基于路由规则根据访问请求在众多服务应用中匹配目标服务应用，在匹配成功后，获取目标服务应用的访问地址并发送至请求设备，这样，请求设备就能够根据目标服务应用的访问地址对目标服务应用进行访问，准确定位目标服务应用，代理设备实现热加载配置文件，从而及时更新服务名缓存，去除ESB实现代理设备、请求设备和目标服务应用的直联互通。

参考图1，因此本申请中一个或多个实施例提供的一种服务资源处理方法，应用于代理设备，具体包括以下步骤：

S101：接收访问请求；

S102：基于路由规则根据所述访问请求匹配目标服务应用；

S103：获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。

本实施例中，在步骤S101中，代理设备能够接收来自请求设备的访问请求，其中，请求设备可以位于域内，也可以位于域外。域，也可称为服务域，将服务应用划分为多个域，每个域可以为不同的APP。请求设备会暴露出两个端口，分别为第一接收端口和第一发送端口，同样，代理设备也会暴露出两个端口，分别为第二接收端口和第二发送端口。具体地，当请求设备位于域内时，代理设备通过第二接收端口接收请求设备通过第一发送端口发送的访问请求；当请求设备位于域外时，代理设备通过第二接收端口接收域内的边缘代理模块监听的来自请求设备通过第一发送端口发送的访问请求，从而接收到来自域内或域外的请求设备的访问请求。域内访问以及跨域的域外访问只通过代理设备的两个端口以及请求设备的两个端口进行通信，设置端口是为了应对代理设备和请求设备之间的防火墙问题、不同域之间的防火墙问题以及不同服务应用与代理设备或其他服务应用的防火墙问题，不需要申请各个服务应用、代理设备、请求设备以及不同域之间繁琐不规律的防火墙策略，不对存量应用、代理设备、请求设备以及不同域产生额外影响，对应用系统、代理设备、请求设备以及不同域低侵入性，降低了应用系统、代理设备、请求设备以及不同域去中心化门槛。

需要说明的是，在步骤S102中，当代理设备接收到访问请求后，基于路由规则根据访问请求进行目标服务应用的匹配，具体地，目标服务应用位于服务应用库中，服务应用库中包括若干个服务应用。

在一些可选的实施方式中，访问请求包括以下信息：请求设备的端口名称、请求设备所处域的域名以及要求访问的目标服务应用的名称。代理设备在服务应用库中的服务应用运行时获取根据服务应用的服务信息转换的配置文件，并根据配置文件发现服务，从而根据配置文件确定路由规则，识别请求设备的访问请求，并根据请求设备要求访问的目标服务应用的名称在服务应用库中进行匹配，从而确定目标服务应用。

需要说明的是，在步骤S103中，代理设备会根据匹配到的目标服务应用，获取目标服务应用的访问地址，并将其发送至请求设备。具体地，根据接收访问请求的路径将目标服务应用的访问地址发送至请求设备，当请求设备位于域内时，代理设备通过第二发送端口将目标服务应用的访问地址发送至请求设备的第一接收端口；当请求设备位于域外时，代理设备通过第二发送端口将目标服务应用发送至域内的边缘代理模块，再通过边缘代理模块将目标服务应用转发至请求设备的第一接收端口，从而将目标服务应用发送至请求设备。

在一些可选的实施方式中，在获取目标服务引用的访问地址之后，还能够存储所有目标服务应用的访问地址，甚至能够存储位于代理设备所在域的域内的所有服务应用的访问地址，并对需要修改的访问地址进行更新。例如，代理设备定时访问域内的所有服务应用，当根据存储的访问地址无法访问对应的服务应用时，则根据服务应用库重新获取原访问地址对应的服务应用的新访问地址。在另一个例子中，当服务应用修改其访问地址后，代理设备将接收该服务应用发送的新的访问地址，存储该服务应用的新访问地址并对新访问地址进行更新。

在一些可选的实施方式中，在存储并更新目标服务应用的访问地址之后，还可以关联目标服务应用，检测目标服务应用的运行状态，并实时进行更新，其中目标服务应用的运行状态，包括：正常状态和故障状态。

需要说明的是，在确定目标服务应用的运行状态后，需要对其运行状态进行判断，判断目标服务应用的运行状态是否为故障状态，若是，则根据已经存储的该目标服务应用的访问地址对其进行访问，并对其进行修复；若否，则当接收到请求设备发送的访问请求后，可以将该目标服务应用的访问地址发送至请求设备。

可以理解的是，如果目标服务应用处于故障状态，则将该目标服务应用的运行状态更新为故障状态，如果接收到来自请求设备的访问请求，则向请求设备发送反馈信息以告知请求设备该目标服务应用处于故障状态，不将该目标服务应用的访问地址发送至请求设备。

在一些可选的实施方式中，在基于路由规则根据访问请求匹配目标服务应用之前，需要配置该路由规则。具体地，首先读取本地的配置文件，每一个域内的所有服务应用都会读取该域内的同一个配置文件，共用同一种路由规则，而每个域内的边缘代理模块均对应有其所在域的预设配置文件。例如，根据服务应用库生成服务配置文件，根据服务配置文件配置路由规则，每个域内的不同服务应用均遵循该域内同一种路由规则。

参考图2，基于同一发明构思，本申请中一个或多个实施例还提出了一种服务资源处理方法，应用于请求设备，具体包括以下步骤：

S201：发送访问请求至代理设备；

S202：接收目标服务应用的访问地址；所述目标服务应用的访问地址由所述代理设备根据目标服务应用获取；所述目标服务应用由所述代理设备基于路由规则根据所述访问请求匹配确定。

本实施例中，对于步骤S201，请求设备发送的访问请求包括：域内访问请求和/或域外访问请求；当请求设备位于域内时，即请求设备与代理设备处于同一个域时，则请求设备通过第一发送端口将域内访问请求发送至代理设备的第二接收端口；当请求设备位于域外时，即请求设备与代理设备处于不同的域时，则请求设备通过第一发送端口将域外访问请求发送至预设的边缘代理模块，然后再通过边缘代理模块将域外访问请求发送至与边缘代理模块处于同一域内的代理设备的第二接收端口。

需要说明的是，对于步骤S202，当代理设备接收到访问请求后，基于路由规则根据访问请求进行目标服务应用的匹配，具体地，目标服务应用位于服务应用库中，服务应用库中包括若干个服务应用。

在一些可选的实施方式中，访问请求包括以下信息：请求设备的端口名称、请求设备所处域的域名以及要求访问的目标服务应用的名称。代理设备在服务应用库中的服务应用运行时获取根据服务应用的服务信息转换的配置文件，并根据配置文件发现服务，从而根据配置文件确定路由规则，识别请求设备的访问请求，并根据请求设备要求访问的目标服务应用的名称在服务应用库中进行匹配，从而确定目标服务应用。

需要说明的是，在步骤S202中，代理设备会根据匹配到的目标服务应用，获取目标服务应用的访问地址，并将其发送至请求设备。具体地，根据接收访问请求的路径将目标服务应用的访问地址发送至请求设备，当请求设备位于域内时，代理设备通过第二发送端口将目标服务应用的访问地址发送至请求设备的第一接收端口；当请求设备位于域外时，代理设备通过第二发送端口将目标服务应用发送至域内的边缘代理模块，再通过边缘代理模块将目标服务应用转发至请求设备的第一接收端口，从而将目标服务应用发送至请求设备。

从上面所述可以看出，本申请中一个或多个实施例提供的一种服务资源处理方法，应用于代理设备，包括：接收访问请求；基于路由规则根据所述访问请求匹配目标服务应用；获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。本申请能够通过代理设备实现请求设备和目标服务应用的交互，去除总线，实现设备与服务间的交互无中心瓶颈点，降低系统去中心化门槛，及时更新服务名缓存，准确定位目标服务应用，从而避免了服务应用需要通过服务总线被访问，而服务总线一旦故障，则服务应用全部瘫痪的问题。而且本申请去除ESB的设置，实现对应用系统低侵入性，实现了统一服务治理与管控，还能够支持灰度等管控策略，实现基础设施(即虚拟机和/或云环境)对服务网格的原生集成。

上述对本申请中特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种代理设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的应用于代理设备的服务资源处理方法。

图3示出了本实施例所提供的一种更为具体的分发设备硬件结构示意图，该设备可以包括：处理器310、存储器320、输入/输出接口330、通信接口340和总线350。其中处理器310、存储器320、输入/输出接口330和通信接口340通过总线350实现彼此之间在设备内部的通信连接。

处理器310可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器320可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器320可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器320中，并由处理器310来调用执行。

输入/输出接口330用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触控屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口340用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线350包括一通路，在设备的各个组件(例如处理器310、存储器320、输入/输出接口330和通信接口340)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器310、存储器320、输入/输出接口330、通信接口340以及总线350，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种请求设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的应用于请求设备的服务资源处理方法。

图4示出了本实施例所提供的一种更为具体的分发设备硬件结构示意图，该设备可以包括：处理器410、存储器420、输入/输出接口430、通信接口440和总线450。其中处理器410、存储器420、输入/输出接口430和通信接口440通过总线450实现彼此之间在设备内部的通信连接。

处理器410可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器420可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器420可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器420中，并由处理器410来调用执行。

输入/输出接口430用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触控屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口440用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线450包括一通路，在设备的各个组件(例如处理器410、存储器420、输入/输出接口430和通信接口440)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器410、存储器420、输入/输出接口430、通信接口440以及总线450，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

参考图5，基于同一发明构思，本申请中一个或多个实施例还提出了一种服务资源处理系统，包括：至少一个上述的代理设备以及至少一个上述的请求设备。

所述代理设备，被配置为接收访问请求；基于路由规则根据所述访问请求匹配目标服务应用；获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。

所述请求设备，被配置为发送访问请求至代理设备；接收目标服务应用的访问地址；所述目标服务应用的访问地址由所述代理设备根据目标服务应用获取；所述目标服务应用由所述代理设备基于路由规则根据所述访问请求匹配确定。

在一些可选的实施方式中，所述获取所述目标服务应用的访问地址，之后还包括：

存储并更新所述目标服务应用的访问地址。

在一些可选的实施方式中，所述存储并更新所述目标服务应用的访问地址，之后还包括：

关联所述目标服务应用；

检测并更新所述目标服务应用的运行状态；所述目标服务应用的运行状态，包括：正常状态和故障状态。

在一些可选的实施方式中，所述检测并更新所述目标服务应用的运行状态，之后还包括：

判断所述目标服务应用的运行状态是否为所述故障状态；

若是，则根据所述目标服务应用的访问地址访问并修复所述目标服务应用。

在一些可选的实施方式中，所述基于路由规则根据所述访问请求匹配目标服务应用，之前还包括：

获取服务应用库；所述服务应用库是域内所有服务应用的集合，至少包括：所述目标服务引用；

根据所述服务应用库生成服务配置文件；

根据所述服务配置文件配置所述路由规则。

在一些可选的实施方式中，所述访问请求，包括：域内访问请求和/或域外访问请求；

所述发送访问请求至代理设备，具体包括：

发送所述域内访问请求至所述代理设备；

和/或

通过预设的边缘代理模块将所述域外访问请求发送至所述代理设备。

参考图7，在一些可选的实施方式中，服务资源处理系统，可以单独设置全局服务注册中心，用于存储并更新所有所述目标服务应用的访问地址。在环境中划分有若干个域，每个域中均包括代理设备和请求设备，每个代理设备可以注册在全局服务注册中心，从而将每个代理设备关联的服务应用注册在全局服务注册中心。

在一些可选的实施方式中，服务资源处理系统，可以单独设置服务检测模块，关联所有所述目标服务应用，用于检测并更新所述目标服务应用的运行状态；所述目标服务应用的运行状态，包括：正常状态和故障状态。

在一些可选的实施方式中，服务资源处理系统，可以单独设置服务修复模块，用于读取所述服务检测模块中的所述目标服务应用的运行状态，判断所述目标服务应用的运行状态是否为所述故障状态；若是，则根据所述目标服务应用的访问地址访问并修复所述目标服务应用。

在一些可选的实施方式中，服务资源处理系统，可以单独设置域内管控模块，具体地，每个域均设置域内管控模块，用于根据所述目标服务应用生成服务配置文件，并根据所述服务配置文件配置所述路由规则。

在一些可选的实施方式中，服务资源处理系统，可以单独设置全局管控模块，用于管理所有的域内管控模块，实现每个域内的代理服务配置的更新、下发以及热加载。路由规则便是根据本地的配置文件实现热加载配置的，具体地，全局管控模块读取全局服务注册中心的数据动态生成最新的配置文件，每一个域内的服务应用读取同一个配置文件，共用同一种路由规则，而每个域内的边缘代理模块读取各自的配置文件。

在一些可选的实施方式中，参考图6，除了利用代理设备根据服务应用库生成配置文件实现热加载以外，还可以利用全局管控模块定时从全局服务注册中心读取服务信息，并生成代理设备可识别的配置文件写入NFS服务器。应用容器或者应用服务器中运行各个服务应用，应用容器中会挂载一个目录映射到NFS服务器上的指定目录，代理设备会通过代理设备配置目录访问NFS卷映射目录，并实时同步更新。当全局管控模块向NFS服务器写文件时，应用容器中的NFS卷映射目录中的内容也会实时的更新，同时应用容器中会运行一个定时任务，例如定时间隔为10秒，根据定时间隔读取NFS卷映射目录中的配置文件，如果发现有更新，会更改文件树的结构，这样代理设备就能探测到配置文件更新，然后实现热加载。

在一些可选的实施方式中，服务资源处理系统还可以单独设置注册代理模块和域内服务注册中心，当不同的服务应用启动起来的时候，会在本地启动注册代理模块，通过注册代理模块和域内服务注册中心进行通信，利用注册代理模块读取本地的服务配置，将服务配置的信息注册到域内服务注册中心上，同时实时更新服务的状态。域内服务注册中心和域内的边缘服务代理模块都会注册到全局服务注册中心上。

为了描述的方便，描述以上系统时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的系统用于实现前述实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请中一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

本申请中一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请中一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (10)

1.一种服务资源处理方法，其特征在于，应用于代理设备，包括：

接收访问请求；

基于路由规则根据所述访问请求匹配目标服务应用；

获取所述目标服务应用的访问地址并发送至请求设备；所述请求设备位于域内或域外。

2.根据权利要求1所述的服务资源处理方法，其特征在于，所述获取所述目标服务应用的访问地址，之后还包括：

存储并更新所述目标服务应用的访问地址。

3.根据权利要求2所述的服务资源处理方法，其特征在于，所述存储并更新所述目标服务应用的访问地址，之后还包括：

关联所述目标服务应用；

检测并更新所述目标服务应用的运行状态；所述目标服务应用的运行状态，包括：正常状态和故障状态。

4.根据权利要求3所述的服务资源处理方法，其特征在于，所述检测并更新所述目标服务应用的运行状态，之后还包括：

判断所述目标服务应用的运行状态是否为所述故障状态；

若是，则根据所述目标服务应用的访问地址访问并修复所述目标服务应用。

5.根据权利要求1所述的服务资源处理方法，其特征在于，所述基于路由规则根据所述访问请求匹配目标服务应用，之前还包括：

获取服务应用库；所述服务应用库是域内所有服务应用的集合，至少包括：所述目标服务引用；

根据所述服务应用库生成服务配置文件；

根据所述服务配置文件配置所述路由规则。

6.一种服务资源处理方法，其特征在于，应用于请求设备，包括：

发送访问请求至代理设备；

接收目标服务应用的访问地址；所述目标服务应用的访问地址由所述代理设备根据目标服务应用获取；所述目标服务应用由所述代理设备基于路由规则根据所述访问请求匹配确定。

7.根据权利要求6所述的服务资源处理方法，其特征在于，所述访问请求，包括：域内访问请求和/或域外访问请求；

所述发送访问请求至代理设备，具体包括：

发送所述域内访问请求至所述代理设备；

和/或

通过预设的边缘代理模块将所述域外访问请求发送至所述代理设备。

8.一种代理设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至5所述的方法。

9.一种请求设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求6至7任意一项所述的方法。

10.一种服务资源处理系统，其特征在于，包括：至少一个如权利要求8所述的代理设备以及至少一个如权利要求9所述的请求设备。

Images