CN110928709B - 一种微服务框架下的服务调用方法、装置及服务器 - Google Patents

Abstract

本申请公开了一种微服务框架下的服务调用方法、装置及服务器，方法包括：获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；基于所述目标服务特征，确定目标入口对象；其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于各服务路由组件中的各应用服务组件的服务特征生成的；获得所述目标入口对象所对应的目标服务路由组件的访问地址；利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

Description

一种微服务框架下的服务调用方法、装置及服务器

技术领域

本申请涉及云计算技术领域，特别涉及一种微服务框架下的服务调用方法、装置及服务器。

背景技术

在单体架构下，根据用户访问请求触发业务系统的调用顺序，从上到下一般为表示(WEB)层、业务(BO)层、数据访问(DAO)层及数据库。当使用单体架构模式进行业务交互时，请求方将通过表示层向业务层发起一次REST调用发起请求，之后，负载均衡器将请求路由给N个相同的业务服务实例中的一个，之后，业务服务实例会查询各种数据库表，并将响应返回给请求方。

随着业务增长所引发的可扩展性需求逐渐紧迫，目前多采用基于微服务框架的服务调用方式，例如，请求方可以直接向每个微服务组件发送请求，每个微服务组件都有一个开放的端口，通过构建服务组件和端口的映射关系，将该请求直接发送到微服务组件所在集群的开放端口上，再由每个集群的路由组件负责在可用的业务实例间分发请求。

明显的，以上的服务调用方式中，如果微服务出现版本变化或者合并拆分等情况，可能就会出现微服务无法调用的情况，使得服务调用的可靠性较低。

发明内容

有鉴于此，本申请的目的在于提供一种微服务框架下的服务调用方法、装置及服务器，用以解决现有技术中微服务框架下的服务调用可靠性较低的技术问题。

本申请提供了一种微服务框架下的服务调用方法，包括：

获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；

基于所述目标服务特征，确定目标入口对象；

其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于各服务路由组件中的各应用服务组件的服务特征生成的；

获得所述目标入口对象所对应的目标服务路由组件的访问地址；

利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

上述方法，优选的，所述入口对象分别基于各服务路由组件中的多个应用服务组件的服务特征生成，包括：

获得每个应用服务组件的服务特征，所述服务特征表征所述应用服务组件的功能类型；

基于所述服务特征，生成每个所述应用服务组件的入口对象，所述入口对象通过指向其所属的服务路由组件与该服务路由组件下的应用服务组件相对应。

上述方法，优选的，所述服务特征包括服务名；

所述入口对象为CNAME类型的名称对象。

上述方法，优选的，基于所述目标服务特征，确定目标入口对象，包括：

对所述目标服务特征的服务名进行域名补全，得到目标完整域名；

在具有多个入口对象的目标对象集合中，获得所述目标完整域名对应的目标入口对象。

上述方法，优选的，所述目标完整域名包括：目标服务特征的服务名在其所对应的服务路由组件下的完整域名；

其中，在目标对象集合中，获得所述目标完整域名对应的目标入口对象，包括：

将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，所述目标对象集合中的入口对象为所述当前调用组件所属的服务路由组件下各应用服务组件对应的入口对象。

上述方法，优选的，所述目标完整域名包括：目标服务特征的服务名在所述微服务框架下的完整域名；

其中，在目标对象集合中，获得所述目标完整域名对应的目标入口对象，包括：

将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，所述目标对象集合中的入口对象为所述微服务框架中各服务路由组件下各应用服务组件对应的入口对象。

上述方法，优选的，在接收服务调用请求之后，所述方法还包括：

在所述当前调用组件对应的缓存中，查找是否已经缓存有所述目标服务特征；

如果查找到，将所述缓存中所述目标服务特征对应的地址作为所述访问地址，执行利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件的步骤；

如果没有查找到，执行所述基于所述目标服务特征，确定目标入口对象的步骤。

上述方法，优选的，利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件，包括：

将所述服务调用请求通过所述访问地址传输至所述目标服务路由组件中的目标端口上，以使得所述服务调用请求在所述目标端口上转发到目标应用服务组件，所述目标应用服务组件的服务特征与所述目标服务特征相匹配。

