CN110990047A - 用于多个微服务架构的融合方法及装置 - Google Patents

Abstract

本申请公开了一种用于多个微服务架构的融合方法及装置。该方法包括：部署统一注册中心和注册中心控制器；通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；通过所述注册中心控制器监听所述服务端的服务状态；根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。本申请解决了相关技术中的微服务架构由于注册中心互不兼容而造成的难以对微服务架构进行集成的的技术问题。本申请的多个微服务架构通过统一注册中心达到了相互兼容的目的，从而实现了降低多个微服务架构集成和融合的难度的技术效果。

Description

用于多个微服务架构的融合方法及装置

技术领域

本申请涉及微服务技术领域，具体而言，涉及一种用于多个微服务架构的融合方法及装置。

背景技术

随着微服务架构的普及，企业内部应用开发越来越多的使用一些微服务开发框架，包括Spring Cloud、Dubbo、Service Mesh等微服务开发、治理框架，用来解决服务发现、调用链跟踪、配置管理、路由管理、服务限流、熔断监控、认证等各种分布式架构下要面临的各种问题。

发明人发现，相关技术中的微服务开发框架至少存在以下问题：1)各个微服务框架都带有注册中心，用来提供服务注册、发现等相关能力，但互相之间又不兼容，很难互相进行集成；2)不同框架的注册中心提供的功能、支持的协议也不尽相同，使得改造成本很大，也不利于扩展；3)部署多个注册中心不但不利于管理运维，也带来了额外的资源需求，增加了使用成本。

针对相关技术中的微服务架构由于注册中心互不兼容而造成的难以对微服务架构进行集成的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种用于多个微服务架构的融合方法及装置，以解决相关技术中的微服务架构由于注册中心互不兼容而造成的难以对微服务架构进行集成的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种用于多个微服务架构的融合方法。

根据本申请的用于多个微服务架构的融合方法包括：部署统一注册中心和注册中心控制器；通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；通过所述注册中心控制器监听所述服务端的服务状态；根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

进一步地，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求；根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用；将服务调用结果发送至所述客户端。

进一步地，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端；判断所述服务端的服务状态信息；根据所述服务状态信息确定是否调用所述服务端。

进一步地，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息；对所述服务端的域名信息进行解析；基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

进一步地，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后包括：获取所述自定义资源库的服务实例列表；将所述服务实例列表发送至所述客户端；根据所述客户端的选择结果确定调用的服务端。

为了实现上述目的，根据本申请的另一方面，提供了一种用于多个微服务架构的融合装置。

根据本申请的用于多个微服务架构的融合装置包括：部署模块，用于部署统一注册中心和注册中心控制器；构建模块，用于通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；监听模块，用于通过所述注册中心控制器监听所述服务端的服务状态；更新模块，用于根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

进一步地，所述装置还包括：接收模块，用于接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求；调用模块，用于根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用；第一发送模块，用于将服务调用结果发送至所述客户端。

进一步地，所述装置还包括：第一获取模块，用于根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端；判断模块，用于判断所述服务端的服务状态信息；确定模块，用于根据所述服务状态信息确定是否调用所述服务端。

进一步地，所述装置还包括：识别模块，用于根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息；解析模块，用于对所述服务端的域名信息进行解析；访问模块，用于基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

进一步地，所述装置还包括：第二获取模块，用于获取所述自定义资源库的服务实例列表；第二发送模块，用于将所述服务实例列表发送至所述客户端；选择模块，根据所述客户端的选择结果确定调用的服务端。

在本申请实施例中，采用部署统一注册中心和注册中心控制器的方式，通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；通过所述注册中心控制器监听所述服务端的服务状态；根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中，多个微服务架构通过统一注册中心达到了相互兼容的目的，从而实现了降低多个微服务架构集成和融合的难度的技术效果，进而解决了相关技术中的微服务架构由于注册中心互不兼容而造成的难以对微服务架构进行集成的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请第一实施例的用于多个微服务架构的融合方法的流程示意图；

图2是根据本申请第二实施例的用于多个微服务架构的融合方法的流程示意图；

图3是根据本申请第三实施例的用于多个微服务架构的融合方法的流程示意图；

图4是根据本申请第四实施例的用于多个微服务架构的融合方法的流程示意图；

