CN117879955A - 微服务通信方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种微服务通信方法、装置、计算机设备和存储介质，所述方法包括：在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址；所述虚拟地址为针对所述被调用微服务设置的不可实际使用的地址；若所述虚拟地址符合预设的地址条件，发送携带所述虚拟地址的第二调用请求至所述主动调用微服务的代理组件；接收所述代理组件返回的所述被调用微服务的数据包；所述数据包为所述代理组件基于所述第二调用请求中的所述虚拟地址，从所述被调用微服务中获取得到。采用本方法能够无侵入式地拦截请求流量，实现快速无侵入式地接入服务网格，减少接入服务网格的成本。

Description

微服务通信方法、装置、计算机设备和存储介质

技术领域

本申请涉及微服务技术领域，特别是涉及一种微服务通信方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

服务网格（Service Mesh）是一个专用的基础架构层，用于管理分布式应用程序中各个微服务之间的通信，支持不同的微服务接入。

相关技术中，在实际将微服务接入服务网格的过程中，会因微服务的已有框架、架构、部署等原因，导致将微服务接入服务网格时，或多或少会有开发改造的成本，无法对微服务做到“无侵入式”地接入服务网格。

发明内容

基于此，有必要针对上述方法存在的需要改造微服务，无法将微服务无侵入式地接入服务网格的技术问题，提供一种微服务通信方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种微服务通信方法。所述方法包括：

在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址；所述虚拟地址为针对所述被调用微服务设置的不可实际使用的地址；

若所述虚拟地址符合预设的地址条件，发送携带所述虚拟地址的第二调用请求至所述主动调用微服务的代理组件；

接收所述代理组件返回的所述被调用微服务的数据包；所述数据包为所述代理组件基于所述第二调用请求中的所述虚拟地址，从所述被调用微服务中获取得到。

在其中一个实施例中，所述响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址，包括：

获取所述第一调用请求携带的所述被调用微服务的服务标识；

基于所述服务标识，确定所述被调用微服务对应的虚拟地址。

在其中一个实施例中，所述服务标识为服务域名；所述基于所述服务标识，确定所述被调用微服务对应的虚拟地址，包括：

通过域名解析组件，对所述服务标识进行域名解析处理，得到所述被调用微服务对应的虚拟地址；所述域名解析组件为与所述服务网格匹配的域名解析组件；

或者，基于所述服务标识，查找预先设置的配置文件，得到所述被调用微服务对应的虚拟地址；所述配置文件中存储有所述服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系。

在其中一个实施例中，所述方法还包括：

获取针对虚拟地址设置的基准地址格式；

当所述虚拟地址的地址格式符合所述基准地址格式时，确定所述虚拟地址符合预设的地址条件。

在其中一个实施例中，所述被调用微服务对应至少一个服务实例；所述接收所述代理组件返回的所述被调用微服务的数据包，包括：

接收所述代理组件返回的所述被调用微服务中的目标服务实例的数据包；

其中，所述代理组件，还用于基于所述第二调用请求中的所述虚拟地址，确定对应的被调用微服务；从所述被调用微服务对应的至少一个服务实例中，选择出目标服务实例；发送获取请求至所述目标服务实例，以获取所述目标服务实例的数据包。

在其中一个实施例中，所述方法还包括：

调用名字服务组件，对所述主动调用微服务的各个服务实例进行注册；

所述名字服务组件用于存储接入所述服务网格的每个微服务的虚拟地址与所述每个微服务的服务实例之间的关联关系。

在其中一个实施例中，所述名字服务组件，还用于：

在注册所述主动调用微服务的第一个服务实例时，生成所述主动调用微服务的目标虚拟地址，建立所述第一个服务实例与所述目标虚拟地址之间的关联关系；

在注册所述主动调用微服务的后续的服务实例时，将所述后续的服务实例关联至所述目标虚拟地址。

在其中一个实施例中，所述名字服务组件，还用于：

检测所述名字服务组件中的服务实例的运行情况；

若检测到任一个服务实例处于未运行状态，则剔除所述任一个服务实例，并解除所述任一个服务实例与对应的微服务的虚拟地址之间的关联关系。

第二方面，本申请还提供了一种微服务通信装置。所述装置包括：

地址获取模块，用于在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址；所述虚拟地址为针对所述被调用微服务设置的不可实际使用的地址；

请求发送模块，用于若所述虚拟地址符合预设的地址条件，发送携带所述虚拟地址的第二调用请求至所述主动调用微服务的代理组件；

数据接收模块，用于接收所述代理组件返回的所述被调用微服务的数据包；所述数据包为所述代理组件基于所述第二调用请求中的所述虚拟地址，从所述被调用微服务中获取得到。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上任一项所述方法的步骤。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任一项所述方法的步骤。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如上任一项所述方法的步骤。