本申请还提供了一种微服务框架下的服务调用装置，包括：

入口生成单元，用于针对所述微服务框架下的服务路由组件，分别基于所述服务路由组件中的各应用服务组件的服务特征生成入口对象；

请求获得单元，同于获得当前调用组件的服务调用请求，所述服务调用请求中至少包括目标服务特征；

入口确定单元，用于基于所述目标服务特征，确定目标入口对象；

地址获得单元，用于获得所述目标入口对象所对应的目标服务路由组件的访问地址；

组件调用单元，用于利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

本申请还提供了一种服务器，所述服务器上部署有微服务框架，所述服务器包括：

存储器，用于存储应用程序及所述应用程序运行所产生的数据；

处理器，用于获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；基于所述目标服务特征，确定目标入口对象；其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于所述服务路由组件中的各应用服务组件的服务特征生成的；获得所述目标入口对象所对应的目标服务路由组件的访问地址；利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

由以上方案可知，本申请提供的一种微服务框架下的服务调用方法、装置及服务器，针对微服务框架下的服务路由组件中的各应用服务组件，基于各应用服务组件的服务特征生成该应用服务组件的入口对象，而该入口对象指向于其所对应的应用服务组件所属的服务路由组件，因此，在某个调用组件发出服务调用请求时，可以根据请求中的目标服务特征来确定对应的目标入口对象，进而利用该目标入口对象所指向的目标服务路由组件的访问地址来调用该目标服务路由组件中的目标应用服务组件，实现服务调用。可见，在本申请中，由于应用服务组件的服务特征通常是不会变的，由此，即使应用服务组件出现组件变化如版本合并或者拆分等情况，本申请中也能够利用利用基于服务特征所生成的入口对象来调用到相应服务特征的应用服务组件，而不会出现无法调用到应用服务组件的情况，由此提高服务调用的可靠性。

附图说明

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

图1为其示出了本申请一种实现服务调用集群的一种组成架构示意图；

图2为本申请实施例的示例图；

图3为本申请实施例中的微服务框架结构图；

图4为本申请的服务器的一种组成结构示意图；

图5为本申请实施例提供的一种微服务框架下的服务调用方法的流程图；

图6-图10分别为本申请实施例的其他应用示例图；

图11为本申请实施例提供的一种微服务框架下的服务调用装置的结构示意图。

具体实施方式

本申请发明人通过研究发现：在单体(monolithic)的组件调用服务架构中，根据用户访问请求触发业务系统的调用顺序，从上到下一般为表示(WEB)层、业务(BO)层、数据访问(DAO)层及数据库。当使用单体架构模式进行业务交互时，服务请求方将通过表示层向业务层发起一次REST调用来获取数据。其中，负载均衡器将服务请求路由给N个相同的业务实例中的一个，之后，业务实例会查询各种数据库表，并将响应数据返回给服务请求方。

而随着业务增长引发的可扩展性需求逐渐紧迫，单体应用的局限性愈发明显，因此近年来业务系统逐步向微服务模式进行转变。和单体架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网络，服务组件间通过轻量机制进行通信，这是就必然就引入了分布式服务寻址和治理的问题。

其中，在理论上，服务请求方可以直接向每个微服务(组件)发送请求，每个微服务都有一个开放的端口，通过构建服务和端口的映射关系，将该请求直接发送到微服务所在集群的开放端口上，再由每个集群的路由组件负责在可用的业务实例间分发请求。例如，在使用Kubernetes实现微服务的寻址和治理过程中，系统中每个Service对象的服务名与ClusterIP的映射关系首先被自动同步到Kubernetes集群中内置的DNS组件里，通过对所请求Service对象服务名的DNS Lookup机制，可以得到Service IP(A记录)和Service Port(SRV记录)，对服务发起的请求再由IPTables实现从“Service IP+Service Port”到“PodIP+Pod Port”的映射(该映射关系由Kubernetes中每个Node上运行的proxy根据Service上的Label生成，映射过程同时也完成了负载均衡)，从而将请求分发到正确的Pod中进行处理。