图5是根据本申请第五实施例的用于多个微服务架构的融合方法的流程示意图；

图6是根据本申请第一实施例的用于多个微服务架构的融合装置的组成结构示意图；

图7是根据本申请第二实施例的用于多个微服务架构的融合装置的组成结构示意图；

图8是根据本申请第三实施例的用于多个微服务架构的融合装置的组成结构示意图；

图9是根据本申请第四实施例的用于多个微服务架构的融合装置的组成结构示意图；以及

图10是根据本申请第五实施例的用于多个微服务架构的融合装置的组成结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本发明实施例，提供了一种用于多个微服务架构的融合方法，如图1所示，该方法包括如下的步骤S101至步骤S104：

步骤S101，部署统一注册中心和注册中心控制器。

具体实施时，本申请实施例的统一注册中心可以是以Dubbo注册中心为基础，Dubbo是一个分布式服务框架，致力于提供高性能透明化RPC远程调用方案，提供SOA服务治理解决方案。Dubbo在各个分层有很多扩展，比如注册中心有redis、zookeeper选项，通信模块有netty、mina，序列化有hession、hession2、java序列化等，本申请实施例部署的统一注册中心用于替换传统注册中心中的zookeeper。注册中心控制器则被部署为用于监听各个服务端的服务状态、处理服务实例的注册、注销等事件，对统一注册中心内部的资源进行控制和管理。

步骤S102，通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库。

具体实施时，通过上述部署的统一注册中心获取各个服务端的信息，包括服务端的名称、IP地址信息等，基于上述信息在部署的统一注册中心中构建一个自定义资源库(Custom Resource Definition，简称CRD)，通过该自定义资源库使各个服务端之间能够相互知晓对方的基本信息，具体地，服务端的基本信息可以通过应用开发时引用依赖包进行注入。

步骤S103，通过所述注册中心控制器监听所述服务端的服务状态。

具体实施时，通过注册中心的控制器来监听部署的统一注册中心中的服务端服务状态及其他相关信息如服务端的名称、IP地址信息等。

步骤S104，根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

具体实施时，判断服务端的服务状态是否发生变化或者其他相关信息如服务端的名称等是否发生变化，如果通过注册中心控制器监听到的结果是服务端的服务状态发生变化或者服务端的名称等信息发生变化，则将被变化后的信息更新或同步至上述自定义资源库中，进而实现了所需信息在统一注册中心和服务端之间的实时同步，保证注册中心和关联服务的状态一致性。

此外，当新建、删除、重建、迁移任何服务实例时，注册中心控制器都会实时更新自定义资源库中的相关状态信息，以便客户端能够通过统一注册中心获取到当前的正确信息。每个客户端也可以监听自定义资源库中自己感兴趣的服务资源，当自定义资源库中的相关状态信息发生变化时，更新自己可以调用的服务实例列表，实现与统一注册中心的状态同步。

作为本申请实施例的一种优选实施方式，如图2所示，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括如下的步骤S201至步骤S203：

步骤S201，接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求。

具体实施时，在部署好所述统一注册中心和注册中心控制器后，接收客户端发起的用于调用服务端的请求，所述服务调用请求可以包括调用的服务端的名称信息等。

步骤S202，根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用。

具体实施时，例如当客户端A要访问服务端B时，可以先通过统一注册中心内的自定义资源库获取服务端的相关信息，然后对所述服务端的服务直接进行调用。

步骤S203，将服务调用结果发送至所述客户端。

具体实施时，服务调用的结果可能是调用成功的结果，也可能是调用失败的结果，如果服务调用成功，则直接建立起客户端与调用的服务端之间的连接，如果服务调用失败，可以告知用户端重新发起服务调用请求。

作为本申请实施例的一种优选实施方式，如图3所示，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括如下的步骤S301至步骤S303：

步骤S301，根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端。

具体实施时，在接收到客户端发起的用于调用服务端的请求后，通过识别所述请求中的服务端信息在上述构建的自定义资源库中进行检索或查询，获取到与客户端的请求相匹配的服务端。

步骤S302，判断所述服务端的服务状态信息。