上述微服务通信方法、装置、计算机设备、存储介质和计算机程序产品，在微服务与服务网格管理的其他微服务进行通信时，通过处理第一调用请求，获取被调用微服务的虚拟地址，然后判断虚拟地址是否符合预设的地址条件，并在符合时发送携带所述虚拟地址的第二调用请求至配置的代理组件，由代理组件获取被调用微服务的数据包。该方法通过设置微服务的虚拟地址，从而在主动调用微服务进行请求调用时，可以只需设置一条简单的路由规则来判断虚拟地址与预设地址条件之间的匹配关系，即可实现对请求流量的拦截，无需对微服务进行代码改造，从而可以无侵入式地拦截请求流量，实现快速无侵入式地接入服务网格，减少接入服务网格的成本。并且，由于虚拟地址为实际不可达的IP地址，因此也不会误命中路由规则导致误拦截正常流量。此外，该方法不依赖于部署环境的能力，因此，可以应用于虚拟机、物理机、云和容器等部署环境下。同时，由于只需配置一条简单的匹配规则进行流量拦截，几乎不会带来处理资源的开销，可克服传统为每一个微服务调用关系配置一条路由规则的方法，容易导致微服务数不断增长时，路由规则的查找和匹配消耗大量系统资源，降低系统处理能力的缺陷。

附图说明

图1为一个实施例中微服务通信方法的应用环境图；

图2为一个实施例中微服务通信方法的流程示意图；

图3为另一个实施例中微服务通信方法的流程示意图；

图4为一个实施例中微服务通信方法的原理示意图；

图5为一个实施例中微服务通信装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

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

为便于理解本申请，以下对本申请的背景作进一步说明。服务网格（ServiceMesh）旨在解决软件系统中大规模微服务的治理问题。其核心理念是将基础设施能力（如服务路由、熔断、限流、监控等）下沉到Mesh（网格）层，向上统一进行服务治理，服务网格支持不同开发语言、不同框架，甚至不同协议的微服务接入，以提升整体研发效率。但是在接入微服务时，会因微服务所对应业务的已有框架、架构、部署等原因，致使微服务接入服务网格时或多或少会有开发改造的成本，无法对微服务做到“无侵入式接入”。

现有技术中，针对微服务接入服务网格的研究多集中在如何部署服务网格组件、如何优化和改造服务网格架构，使得微服务可以低成本快速接入。公开的方案通常借鉴业界开源组件Istio（一种服务网格形态的开放平台）来实现，并通过修改操作系统的IP表（iptables）规则，以接管请求流量。但修改iptables规则的方案会带来较大的性能折损，且不能保证微服务不需要修改而无侵入式接入。并且，基于开源组件Istio的微服务接入方案，通常部署在K8s容器环境下，强依赖于K8s服务机制，较少有在虚拟机（VirtualMachine，VM）或物理机等环境上成功部署的案例；并且，K8s部署容器时需要执行初始化脚本，向容器（Pod）内注入iptables转发规则，该转发规则极为复杂，但目标仅是拦截指定出、入端口的流量到服务网格的代理组件（sidecar）和配合指定ip范围；代理组件（sidecar）拦截到流量后，解析出被调用方的服务信息，通常是识别请求协议并从中拿到服务名信息，再依赖K8s的服务发现机制，进行实例寻址。

因此，现有基于开源组件Istio的微服务接入方案，存在以下问题：

（1）iptables规则复杂，维护成本大。由于需要精确的设计iptables规则，以尽可能完整的接管微服务的出入流量。因此iptables规则通常极为复杂，维护成本较高。

（2）影响服务处理性能。同样是因为过于复杂的iptables规则，使得规则处理本身需要消耗一些处理性能。而当主动调用服务方、被调用服务方的数目和服务实例数增长时，对应需要的处理资源亦对应增长。因此，微服务数和服务实例数过多时，将会对服务处理性能影响较大。

（3）无法保证精确拦截。因无法事先获取所有被调用服务的所有实例的ip信息，发起调用方的iptables规则通常只针对出、入端口设置，这可能会导致未接入服务网格但使用到了iptables规则端口的流量，被异常拦截到代理组件（sidecar），可能导致流量处理异常。

（4）不兼容非K8s环境部署。由于要注入的iptables规则跟随服务部署而变化，在K8s环境下，可以在容器初始化时注入，实现尚不复杂。但若微服务部署在虚拟机或物理机上时，需要针对性地开发指定服务的iptables脚本，且导致部署服务需要更高的根用户权限（root权限）执行。

因此，为解决上述问题，本申请提出了基于虚拟地址进行透传的方法，使得微服务在接入服务网格时不需要做任何改动，可在绝大多数场景下保证微服务业务无侵入式地接入服务网格，提升研发效率。

本申请实施例提供的微服务通信方法，可以应用于如图1所示的应用环境中。其中，部署主动调用微服务的设备102通过网络与针对主动调用微服务设置的代理组件104进行通信。针对主动调用微服务设置的代理组件104通过网络与部署被调用微服务的设备106进行通信。其中，针对主动调用微服务设置的代理组件104可以部署于主动调用微服务所在的设备102中，也可以部署于主动调用微服务所在的设备102之外。为各个微服务配置的代理组件构成服务网格。