但是，随着业务的不断发展，服务组件需要不断升级、甚至需更改系统划分服务的方式，例如，合并两个服务组件，或将一个服务组件拆分成多个服务组件，因此，服务请求方发起服务调用指向的URL同样也需要改变，使得该架构下服务的重构难以执行，导致服务组件的调用不可实现。

而且，业务请求于每个微服务暴露的细粒度不匹配，例如，服务请求方在一次复杂的业务流程中，可能发起数十次服务调用，导致公网环境下业务时延增大，用户体验差。

基于以上缺陷，本申请发明人进一步研究发现：通过在具有相同服务特征(功能或服务名等)的微服务集群中动态的为应用服务组件创建入口服务组件，从而将调用请求重定向到具有相同服务特征的微服务组件或组件集群中，具体可以通过集群中的服务路由组件根据配置的策略将请求转发到相应版本的应用服务组件的某个特定实例中，从而降低微服务组件升级、拆分、合并过程中的复杂程度，避免服务调用的不可实现的情况，从而提高服务调用的可靠性。

需要说明的是，本申请中的微服务框架可以基于HTTP协议和Kubernetes原生框架实现，对应用服务组件的调用方和提供方非侵入，因此，可以广泛适用于各类微服务。

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

为了便于理解，本文中先对本申请的方案所适用的系统进行介绍，参考图1，其示出了本申请一种实现服务调用集群的一种组成架构示意图。

由图1中可知，该系统中可以包括有：多个服务器10、集群控制服务器20，服务器10与集群控制服务器20之间通过网络实现通信连接。

其中，服务器10上部署有微服务框架，如基于HTTP协议在应用服务器10上部署Kubernetes原生框架，并在该框架上进行改进，改进之处在于：针对对应多个应用服务组件的服务路由组件中为每个应用服务组件基于其服务特征(也可以成为业务特征，如功能、名称等)创建作为应用服务访问入口点的入口对象，这些入口对象与服务路由组件之间有关联关系，如这些入口对象指向于其所对应的应用服务组件所属的服务路由组件，如图2中所示。

如图3中改进的微服务框架所示，本申请改进的微服务框架中由API Server、控制组件、服务路由组件、服务调用组件以及应用服务组件等共同组成，在微服务框架中，以上组件运行于同一个微服务管控集群中，其中：

API Server：主要用于管理在微服务框架上需要使用到的自定义的入口服务组件(入口对象)生成规则；

服务调用组件：服务调用的发起方(也可以作为被调用的服务提供方)，其中，服务调用组件在需要调用其他组件时，可以首先通过微服务管控集群提供的域名服务器对入口服务组件的服务名进行地址解析，再基于解析到的IP地址构造HTTP请求并发送至具体的服务路由组件的对应端口中，从而调用到合适的应用服务组件。

服务路由组件：主要用于根据预先配置的策略将调用方发起的服务调用请求转发给相应版本的应用服务组件的某个实例。本申请中服务路由组件通过动态存储用户自定义的版本选择规则及服务治理规则(如负载均衡、请求拒绝及权限规则等)，使得服务调用方可通过统一的入口服务组件针对不同版本的应用服务组件进行精确访问。

控制组件：主要用于根据自定义的入口服务组件(入口对象)生成规则的定义，在集群中创建/修改/删除其他关联对象。本申请中控制组件定期读取微服务集群的各服务路由组件中每个应用服务组件实例的版本选择规则和服务治理规则，基于应用服务组件的业务特征动态创建一个新的用作服务访问的入口服务组件，该入口服务组件指向对应应用服务组件所属的服务路由组件。

应用服务组件：业务服务提供方(也可以作为服务调用的发起方)。在本申请的框架中，每一个业务服务的不同版本都对应一个应用服务组件实例。

需要说明的是，以上是以服务器分别为一台独立的服务器为例进行说明，但是可以理解的是，在实际应用中，服务器也可以被替换为服务器集群，或者由多台服务器构成的分布式集群，由集群控制服务器20进行统一部署管理。

其中，为了实现各服务器上相应的功能，服务器的存储器中需要存储实现相应功能的程序。为了便于理解服务器的硬件构成，下面以服务器为例进行介绍。如图4中所示，为本申请的服务器的一种组成结构示意图，本实施例中的服务器10可以包括有：处理器401、存储器402、通信接口403、输入单元404、显示器405和通信总线406。