具体实施时，在获取到与客户端的服务调用请求相匹配的服务端之后，进一步判断客户端请求调用的服务端的服务状态信息，即该服务端的服务状态是否正常，是否被过度调用等等。

步骤S303，根据所述服务状态信息确定是否调用所述服务端。

具体实施时，如果客户端请求调用的服务端的服务状态异常或者被过度调用，则说明服务端的服务状态较差，不宜被再次调用，如果客户端请求调用的服务端的服务状态正常，则调用该服务端，建立该服务端与客户端之间的连接，即通过服务端的服务状态信息确定是否调用服务端。

作为本申请实施例的一种优选实施方式，如图4所示，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括如下的步骤S401至步骤S403：

步骤S401，根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息。

具体实施时，例如当客户端A想要调用服务端B时，可以配置两种调用方式，第一种是基于服务端的负载均衡的方式进行服务调用，具体地可以通过域名解析服务器来实现，因此首先需要识别客户端A发起的服务调用请求中对应的服务端B的域名信息。

步骤S402，对所述服务端的域名信息进行解析。

具体实施时，在得到服务端B的域名信息之后，通过统一注册中心提供的域名解析服务器对客户端请求访问的服务端B的域名进行解析。

步骤S403，基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

具体实施时，通过域名解析服务器对服务端B的域名进行解析，可以得到服务端B的IP地址信息，使得客户端A可以通过该IP地址信息访问服务端B，实现对服务端B的调用。通过为注册中心的服务提供服务端负载均衡，并可配置灵活的访问策略，减少了客户端负载均衡的开发成本，并可以通过注册中心定义路由策略。

作为本申请实施例的一种优选实施方式，如图5所示，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后包括如下的步骤S501至步骤S503：

步骤S501，获取所述自定义资源库的服务实例列表。

具体实施时，当客户端A想要调用服务端B时，还可以采用第二种调用方式，即基于客户端的负载均衡的方式进行服务调用，首先根据客户端A发起的服务调用请求在上述构建的自定义资源库中进行检索、匹配，得到与用户请求调用的服务端信息相匹配的服务实例列表，该服务实例列表中可以包含一个或多个与用户请求相匹配的服务端信息。

步骤S502，将所述服务实例列表发送至所述客户端。

具体实施时，在得到上述服务实例列表后，将该服务实例表发送至客户端，由客户端自行决定调用的服务端。

步骤S503，根据所述客户端的选择结果确定调用的服务端。

具体实施时，在接收到客户端选择的服务端信息之后，对所述服务端进行调用，建立起客户端与该服务端的连接。

从以上的描述中，可以看出，本发明实现了如下技术效果：1)统一的服务注册中心，通过扩展可以兼容各种微服务框架对于注册中心的需求，方便满足各种编程语言及不同协议的统一微服务框架需求；2)通过部署注册中心控制器，允许对注册中心进行能力扩展，并由控制器保持注册中心处于期望的状态；3)移除了每个注册中心对于不同中间件的依赖，大幅简化了服务中心自身的技术依赖和减轻了对于复杂环境的运维成本；4)通过简单配置，允许服务之间通过服务端负载均衡或者客户端负载均衡进行相互调用，增加了服务访问模式的灵活性。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本发明实施例，还提供了一种用于实施上述用于多个微服务架构的融合方法的装置，如图6所示，该装置包括：部署模块1、构建模块2、监听模块3及更新模块4。

本申请实施例的部署模块1，用于部署统一注册中心和注册中心控制器。

具体实施时，本申请实施例的统一注册中心可以是以Dubbo注册中心为基础，Dubbo是一个分布式服务框架，致力于提供高性能透明化RPC远程调用方案，提供SOA服务治理解决方案。Dubbo在各个分层有很多扩展，比如注册中心有redis、zookeeper选项，通信模块有netty、mina，序列化有hession、hession2、java序列化等，本申请实施例通过部署模块部署的统一注册中心用于替换传统注册中心中的zookeeper。注册中心控制器则被部署为用于监听各个服务端的服务状态、处理服务实例的注册、注销等事件，对统一注册中心内部的资源进行控制和管理。

本申请实施例的构建模块2，用于通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库。

