CN112804289B - 一种资源同步方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种资源同步方法、装置、设备及存储介质，应用于云应用的云服务器中，涉及计算机技术领域，用于解决资源更新滞后的问题。该方法包括：在资源发现组件监控到对应的源数据平台的目标资源发生变化时触发资源更新事件；根据资源更新事件的触发，调用对应的资源发现组件生成资源更新任务，并将资源更新任务发送至与对应的任务队列；调用资源更新组件从任务队列中获取资源更新任务，并根据资源更新任务向资源发现组件下发资源更新命令；根据资源更新命令，调用资源发现组件从源数据平台获取更新资源；调用资源聚合组件对更新资源进行数据结构转换；调用资源更新组件将结构转换后的更新资源更新至云服务器的存储空间中。

Description

一种资源同步方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源同步方法、装置、设备及存储介质。

背景技术

随着容器技术的不断发展，针对急剧增长的容器运行需求，容器治理技术应用而生。由于Kubernetes(K8s)在容器编排调度上具有良好的特性，且云应用服务架构，例如斯普瑞云(Spring Cloud)在服务治理上具有完善的分布式框架，使得在资源管理行业广泛地采用Kubernetes加Spring Cloud的组合模式进行资源管理，该组合模式大大降低了企业应用的成本，提升了数据传输效率。

目前，无论是基于Kubernetes Service模型的负载均衡，还基于KubernetesConfigMap模型的配置管理，它们都只能作用于运行在相同Kubernetes集群上的服务，但是目前的系统通常仅能够处理单一类型的资源，如服务资源，功能尚不完善。此外，SpringCloud中基于Eureka的服务发现模型的数据同步机制为被动式数据同步机制，通过定时查询的方式去查询源数据平台是否发生变化，且该数据同步机制在获取更新资源时，采用获取源数据平台的全部资源方式来进行更新资源的获取，增加了资源更新的时长，因此，Spring Cloud并不能保证资源更新的实时性，进而导致了资源更新滞后的问题。

发明内容

本申请实施例提供一种资源同步方法、装置、设备及存储介质，用于解决资源更新滞后的问题。

一方面，提供一种资源同步方法，应用于云应用的云服务器中，所述方法包括：

在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程；所述云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；

根据所述资源更新流程的触发，调用与所述目标资源的类型对应的资源发现组件生成资源更新任务，并将所述资源更新任务发送至与所述目标资源的类型对应的任务队列；

调用所述云服务器包括的资源更新组件从所述任务队列中获取所述资源更新任务，并根据所述资源更新任务向所述资源发现组件下发资源更新命令；

根据所述资源更新命令，调用所述资源发现组件从所述源数据平台获取更新资源；

调用所述资源聚合组件对所述更新资源进行数据结构转换；

调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中。

一方面，提供一种资源同步装置，应用于云应用的云服务器中，所述装置包括：

资源发现控制单元，用于在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程；所述云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；

资源聚合控制单元，用于根据所述资源更新流程的触发，调用与所述目标资源的类型对应的资源发现组件生成资源更新任务，并将所述资源更新任务发送至与所述目标资源的类型对应的任务队列；

资源更新控制单元，还用于调用所述云服务器包括的资源更新组件从所述任务队列中获取所述资源更新任务，并根据所述资源更新任务向所述资源发现组件下发资源更新命令；

所述资源发现控制单元，还用于根据所述资源更新命令，调用所述资源发现组件从所述源数据平台获取更新资源；

所述资源聚合控制单元，还用于调用所述资源聚合组件对所述更新资源进行数据结构转换；

所述资源更新控制单元，还用于调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中。

可选的，所述装置还包括注册单元；

所述注册单元，用于分别向各个资源聚合组件注册所述资源更新组件的第一回调接口，所述第一回调接口用于各个资源聚合组件在数据结构转换完成时，调用所述资源更新组件进行资源更新；

所述注册单元，还用于分别向各个资源发现组件注册所对应的资源聚合组件的第二回调接口，所述第二回调接口用于实现各个资源发现组件与各自对应的资源聚合组件之间的数据传输。

可选的，所述资源发现控制单元，还用于：

在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时，通过异步触发方式触发所述资源更新流程；其中，所述异步触发方式为在所述资源发现组件已完成上一次资源更新流程时，不等待上一次资源更新流程的触发响应，继续下一次资源更新流程触发的触发方式。

可选的，所述资源发现控制单元，还用于：

通过所述资源发现组件接收设置于源数据平台的监控组件发送的资源变化信息；其中，所述监控组件的监控方式与对应的源数据平台相适配；

根据所述资源变化信息，触发所述资源更新流程。

可选的，资源发现控制单元，还用于在所述资源发现组件与所述源数据平台之间建立流式通信信道；

则所述资源发现控制单元，具体用于：

通过所述资源发现组件接收设置于源数据平台的监控组件经所述流式通信信道发送的资源变化信息。