在本申请的应用场景中，在主动调用微服务接入服务网格所需的代理组件104配置完成的情况下，设备102可响应于针对被调用微服务的第一调用请求，获取被调用微服务对应的虚拟地址，并检测获取虚拟地址是否符合预设的地址条件。若符合，则发送携带虚拟地址的第二调用请求至主动调用微服务的代理组件104，代理组件104基于第二调用请求中的虚拟地址，从被调用微服务所在的设备106中获取得到被调用微服务的数据包，并返回给设备102，由此实现主动调用微服务与被调用微服务之间的通信。

其中，主动调用微服务所在的设备102，以及被调用微服务所在的设备106可以是服务器，也可以为是虚拟机、物理机和云上等。

在一个实施例中，如图2所示，提供了一种微服务通信方法，以该方法应用于图1中的主动调用微服务所在的设备102为例进行说明，包括以下步骤：

步骤S210，在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取被调用微服务对应的虚拟地址。

其中，微服务，即后台服务，在软件架构设计中，将服务功能足够内聚、较小型的服务称为微服务。

其中，当将主动调用微服务接入服务网格后，主动调用微服务可视为服务网格所管理的微服务。

其中，服务网格是一种后台服务架构，通过为每个微服务配套部署一个“边车”型组件，所有的边车组件（即sidecar，或称代理组件）连接成的网格，即是服务网格。服务网格也可以理解为将所有的微服务放在类似于一张网上面，并控制微服务与微服务之间调用请求的路由。

其中，代理组件是服务网格架构中用于接收、处理请求的网络组件，具体是指sidecar（边车）组件。

其中，第一调用请求携带有被调用微服务的服务标识，如服务域名。

其中，被调用微服务可以为服务网格所管理的多个微服务中的任一个微服务。

其中，虚拟地址为实际不可达的地址，即实际上并没有这个地址，是个伪地址。虚拟地址仅用于服务网格内的路由处理。

其中，服务网格中的每个微服务都预先设置有对应的虚拟地址。

具体实现中，当需要将一个微服务接入服务网格时，会为该微服务配置对应的代理组件。在配置完成后，若该微服务对应的客户端需要调用服务网格中的其他微服务的数据，则将发送针对被调用微服务的第一调用请求至部署该微服务的设备，该微服务此时可视为主动调用微服务。部署该微服务的设备接收到第一调用请求后，首先获取第一调用请求携带的被调用微服务的服务标识，根据该服务标识，确定被调用微服务的虚拟地址。

步骤S220，若虚拟地址符合预设的地址条件，发送携带虚拟地址的第二调用请求至主动调用微服务的代理组件。

其中，地址条件为针对地址格式设置的条件。

具体实现中，部署主动调用微服务的设备获取到被调用微服务的虚拟地址后，可进一步对虚拟地址进行检测，即检测虚拟地址的地址格式是否符合预设的地址格式条件。若符合，则将针对被调用微服务的调用请求重定向到主动调用微服务的代理组件，即发送携带虚拟地址的第二调用请求至主动调用微服务的代理组件；若不符合，则直接将针对被调用微服务的调用请求发送给被调用微服务。

更具体地，对虚拟地址进行检测可通过流量拦截工具实现，在流量拦截工具中预先设置检测规则，以通过该检测规则检测虚拟地址是否符合预设的地址条件。

步骤S230，接收代理组件返回的被调用微服务的数据包；数据包为代理组件基于第二调用请求中的虚拟地址，从被调用微服务中获取得到。

具体实现中，在主动调用微服务的代理组件接收到部署主动调用微服务的设备发送的携带虚拟地址的第二调用请求后，代理组件可获取到虚拟地址。进而可根据该虚拟地址，查找之前获取的虚拟地址与微服务的服务实例的IP地址之间的映射关系，得到该虚拟地址对应的微服务的真实IP地址。向该真实IP地址发送数据获取请求，得到该真实IP地址的服务实例返回的数据包，将该数据包返回给部署主动调用微服务的设备。由此，实现了部署主动调用微服务的设备针对被调用微服务的数据调用。

上述微服务通信方法中，在微服务与服务网格管理的其他微服务进行通信时，通过处理第一调用请求，获取被调用微服务的虚拟地址，然后判断虚拟地址是否符合预设的地址条件，并在符合时发送携带所述虚拟地址的第二调用请求至配置的代理组件，由代理组件获取被调用微服务的数据包。该方法通过设置微服务的虚拟地址，从而在主动调用微服务进行请求调用时，可以只需设置一条简单的路由规则来判断虚拟地址与预设地址条件之间的匹配关系，即可实现对请求流量的拦截，无需对微服务进行代码改造，从而可以无侵入式地拦截请求流量，实现快速无侵入式地接入服务网格，减少接入服务网格的成本。并且，由于虚拟地址为实际不可达的IP地址，因此也不会误命中路由规则导致误拦截正常流量。此外，该方法不依赖于部署环境的能力，因此，可以应用于虚拟机、物理机、云和容器等部署环境下。同时，由于只需配置一条简单的匹配规则进行流量拦截，几乎不会带来处理资源的开销，可克服传统为每一个微服务调用关系配置一条路由规则的方法，容易导致微服务数不断增长时，路由规则的查找和匹配消耗大量系统资源，降低系统处理能力的缺陷。