具体实施时，通过上述部署的统一注册中心获取各个服务端的信息，包括服务端的名称、IP地址信息等，基于上述信息在上述部署的统一注册中心中通过构建模块构建一个自定义资源库(Custom Resource Definition，简称CRD)，通过该自定义资源库使各个服务端之间能够相互知晓对方的基本信息，具体地，服务端的基本信息可以通过应用开发时引用依赖包进行注入。

本申请实施例的监听模块3，用于通过所述注册中心控制器监听所述服务端的服务状态。

具体实施时，监听模块通过注册中心的控制器来监听部署的统一注册中心中的服务端服务状态及其他相关信息如服务端的名称、IP地址信息等。

本申请实施例的更新模块4，用于根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

具体实施时，通过更新模块判断服务端的服务状态是否发生变化或者其他相关信息如服务端的名称等信息是否发生变化，如果通过注册中心控制器监听到的结果是服务端的服务状态发生变化或者服务端的名称等信息发生变化，则将被变化后的信息更新或同步至上述自定义资源库中，进而实现了所需信息在统一注册中心和服务端之间的实时同步，保证注册中心和关联服务的状态一致性。

作为本申请实施例的一种优选实施方式，如图7所示，所述装置还包括：接收模块5、调用模块6及第一发送模块7。

本申请实施例的接收模块5，用于接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求。

具体实施时，在部署好所述统一注册中心和注册中心控制器后，接收模块接收客户端发起的用于调用服务端的请求，所述服务调用请求可以包括调用的服务端的名称信息等。

本申请实施例的调用模块6，用于根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用。

具体实施时，例如当客户端A要访问服务端B时，可以先通过统一注册中心内的自定义资源库获取服务端的相关信息，然后通过调用模块对所述服务端的服务直接进行调用。

本申请实施例的第一发送模块7，用于将服务调用结果发送至所述客户端。

具体实施时，服务调用的结果可能是调用成功的结果，也可能是调用失败的结果，通过第一发送模块将服务调用结果发送至所述客户端，如果服务调用成功，则直接建立起客户端与调用的服务端之间的连接，如果服务调用失败，可以告知用户端重新发起服务调用请求。

作为本申请实施例的一种优选实施方式，如图8所示，所述装置还包括：第一获取模块8、判断模块9及确定模块10。

本申请实施例的第一获取模块8，用于根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端。

具体实施时，在接收到客户端发起的用于调用服务端的请求后，通过识别所述请求中的服务端信息在上述构建的自定义资源库中进行检索或查询，通过第一获取模块获取到与客户端的请求相匹配的服务端。

本申请实施例的判断模块9，用于判断所述服务端的服务状态信息。

具体实施时，在获取到与客户端的服务调用请求相匹配的服务端之后，进一步通过判断模块判断客户端请求调用的服务端的服务状态信息，即该服务端的服务状态是否正常，是否被过度调用等等。

本申请实施例的确定模块10，用于根据所述服务状态信息确定是否调用所述服务端。

具体实施时，如果客户端请求调用的服务端的服务状态异常或者被过度调用，则说明服务端的服务状态较差，不宜被再次调用，如果客户端请求调用的服务端的服务状态正常，则调用该服务端，建立该服务端与客户端之间的连接，即确定模块通过服务端的服务状态信息确定是否调用服务端。

作为本申请实施例的一种优选实施方式，如图9所示，所述装置还包括：识别模块11、解析模块12及访问模块13。

本申请实施例的识别模块11，用于根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息。

具体实施时，例如当客户端A想要调用服务端B时，可以配置两种调用方式，第一种是基于服务端的负载均衡的方式进行服务调用，具体地可以通过域名解析服务器来实现，因此首先需要通过识别模块识别客户端A发起的服务调用请求中对应的服务端B的域名信息。

本申请实施例的解析模块12，用于对所述服务端的域名信息进行解析。

具体实施时，在得到服务端B的域名信息之后，解析模块通过统一注册中心提供的域名解析服务器对客户端请求访问的服务端B的域名进行解析。

本申请实施例的访问模块13，用于基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

具体实施时，通过域名解析服务器对服务端B的域名进行解析，可以得到服务端B的IP地址信息，使得客户端A可以通过访问模块基于该IP地址信息访问服务端B，实现对服务端B的调用。通过为注册中心的服务提供服务端负载均衡，并可配置灵活的访问策略，减少了客户端负载均衡的开发成本，并可以通过注册中心定义路由策略。