其中，处理器401、存储器402、通信接口403、输入单元404、显示器405、均通过通信总线406完成相互间的通信。

在本实施例中，该处理器401，可以为中央处理器(Central Processing Unit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。

该处理器401可以调用存储器402中存储的程序。具体的，处理器401可以执行以下服务调用方法的实施例中服务器侧所执行的操作。

存储器402中用于存放一个或者一个以上程序，程序可以包括程序代码，所述程序代码包括计算机操作指令，在本申请实施例中，该存储器中至少存储有用于实现以下功能的程序：

获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；

基于所述目标服务特征，确定目标入口对象；

其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于所述服务路由组件中的各应用服务组件的服务特征生成的；

获得所述目标入口对象所对应的目标服务路由组件的访问地址；

利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

在一种可能的实现方式中，该存储器402可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如入口对象的显示等)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，应用服务组件对应的入口对象等等。

此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

该通信接口403可以为通信模块的接口，如GSM模块的接口。

当然，图4所示的服务器的结构并不构成对本申请实施例中服务器的限定，在实际应用中服务器可以包括比图4所示的更多或更少的部件，或者组合某些部件。

参考图5，为本申请实施例提供的一种微服务框架下的服务调用方法的流程图，该方法适用于服务器10上，如部署有微服务框架的应用服务器或服务器集群等，本实施例中的方法主要用于对微服务框架下的应用服务组件进行调用。

在本实施例中，该方法可以包括以下步骤：

步骤501：获得当前调用组件的服务调用请求。

其中，服务调用请求中至少包含目标服务特征。而当前调用组件为部署在微服务框架下某个服务路由组件对应的某个应用服务组件，其作为服务调用的发起方利用其所需求来生成服务调用请求，该服务调用请求中包含有表征当前调用组件的调用需求的目标服务特征。

需要说明的是，目标服务特征可以为当前调用组件所需要调用的组件的功能特征、或者类型特征或者服务名特征等。

步骤502：基于目标服务特征，确定目标入口对象。

其中，结合前文中内容可知，入口对象是基于其对应的应用服务组件的服务特征来生成的，因此，本实施例中可以基于目标服务特征在微服务框架下的各入口对象中确定目标入口对象。

步骤503：获得目标入口对象所对应的目标服务路由组件的访问地址。

其中，入口对象作为应用服务组件的访问入口点，可以指向该应用服务组件所属的服务路由组件，因此，本实施例中可以先基于目标入口对象确定其所指向的目标服务路由组件，再获得目标服务路由组件的访问地址。

其中，目标服务路由组件的访问地址可以为目标服务路由组件的网际协议IP(Internet Protocol Address)地址。

具体的，本实施例中可以利用DNS寻址算法对目标入口对象进行地址解析，以得到对应的目标服务路由组件的IP地址。

步骤504：利用访问地址，调用目标服务路由组件中的目标应用服务组件。

其中，本实施例中在获得访问地址之后，可以将当前调用组件的服务调用请求通过该访问地址传输至目标服务路由组件的目标端口上，进而在该目标端口上根据服务调用请求中所请求的负载或其他参数，在目标服务路由组件下的各个应用服务组件中按照预设的负载规则确定合适的目标应用服务组件，而目标应用服务组件的服务特征与服务调用请求中的目标业务特征是相匹配的，由此，完成当前调用组件按照目标服务特征对目标应用服务组件的调用。

由以上方案可知，本申请实施例提供的一种微服务框架下的服务调用方法，针对微服务框架下的服务路由组件中的各应用服务组件，基于各应用服务组件的服务特征生成该应用服务组件的入口对象，而该入口对象指向于其所对应的应用服务组件所属的服务路由组件，因此，在某个调用组件发出服务调用请求时，可以根据请求中的目标服务特征来确定对应的目标入口对象，进而利用该目标入口对象所指向的目标服务路由组件的访问地址来调用该目标服务路由组件中的目标应用服务组件，实现服务调用。可见，在本实施例中，由于应用服务组件的服务特征通常是不会变的，由此，即使应用服务组件出现组件变化如版本合并或者拆分等情况，本实施例中也能够利用利用基于服务特征所生成的入口对象来调用到相应服务特征的应用服务组件，而不会出现无法调用到应用服务组件的情况，由此提高服务调用的可靠性。