可选的，所述目标资源包括服务资源、配置资源和实体资源；所述服务资源为所述源资源平台对进行的服务功能的描述信息，所述配置资源为所述源资源平台对进行的配置功能的描述信息，所述实体资源为所述源资源平台对进行的证书实体功能的描述信息；

所述资源发现组件包括服务发现组件、配置发现组件和实体发现组件；所述资源聚合组件包括服务聚合组件、配置聚合组件和实体聚合组件；

其中，所述服务发现组件与所述服务聚合组件对应所述服务资源，所述配置发现组件与所述配置聚合组件对应所述配置资源，所述实体发现组件与所述实体聚合组件对应所述实体资源。

可选的，所述装置还包括解耦单元；

所述解耦单元，用于通过所述资源发现组件对所述获取的更新资源进行解耦处理，以解除所述源数据平台与所述更新数据之间的关系；

则所述资源聚合控制单元，具体用于：

调用所述资源聚合组件对解耦处理后的更新资源进行数据结构转换。

可选的，所述装置还包括订阅控制单元，用于：

接收客户端的资源订阅请求；其中，所述资源订阅请求为所述客户端向所述源数据平台中的目标资源进行订阅时所发出的请求；

根据所述资源订阅请求建立所述客户端与资源更新组件之间的流式通信信道；并，存储所述资源订阅请求对应的资源订阅关系，所述资源订阅关系为所述客户端与所述客户端所订阅的目标资源之间的对应关系；

调用本地事件响应模块获取所述资源订阅关系，并根据所述资源订阅关系从所述云服务器的存储空间中获取所述结构转换后的更新资源；

将所述结构转换后的更新资源推送至所述客户端。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

本申请实施例中，云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时，触发资源更新流程；进而根据资源更新流程的触发，调用与目标资源的类型对应的资源聚合组件生成资源更新任务，并将资源更新任务发送至与目标资源的类型对应的任务队列；调用云服务器包括的资源更新组件从任务队列中获取资源更新任务，并根据资源更新任务向资源发现组件下发资源更新命令；根据资源更新命令，调用资源发现组件从源数据平台获取更新资源；调用资源聚合组件对更新资源进行数据结构转换；调用资源更新组件将结构转换后的更新资源更新至云服务器的存储空间中。因此，在本申请实施例中，针对不同类型的数据资源，设置对应的资源发现组件与资源聚合组件，如针对服务资源，可以设置对应的服务资源发现组件与服务资源聚合组件，进而对资源更新架构进行扩展，使得扩展后的资源更新框架可以处理多种类型的数据资源，进一步降低了对外部服务协助的依赖性，进而降低资源更新架构的运维成本，且提高了资源更新架构的通用性。且通过资源发现组件对源数据平台进行的实时监控，可以实时地获取源数据平台中目标资源变化情况，以降低资源更新的延时。

附图说明

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

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的资源同步方法的流程示意图；

图3为本申请实施例提供的云服务器的结构示意图；

图4为本申请实施例提供的资源更新流程示意图；

图5为本申请实施例提供的以服务资源为例的资源更新示意图；

图6为本申请实施例提供的资源同步装置的一种结构示意图；

图7为本申请实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

首先，对本申请中的部分用语进行解释说明。

容器(Docker)技术：是解决运行环境和配置问题的软件容器，方便做持续集中并有助于整体发布的容器虚拟化技术。也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的应用(Application，APP)或及其运行环境能够做到“一次封装，到处运行”。由于Docker容器在任何操作系统上都是一致的，所以，将应用运行在Docker容器上面，就可以在跨平台、跨服务器时，实现只需要配置一次环境，跨平台、跨服务器时就可以一键部署，大大简化了操作。

Kubernetes：是谷歌(Google)开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩以及应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡，而在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，就可以实现对这一组应用实例的管理、发现和访问，且这些过程都不需要运维人员去进行复杂的手工配置和处理。

Spring Cloud：是一系列资源服务框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器以及数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud将各家资源服务框架组合起来，通过Spring Boot风格进行再封装，避免了复杂的配置和实现原理，给开发者一套简单易懂、易部署和易维护的分布式系统开发工具包。

CS架构：即服务器-客户机架构。CS架构通常采取两层的架构，服务器负责数据的管理，客户机负责完成与用户的交互任务。

客户机通过局域网与服务器相连，接受用户的请求，并通过网络向服务器提出请求，对数据库进行操作。服务器接受客户机的请求，将数据提交给客户机，客户机将数据进行计算并将结果呈现给用户。服务器还要提供完善安全保护及对数据完整性的处理等操作，并允许多个客户机同时访问服务器。

CS架构具有交互性强、安全的存取模式、响应速度快以及利于处理大量数据等特点。但是CS架构缺少通用性，在系统维护与升级时，需要重新设计和开发，增加了维护和管理的难度，进一步的数据拓展困难较多，导致CS架构只限于小型的局域网。