在一示例性实施例中，上述步骤S210中，响应于针对被调用微服务的第一调用请求，获取被调用微服务对应的虚拟地址，包括：获取第一调用请求携带的被调用微服务的服务标识；基于服务标识，确定被调用微服务对应的虚拟地址。

其中，服务标识可以为服务域名。

具体实现中，服务网格中的每个微服务都预先设置有对应的虚拟地址，具体为设置每个微服务的服务标识与虚拟地址之间的映射关系。因此，部署主动调用微服务的设备在获取到第一请求携带的被调用微服务的服务标识后，可基于服务标识，查找服务网格中的每个微服务的服务标识与虚拟地址之间的映射关系，得到被调用微服务的服务标识对应的虚拟地址。

本实施例中，通过预先设置微服务的服务标识与虚拟地址之间的映射关系，从而在任一微服务被调用时，可以基于被调用微服务的服务标识，确定被调用微服务对应的虚拟地址，提高确定虚拟地址的速率和准确性。

在一示例性实施例中，服务标识为服务域名；基于服务标识，确定被调用微服务对应的虚拟地址，包括以下至少两种方式：

方式一：通过域名解析组件，对服务标识进行域名解析处理，得到被调用微服务对应的虚拟地址；域名解析组件为与服务网格匹配的域名解析组件。

其中，服务域名是由一串用点分隔的名字组成的网络上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位，例如，服务域名为：business.module.service/interface。服务域名具有唯一性。

具体实现中，在通过域名解析组件（Domain Name System，DNS解析组件），对服务标识进行域名解析处理之前，需预先将服务网格的域名解析组件添加至部署主动调用微服务的设备所使用的操作系统的DNS解析列表中，以便于针对被调用微服务的服务域名进行解析时，能够使用与服务网格匹配的域名解析组件。

更具体地，通过域名解析组件，确定被调用微服务对应的虚拟地址的过程为：域名解析组件通过查找名字服务组件，从名字服务组件中获取被调用微服务对应的虚拟地址。名字服务组件中存储有服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系。

进一步地，在将服务网格的域名解析组件添加至操作系统的DNS解析列表中后，由于DNS解析列表中还存在操作系统原有的域名解析组件。因此，还需进一步设置DNS解析列表中各域名解析组件的使用优先级，即需将服务网格的域名解析组件设置为最高优先级，以保证针对被调用微服务的服务域名进行解析时，能优先由服务网格对应的域名解析组件处理，保证解析出的为虚拟地址，而不是使用操作系统原有的域名解析组件，以避免其他域名解析组件无法解析出虚拟地址，影响后续的流量拦截。可以理解，由于针对微服务设置虚拟地址是在服务网格中进行的，因此，只有服务网格对应的域名解析组件解析出的为虚拟地址，而其他域名解析组件解析出的不为虚拟地址，所以需要将服务网格的域名解析组件设置为最高优先级。

方式二：基于服务标识，查找预先设置的配置文件，得到被调用微服务对应的虚拟地址；配置文件中存储有服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系。

其中，配置文件可以为部署主动调用微服务的设备的本地配置文件。

具体实现中，也可以预先将服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系存储在部署主动调用微服务的设备的本地配置文件中，从而在部署主动调用微服务的设备进行寻址时，可以直接从本地配置文件中进行查找，得到被调用微服务对应的虚拟地址。

需要说明，除了本实施例列举的通过域名解析组件和配置文件查找被调用微服务对应的虚拟地址外，实际应用中，也可以采用其他的开源或私有服务寻址方式，本申请对此不作具体限定。

本实施例中，通过与服务网格对应的域名解析组件或配置文件的方式确定被调用微服务对应的虚拟地址，以便于能够保证所确定虚拟地址的准确性。

在一示例性实施例中，上述步骤S220中，判断虚拟地址是否符合预设的地址条件为方法为：获取针对虚拟地址设置的基准地址格式；当虚拟地址的地址格式符合基准地址格式时，确定虚拟地址符合预设的地址条件。

具体实现中，虚拟地址为一个实际不可达的地址，因此，可设定一个基准地址格式，例如，127.127.*.*。将所确定被调用微服务的虚拟地址的地址格式与该基准地址格式进行比对，若两者匹配，则确定被调用微服务的虚拟地址符合预设的地址条件，从而可以将针对被调用微服务的调用请求重定向至主动调用微服务的代理组件。