在一种实现方式中，服务器在对各应用服务组件生成入口对象时，可以通过以下方式实现：

首先，获得每个应用服务组件的服务特征，其中，该服务特征表征应用服务组件的功能类型，如对每个应用服务组件的服务名进行提取等；

之后，基于服务特征，生成每个应用服务组件的入口对象，而该入口对象通过指向其所属的服务路由组件与该服务路由组件下的应用服务组件相对应，例如，基于服务名，生成每个应用服务组件的入口对象，该入口对象可以为CNAME类型的名称对象，该入口对象指向其对应的应用服务组件所属的服务路由组件。

例如，首先，在图3所示的基于Kubernetes原生框架部署的微服务框架下，APIServer根据各应用服务组件的业务特征，配置并存储所在的名称空间(Namespace)中不同版本应用服务组件的调用规则及服务治理规则；其次，控制组件定期读取API Server，并根据上述基于业务特征的服务调用与服务治理规则及服务的可见性(即是否只能在当前名称空间中被调用)，在相应的名称空间中创建一个类型为ExternalName的服务对象(入口对象)作为应用服务访问入口点，并将其指向位于default名称空间中且服务于当前名称空间的服务路由组件，如图6所示。

在一种实现方式中，本实施例中在接收到服务调用请求之后，可以先在当前调用组件对应的缓存中，查找是否已经缓存有目标服务特征如服务名；如果查找到目标服务特征，那么不再执行步骤502和步骤503，而是将缓存中所述目标服务特征对应的地址作为所述访问地址，再执行步骤504；如果没有查找到，那先执行步骤502基于目标服务特征确定目标入口对象后，再执行步骤503及后续步骤。

也就是说，本实施例中在第一次获得目标服务特征并获得访问地址之后，可以将其缓存在当前调用组件所在的容器的缓存中，如果后续在再次发起调用该目标服务特征对应的应用服务组件时，可以无需再对目标入口对象进行重新获取，可以直接在缓存中获得该目标服务特征所关联的地址作为访问地址，进而利用该访问地址调用目标应用服务组件。

例如，当服务调用方通过应用服务访问入口发起HTTP调用请求时，首先对请求中的服务名进行解析，如图7中的寻址流程所示，先在当前pod的DNS客户端缓存中查找是否已经存在该服务名信息，如果有，直接将记录的IP地址返回，如果没有，那么将对应用服务访问入口的域名解析最终转换成为对应用服务访问入口所在的服务路由组件IP地址的解析，如基于当前pod所在的名称空间补全请求中的DNS域名，然后将请求发送至集群的DNS服务器查找域名是否存在，如果不存在那么说明没有这个组件，如果存在那么返回该域名的CNAME，即服务路由组件的域名，之后，基于CNAME再次发起查询请求至集群的DNS服务器，对该域名进行DNS解析，得到服务路由组件的IP地址，至此结束寻址流程。

在一种实现方式中，服务器在基于目标服务特征，确定目标入口对象时，具体可以通过以下方式实现：

首先，可以对目标服务特征的服务名进行域名补全，得到目标完整域名，之后，在具有多个入口对象的目标对象集合中，获得目标完整域名对应的目标入口对象。

具体的，目标完整域名可以为目标服务特征的服务名在其所对应的服务路由组件下的完整域名，如“<servicename>.<namespace>.svc.<cluster domain>”；

相应的，在得到目标完整域名之后，将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，而此时的目标对象集合中的入口对象为所述当前调用组件所属的服务路由组件下各应用服务组件对应的入口对象，之后，获得所述目标入口对象所对应的目标服务路由组件的访问地址。

例如，在当前调用组件与目标应用服务组件所属的服务路由组件相同时，即调用私有服务时，调用方使用的域名为目标应用服务组件的服务名(没有“.”)。此时，根据容器内的DNS解析补全规则，Kubernetes集群会对待解析的域名进行自动补全得到：“<servicename>.<namespace>.svc.<cluster domain>”，然后使用该完整域名发起地址解析。而地址解析会指向由微服务框架别名服务辅助程序(控制组件)在当前名称空间(目标对象集合)中生成的别名服务(查找别名对象)上，该服务的解析结果是一个CNAME，指向了default名称空间中为当前名称空间服务的服务路由组件Service Router的服务名，从而最终解析到的IP地址就是该Service Router的服务IP地址：10.128.0.55。