Eureka：是Netflix公司出品的用于实现服务注册和发现的工具，Spring Cloud封装了Netflix公司开发的Eureka模块，可以用来实现服务注册和服务发现，Eureka模块采用CS的设计架构，其包含Eureka Server和Eureka Client两个组件。

资源同步：为将不同具有存储功能的设备、终端或者服务器之间进行的资源备份操作。如，存在服务器A与服务器B，在需要将服务器A的资源与服务器B的资源进行同步时，就需要将服务器A的资源备份至服务器B中即可。

目前，在资源管理行业广泛地采用Kubernetes加Spring Cloud的组合模式进行资源管理，该组合模式大大降低了企业应用的成本，提升了数据传输效率。

在进行资源同步时，由于Spring Cloud是通过集成一系列独立组件而形成的一套框架体系，且大多数组件都是采用基于客户机-服务器(Client-Server，CS)架构的被动式数据同步机制，因此，在采用Kubernetes加Spring Cloud的组合模式进行组合的过程中，还存在以下几点问题有待解决：

(1)由于Spring Cloud的服务发现模型和配置中心都是基于CS架构的被动数据同步机制，所以，在Spring Cloud中，服务发现模型和配置中心都各自包括一套CS架构，使得开发者需要独立的维护管理这两套CS架构组件，无形中增加了Spring Cloud应用的开发复杂性。此外，由于Spring Cloud的数据同步机制是采用客户端一次性对服务端的全部数据的方式进行更新资源的获取，并在本地对获取的更新数据与本地的数据进行合并，这样的数据同步机制不仅增加了通信开销，还使数据结构不一致性导致的不兼容问题延时暴露。

(2)由于采用Kubernetes加Spring Cloud的组合模式无法动态更新证书类的实体资源，因此，通常需要运维人员手工进行维护，使得在证书过期需要进行轮换时常常需要付出很高的运维成本。此外，由于Spring Cloud中基于Eureka的服务发现模型机制复杂，通常需要耗费较多人力进行调优工作，因此，也需要付出很高的人力资源成本。

(3)由于Spring Cloud的基于Eureka的服务发现模型采用被动式的数据更新的方式，通过定时查询的方式去查询源数据平台，不能保证对服务实例的实时更新，进而导致不能及时地响应或者不能响应接收到的资源更新请求。

在相关技术中，通常通过复用Kubernetes的特性，来降低Spring Cloud的复杂性。此外，在服务发现方面，将Eureka提供的多实例负载迁移至基于Kubernetes Service模型的负载模式，基于Kubernetes Service模型的负载均衡使客户端无需关心后端实例的变化，且实例信息的变化由处于系统内核态的路由规则去管理，因此，可以解决服务资源的更新延时问题；在配置管理方面，将配置管理组件使用Kubernetes ConfigMap资源模型替代，可以将配置更新的逻辑委托给Kuberntes平台的数据投影机制，以降低Spring Cloud应用配置刷新的复杂性，同时将Kubernetes的资源模型存储于etcd中，不再需要单独维护配置数据的后台存储组件，进一步降低了应用的架构负载性。

但无论是基于Kubernetes Service模型的负载均衡，还基于KubernetesConfigMap模型的配置管理，它们都只能作用于运行在相同Kubernetes集群上的服务，但是大型系统通常是采用多元化的部署方式，在处理证书实体等资源时，就需要外部服务的协助，因此在使用基于Kubernetes的Serivce模型和ConfigMap模型就会增加很多额外的维护成本来支持外部服务的协助处理。此外，Spring Cloud中基于Eureka的服务发现模型的数据同步机制为被动式数据同步机制，通过定时查询的方式去查询源数据平台是否发生变化，且该数据同步机制在获取更新资源时，采用获取源数据平台的全部资源方式来进行更新资源的获取，增加了资源更新的时长，因此，Spring Cloud并不能保证资源更新的实时性，进而导致了资源更新滞后的问题。

此外，Kubernetes集群常使用安全套接字层(Secure Socket Layer，SSL)证书来进行通信加密，但是证书通常情况下是具有时限性的，如apiserver、controller-manager、kubelet、kubernetes等集群的证书默认的有效期只有一年，这意味着如果在大约1年前创建了Rancher配置集群，那么就需要尽快开始轮换证书了，否则证书过期后集群将进入错误状态，而目前受Kubernetes加Spring Cloud的组合模式框架的限制，通常需要运维人员采用手动的方式来轮换Rancher Kubernetes集群的证书，使得在证书进行轮换需要付出很高的运维成本。

综上所述，在采用Kubernetes加Spring Cloud的组合模式进行资源管理过程中存在的问题还未找到较为完善的解决方案。