更具体地，可以通过IP表（iptables）规则实现请求流量的拦截，具体而言，可在将主动调用微服务接入服务网格，即进行初始化时，在部署主动调用微服务的设备中自动添加一条iptables规则，该规则为将地址格式符合基准地址格式的调用请求，重定向到本设备对应的代理组件。

需要说明，实际应用中，也可以使用其他技术实现请流量求的拦截，如eBPF技术实现拦截、通过开发程序直接调用系统库实现拦截等，本申请对此不作具体限定。其中，eBPF技术是一个能够在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制。

本实施例中，通过设定虚拟地址的基准地址格式，在每次进行请求重定向前，通过将被调用微服务的虚拟地址的地址格式与该基准地址格式进行比对，基于比对结果确定是否进行重定向，判断规则简单且适用于所有微服务，可以极大地节省操作系统的处理资源。

需要说明，一个微服务通常部署有多个运行实体（IP、容器、进程等），这些运行实体称为服务实例。例如，在一个服务器上只运行一个进程，就是一个实例（IP级）；在一个服务器上运行多个进程，就是多个实例（进程级）；在服务器上或云服务平台上运行容器，一个容器就是一个实例。因此，服务网格中的一个微服务可能对应一个服务实例，也可能对应多个服务实例。

对应地，在一示例性实施例中，被调用微服务对应至少一个服务实例；接收代理组件返回的被调用微服务的数据包，包括：接收代理组件返回的被调用微服务中的目标服务实例的数据包。

其中，代理组件，还用于基于第二调用请求中的虚拟地址，确定对应的被调用微服务；从被调用微服务对应的至少一个服务实例中，选择出目标服务实例；发送获取请求至目标服务实例，以获取目标服务实例的数据包。

其中，一个微服务对应的各个服务实例均对应同一个虚拟地址，即虚拟地址为以微服务为粒度进行设置的。

具体地，代理组件中预先存储有不同微服务与对应的至少一个服务实例之间的关联关系信息，每个服务实例具有对应的IP地址。该关联关系信息由名字服务组件实时地推送得到。因此，在代理组件接收到携带被调用微服务的虚拟地址的第二调用请求后，可通过虚拟地址查找所存储的不同微服务与对应的至少一个服务实例之间的关联关系信息，得到该虚拟地址对应的至少一个服务实例。然后从至少一个服务实例中选择出目标服务实例，基于该目标服务实例的IP地址，发送获取请求给目标服务实例，接收目标服务实例返回的数据包，进一步返回给部署主动调用微服务的设备。

更具体地，从至少一个服务实例中选择出目标服务实例具体包括：当至少一个服务实例中只有一个服务实例时，将该服务实例作为目标服务实例；当至少一个服务实例中有多个服务实例时，则根据负载均衡算法，从多个服务实例中挑选出一个服务实例，作为目标服务实例。其中，负载均衡算法可以为随机算法、轮询算法、加权轮询算法、最小活跃连接算法、一致性哈希算法和自适应最优选择算法等等，具体采用哪一种算法可根据实际需求或应用场景确定，本申请对此不作具体限定。

本实施例中，通过代理组件从被调用微服务对应的至少一个服务实例中选则目标服务实例时，结合负载均衡算法进行目标服务实例的选择，以确保系统的高可用性、高性能和可扩展性。

在一示例性实施例中，所述方法还包括：调用名字服务组件，对主动调用微服务的各个服务实例进行注册；名字服务组件用于存储接入服务网格的每个微服务的虚拟地址与每个微服务的服务实例之间的关联关系。

其中，名字服务组件是指为微服务分配“虚拟地址”，实现注册、寻址的请求路由组件。

具体地，在将一个微服务初次接入服务网格时，除了为该微服务配置对应的代理组件外，还需对该微服务进行注册，即为该微服务分配虚拟地址。其中，微服务对应至少一个服务实例，因此，对微服务的注册实际为对微服务对应的各个服务实例的注册，具体可注册至名字服务组件中。

更具体地，在将微服务初次接入服务网格时，可通过部署脚本自动调用名字服务组件对微服务的各个服务实例进行注册。名字服务组件收到注册请求后，检查微服务对应的各个服务实例，为该微服务分配虚拟地址，并将该微服务的各个服务实例加入到该虚拟地址对应的服务实例集合中，即建立该微服务的虚拟地址与服务实例之间的关联关系，按照该方法可实现对主动调用微服务的注册。

本实施例中，在将一个微服务初次接入服务网格时，除了为该微服务配置对应的代理组件外，还需对该微服务进行注册，即为该微服务分配虚拟地址，以便于后续任一微服务在被调用时，能够获取其虚拟地址和对应的服务实例。

在一示例性实施例中，名字服务组件还用于在注册主动调用微服务的第一个服务实例时，生成主动调用微服务的目标虚拟地址，建立第一个服务实例与目标虚拟地址之间的关联关系；在注册主动调用微服务的后续的服务实例时，将后续的服务实例关联至目标虚拟地址。