具体如图8中所示：以名称空间‘2’中的服务实例‘svc22-1-c’调用相同名称空间中的服务‘svc21’为例：

步骤①：svc22-1-c以服务名‘svc21’发起DNS查询请求，该请求会在容器中被补全为svc21.2.svc.cluster.local，由于该名称是服务svc21在名称空间‘2’中创建的入口服务组件在集群DNS中注册的名称，故该查询请求会解析为svc21的入口服务组件指向的结果；

步骤②：由于svc21的入口服务组件在集群DNS中注册为一个CNAME类型的对象，故集群DNS在查询到该域名的解析结果“namspace2.default.svc.cluster.local”(该地址即是集群中负责名称空间‘2’中服务路由的服务路由器的名称)后，会进一步查询该结果所对应的IP地址；而此域名正好为虚拟IP地址是172.30.12.35的服务路由组件所注册的域名，故最终向svc22-1-c返回的查询结果即该IP地址；

步骤③：svc22-1-c以http://svc21/path/to/host发起HTTP请求，该请求发送至上一步骤中解析出的虚拟IP地址172.30.12.35；

步骤④：集群的IPTables截获该请求，并将目标地址172.30.12.35修改为服务路由组件某个实例的真实IP地址，此例中为10.128.0.55；

步骤⑤：请求到达服务路由组件，组件根据配置的路由规则信息，找到一个具体可被调用的目标实例，本例中为10.128.2.115，然后将此调用请求转发至该实例。

此时，服务svc21的实例svc21-1-v-1-a(IP：10.128.2.115)就收到了来自调用方svc22-1-c的调用请求。

或者，目标完整域名也可以为：目标服务特征的服务名在所述微服务框架下的完整域名，如“<service name>.global.svc.<clusterdomain>”；

相应的，在得到目标完整域名之后，将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，而此时的目标对象集合中的入口对象为所述微服务框架中各服务路由组件下各应用服务组件对应的入口对象。

例如，在当前调用组件与目标应用服务组件所属的服务路由组件不相同时，即调用全局服务时，调用方使用的域名为目标服务的服务名加上全局服务后缀(“.global”)。此时，根据容器内的DNS解析补全规则，Kubernetes集群会对待解析的域名进行自动补全得到“<service name>.global.svc.<cluster domain>”，然后使用该完整域名发起地址解析。地址解析会指向由微服务框架别名服务辅助程序在特殊的全局名称空间中生成的别名服务上，而该服务的解析结果是一个CNAME，指向了default名称空间中为当前名称空间服务的Service Router的服务名，从而最终解析到的IP地址就是该Service Router的服务IP：10.128.0.14。

具体如图9中所示：以名称空间‘2’中的服务实例‘svc22-1-c’调用名称空间‘1’中的服务‘svc11’为例

步骤①：与图8中步骤①类似，不同的是发起DNS查询请求时，使用的名称为“svc11.global”而不是“svc11”，该请求会被实例为“svc11.global.svc.cluster.local”，从而集群DNS将该请求解析为服务svc11在名称空间‘global’中创建的入口服务组件指向的结果(此处需要说明的是，调用方svc21并不知道被调用方svc11所在的具体名称空间，故svc11能被svc21调用的前提是它在一个固定的名称空间，如‘global’中，创建一个入口服务组件，而svc21在发起调用时，也使用该固定名称空间中的入口服务组件名称)；

步骤②：与图8中步骤②类似，只不过返回的结果是集群中负责名称空间‘1’中服务路由的服务路由器的名称及其IP地址(172.30.11.35)；

步骤③：与图8中步骤③类似，只不过请求的URL为http://svc11.global/path/to/host，目标虚拟IP地址为172.30.11.35；

步骤④：与图8中步骤④类似，只不过修改后的真实IP地址为10.128.0.14；