基于此，本申请实施例提供了一种资源同步方法，在该方法中，云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时，触发资源更新流程；进而根据资源更新流程的触发，调用与目标资源的类型对应的资源聚合组件生成资源更新任务，并将资源更新任务发送至与目标资源的类型对应的任务队列；调用云服务器包括的资源更新组件从任务队列中获取资源更新任务，并根据资源更新任务向资源发现组件下发资源更新命令；根据资源更新命令，调用资源发现组件从源数据平台获取更新资源；调用资源聚合组件对更新资源进行数据结构转换；调用资源更新组件将结构转换后的更新资源更新至云服务器的存储空间中。因此，在本申请实施例中，针对不同类型的数据资源，设置对应的资源发现组件与资源聚合组件，如针对服务资源，可以设置对应的服务资源发现组件与服务资源聚合组件，进而对资源更新架构进行扩展，使得扩展后的资源更新框架可以处理多种类型的数据资源，进一步降低了对外部服务协助的依赖性，进而降低资源更新架构的运维成本，且提高了资源更新架构的通用性。且通过资源发现组件对源数据平台进行的实时监控，可以实时地获取源数据平台中目标资源变化情况，以降低资源更新的延时。此外，扩展后的资源更新架构能够处理证书实体资源，为证书自动轮换提供技术基础。

在本申请实施例中，还通过各个资源聚合组件对相应的更新资源进行了结构转换，使得在云服务器中能够将各个源数据平台的数据资源按照统一的数据结构进行存储，方便在云服务器对资源进行统一管理，以及解决对不同源数据平台的资源不兼容的问题。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

如图1所示，为本申请实施例提供的一种应用场景示意图，其中，该资源同步的应用场景可以包括源数据平台设备101、云服务器102以及用户终端103。

其中，源数据平台设备101可以为包含有数据库、数据资源的组件或者模块等的设备。云服务器102可以为多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。用户终端103可以为包含云应用客户端、模块或者组件等的终端设备，例如手机、个人计算机(personal computer，PC)或者平板电脑(PAD)等。源数据平台设备101、云服务器102以及用户终端103之间可以通过一个网络进行直接或间接的通信连接，该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是WIFI网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。

在本申请实施例中，在源数据平台设备101中的资源发生变化时，如数据的增加、删除或者更新，云服务器102会实时检测到该资源变化，并从源数据平台设备101中获取到发生了变化的对应部分的更新资源，进而对获取的更新资源进行更新处理，并将处理后的更新资源存储至云服务器102的存储空间中，进而根据云服务器中存储的订阅关系将处理后的更新资源推送至用户终端103。

示例性的，以用户在终端上的云应用中订阅云应用中的某个资源为例，该资源可以为证书文件、配置文件或者提供某种服务功能的一段服务描述信息等，用户小梅通过自己的终端进入云应用的页面，并进行了服务功能订阅，当该网站相应源数据平台中服务功能相关数据发生变化时，云服务器就会监控到相关的数据变化，并获取变化后的相关数据，且在将变化后的相关数据在云服务器的本地存储空间进行更新之后，就会根据云服务器中存储的订阅关系，如“小梅订阅了云应用中的服务功能”，主动将服务功能的更新数据推送至用户终端供用户进行查阅。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。下面，将结合附图对本申请实施例的方法进行介绍。

如图2所示，为本申请实施例提供的资源同步方法的流程示意图，该方法的流程介绍如下，该方法可以通过图1所示的源数据平台设备101、云服务器102以及用户终端103来执行。

步骤201：资源更新初始化。

在云服务器包含的各个组件实现相应功能之前，云服务器需要进行相应的资源更新初始化，以建立各个组件之间的连接，便于数据传输。

在本申请实施例中，如图3所示，为本申请实施例提供的云服务器的结构示意图，该云服务器可包括监控组件、资源发现组件、资源聚合组件和资源更新组件。

在本申请实施例中，不同的源数据平台可以包括不同类型的数据资源，具体可以包含有服务资源、配置资源以及实体资源，其中，服务资源可以为源资源平台对进行的服务功能的描述信息，如“服务名称、IP地址、端口、端口地址”等信息；配置资源可以为源资源平台对进行的配置功能的描述信息，如“字符串的结构体”等；实体资源可以为源资源平台的证书实体的描述信息，如“证书文件的格式、编码方式、内容以及名称”等。

此外，每一源数据平台中可以包括一种类型的数据资源，也可以包括多种类型的数据资源，例如在一个基于Kubernetes的源数据平台中，该源数据平台可以只包含服务资源、配置资源、实体资源中的一类资源，也可以包含这三类资源中的两类或者三类。

本申请实施例中，为了适配不同类型的资源，设置有多种资源发现组件和多种资源聚合组件，其中，一种资源发现组件和资源聚合组件对应一种资源类型。具体的，资源发现组件可以包括服务发现组件、配置发现组件和实体发现组件，资源聚合组件可以包括服务聚合组件、配置聚合组件和实体聚合组件，且服务发现组件与服务聚合组件对应服务资源，配置发现组件与配置聚合组件对应配置资源，实体发现组件与实体聚合组件对应实体资源。其中，资源发现组件可以包括一系列对接不同源数据平台的适配器。