具体实现中，名字服务组件在对主动调用微服务的各个服务实例进行注册的过程中，当注册第一个服务实例时，名字服务组件生成针对该主动调用微服务的虚拟地址，并将第一个服务实例关联到该虚拟地址。后续再注册该微服务的其他服务实例时，则可直接将其他服务实例关联到该虚拟地址，由此实现将一个微服务的多个服务实例绑定同一个虚拟地址。

本实施例中，将一个微服务的多个服务实例绑定同一个虚拟地址，以便于后续在对微服务进行调用时，在确定该微服务的虚拟地址后，可基于一个虚拟地址确定出该微服务对应的各个服务实例，进而从各个服务实例中进行目标服务实例的选择。

在一示例性实施例中，名字服务组件还用于检测名字服务组件中的服务实例的运行情况；若检测到任一个服务实例处于未运行状态，则剔除任一个服务实例，并解除任一个服务实例与对应的微服务的虚拟地址之间的关联关系。

具体地，名字服务组件还可定期检测其存储的不同微服务的各个服务实例的运行情况，或称存活情况。若检测到任一个微服务的任一个服务实例不存活，即处于未运行状态，则可剔除该服务实例，同时解除该服务实例与对应的微服务的虚拟地址之间的关联关系。

例如，若检测到微服务A中的服务实例A₃不存活，则剔除该服务实例A₃，同时解除该服务实例A₃与对应的微服务A的虚拟地址之间的关联关系。

进一步地，路由推送组件可监听名字服务组件中的更新信息，更新信息包括服务实例的剔除、微服务的增加、微服务实例的增加等。在监测到存在更新时，将更新信息推送至服务网格中各个微服务的代理组件中，以便于各个微服务在调用其他微服务时，其对应的代理组件能够从存储的各个微服务的虚拟地址与服务实例之间的关联关系信息中，快速确定出被调用微服务对应的服务实例。

本实施例中，通过名字服务组件检测各服务实例的运行情况，并在检测到任一个服务实例处于未运行状态时，剔除该服务实例，以及解除该服务实例与对应的微服务的虚拟地址之间的关联关系，从而可以保证名字服务组件中服务实例的实时有效性。

在另一示例性实施例中，如图3所示，是根据一示例性实施例示出的一种微服务通信方法的具体流程图，本实施例中，该方法包括以下步骤：

步骤S310，在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取第一调用请求携带的被调用微服务的服务域名；

步骤S320，通过与服务网格匹配的域名解析组件，对服务域名进行域名解析处理，得到被调用微服务对应的虚拟地址；或者，

步骤S330，基于服务域名，查找预先设置的配置文件，得到被调用微服务对应的虚拟地址；

步骤S340，当虚拟地址的地址格式符合基准地址格式时，发送携带虚拟地址的第二调用请求至主动调用微服务的代理组件；

步骤S350，接收代理组件返回的被调用微服务中的目标服务实例的数据包。

本实施例提供的方法，针对服务网格接入过程中如何无侵入式拦截请求流量的问题，通过一个虚拟地址机制，只需要在iptables中内置一条路由规则即可，对系统iptables处理性能几乎无影响，且不会对系统其它流量规则带来干扰。

在一个实施例中，为了便于本领域技术人员理解本申请实施例，以下将结合附图的具体示例进行说明。

参考图4，示出了本申请提供的微服务通信方法的原理示意图。如图4所示，本申请的微服务通信方法主要包括四个处理流程：服务注册、服务寻址、流量拦截和请求发送。以下对各个处理流程分别进行介绍。

1、服务注册

（1.1）当一个微服务初次接入服务网格时，通过部署脚本自动调用名字服务组件进行注册。

其中，名字服务组件为外部组件，与服务网格进行对接。

（1.2）名字服务组件接收到注册请求后，检查微服务对应的各个服务实例，对各个服务实例进行注册。

具体地，当注册该微服务的第一服务实例时，名字服务组件生成虚拟地址，将第一个服务实例关联到该虚拟地址。后续再注册该微服务的其他服务实例时，直接将其他服务实例关联到该虚拟地址。

（1.3）名字服务组件定期检查服务实例是否存活，若检测到不存活的服务实例，则剔除该服务实例，并解除该不存活的服务实例与对应的虚拟地址之间的关联。

（1.4）路由推送组件监听名字服务组件中的变更情况，将最新的服务路由信息推送到服务网格中各微服务的代理组件（sidecar）。

具体地，路由推送组件从名字服务组件中获取服务实例的路由信息后，转换为服务网格的配置，推送给各微服务的代理组件。

2、服务寻址

（2.1）部署主动调用微服务的设备将服务网格的DNS解析组件添加到其操作系统的DNS解析列表中，并设置服务网格的DNS解析组件为最高的使用优先级，以保证后续的DNS解析过程可优先使用服务网格配套的DNS组件，而不是系统默认的DNS解析组件。