步骤⑤：与图8中步骤⑤类似，只不过目标真实IP地址为10.128.1.15；

经过相似的5个步骤，服务svc11的实例svc11-v-1-1-b(IP：10.128.1.15)就收到了来自调用方svc22-1-c的调用请求。。

最后，在寻址完成得到服务路由组件的IP地址之后，就可以构造HTTP请求发送到服务路由组件的服务IP，由所在集群节点上的IPtables将请求转发到某个具体的服务路由组件Pod的对应端口中，该端口被服务路由组件Pod中的负载均衡模块进程侦听。负载均衡模块为服务调用方选择一个合适的目标应用服务组件的版本后，根据负载均衡策略将服务调用方的服务请求最终转发到具体版本的某个应用服务组件Pod上，这一流程的实例如图10所示。所述负载均衡模块的负载均衡策略可以由Pod中的服务路由组件进程根据对应名称空间中所有服务路由策略的内容生成并在服务路由策略发生变化时动态更新。

由上述方案可知，本实施例中根据提取的服务特征动态创建一个用作服务访问的新入口，同时，将调用请求重定向到该入口上，使得服务调用方可通过统一的访问点针对不同版本的服务进行访问。

而且，本实施例中通过构建动态的服务调用组件，利用通过访问入口服务名解析到的IP地址，构造新的HTTP请求并发送至本实施例中的服务路由组件中，由服务路由组件提供请求负载均衡处理，面向企业级复合服务集群的集成提供一套通用的服务发现与治理模型。

参考图11，为本申请实施例提供的一种微服务框架下的服务调用装置的结构示意图，该装置可以配置在服务器10上，如部署有微服务框架的应用服务器或服务器集群等，本实施例中的装置主要用于对微服务框架下的应用服务组件进行调用。

在本实施例中，该装置可以包括以下功能组件：

入口生成单元1101，用于针对所述微服务框架下的服务路由组件，分别基于所述服务路由组件中的各应用服务组件的服务特征生成入口对象；

请求获得单元1102，同于获得当前调用组件的服务调用请求，所述服务调用请求中至少包括目标服务特征；

入口确定单元1103，用于基于所述目标服务特征，确定目标入口对象；

地址获得单元1104，用于获得所述目标入口对象所对应的目标服务路由组件的访问地址；

组件调用单元1105，用于利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件。

由以上方案可知，本申请实施例二提供的一种微服务框架下的服务调用装置，针对微服务框架下的服务路由组件中的各应用服务组件，基于各应用服务组件的服务特征生成该应用服务组件的入口对象，而该入口对象指向于其所对应的应用服务组件所属的服务路由组件，因此，在某个调用组件发出服务调用请求时，可以根据请求中的目标服务特征来确定对应的目标入口对象，进而利用该目标入口对象所指向的目标服务路由组件的访问地址来调用该目标服务路由组件中的目标应用服务组件，实现服务调用。可见，在本实施例中，由于应用服务组件的服务特征通常是不会变的，由此，即使应用服务组件出现组件变化如版本合并或者拆分等情况，本实施例中也能够利用利用基于服务特征所生成的入口对象来调用到相应服务特征的应用服务组件，而不会出现无法调用到应用服务组件的情况，由此提高服务调用的可靠性。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种微服务框架下的服务调用方法、装置及服务器进行了详细介绍，对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种微服务框架下的服务调用方法，其特征在于，包括：

获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；

基于所述目标服务特征，确定目标入口对象；

其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于各服务路由组件中的各应用服务组件的服务特征生成的；

获得所述目标入口对象所对应的目标服务路由组件的访问地址，其中，基于所述目标入口对象确定其所指向的目标服务路由组件，获得所述目标服务路由组件的访问地址；

利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件；

其中，基于所述目标服务特征，确定目标入口对象包括：

根据容器内的DNS解析补全规则，对目标服务特征的服务名进行域名补全，得到目标完整域名，所述目标完整域名为目标服务特征的服务名在其所对应的服务路由组件下的完整域名；

在具有多个入口对象的目标对象集合中，获得所述目标完整域名对应的目标入口对象。

2.根据权利要求1所述的方法，其特征在于，所述入口对象分别基于各服务路由组件中的多个应用服务组件的服务特征生成，包括：