具体的，在进行初始化时，资源更新组件会分别向所对应的各个资源聚合组件注册自身的第一回调接口，即资源更新组件将自身的回调接口告知给所对应的各个资源聚合组件，以便后续各个资源聚合组件通过该回调接口将更新资源传递给资源更新组件。

资源聚合组件也会分别向所对应的各个资源发现组件注册自身的第二回调接口，即资源聚合组件将自身的回调接口告知给所对应的各个资源发现组件，以便后续进行各种数据传输。例如，实体资源聚合组件会将自身的用于回调的接口通知给实体资源发现组件，使得实体资源发现组件可以调用该接口进行数据传输。

由于在不同系统和不同编程语言之间的数据通信往往可以采用应用程序编程接口(Application Programming Interface，API)形式进行数据传输，因此，在申请实施例中，源数据平台与云服务器之间进行数据传输也是通过API接口进行数据传输。此外，由于云服务器可以进行即时连接，所以云服务器与源数据平台之间可以采用超文本传输协议(Hyper Text Transfer Protocol，HTTP)方式进行通信；也可以进行不中断通信的流式管道连接，即采用谷歌远程过程调用(google Remote Procedure Call，gRPC)方式进行通信。在进行通信连接时，可以优先使用gRPC通信方式，降低数据传输时延，当然，针对实际情况也可以选择使用HTTP通信方式，如偶尔连接一次的情况，或者是连接的数据平台非常老旧，只能通过HTTP服务器的接口进行连接的情况。也就是说，云服务器是一个给客户端提供API访问接口的HTTP服务器，同时也是一个gRPC服务器，云服务器基于控制器模式来拉取所有资源控制聚合组件的事件，根据事件类型作出响应，例如资源数据更新时，资源服务器主动向已订阅该资源的客户端推送数据。

步骤202：在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程。

在本申请实施例中，目标资源可以为对应源数据平台的全部数据资源，也可以为对应源数据平台的部分数据资源。

在本申请实施例中，监控组件设置于源数据平台中，如图3所示的在N个源数据平台相对应的N个监控组件，在进行资源更新初始化时，资源发现组件将自身的回调接口通知给监控组件，即将资源发现组件的API接口通知给监控组件，并获取各个源数据平台中监控组件进行数据传输的接口，即获取各个监控组件的API接口，进而基于相应的通信协议，以建立监控组件与所述资源发现组件之间的通信信道。

具体的，由于采用基于gRPC框架的流式管道技术可以使得云服务器与源数据平台在进行多次通信时，云服务器与源数据平台之间一直保持通信连接的状态，而不需要重新建立通信连接，进而可以减小资源更新流程的通知时延。因此，为了降低资源同步带来的延时，监控组件与所述资源发现组件之间的通信信道可以为流式(Stream)通信信道。

本申请实施例中，设置于各个源数据平台的监控组件的监控方式可以与对应的源数据平台相适配。例如，该监控组件可以为服务注册中心组件，即可以为Consul、Eureka、Kubernetes、Config-Center、Kube-apiserver、File-System以及Authority-Center组件等，其中，与Consul和Eureka组件对应的适配器可以使用Consul和Eureka组件对应平台的资源监视方式来实时感知源数据平台中服务数据的变化，并进行回调操作。而与Kubernetes组件对应的适配器基于Kubernetes Informer机制，并以循环模式(即控制器模式)分别创建可以用于Kubernetes Service和Kubernetes的基本构建模块Pod的监听器，从而感知Kubernetes组件上资源的动态变化。

在本申请实施例中，在源数据平台中的目标资源发生变化时，监控组件会通过流式通信信道向资源发现组件发送资源变化信息，进而资源发现组件根据接收到的资源变化信息发现该源数据平台的目标资源发生了变化，进而通过资源发现组件触发资源更新流程。

为了进一步降低资源同步带来的延时，在本申请实施例中，可以采用异步触发资源更新流程的方式来进行资源更新流程的触发。其中，异步触发方式是指在资源发现组件已完成上一次资源更新流程时，不等待上一次资源更新流程的触发响应，继续下一次资源更新流程触发的触发方式，这样，即使上一次资源更新流程还未完成，依然可以继续下一次资源更新的触发，提升资源更新的并行性，进一步减小资源更新流程的通知时延。

步骤203：根据资源更新流程的触发，调用与目标资源的类型对应的资源发现组件生成资源更新任务，并将资源更新任务发送至与目标资源的类型对应的任务队列。

具体的，如图4所示，为本申请实施例提供的资源更新流程示意图，在触发资源更新流程之后，资源发现组件就会根据监控组件通知的资源变化封装资源更新任务，并将该资源更新任务发送至与目标资源的类型对应的任务队列，缓存该资源更新任务。

例如，当触发证书实体的资源更新流程之后，证书实体对应的实体资源发现组件就会将更新的证书实体封装成对应的证书实体资源更新任务，并将该证书实体资源更新任务发送至与证书实体对应的证书实体任务队列。