（2.2）部署主动调用微服务的设备接收到携带被调用微服务的服务域名的第一调用请求后，通过服务网格的DNS解析组件，从名字服务组件中查找服务域名与虚拟地址之间的映射关系，得到被调用微服务的服务域名对应的虚拟地址。

其中，服务网格的DNS解析组件兼容标准DNS解析请求。

3、流量拦截

（3.1）部署主动调用微服务的设备在初始化时自动添加一条iptables规则，该规则设定将虚拟地址符合基准地址格式的请求，重定向到本设备的代理组件（sidecar）端口。

（3.2）部署主动调用微服务的设备获取到DNS解析返回的被调用微服务的虚拟地址后，先判断该虚拟地址是否符合所添加的iptables规则。

（3.3）若符合iptables规则，则发送携带该虚拟地址的第二调用请求至本设备的代理组件（sidecar）。

（3.4）代理组件（sidecar）接收到第二调用请求后，可获取到被调用微服务的虚拟地址，至此实现流量拦截。

4、请求发送

（4.1）由于路由推送组件会将最新的服务路由信息（即微服务与服务实例之间的映射关系）推送到代理组件（sidecar），因此，代理组件（sidecar）拦截到第二调用请求，并获取到被调用微服务的虚拟地址后，可根据虚拟地址，查找其预先接收的路由推送组件推送的服务路由信息，得到虚拟地址对应的所有服务实例。

（4.2）代理组件（sidecar）根据特定的负载均衡算法，从所有服务实例中挑选一个服务实例，作为目标服务实例，向该目标服务实例发送调用请求。

（4.3）代理组件（sidecar）接收被调用的目标服务实例返回的数据包，并将该数据包原路返回给发起调用的主动调用微服务。

本申请提供的方法，具体具有以下效果：

（1）不限定服务部署环境。

现有的常规方案通常只能基于K8s容器环境部署，流量拦截、路由规则基本限定为K8s环境下，大量依赖容器化能力。本技术方案不对部署环境做假定，既可以部署在K8s环境下，亦部署在虚拟机、物理机或云上。

（2）减少服务网格接入成本。

当前的软件技术架构，特别是互联网海量服务后台，正在往服务网格架构发展。但接入过程中大多面临新老服务兼容的问题：新服务接入容易，老服务适配困难。本方案减化了服务网格接入成本，可实现快速无侵入式接入。

（3）减少服务网格流量拦截的开销。

现有的常规接入方案是为每一个服务调用关系配置一条iptables路由规则，当微服务数不断增长时，iptables规则的查找和匹配会消耗大量的系统资源，降低服务处理能力。而本方案只需一条匹配规则，几乎不带来系统开销。

（4）不会因误命中网络规则导致误拦截流量。

当主动调用微服务预先不知道被调用的所有IP端口时，一种做法是仅针对出流量端口配置规则，如将目标端口为10240的所有流量转发到代理组件（sidecar）。这种方式有可能误命中（如请求另外一个目标端口也为10240的未接入服务网格的服务），将未接入网格的流量也重定向到sidecar，导致处理异常。本方案通过虚拟地址匹配，该虚拟地址范围可设置为实际不可达的IP范围（如127.127.*.*），不会误匹配正常流量，具有较好的落地可行性。

（5）具备切实有效的可扩展性。

基于虚拟VIP的路由方案，不仅可用于RPC流量接管，亦可用于其它流量如存储流量、监控上报流量等。理论上通过配套的管理控制系统，本方案可用于无侵入式接管任意流量。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的微服务通信方法的微服务通信装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个微服务通信装置实施例中的具体限定可以参见上文中对于微服务通信方法的限定，在此不再赘述。

在一个实施例中，如图5所示，提供了一种微服务通信装置，包括：地址获取模块510、请求发送模块520和数据接收模块530，其中：

地址获取模块510，用于在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取被调用微服务对应的虚拟地址；虚拟地址为针对被调用微服务设置的不可实际使用的地址；

请求发送模块520，用于若虚拟地址符合预设的地址条件，发送携带虚拟地址的第二调用请求至主动调用微服务的代理组件；

数据接收模块530，用于接收代理组件返回的被调用微服务的数据包；数据包为代理组件基于第二调用请求中的虚拟地址，从被调用微服务中获取得到。

在其中一个实施例中，地址获取模块510，还用于获取第一调用请求携带的被调用微服务的服务标识；基于服务标识，确定被调用微服务对应的虚拟地址。

在其中一个实施例中，服务标识为服务域名；地址获取模块510，还用于通过域名解析组件，对服务标识进行域名解析处理，得到被调用微服务对应的虚拟地址；域名解析组件为与服务网格匹配的域名解析组件；或者，基于服务标识，查找预先设置的配置文件，得到被调用微服务对应的虚拟地址；配置文件中存储有服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系。