获得每个应用服务组件的服务特征，所述服务特征表征所述应用服务组件的功能类型；

基于所述服务特征，生成每个所述应用服务组件的入口对象，所述入口对象通过指向其所属的服务路由组件与该服务路由组件下的应用服务组件相对应。

3.根据权利要求2所述的方法，其特征在于，

所述入口对象为CNAME类型的名称对象。

4.根据权利要求1所述的方法，其特征在于，所述目标完整域名包括：目标服务特征的服务名在其所对应的服务路由组件下的完整域名；

其中，在目标对象集合中，获得所述目标完整域名对应的目标入口对象，包括：

将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，所述目标对象集合中的入口对象为所述当前调用组件所属的服务路由组件下各应用服务组件对应的入口对象。

5.根据权利要求1所述的方法，其特征在于，所述目标完整域名包括：目标服务特征的服务名在所述微服务框架下的完整域名；

其中，在目标对象集合中，获得所述目标完整域名对应的目标入口对象，包括：

将所述目标完整域名与目标对象集合中的各入口对象进行比对，获得与所述目标完整域名相匹配的目标入口对象，所述目标对象集合中的入口对象为所述微服务框架中各服务路由组件下各应用服务组件对应的入口对象。

6.根据权利要求1所述的方法，其特征在于，在接收服务调用请求之后，所述方法还包括：

在所述当前调用组件对应的缓存中，查找是否已经缓存有所述目标服务特征；

如果查找到，将所述缓存中所述目标服务特征对应的地址作为所述访问地址，执行利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件的步骤；

如果没有查找到，执行所述基于所述目标服务特征，确定目标入口对象的步骤。

7.根据权利要求1所述的方法，其特征在于，利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件，包括：

将所述服务调用请求通过所述访问地址传输至所述目标服务路由组件中的目标端口上，以使得所述服务调用请求在所述目标端口上转发到目标应用服务组件，所述目标应用服务组件的服务特征与所述目标服务特征相匹配。

8.一种微服务框架下的服务调用装置，其特征在于，包括：

入口生成单元，用于针对所述微服务框架下的服务路由组件，分别基于所述服务路由组件中的各应用服务组件的服务特征生成入口对象；

请求获得单元，同于获得当前调用组件的服务调用请求，所述服务调用请求中至少包括目标服务特征；

入口确定单元，用于基于所述目标服务特征，确定目标入口对象；

地址获得单元，用于获得所述目标入口对象所对应的目标服务路由组件的访问地址，其中，基于所述目标入口对象确定其所指向的目标服务路由组件，获得所述目标服务路由组件的访问地址；

组件调用单元，用于利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件；

其中，所述入口确定单元具体用于：

根据容器内的DNS解析补全规则，对目标服务特征的服务名进行域名补全，得到目标完整域名，所述目标完整域名为目标服务特征的服务名在其所对应的服务路由组件下的完整域名；

在具有多个入口对象的目标对象集合中，获得所述目标完整域名对应的目标入口对象。

9.一种服务器，其特征在于，所述服务器上部署有微服务框架，所述服务器包括：

存储器，用于存储应用程序及所述应用程序运行所产生的数据；

处理器，用于获得当前调用组件的服务调用请求，所述服务调用请求中至少包含目标服务特征；基于所述目标服务特征，确定目标入口对象；其中，针对所述微服务框架下的服务路由组件具有其对应的至少一个入口对象，所述入口对象分别是基于所述服务路由组件中的各应用服务组件的服务特征生成的；获得所述目标入口对象所对应的目标服务路由组件的访问地址，其中，基于所述目标入口对象确定其所指向的目标服务路由组件，获得所述目标服务路由组件的访问地址；利用所述访问地址，调用所述目标服务路由组件中的目标应用服务组件；其中，基于所述目标服务特征，确定目标入口对象包括：根据容器内的DNS解析补全规则，对目标服务特征的服务名进行域名补全，得到目标完整域名，所述目标完整域名为目标服务特征的服务名在其所对应的服务路由组件下的完整域名；在具有多个入口对象的目标对象集合中，获得所述目标完整域名对应的目标入口对象。