步骤204：调用资源更新组件从任务队列中获取资源更新任务，并根据资源更新任务向资源发现组件下发资源更新命令。

在本申请实施例中，资源更新组件可以监控任务队列中的资源更新任务，当任务队列中存在资源更新任务时，则可以从任务队列中获取资源更新任务，并向资源发现组件下发资源更新命令。

具体的，资源更新组件可以通过轮询模式来实现对任务队列的监控，并将对应不同类型资源的资源更新任务从对应的任务队列中获取，如对应服务资源的服务资源更新任务，那么资源更新组件将会从对应的服务资源任务队列中获取该服务资源更新任务，并根据获取的服务资源更新任务向服务资源发现组件下发服务资源更新命令。

该服务资源更新命令包括含有更新资源的源数据平台的平台标识、更新资源的标识以及更新资源的类型等信息，其中，源数据平台的平台标识用于查找将要进行更新资源获取的源数据平台。

步骤205：根据资源更新命令，调用资源发现组件从源数据平台获取更新资源。

在本申请实施例中，在资源发现组件接收到资源更新组件发送的资源更新命令之后，该资源发现组件会根据资源更新命令中包含的源数据平台的平台标识区查找含有更新资源的源数据平台，进而根据更新资源的标识以及类型等信息从该源数据平台获取相应的更新资源。

本申请实施例中，在资源发现组件获取到更新资源之后，资源发现组件可以对获取的更新资源进行解耦处理，以解除源数据平台与更新数据之间的关系。

步骤206：调用资源聚合组件对更新资源进行数据结构转换。

由于不同平台之间采用的数据结构可能不相同，所以为了便于数据能适用于不同平台，在本申请实施例中，在对更新资源进行解耦处理之后，会调用云服务器包含的资源聚合组件对解耦后的更新资源进行数据结构转换。如源数据平台A的数据结构A包括姓名、性别以及电话号码，源数据平台B的数据结构B包括姓名、性别、身份证号，对源数据平台A与源数据平台B进行数据结构转换，可获得经过结构转换后的数据结构C，该数据结构C中包括姓名、性别、电话号码以及身份证号，以数据结构C作为新的数据结构。

从而，不同类型的资源聚合组件对相应资源类型的更新资源进行结构转换，再发送给资源更新组件统一进行处理，实现了将各个源数据平台的更新资源进行聚合的作用。

如图5所示，为本申请实施例提供的以服务资源为例的资源更新示意图，当资源为服务资源时，则相应的资源发现组件为服务资源发现组件，在服务资源发现组件中包括多个对接不同源数据平台的适配器，且一个源数据平台对应一个适配器，通过适配器从获取对应源数据平台中的更新服务资源，进而通过适配器对获取的更新服务资源进行解耦处理后，服务资源聚合组件可以对解耦处理后的更新服务资源进行数据结构转换，资源更新组件将结构转换后的更新资源更新至存储空间中。使得资源发现组件实现了对不同源数据平台的资源的解耦，进而资源聚合组件只会关心当前资源类型的更新资源的响应控制逻辑与资源聚合逻辑，降低了资源更新框架的工程复杂性。

步骤207：调用资源更新组件将结构转换后的更新资源更新至云服务器的存储空间中。

当用户想要订阅某源数据平台中的目标资源时，该用户就可以通过终端中对应安装的客户端进行订阅操作，进而云服务器可以获取用户对源数据平台中的目标资源进行订阅的资源订阅请求。

在云服务器接收到客户端发送的资源订阅请求时，云服务器会根据资源订阅请求中携带的关于客户端的信息，建立云服务器与客户端之间的流式通信信道，以保证将目标资源的更新情况实时的推送至用户的终端上。

此外，云服务器会将接收到资源订阅请求中携带的表示客户端与客户端所订阅的目标资源之间的对应的资源订阅关系进行存储，当用户订阅的目标资源发生变化时，可以调用云服务器包含的本地事件响应模块获取相应的资源订阅关系，并将获取的资源订阅关系发送给资源聚合组件，指示资源聚合组件根据资源订阅关系从云服务器的存储空间检索出相应的更新资源，并将更新资源实时地推送至客户端。

综上所述，在本申请实施例中，针对不同类型的数据资源，设置对应的资源发现组件与资源聚合组件，如针对服务资源，可以设置对应的服务资源发现组件与服务资源聚合组件，进而对资源更新架构进行扩展，使得扩展后的资源更新框架可以处理多种类型的数据资源，进一步降低了对外部服务协助的依赖性，进而降低资源更新架构的运维成本，且提高了资源更新架构的通用性。且通过资源发现组件对源数据平台进行的实时监控，可以实时地获取源数据平台中目标资源变化情况，以降低资源更新的延时。此外，扩展后的资源更新架构能够处理证书实体资源，为证书自动轮换提供技术基础。且还通过各个资源聚合组件对相应的更新资源进行了结构转换，使得在云服务器中能够将各个源数据平台的数据资源按照统一的数据结构进行存储，方便在云服务器对资源进行统一管理，以及解决对不同源数据平台的资源不兼容的问题。