在其中一个实施例中，所述装置还包括地址检测模块，用于获取针对虚拟地址设置的基准地址格式；当虚拟地址的地址格式符合基准地址格式时，确定虚拟地址符合预设的地址条件。

在其中一个实施例中，被调用微服务对应至少一个服务实例；数据接收模块530，还用于接收代理组件返回的被调用微服务中的目标服务实例的数据包；其中，代理组件，还用于基于第二调用请求中的虚拟地址，确定对应的被调用微服务；从被调用微服务对应的至少一个服务实例中，选择出目标服务实例；发送获取请求至目标服务实例，以获取目标服务实例的数据包。

在其中一个实施例中，所述装置还包括服务注册模块，用于调用名字服务组件，对主动调用微服务的各个服务实例进行注册；名字服务组件用于存储接入服务网格的每个微服务的虚拟地址与每个微服务的服务实例之间的关联关系。

在其中一个实施例中，名字服务组件，还用于在注册主动调用微服务的第一个服务实例时，生成主动调用微服务的目标虚拟地址，建立第一个服务实例与目标虚拟地址之间的关联关系；在注册主动调用微服务的后续的服务实例时，将后续的服务实例关联至目标虚拟地址。

在其中一个实施例中，名字服务组件，还用于检测名字服务组件中的服务实例的运行情况；若检测到任一个服务实例处于未运行状态，则剔除任一个服务实例，并解除任一个服务实例与对应的微服务的虚拟地址之间的关联关系。

上述微服务通信装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储微服务通信过程中的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种微服务通信方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-OnlyMemory，ROM）、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器（ReRAM）、磁变存储器（Magnetoresistive Random Access Memory，MRAM）、铁电存储器（Ferroelectric Random Access Memory，FRAM）、相变存储器（Phase Change Memory，PCM）、石墨烯存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic RandomAccess Memory，DRAM）等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种微服务通信方法，其特征在于，所述方法包括：

在主动调用微服务接入服务网格所需的代理组件配置完成的情况下，响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址；所述虚拟地址为针对所述被调用微服务设置的不可实际使用的地址；

若所述虚拟地址符合预设的地址条件，发送携带所述虚拟地址的第二调用请求至所述主动调用微服务的代理组件；

接收所述代理组件返回的所述被调用微服务的数据包；所述数据包为所述代理组件基于所述第二调用请求中的所述虚拟地址，从所述被调用微服务中获取得到。

2.根据权利要求1所述的方法，其特征在于，所述响应于针对被调用微服务的第一调用请求，获取所述被调用微服务对应的虚拟地址，包括：

获取所述第一调用请求携带的所述被调用微服务的服务标识；

基于所述服务标识，确定所述被调用微服务对应的虚拟地址。

3.根据权利要求2所述的方法，其特征在于，所述服务标识为服务域名；所述基于所述服务标识，确定所述被调用微服务对应的虚拟地址，包括：

通过域名解析组件，对所述服务标识进行域名解析处理，得到所述被调用微服务对应的虚拟地址；所述域名解析组件为与所述服务网格匹配的域名解析组件；

或者，基于所述服务标识，查找预先设置的配置文件，得到所述被调用微服务对应的虚拟地址；所述配置文件中存储有所述服务网格中的各个微服务的服务标识与虚拟地址之间的映射关系。

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

获取针对虚拟地址设置的基准地址格式；

当所述虚拟地址的地址格式符合所述基准地址格式时，确定所述虚拟地址符合预设的地址条件。

5.根据权利要求1所述的方法，其特征在于，所述被调用微服务对应至少一个服务实例；所述接收所述代理组件返回的所述被调用微服务的数据包，包括：

接收所述代理组件返回的所述被调用微服务中的目标服务实例的数据包；

其中，所述代理组件，还用于基于所述第二调用请求中的所述虚拟地址，确定对应的被调用微服务；从所述被调用微服务对应的至少一个服务实例中，选择出目标服务实例；发送获取请求至所述目标服务实例，以获取所述目标服务实例的数据包。

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

调用名字服务组件，对所述主动调用微服务的各个服务实例进行注册；

所述名字服务组件用于存储接入所述服务网格的每个微服务的虚拟地址与所述每个微服务的服务实例之间的关联关系。

7.根据权利要求6所述的方法，其特征在于，所述名字服务组件，还用于：

在注册所述主动调用微服务的第一个服务实例时，生成所述主动调用微服务的目标虚拟地址，建立所述第一个服务实例与所述目标虚拟地址之间的关联关系；

在注册所述主动调用微服务的后续的服务实例时，将所述后续的服务实例关联至所述目标虚拟地址。

8.根据权利要求6或7所述的方法，其特征在于，所述名字服务组件，还用于：

检测所述名字服务组件中的服务实例的运行情况；

若检测到任一个服务实例处于未运行状态，则剔除所述任一个服务实例，并解除所述任一个服务实例与对应的微服务的虚拟地址之间的关联关系。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至8中任一项所述的微服务通信方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的微服务通信方法的步骤。