作为本申请实施例的一种优选实施方式，如图10所示，所述装置还包括：第二获取模块14、第二发送模块15及选择模块16。

本申请实施例的第二获取模块14，用于获取所述自定义资源库的服务实例列表。

具体实施时，当客户端A想要调用服务端B时，还可以采用第二种调用方式，即基于客户端的负载均衡的方式进行服务调用，首先根据客户端A发起的服务调用请求通过第二获取模块在上述构建的自定义资源库中进行检索、匹配，得到与用户请求调用的服务端信息相匹配的服务实例列表，该服务实例列表中可以包含一个或多个与用户请求相匹配的服务端信息。

本申请实施例的第二发送模块15，用于将所述服务实例列表发送至所述客户端。

具体实施时，在得到上述服务实例列表后，通过第二发送模块将该服务实例表发送至客户端，由客户端自行决定调用的服务端。

本申请实施例的选择模块16，根据所述客户端的选择结果确定调用的服务端。

具体实施时，在接收到客户端选择的服务端信息之后，通过选择模块所述服务端进行调用，建立起客户端与该服务端的连接。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种用于多个微服务架构的融合方法，其特征在于，包括：

部署统一注册中心和注册中心控制器；

通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；

通过所述注册中心控制器监听所述服务端的服务状态；

根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

2.根据权利要求1所述的用于多个微服务架构的融合方法，其特征在于，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：

接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求；

根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用；

将服务调用结果发送至所述客户端。

3.根据权利要求1所述的用于多个微服务架构的融合方法，其特征在于，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：

根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端；

判断所述服务端的服务状态信息；

根据所述服务状态信息确定是否调用所述服务端。

4.根据权利要求1中所述的用于多个微服务架构的融合方法，其特征在于，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后还包括：

根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息；

对所述服务端的域名信息进行解析；

基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

5.根据权利要求1中所述的用于多个微服务架构的融合方法，其特征在于，所述通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库之后包括：

获取所述自定义资源库的服务实例列表；

将所述服务实例列表发送至所述客户端；

根据所述客户端的选择结果确定调用的服务端。

6.一种用于多个微服务架构的融合装置，其特征在于，包括：

部署模块，用于部署统一注册中心和注册中心控制器；

构建模块，用于通过所述统一注册中心获取服务端信息，以根据所述服务端信息在所述统一注册中心中构建自定义资源库；

监听模块，用于通过所述注册中心控制器监听所述服务端的服务状态；

更新模块，用于根据监听结果更新所述服务端的服务状态，并将更新后的所述服务端的服务状态存储至所述自定义资源库中。

7.根据权利要求6所述的用于多个微服务架构的融合装置，其特征在于，还包括：

接收模块，用于接收客户端的服务调用请求，所述服务调用请求是指客户端用于调用服务端的请求；

调用模块，用于根据所述客户端的服务调用请求，按照预设规则在所述自定义资源库中进行服务调用；

第一发送模块，用于将服务调用结果发送至所述客户端。

8.根据权利要求6所述的用于多个微服务架构的融合装置，其特征在于，还包括：

第一获取模块，用于根据客户端的服务调用请求，在所述自定义资源库中获取与所述服务调用请求相匹配的服务端；

判断模块，用于判断所述服务端的服务状态信息；

确定模块，用于根据所述服务状态信息确定是否调用所述服务端。

9.根据权利要求6所述的用于多个微服务架构的融合装置，其特征在于，还包括：

识别模块，用于根据客户端的服务调用请求识别调用的服务端信息，所述服务端信息包括服务端的域名信息；

解析模块，用于对所述服务端的域名信息进行解析；

访问模块，用于基于解析后的域名信息获取服务端的IP地址信息，以使所述客户端通过所述IP地址信息访问所述服务端。

10.根据权利要求6所述的用于多个微服务架构的融合装置，其特征在于，还包括：

第二获取模块，用于获取所述自定义资源库的服务实例列表；

第二发送模块，用于将所述服务实例列表发送至所述客户端；

选择模块，根据所述客户端的选择结果确定调用的服务端。

Images