请参见图6，基于同一发明构思，本申请实施例还提供了一种资源同步装置，应用于云应用的云服务器中，该装置60包括：

资源发现控制单元601，用于在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程；云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；

资源聚合控制单元602，用于根据资源更新流程的触发，调用与目标资源的类型对应的资源发现组件生成资源更新任务，并将资源更新任务发送至与目标资源的类型对应的任务队列；

资源更新控制单元603，还用于调用云服务器包括的资源更新组件从任务队列中获取资源更新任务，并根据资源更新任务向资源发现组件下发资源更新命令；

资源发现控制单元601，还用于根据资源更新命令，调用资源发现组件从源数据平台获取更新资源；

资源聚合控制单元602，还用于调用资源聚合组件对更新资源进行数据结构转换；

资源更新控制单元603，还用于调用资源更新组件将结构转换后的更新资源更新至云服务器的存储空间中。

可选的，该装置还包括注册单元604；

注册单元604，用于分别向各个资源聚合组件注册资源更新组件的第一回调接口，第一回调接口用于各个资源聚合组件在数据结构转换完成时，调用资源更新组件进行资源更新；

注册单元604，还用于分别向各个资源发现组件注册所对应的资源聚合组件的第二回调接口，第二回调接口用于实现各个资源发现组件与各自对应的资源聚合组件之间的数据传输。

可选的，资源发现控制单元601，还用于：

在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时，通过异步触发方式触发资源更新流程；其中，异步触发方式为在资源发现组件已完成上一次资源更新流程时，不等待上一次资源更新流程的触发响应，继续下一次资源更新流程触发的触发方式。

可选的，资源发现控制单元601，还用于：

通过资源发现组件接收设置于源数据平台的监控组件发送的资源变化信息；其中，监控组件的监控方式与对应的源数据平台相适配；

根据资源变化信息，触发资源更新流程。

可选的，资源发现控制单元601，还用于在资源发现组件与源数据平台之间建立流式通信信道；

则资源发现控制单元601，具体用于：

通过资源发现组件接收设置于源数据平台的监控组件经流式通信信道发送的资源变化信息。

可选的，目标资源包括服务资源、配置资源和实体资源；服务资源为源资源平台对进行的服务功能的描述信息，配置资源为源资源平台对进行的配置功能的描述信息，实体资源为源资源平台对进行的证书实体功能的描述信息；

资源发现组件包括服务发现组件、配置发现组件和实体发现组件；资源聚合组件包括服务聚合组件、配置聚合组件和实体聚合组件；

其中，服务发现组件与服务聚合组件对应服务资源，配置发现组件与配置聚合组件对应配置资源，实体发现组件与实体聚合组件对应实体资源。

可选的，该装置还包括解耦单元605；

解耦单元605，用于通过资源发现组件对获取的更新资源进行解耦处理，以解除源数据平台与更新数据之间的关系；

则资源聚合控制单元602，具体用于：

调用资源聚合组件对解耦处理后的更新资源进行数据结构转换。

可选的，该装置还包括订阅控制单元606，用于：

接收客户端的资源订阅请求；其中，资源订阅请求为客户端向源数据平台中的目标资源进行订阅时所发出的请求；

根据资源订阅请求建立客户端与资源更新组件之间的流式通信信道；并，存储资源订阅请求对应的资源订阅关系，资源订阅关系为客户端与客户端所订阅的目标资源之间的对应关系；

调用本地事件响应模块获取资源订阅关系，并根据资源订阅关系从云服务器的存储空间中获取结构转换后的更新资源；

将结构转换后的更新资源推送至客户端。

该装置可以用于执行图2～图5所示的实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图2～图5所示的实施例的描述，不多赘述。其中，注册单元604、解耦单元605以及订阅单元606为可选的功能模块，因此在图6中以虚线进行示出。

请参见图7，基于同一技术构思，本申请实施例还提供了一种计算机设备70，包括存储器701和处理器702。

所述存储器701，用于存储处理器702执行的计算机程序。存储器701可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器702，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本申请实施例中不限定上述存储器701和处理器702之间的具体连接介质。本申请实施例在图7中以存储器701和处理器702之间通过总线703连接，总线703在图7中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线703可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器701可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器701也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器701是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器701可以是上述存储器的组合。

处理器702，用于调用所述存储器701中存储的计算机程序时执行如图2～图5所示的实施例中设备所执行的方法。

在一些可能的实施方式中，本申请提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图2～图5所示的实施例中设备所执行的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

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

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

Claims (11)

1.一种资源同步方法，其特征在于，应用于云应用的云服务器中，所述方法包括：

在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程；所述云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；

根据所述资源更新流程的触发，调用与所述目标资源的类型对应的资源发现组件生成资源更新任务，并将所述资源更新任务发送至与所述目标资源的类型对应的任务队列；

调用所述资源更新组件从所述任务队列中获取所述资源更新任务，并根据所述资源更新任务向所述资源发现组件下发资源更新命令；

根据所述资源更新命令，调用所述资源发现组件从所述源数据平台获取更新资源；

调用所述资源聚合组件对所述更新资源进行数据结构转换；

调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中。

2.根据权利要求1所述的方法，其特征在于，在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程之前，所述方法还包括：

分别向各个资源聚合组件注册所述资源更新组件的第一回调接口，所述第一回调接口用于各个资源聚合组件在数据结构转换完成时，调用所述资源更新组件进行资源更新；

分别向各个资源发现组件注册所对应的资源聚合组件的第二回调接口，所述第二回调接口用于实现各个资源发现组件与各自对应的资源聚合组件之间的数据传输。

3.根据权利要求1所述的方法，其特征在于，在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程，包括：

在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时，通过异步触发方式触发所述资源更新流程；其中，所述异步触发方式为在所述资源发现组件已完成上一次资源更新流程时，不等待上一次资源更新流程的触发响应，继续下一次资源更新流程触发的触发方式。

4.根据权利要求1所述的方法，其特征在于，在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程，包括：

通过所述资源发现组件接收设置于源数据平台的监控组件发送的资源变化信息；其中，所述监控组件的监控方式与对应的源数据平台相适配；

根据所述资源变化信息，触发所述资源更新流程。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在所述资源发现组件与所述源数据平台之间建立流式通信信道；

则通过所述资源发现组件接收设置于源数据平台的监控组件发送的资源变化信息，包括：

通过所述资源发现组件接收设置于源数据平台的监控组件经所述流式通信信道发送的资源变化信息。

6.根据权利要求1所述的方法，其特征在于，所述目标资源包括服务资源、配置资源和实体资源；所述服务资源为所述源数据平台对进行的服务功能的描述信息，所述配置资源为所述源数据平台对进行的配置功能的描述信息，所述实体资源为所述源数据平台对进行的证书实体功能的描述信息；

所述资源发现组件包括服务发现组件、配置发现组件和实体发现组件；所述资源聚合组件包括服务聚合组件、配置聚合组件和实体聚合组件；

其中，所述服务发现组件与所述服务聚合组件对应所述服务资源，所述配置发现组件与所述配置聚合组件对应所述配置资源，所述实体发现组件与所述实体聚合组件对应所述实体资源。

7.根据权利要求1所述的方法，其特征在于，在调用所述资源聚合组件对所述更新资源进行数据结构转换之前，所述方法还包括：

通过所述资源发现组件对所述获取的更新资源进行解耦处理，以解除所述源数据平台与所述更新资源之间的关系；

则调用所述资源聚合组件对所述更新资源进行数据结构转换，包括：

调用所述资源聚合组件对解耦处理后的更新资源进行数据结构转换。

8.根据权利要求1所述的方法，其特征在于，在调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中之前，所述方法还包括：

接收客户端的资源订阅请求；其中，所述资源订阅请求为所述客户端向所述源数据平台中的目标资源进行订阅时所发出的请求；

根据所述资源订阅请求建立所述客户端与资源更新组件之间的流式通信信道；并，存储所述资源订阅请求对应的资源订阅关系，所述资源订阅关系为所述客户端与所述客户端所订阅的目标资源之间的对应关系；

则在调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中之后，所述方法还包括：

调用本地事件响应模块获取所述资源订阅关系，并根据所述资源订阅关系从所述云服务器的存储空间中获取所述结构转换后的更新资源；

将所述结构转换后的更新资源推送至所述客户端。

9.一种资源同步装置，其特征在于，应用于云应用的云服务器中，所述装置包括：

资源发现控制单元，用于在资源发现组件监控到自身监控的源数据平台的目标资源发生变化时触发资源更新流程；所述云服务器包括资源更新组件、多种资源发现组件和多种资源聚合组件，一种资源发现组件和资源聚合组件对应一种资源类型；

资源聚合控制单元，用于根据所述资源更新流程的触发，调用与所述目标资源的类型对应的资源发现组件生成资源更新任务，并将所述资源更新任务发送至与所述目标资源的类型对应的任务队列；

资源更新控制单元，还用于调用所述资源更新组件从所述任务队列中获取所述资源更新任务，并根据所述资源更新任务向所述资源发现组件下发资源更新命令；

所述资源发现控制单元，还用于根据所述资源更新命令，调用所述资源发现组件从所述源数据平台获取更新资源；

所述资源聚合控制单元，还用于调用所述资源聚合组件对所述更新资源进行数据结构转换；

所述资源更新控制单元，还用于调用所述资源更新组件将结构转换后的更新资源更新至所述云服务器的存储空间中。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至8任一项所述方法的步骤。

11.一种存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行权利要求1-8中任一所述的方法包括的步骤。

Images