一种对接微服务网格的方法以及装置与流程

1.本技术涉及云计算技术领域，尤其涉及一种对接微服务网格的方法以及装置。


背景技术：

2.在微服务架构的逐步演进中，服务网格(service mesh)技术作为一种新型的微服务形态，受到业界的广泛关注。目前，服务网格技术最主流的一个产品开源项目：伊斯特亿欧(istio)。为了享受istio完善的微服务治理能力，当前大部分新开发的业务都对接istio。现有的基于开源分布式服务框架，如达博(dubbo)、或分布式云服务框架，如春云(spring cloud)等分布式应用开发框架开发的应用也可以对接istio，以享受istio完善的微服务治理能力。
3.基于dubbo、或spring cloud等分布式应用开发框架开发的应用已经存在一套完整的服务注册、服务发现、以及负载均衡等逻辑，而istio也有一套完整的服务注册、服务发现、以及负载均衡等逻辑，这就导致基于dubbo、或spring cloud等分布式应用开发框架开发的应用自身的服务注册、服务发现、负载均衡等逻辑与istio的冲突。如何将基于dubbo、或spring cloud等分布式应用开发框架开发的应用对接istio是需要考虑的问题。


技术实现要素：

4.本技术的目的在于提供了一种对接微服务网格的方法以及代理组件，该微服务网格可以为istio服务网格，该方法用以实现dubbo应用、或spring cloud应用无侵入式的对接istio。
5.第一方面，本技术实施例提供一种对接微服务网格的方法，该方法可以由微服务系统的代理(agent)组件执行。在该方法中，agent组件拦截所述微服务系统中的第一应用实例发出的服务发现请求，所述服务发现请求用于获取所述微服务系统中的一个或多个第二应用实例对应的ip地址集，其中，第二应用实例用于提供目标服务；所述agent组件向所述第一应用实例发送服务发现响应，其中，所述服务发现响应包括所述ip地址集对应的域名。所述ip地址集对应的域名可以为kubernetes域名。
6.其中，agent组件与第一应用实例运行在同一进程中，且agent组件未集成在所述第一应用实例中。
7.可选的，第一应用实例为基于dubbo架构开发的应用，或者为基于spring cloud架构开发的应用。第一应用实例可以为第一应用程序的一个或多个应用实例中的一个。一个或多个第二应用实例可以为第二应用程序的应用实例。该服务发现请求用于获取一个或多个第二应用实例对应的ip地址集可以为该服务发现请求用于获取第二应用程序的一个或多个第二应用实例对应的ip地址集。例如，第二应用程序仅在一个运行环境中运行，则该第二应用程序包括一个第二应用实例。又例如，第二应用程序在多个运行环境中运行，则该第二应用程序包括多个第二应用实例。
8.在上述实施例中，agent组件拦截第一应用实例原有服务发现逻辑所发送的服务
发现请求，并向第一应用实例发送包括kubernetes域名的服务发现响应，这样服务发现请求就无法发送到第一应用实例对应的注册中心，从而可以屏蔽第一应用实例自身的服务发现逻辑，能够避免第一应用实例自身的服务发现逻辑与istio的服务发现逻辑之间的冲突。第一应用实例接收到的服务发现响应中包括的是kubernetes域名，而不是ip地址集，第一应用实例无需对kubernetes域名执行路由、负载均衡等，能够省去第一应用实例自身的路由、负载均衡等流程，减少第一应用实例的计算量，减少性能消耗。并且，agent组件的升级或修改无需更改第一应用实例的sdk，也无需更改istio的服务发现逻辑，实现了第一应用实例非侵入式的对接istio，可以减少工作量。
9.在一种可能的设计中，所述第一服务发现请求包括所述第二应用实例的标识信息，该方法还可以包括：agent组件根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名；所述agent组件根据所述域名生成所述服务发现响应。
10.其中，所述标识信息包括第二应用实例的应用名(又可以称为第二应用程序的应用名)，或者包括目标服务的服务名，或者包括第二应用实例的应用名和目标服务的服务名。
11.例如，标识信息包括第二应用实例的应用名，则agent组件根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名可以为：agent组件根据所述第二应用实例的应用名和所述第一应用实例的环境变量，构建所述域名。
12.又例如，标识信息包括目标服务的服务名，则agent组件根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名可以为：agent组件根据配置文件和目标服务的服务名，获取第二应用实例的应用名，并根据第二应用实例的应用名和第一应用实例的环境变量构建所述域名；其中，该配置文件包括目标服务的服务名与提供所述目标服务的应用实例的应用名的对应关系。
13.通过上述设计，agent组件拦截第一应用实例发出的服务发现请求后，可以根据第二应用实例的标识信息和自身的环境变量构建一个kubernetes域名，并向第一应用实例发送该一个kubernetes域名，相当于agent组件为第一应用实例构建了一个服务发现结果，终止了第一应用实例的服务发现流程，从而可以避免第一应用实例自身的服务发现流程与istio的服务发现流程之间的冲突。
14.在一种可能的设计中，所述微服务系统还包括接口服务器组件，在所述agent组件拦截所述第一应用实例发出的服务发现请求之前，该方法还可以包括：agent组件拦截所述第一应用实例发出的第一服务注册请求；agent组件根据所述第一服务注册请求，生成第二服务注册请求，所述第二服务注册请求包括所述第一应用实例的应用名；以及，agent组件向所述接口服务器组件发送所述第二服务注册请求。其中，接口服务器组件可以为应用程序接口服务器(api server)组件。
15.在上述实施例中，agent组件拦截第一应用实例按照自身的服务注册逻辑所发送的第一服务注册请求，并以第一应用实例的应用名向api server组件发起服务注册流程，以屏蔽第一应用实例自身的服务注册逻辑。也就是说，开发人员可以通过修改或升级第一应用实例的agent组件就可以避免第一应用实例自身的服务注册逻辑与istio的服务注册逻辑之间的冲突。并且，agent组件的升级或修改无需更改第一应用实例的sdk，也无需更改istio的服务注册逻辑，实现了dubbo应用(或spring cloud应用)非侵入式的对接istio，可
以减少工作量。
16.在一种可能的设计中，在agent组件向所述接口服务器组件发送第二服务注册请求之后，agent组件还可以接收来自所述接口服务器组件发送的第二服务注册响应，该第二服务注册响应可用于指示第一应用实例注册成功或失败。进一步，agent组件可以根据第二服务注册响应生成第一服务注册响应，并将第一服务注册响应发送给第一应用实例，该第一服务注册响应用于指示第一应用实例注册成功或失败。其中，若第二服务注册响应用于指示第一应用实例注册成功，则第一服务注册响应也用于指示第一应用实例注册成功。若第二服务注册响应用于指示第一应用实例注册失败，则第一服务注册响应也用于指示第一应用实例注册失败。
17.通过上述设计，第一应用实例可以实现在api server组件中的注册。
18.第二方面，本技术实施例提供一种代理组件，该代理组件可以部署在电子设备(如服务器等)，用于实现上述第一方面或第一方面任一项可能的设计中所述的方法。所述代理组件所实现的功能可以过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块(或单元)，如包括处理模块和通信模块。其中，代理组件可以为agent组件。
19.示例性的，处理模块，用于拦截微服务系统中的第一应用实例发出的服务发现请求，所述服务发现请求用于获取所述微服务系统中的一个或多个第二应用实例对应的ip地址集，其中，第二应用实例用于提供目标服务。
20.通信模块，用于向所述第一应用实例发送服务发现响应，其中，所述服务发现响应包括所述ip地址集对应的域名。所述ip地址集对应的域名可以为kubernetes域名。
21.其中，agent组件与第一应用实例运行在同一进程中，且agent组件未集成在所述第一应用实例中。
22.可选的，第一应用实例为基于dubbo架构开发的应用，或者为基于spring cloud架构开发的应用。
23.在一种可能的设计中，所述第一服务发现请求包括所述第二应用实例的标识信息；所述处理模块，进一步用于根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名；以及，根据所述域名生成所述服务发现响应。
24.其中，所述标识信息包括第二应用实例的应用名，或者包括目标服务的服务名，或者包括第二应用实例的应用名和目标服务的服务名。
25.在一种可能的设计中，标识信息包括第二应用实例的应用名，则处理模块具体用于：根据所述第二应用实例的应用名和所述第一应用实例的环境变量，构建所述域名。
26.在一种可能的设计中，标识信息包括目标服务的服务名，则处理模块具体用于：根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名可以为：agent组件根据配置文件和目标服务的服务名，获取第二应用实例的应用名，并根据第二应用实例的应用名和第一应用实例的环境变量构建所述域名；其中，该配置文件包括目标服务的服务名与提供所述目标服务的应用实例的应用名的对应关系。
27.在一种可能的设计中，所述微服务系统还包括接口服务器组件；所述处理模块，进一步用于拦截所述第一应用实例发出的第一服务注册请求；以及，根据所述第一服务注册请求，生成第二服务注册请求，所述第二服务注册请求包括所述第一应用实例的应用名；所
述通信模块，进一步用于向所述接口服务器组件发送所述第二服务注册请求。
28.在一种可能的设计中，通信模块进一步用于：接收来自所述接口服务器组件发送的第二服务注册响应，该第二服务注册响应可用于指示第一应用实例注册成功或失败。处理模块进一步用于：根据第二服务注册响应生成第一服务注册响应；通信模块进一步用于将第一服务注册响应发送给第一应用实例，该第一服务注册响应用于指示第一应用实例注册成功或失败。其中，若第二服务注册响应用于指示第一应用实例注册成功，则第一服务注册响应也用于指示第一应用实例注册成功。若第二服务注册响应用于指示第一应用实例注册失败，则第一服务注册响应也用于指示第一应用实例注册失败。
29.第三方面，本技术实施例提供一种电子设备，该电子设备可以是服务器等。该电子设备可以包括一个或多个处理器，存储器以及通信接口。其中，存储器，用于存储计算机程序和数据。该存储器与该一个或多个处理器耦合，该一个或多个处理器可以执行该存储器中存储的计算机程序，用于实现上述第一方面或第一方面任一项可能的设计中所述的方法。
30.第四方面，本技术实施例提供一种计算设备集群，包括一个或多个计算设备，所述计算设备包括存储器和一个或多个处理器；所述一个或多个处理器与所述存储器耦合，所述存储器用于存储计算机程序或指令，当所述计算机程序或所述指令被所述一个或多个处理器执行时，使得所述计算设备执行上述第一方面或第一方面任一项可能的设计中所述的方法。
31.第五方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行上述第一方面或第一方面任一项可能的设计中所述的方法。
32.第六方面，本技术实施例提供一种计算机程序产品，包括指令，当所述指令在电子设备上运行时，使得所述电子设备执行上述第一方面或第一方面任一项可能的设计中所述的方法。
33.第七方面，本技术实施例还提供一种芯片系统，该芯片系统包括一个或多个处理器和接口电路，所述处理器用于通过所述接口电路执行指令和/或数据的交互，使得所述芯片系统所在的装置实现上述第一方面或第一方面任一项可能的设计中所述的方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
34.上述第二方面至第七方面及其实现方式的有益效果请参照上述第一方面及其任一项可能的设计所能达到的技术效果，这里不再重复赘述。
附图说明
35.图1为本技术实施例提供的istio微服务系统的一种结构示意图；
36.图2为本技术实施例提供的对接微服务网格的一种流程示意图；
37.图3为本技术实施例提供的istio微服务系统的又一种结构示意图；
38.图4为本技术实施例提供的对接微服务网格的又一种流程示意图；
39.图5为本技术实施例提供的对接微服务网格的再一种流程示意图；
40.图6为本技术实施例提供的通信装置的一种结构示意图；
41.图7为本技术实施例提供的电子设备的一种结构示意图。
具体实施方式
42.首先，先对本技术实施例中涉及的部分用语进行解释说明，以便于本领域技术人员容易理解。
43.(1)微服务，又可以称为微服务系统，是一种软件架构风格，它以专注于单一责任与功能的小型功能区块(small building blocks)为基础，利用模组化的方式组合出复杂的大型应用程序。其中，微服务的各个功能区块使用与语言无关(language-independent/language agnostic)的应用程序接口(application programming interface，api)集进行通信。
44.(2)服务网格(service mesh)，是一种新型的微服务形态，它通过边车(sidecar)方式将已有服务接入微服务治理系统，以享用微服务的服务注册、服务发现、以及服务治理等能力。本技术实施例涉及的服务网格伊斯蒂奥(istio)服务网格。
45.(3)库伯奈踢斯(kubernetes)，是一种开源的容器编排引擎，用于管理云平台中多个主机上的容器化的应用程序(application，app)。在部署一个应用程序时，通常要部署该应用程序的多个应用实例，在kubernetes中，可以为一个应用程序创建多个容器，每个容器里面运行该应用程序的一个应用实例。
46.(4)应用实例，又可以称为应用程序的实例、实例、应用程序实例等等。一个应用程序可以包括一个或多个应用实例。一个应用实例可以理解为应用程序在一个运行环境中的一个进程。一个应用程序在n个不同的运行环境中运行，则该应用程序包括n个应用实例，其中n为大于0的整数。
47.(5)容器，是实现操作系统虚拟化的一种途径，可以让用户在资源受到隔离的进程中运行应用程序及其依赖关系。(6)本技术实施例的描述中，“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本技术中所涉及的至少一个是指一个或多个；多个，是指两个或两个以上。
48.以及，除非有相反的说明，本技术实施例提及“第一”、“第二”、“第三”等序数词是用于对多个对象进行区分，不用于限定多个对象的大小、内容、顺序、时序、优先级或者重要程度等。例如，第一信息、第二信息和第三信息等，只是为了区分不同的信息，而并不是表示这三个信息的大小、内容、发送顺序、优先级或者重要程度等的不同。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
49.为便于理解本技术实施例，接下来对本请的应用场景进行介绍，本技术实施例描述的网络架构以及业务场景是为了更加清楚的说明本技术实施例的技术方案，并不构成对于本技术实施例提供的技术方案的限定，本领域普通技术人员可知，随着新业务场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
50.如前述的背景技术所述，基于dubbo、或spring cloud等分布式应用开发框架开发的应用可以对接istio，以享受istio完善的微服务治理能力。为了便于理解本技术实施例，下文中基于dubbo分布式应用开发框架开发的应用可以简称为dubbo应用。类似的，基于spring cloud分布式应用开发框架开发的应用可简称为spring cloud应用。
51.以dubbo应用为例，dubbo应用的一个应用实例(下文简称为dubbo应用实例)向dubbo应用对应的注册中心发送注册请求，dubbo应用对应的注册中心接收到注册请求后，记录dubbo应用实例的网际互连协议(internet protocol，ip)地址，并完成对该dubbo应用实例的注册。其中，dubbo应用对应的注册中心可以是管理员(zookeeper)，该zookeeper用于提供一致性服务，如服务注册、ip地址查询等等。在dubbo应用实例注册完成之后，dubbo应用实例可以向dubbo应用对应的注册中心发送发现请求，以获取为dubbo应用实例提供服务的一个或多个应用实例的ip地址。进一步，dubbo应用实例通过负载均衡算法等从该一个或多个应用实例中确定其中的一个应用实例为目标应用实例(ip地址)，并向该目标应用实例发送服务调用请求，以请求该目标应用实例为其提供服务。
52.dubbo应用自身的服务注册、服务发现以及负载均衡等逻辑，与istio中的服务注册、服务发现以及负载均衡等逻辑是独立的两套逻辑，这就导致dubbo应用自身的服务注册、服务发现以及负载均衡等、与istio的服务注册、服务发现以及负载均衡等冲突。
53.可以理解的是，spring cloud应用自身的服务注册、服务发现以及负载均衡等流程，与dubbo应用自身的服务注册、服务发现、以及负载均衡等流程类似。也即是说，spring cloud应用自身的服务注册、服务发现以及负载均衡等流程也与istio的冲突。
54.目前，若要将dubbo应用或spring cloud应用对接istio，可以更改dubbo应用或spring cloud应用自身的服务注册、服务发现以及负载均衡等流程，或者更改istio的envoy组件的能力。下面对这两种方式进行简单介绍。
55.方式1：更改dubbo应用或spring cloud应用自身的服务注册、服务发现以及负载均衡等流程。
56.以dubbo应用为例，通过修改dubbo应用的软件开发工具包(software development kit，sdk)，以去除dubbo应用的sdk中自身的服务注册逻辑、自身的服务发现逻辑、以及自身的路由、容错、负载均衡等机制。例如，服务注册逻辑由自身的通过向注册中心发送注册请求，更改为在部署时手动创建kubernetes service对象。例如，服务发现逻辑由自身的通过向zookeeper发送服务发现请求后再进行服务调用，更改为直接构造目标服务的访问域名后向istio的特使(envoy)发送服务调用请求，istio的envoy组件根据目标服务的访问域名进行服务发现流程。
57.通过方式1，可以去除dubbo应用或spring cloud应用自身的服务注册、服务发现以及负载均衡等流程。但是，方式1需要重新编译dubbo应用或spring cloud应用的sdk，编译工作量大，且容易出错。
58.方式2：更改istio的envoy组件的能力。
59.通过修改envoy组件，使envoy组件支持dubbo或spring cloud应用注册中心的服务注册和服务发现能力。例如，修改envoy组件，以使修改后的envoy组件能够实现dubbo应用或spring cloud应用的注册中心接口的功能，从而替代dubbo应用或spring cloud应用对应的注册中心，完成服务注册。再例如，修改envoy组件，以使修改后的envoy组件能够接收dubbo应用或spring cloud应用服务发现请求，将服务发现响应中的目标服务的ip地址修改为该目标服务在kubernetes中的访问域名，并返回给dubbo应用或spring cloud应用；dubbo应用或spring cloud应用执行路由、容错、负载均衡等机制，以该访问域名为目标地址发送服务调用请求；修改后的envoy组件能够接收该服务调用请求，并根据该访问域名进
行服务发现流程。
60.通过方式2，可以使envoy组件支持dubbo或spring cloud应用对应的注册中心的服务注册和服务发现能力，但未去除dubbo应用或spring cloud应用自身的路由、容错、负载均衡等机制，浪费了计算能力，导致额外的性能消耗。另外，方式2需要重新编译envoy组件，不仅编译工作量大，容易出错，且与istio的发展方向(即，通过envoy组件的服务发现以及负载均衡等能力，享用istio完善的微服务治理能力)背离，不易于维护。
61.鉴于此，本技术实施例提供一种对接微服务网格的方法以及代理组件。通过本技术实施例所提供的方法，dubbo应用或spring cloud应用可以无侵入式的对接istio，无需更改dubbo应用或spring cloud应用的sdk，也无需更改istio的envoy组件的能力，减少对接工作量，符合istio的发展方向。
62.下面结合本技术实施例中的附图，对本技术实施例提供的对接istio服务网格方法进行详细地描述。
63.本技术实施例提供的对接istio服务网格方法可以分为三个流程，分别为服务注册流程、服务发现流程和服务调用流程。
64.其中，对接istio服务网格方法可以应用于istio微服务系统，具体可以应用于如下图1所示的istio微服务系统100，或者应用于如下图3所示的istio微服务系统300。下面对接istio服务网格方法所包含的三个流程分别进行说明。
65.一、服务注册流程
66.图1为本技术实施例提供的istio微服务系统的一种结构示意图。如图1所示，istio微服务系统100包括api服务器(server)组件，以及一个或多个kubernetes吊舱(pod)(图1以两个kubernetes pod为例)。其中，应用实例1和envoy组件1部署在kubernetes pod 1中，应用实例2和envoy组件2部署在kubernetes pod 2中。应用实例1为应用程序1的一个应用实例。应用实例2为应用程序2的一个应用实例。
67.api server组件，为kubernetes对外提供管理表现层状态转移(representational state transfer，rest)接口的server组件。该api server组件可以用于kubernetes服务(kubernetes service)对象的创建和查询，还可以用于kubernetes端点(kubernetes endpoint)对象的查询。例如，api server组件可以响应于应用的服务注册请求，为该应用创建kubernetes service对象。又例如，api server组件可以根据提供目标服务的应用程序的访问域名(即，kubernetes域名)，查询提供该目标服务的应用程序的一个或多个应用实例的ip地址。
68.应用实例1，可以是dubbo应用，或者是spring cloud应用，用于发起服务注册流程。该应用实例1可以是服务消费端，也可以是服务提供端。当应用实例1为服务消费端时，该应用实例1还可以用于发起服务发现流程和服务调用流程；当应用实例1为服务提供端时，该应用实例1可以为其它应用提供服务。同理，应用实例2也可以是dubbo应用，或者是spring cloud应用。应用实例2也可以是服务消费端，或者是服务提供端。本技术实施例对应用实例1、应用实例2的具体实现方式不作限定。
69.应用实例的代理(agent)组件，如java agent组件，与应用实例运行在同一进程中。该agent组件可以用于非侵入式的修改应用实例的服务注册、服务发现等逻辑。
70.envoy组件，为istio数据面代理组件。envoy组件用于负责kubernetes service的
服务发现、负载均衡、以及微服务治理等流程。
71.kubernetes pod，为kubernetes的基本运行单元。kubernetes pod可以为envoy组件和dubbo应用提供相同的运行环境，或者为envoy组件和spring cloud应用提供相同的运行环境。一个kubernetes pod中可以运行一个容器，或者运行多个需要一起工作的容器。
72.需要说明的是，图1所示的istio微服务系统100仅为一种示例，并不对istio微服务系统进行限定。例如，该istio微服务系统100还可以包括istio控制面代理组件，即领航员(pilot)组件，和/或包括用于监听的应用部署监听组件。
73.图2为本技术实施例提供的一种对接istio服务网格方法的流程示意图。如图2所示，该方法为dubbo应用或spring cloud应用对接istio的服务注册流程。该方法可以应用于图1所示的istio微服务系统100。为了便于理解本技术实施例，在图2所示的方法流程中以第一应用实例为istio微服务系统100中的应用实例1为例进行描述。
74.s201：应用实例1发送第一服务注册请求。
75.应用实例1启动时，可以按照自身的服务注册逻辑发起服务注册流程。例如，应用实例1可以按照自身的服务注册逻辑生成第一服务注册请求，并企图向应用实例1对应的注册中心发送该第一服务注册请求。其中，应用实例1可以是dubbo应用，也可以是spring cloud应用。
76.下面分别以dubbo应用、spring cloud应用为例，简单介绍应用实例1自身的服务注册逻辑。
77.1、以应用实例1为dubbo应用为例，单个dubbo应用可以包括一个或多个远程过程调用(remote procedure call，rpc)服务。dubbo应用可以以rpc服务为粒度进行服务注册。在此情况下，该第一服务注册请求用于为dubbo应用的每个rpc服务创建注册信息。相应的，dubbo应用对应的注册中心接收到第一服务注册请求后，在注册中心存储rpc服务的注册信息，供后续服务发现时使用。该第一服务注册请求包括dubbo应用的每个rpc服务的服务名。其中，rpc服务的服务名可以是预先定义的，用于区别于该dubbo应用的其它rpc服务。以应用实例1为dubbo应用为例，表1示出了dubbo应用的应用名以及该dubbo应用的每个rpc服务的服务名。如表1所示，dubbo应用的应用名为appbservice，该dubbo应用包括三个rpc服务，服务名分别为com.company.dubbo.demo.serviceb1、com.company.dubbo.demo.serviceb2、com.company.dubbo.demo.serviceb3。可以理解的是，表1中的各项数据仅为一种示例，并不对dubbo应用的应用名，以及rpc服务的服务名进行限定。
78.表1
[0079][0080]
或者，dubbo应用还可以以应用程序为粒度进行服务注册。在此情况下，该第一服务注册请求用于为dubbo应用创建注册信息。相应的，dubbo应用对应的注册中心接收到第一服务注册请求后，在注册中心存储dubbo应用的注册信息，供后续服务发现时使用。该第一服务注册请求包括dubbo应用的应用名。其中，dubbo应用的应用名可以是预先定义的，用
于区别于其它dubbo应用。dubbo应用的应用名可以如表1所示，在此不再赘述。
[0081]
2、以应用实例1为spring cloud应用为例，spring cloud应用是以应用程序为粒度进行服务注册的。在此情况下，该第一服务注册请求用于为spring cloud应用创建注册信息。相应的，spring cloud应用对应的注册中心(如eureka)接收到第一服务注册请求后，在注册中心存储spring cloud应用的注册信息，供后续服务发现时使用。该第一服务注册请求包括spring cloud应用的应用名。其中，spring cloud应用的应用名可以是预先定义的，用于区别于其它spring cloud应用，如appmbservice、appnservice等。
[0082]
s202：应用实例1的agent组件拦截第一服务注册请求。
[0083]
应用实例1按照自身的服务注册逻辑生成第一服务注册请求后，与应用实例1运行在同一进程的agent组件检测到第一服务注册请求，并拦截该第一服务注册请求，以使得应用实例1无法发出该第一服务注册请求。也就是说，在应用实例1发出该第一服务注册请求之前，与应用实例1运行在同一进程的agent组件拦截该第一服务注册请求，这样，该第一服务注册请求就不会发送到应用实例1对应的注册中心，换而言之，应用实例1不会按照自身的服务注册逻辑进行注册，从而可以屏蔽应用实例1自身的服务注册逻辑。
[0084]
s203：应用实例1的agent组件根据应用实例1的标识信息生成第二服务注册请求。
[0085]
应用实例1的agent组件拦截第一服务注册请求后，以应用实例1的应用名向api server组件发起服务注册。具体的，应用实例1的agent组件拦截第一服务注册请求后，可以获取应用实例1的应用名，并根据应用实例1的应用名生成第二服务注册请求。例如，应用实例1的agent组件可以通过读取应用实例1的属性信息、配置信息、或环境变量名等获取应用实例1的应用名。该第二服务注册请求包括应用实例1的应用名。
[0086]
s204：应用实例1的agent组件向api server组件发送第二服务注册请求。相应的，api server组件接收第二服务注册请求。
[0087]
应用实例1的agent组件可以通过应用实例1部署时配置的环境变量获取api server组件的访问地址，并根据api server组件的访问地址向api server组件发送该第二服务注册请求。
[0088]
以应用实例1为dubbo应用为例，表2示出了dubbo应用部署时配置的环境变量的一种示意。如表2所示，环境变量名为kube_api_server，用于表示api server组件的访问地址，如http://192.168.0.2:8080；环境变量名为kube_namespace，用于表示名称空间(namespace)，如mynamespace；环境变量名为kube_app_name，用于表示该dubbo应用的应用名，如myapp。dubbo应用的agent组件通过表2可以获取api server组件的ip地址、namespace、以及自身的应用名。应理解的是，spring cloud应用的agent组件获取api server组件的访问地址、namespace、以及自身的应用名的实现过程与dubbo应用的类似，具体可以参考dubbo应用的相关描述，在此不再赘述。
[0089]
表2
[0090]
环境变量名含义参数值kube_api_serverapi server组件的访问地址http://192.168.0.2:8080kube_namespacenamespacemynamespacekube_app_namedubbo应用的应用名myapp
[0091]
s205：api server组件根据应用实例1的应用名创建kubernetes service对象。
[0092]
api server组件可以采用“应用名 service”的格式为应用实例1创建kubernetes service对象，如应用实例1的应用名为myapp，则应用实例1对应的kubernetes service对象的名称可以为myappservice。例如，api server组件可以调用post http://192.168.0.2:8080/api/v1/namespaces/{namespace}/services接口为应用实例1创建kubernetes service对象，并将该应用实例1对应的kubernetes service对象关联到应用程序1。其中，{namespace}的值为kube_namespace对应的参数值。
[0093]
以应用实例1为dubbo应用为例，应用实例1对应的kubernetes service对象的类型为service，接口版本为v1；kubernetes service对象的名称为myappservice，应用实例1的应用名为myapp；应用实例1对应的kubernetes service对象的访问协议为传输控制协议(transmission control protocol，tcp)，访问端口为9376，目标端口为9376。具体的，api server组件为应用实例1创建的kubernetes service对象可以如下所示。
[0094][0095]
应理解的是，api server组件为spring cloud应用创建kubernetes service对象的实现过程与dubbo应用类似，具体可以参考dubbo应用的相关描述，在此不再赘述。
[0096]
在一种可能的实施方式中，api server组件接收到第二服务注册请求后，可以记录应用实例1的ip地址。例如，api server组件可以根据应用程序1对应的kubernetes域名记录该应用实例1的ip地址。如表3所示，appbservice对应的kubernetes域名为kubernetes域名1，appbservice包括三个应用实例，即应用实例1、应用实例2、以及应用实例3，ip地址分别为ip地址1、ip地址2、以及ip地址3；appcservice对应的kubernetes域名为kubernetes域名2，appcservice包括一个应用实例，即应用实例4，ip地址为ip地址4。可以理解的是，表3中的各项数据仅为一种示例，本技术实施例并不限定于此。
[0097]
表3
[0098][0099]
可选的，在步骤s205之后，api server组件可以向应用实例1的agent组件发送服务注册响应，以指示应用实例1是否成功注册。例如，api server组件为应用实例1创建kubernetes service对象成功，则该服务注册响应用于指示应用实例1的服务注册成功。又例如，api server组件为应用实例1创建kubernetes service对象失败，则该服务注册响应用于指示应用实例1的服务注册失败。api server组件向应用实例1的agnet组件发送服务注册响应的具体流程可以如步骤s206所示。
[0100]
s206：api server组件向应用实例1的agent组件发送第二服务注册响应。相应的，应用实例1的agent组件接收第二服务注册响应。
[0101]
在完成为应用实例1创建kubernetes service对象之后，api server组件可以向应用实例1的agent组件发送第二服务注册响应，该第二服务注册响应用于指示应用实例1的服务注册成功或失败。
[0102]
s207：应用实例1的agent组件向应用实例1发送第一服务注册响应。相应的，应用实例1接收第一服务注册响应。
[0103]
应用实例1的agent组件接收到第二服务注册响应后，可以向应用实例1发送第一服务注册响应，该第一服务注册响应用于指示应用实例1的服务注册成功或失败。例如，应用实例1的agent组件接收到第二服务注册响应后，对第二服务注册响应进行解析等处理，生成第一服务注册响应，然后将该第一服务注册响应发送给应用实例1。当第二服务注册响应用于指示应用实例1的服务注册成功时，第一服务注册响应也用于指示应用实例1的服务注册成功；当第二服务注册响应用于指示应用实例1的服务注册失败时，第一服务注册响应也用于指示应用实例1的服务注册失败。
[0104]
通过上述实施例，应用实例1按照原有服务注册逻辑生成第一服务注册请求后，应用实例1的agent组件拦截该第一服务注册请求，使得应用实例1无法将该第一服务注册请求发送给应用实例1对应的注册中心。在拦截第一服务注册请求后，应用实例1的agent组件以应用实例1的应用名向api server组件发起服务注册流程，以使得api server组件替代应用实例1对应的注册中心完成该应用实例1的服务注册，从而可以屏蔽应用实例1在其对应的注册中心进行服务注册的流程。也就是说，开发人员通过修改应用实例1的agent组件就可以避免应用实例1自身的服务注册逻辑与istio的服务注册逻辑之间的冲突。并且，应用实例1的agent组件的升级或修改无需更改应用实例1的sdk，也无需更改istio的服务注册逻辑，实现了应用实例1非侵入式的对接istio，可以减少工作量。
[0105]
前面介绍了dubbo应用或spring cloud应用的服务注册流程，接下来介绍dubbo应用或spring cloud应用的服务发现流程。
[0106]
二、服务发现流程
[0107]
图3为本技术实施例提供的istio微服务系统的一种结构示意图。如图3示，istio
微服务系统300包括api server组件，pilot组件，以及一个或多个kubernetes pod(图3以kubernetes pod 1和kubernetes pod 2为例)。其中，应用实例1和envoy组件1部署在kubernetes pod 1中，应用实例2和envoy组件2部署在kubernetes pod 2中。另外，api server组件、envoy组件、agent组件、以及kubernetes pod的描述可参考前述的相关内容，在此不再赘述。
[0108]
应用实例1可以是服务消费端，也可以是服务提供端。当应用实例1为服务消费端时，应用实例2可以是为应用实例1提供服务的服务提供端；当应用实例2为服务消费端时，应用实例1则可以是为应用实例2提供服务的服务提供端。应用实例1可以是dubbo应用，或者是spring cloud应用。进一步，若应用实例1为dubbo应用，则应用实例2也为dubbo应用；若应用实例1为spring cloud应用，则应用实例2也为spring cloud应用。
[0109]
为了便于理解本技术实施例，在下文中以应用实例1为服务消费端，应用实例2是为应用实例1提供服务的服务提供端为例进行描述。
[0110]
pilot组件，为istio控制面代理组件。pilot组件可以用于接收来自envoy组件的服务发现请求，与api server组件交互获取服务发现结果，并将服务发现结果发送给envoy组件。该pilot组件还可以用于向envoy组件配置和下发服务治理策略，如限流策略等，以使envoy组件根据该服务治理策略实现微服务治理。
[0111]
需要说明的是，图3所示的istio微服务系统300仅为一种示例，并不对istio微服务系统进行限定。例如，该微服务系统300还可以包括用于监听的应用部署监听组件等。
[0112]
图4为本技术实施例提供的一种对接istio服务网格方法的流程示意图。如图4所示，该方法为dubbo应用或spring cloud应用对接istio的服务发现流程。该方法可以应用于图3所示的istio微服务系统300。以第一应用实例为istio微服务系统300中的应用实例1，第二应用实例为istio微服务系统300中的应用实例2为例，该方法可以包括如下步骤。
[0113]
s401：应用实例1发送第一服务发现请求。
[0114]
应用实例1可以按照自身的服务发现逻辑发起服务发现流程。例如，应用实例1可以按照自身的服务发现逻辑生成第一服务发现请求，并企图向应用实例1对应的注册中心发送该第一服务发现请求。该第一服务发现请求用于获取ip地址集，该ip地址集包括应用程序2的一个或多个应用实例的ip地址。其中，应用程序2用于提供目标服务。该一个或多个应用实例包括应用实例2。
[0115]
在一种可能的实施方式中，该第一服务发现请求可以包括应用程序2的标识信息。其中，应用程序2的标识信息包括应用程序2的应用名(又称为应用实例2的应用名)，或者包括目标服务的服务名，或者包括应用程序2的应用名以及目标服务的服务名。例如，应用程序2为dubbo应用时，应用程序2的标识信息可以包括应用程序2的应用名，如应用程序2的应用实例按照自身的服务注册逻辑以应用名为粒度进行服务注册，在步骤s401中应用实例1以应用程序2的应用名为粒度进行服务发现；或者，包括目标服务的服务名，该目标服务为rpc服务，如应用程序2的应用实例按照自身的服务注册逻辑以服务名为粒度进行服务注册，在步骤s401中应用实例1以rpc服务的服务名为粒度进行服务发现；或者，包括应用程序2的应用名以及目标服务的服务名。又例如，应用程序2为spring cloud应用时，应用程序2的标识信息可以包括应用程序2的应用名。
[0116]
其中，应用实例1可以通过本地存储的配置信息等向提供目标服务的一个应用程
序(即应用程序2)发起服务发现流程，并获取应用程序2的标识信息。例如，在网络初始部署时，应用实例1可以获取为其提供服务的一个或多个应用程序的标识信息。可以理解的是，为应用实例1提供服务的应用程序可以是一个或多个，应用实例1也可以为其它一个或多个应用程序提供服务。
[0117]
s402：应用实例1的agent组件拦截第一服务发现请求。
[0118]
应用实例1按照自身的服务发现逻辑生成第一服务发现请求后，与应用实例1运行在同一进程的agent组件检测到第一服务发现请求，并拦截该第一服务发现请求，以使得应用实例1无法发出该第一服务发现请求。也就是说，在应用实例1发送该第一服务发现请求之前，与应用实例1运行在同一进程的agent组件拦截该第一服务发现请求，这样，该第一服务发现请求就不会发送到应用实例1对应的注册中心，换而言之，应用实例1不会按照自身的服务发现逻辑进行服务发现，从而可以屏蔽应用实例1自身的服务发现逻辑。
[0119]
s403：应用实例1的agent组件生成第一服务发现响应。
[0120]
应用实例1的agent组件拦截第一服务发现请求后，可以生成第一服务发现响应。具体的，应用实例1的agent组件可以根据应用程序2的标识信息生成第一服务发现响应，该第一服务发现响应中的ip地址集填写为应用程序2对应的一个kubernetes域名。该一个kubernetes域名与应用程序2的一个或多个应用实例所对应的kubernetes service对象关联。其中，ip地址集包括提供目标服务的一个或多个应用实例的ip地址集。
[0121]
作为一个示例，当应用实例1以应用名发起服务发现流程，即第一服务发现请求包括提供应用程序2的应用名时，应用实例1的agent组件可以应用程序2的应用名和应用实例1的环境变量(如namespace环境变量)构建kubernetes域名，并根据构建的kubernetes域名生成第一服务发现响应。其中，应用实例1的环境变量可以为表2中的kube_namespace。
[0122]
示例性的，应用实例1的agent组件可以按照“提供目标服务的应用程序的应用名.namespace环境变量.svc.cluster.local”的格式构建kubernetes域名。例如，提供目标服务的应用程序的应用名为appbservice，kube_namespace为mynamespace，应用实例1的agent组件根据提供目标服务的应用程序的应用名和应用实例1的环境变量构建kubernetes域名可以为appbservice.mynamespace.svc.cluster.local。
[0123]
作为另一个示例，当应用实例1以目标服务的服务名发起服务发现流程，即第一服务发现请求包括目标服务的服务名时，应用实例1的agent组件可以根据配置文件获取提供该目标服务的应用程序的应用名，并根据提供该目标服务的应用程序的应用名和应用实例1的环境变量构建kubernetes域名，从而生成第一服务发现响应。其中，配置文件包括服务名与应用名之间的对应关系。
[0124]
以应用实例1为dubbo应用为例，表4示出了应用实例1的配置文件的一种示意。如表4所示，rpc服务为com.company.dubbo.demo.serviceb，提供该rpc服务的应用程序为appbservice；rpc服务为com.company.dubbo.demo.servicec1，提供该rpc服务的应用程序为appcservice；rpc服务为com.company.dubbo.demo.servicec2，提供该rpc服务的应用程序为appcservice。应理解的是，一个应用程序可以提供一个或多个rpc服务，同一个rpc服务也可以由一个或多个应用程序提供。其中，表4作为一种示例，并不对配置文件的数据进行限定。
[0125]
表4
[0126][0127][0128]
应用实例1的agent组件生成的第一服务发现响应中包括的是kubernetes域名，不是ip地址集，这样应用实例1接收到第一服务发现响应后，无需对该kubernetes域名执行路由、负载均衡等，可以根据该kubernetes域名发起服务调用请求，从而能够省去应用实例1自身的路由、负载均衡等流程，可以减少应用实例1的计算量，减少性能消耗。
[0129]
s404：应用实例1的agent组件向应用实例1发送第一服务发现响应。相应的，应用实例1接收第一服务发现响应。
[0130]
应用实例1的agent组件构建好应用程序2对应的一个kubernetes域名后，可以向应用实例1发送第一服务发现响应，该第一服务发现响应包括该kubernetes域名。
[0131]
s405：应用实例1发送第一服务调用请求。
[0132]
应用实例1按照自身的服务调用逻辑，发起服务调用流程。具体的，应用实例1在接收到第一服务发现响应后，生成第一服务调用请求，企图向目标应用实例发送第一服务调用请求。其中，第一服务调用请求包括kubernetes域名。
[0133]
s406：envoy组件1拦截第一服务调用请求。
[0134]
应用实例1按照自身的服务调用逻辑发送第一服务调用请求，与应用实例1部署在同一个kubernetes pod的envoy组件1检测到第一服务调用请求，拦截该第一服务调用请求，以避免因应用实例1未获取目标应用实例的ip地址就发送第一服务调用请求而导致的逻辑错误。进一步，envoy组件1拦截第一服务调用请求后，根据第一服务调用请求包括的kubernetes域名发起服务发现流程，以获取该kubernetes域名对应的ip地址集，即提供目标服务的应用程序2的一个或多个应用实例的ip地址，以及提供目标服务的目标应用实例，如应用实例2。其中，envoy组件1发起的服务发现流程可以如步骤s407至步骤s410所示。
[0135]
s407：envoy组件1向pilot组件发送第二服务发现请求。相应的，pilot组件接收第二服务发现。
[0136]
envoy组件1根据第一服务调用请求所包括的kubernetes域名，生成第二服务发现请求，并向pilot组件发送该第二服务发现请求。其中，第二服务发现请求中包括kubernetes域名。该第二服务发现请求又可以称为服务查询请求等，本技术实施例并不限定于此。
[0137]
s408：pilot组件向api server组件发送第二服务发现请求。相应的，api server组件接收第二服务发现请求。
[0138]
pilot组件接收到第二服务发现请求后，将该第二服务发现请求转发给api server组件。
[0139]
s409：api server组件向pilot组件发送第二服务发现响应。相应的，pilot组件接收第二服务发现响应。
[0140]
api server组件接收到第二服务发现请求后，根据第二服务发现请求包括的kubernetes域名查询该kubernetes域名对应的ip地址集。例如，api server组件可以根据kubernetes域名确定该kubernetes域名对应的应用程序2的应用名，并根据应用程序2的应
用名确定该应用程序2的一个或多个应用实例的ip地址集，如表3所示。api server组件获取到ip地址集后，根据该ip地址集生成第二服务发现响应，并向pilot组件发送第二服务发现响应。其中，该第二服务发现响应包括ip地址集。该ip地址集包括应用实例2的ip地址。
[0141]
s410：pilot组件向envoy组件1发送第二服务发现响应。相应的，envoy组件1接收第二服务发现响应。
[0142]
pilot组件接收到第二服务发现响应后，将该第二服务发现响应转发给envoy组件1，从而envoy组件1获取到提供目标服务的应用程序2的一个或多个应用实例的ip地址集。
[0143]
通过上述实施例，应用实例1的agent组件拦截应用实例1原有服务发现逻辑所发送的第一服务发现请求，根据提供目标服务的应用程序的标识信息构建一个kubernetes域名，并将该一个kubernetes域名发送给应用实例1，这样可以屏蔽应用实例1自身的服务发现逻辑，可以避免应用实例1自身的服务发现逻辑与istio的服务发现逻辑之间的冲突。另外应用实例1接收到的服务发现响应中包括的是kubernetes域名，而不是ip地址集，应用实例1无需对kubernetes域名执行路由、负载均衡等，可以根据该kubernetes域名发起服务调用请求，从而能够省去应用实例1自身的路由、负载均衡等流程，可以减少应用实例1的计算量，减少性能消耗。
[0144]
并且，应用实例1的agent组件的升级或修改无需更改应用实例1的sdk，也无需更改istio的服务发现逻辑，实现了应用实例1非侵入式的对接istio，可以减少工作量。
[0145]
进一步，envoy组件拦截应用实例1原有服务调用逻辑所发送的第一服务调用请求，根据该第一服务调用请求所包括的kubernetes域名发起服务发现流程，以获取提供目标服务的一个或多个应用实例的ip地址，从而可以实现应用实例1对接istio时的服务发现。
[0146]
前面介绍了服务注册流程和服务发现流程，在步骤s410中，与应用实例1部署在同一个kubernetes pod的envoy组件1获取到ip地址集，即提供目标服务的应用程序2的一个或多个应用实例的ip地址集，接下来envoy组件1可以根据该ip地址集发起服务调用流程。下面结合图5介绍dubbo应用(或spring cloud应用)对接istio时的服务调用流程。
[0147]
三、服务调用流程
[0148]
图5为本技术实施例提供的一种对接istio服务网格方法的流程示意图。如图5所示，该方法为dubbo应用或spring cloud应用对接istio的服务调用流程。该方法可以应用于图3所示的istio微服务系统300。在图4中envoy组件1接收到第二服务发现响应，该第二服务发现响应包括ip地址集，接下来envoy组件1执行服务调用逻辑，具体如下所示。
[0149]
s411：envoy组件1根据应用实例1的治理规则，确定发起服务调用。
[0150]
envoy组件1可以根据该应用实例1的治理规则确定是否发起服务调用。例如，envoy组件1根据应用实例1的治理规则，执行消费端治理策略，如熔断机制、调用链分析等，判断是否发起服务调用。如果envoy组件1确定发起服务调用，执行步骤s412、s413的内容；否则，envoy组件1向应用实例1发送服务调用结果，该服务调用结果指示服务调用失败。在本技术实施例中以envoy组件1确定发起服务调用为例进行描述。其中，envoy组件1可以通过与pilot组件交互来获取应用实例1的治理规则，如在kubernetes pod 1部署时，envoy组件1获取应用实例1的治理规则。
[0151]
s412：envoy组件1根据负载均衡算法从ip地址集中选择一个ip地址。
[0152]
例如，envoy组件1可以通过轮询，或随机等负载均衡算法从ip地址集中选择其中的一个ip地址。在本技术实施例中，以envoy组件1选择的一个ip地址为应用实例2的ip地址，即目标应用实例为应用实例2为例进行描述。
[0153]
s413：envoy组件1向envoy组件2发送第二服务调用请求。相应的，envoy组件2接收第二服务调用请求。
[0154]
envoy组件1根据应用实例2的ip地址向与应用实例2部署在同一个kubernetes pod的envoy组件2发送第二服务调用请求。
[0155]
s414：envoy组件2根据应用实例2的治理规则，确定转发第二服务调用请求。
[0156]
envoy组件2可以根据应用实例2的治理规则，确定是否将第二服务调用请求转发给应用实例2。例如，envoy组件2可以根据应用实例2的限流、鉴权等信息确定是否将第二服务调用转发给应用实例2。例如，应用实例2的当前流量没有超过限制，且该第二服务调用请求通过鉴权认证确定为合法请求，则envoy组件2确定转发该第二服务调用请求，即执行步骤s415的内容；否则，envoy组件2确定不转发该第二服务调用请求，并向应用实例1发送服务调用结果，该服务调用结果用于指示服务调用失败。在本技术实施例中以envoy组件2确定转发第二服务调用请求为例进行描述。其中，envoy组件2可以通过与pilot组件交互来获取应用实例2的治理规则，如在kubernetes pod 2部署时，envoy组件2获取应用实例2的治理规则。
[0157]
s415：envoy组件2向应用实例2发送第二服务调用请求。相应的，应用实例2接收第二服务调用请求。
[0158]
s416：应用实例2向envoy组件2发送目标服务执行结果。相应的，envoy组件2接收该目标服务执行结果。
[0159]
应用实例2接收到第二服务调用请求后，解析该第二服务调用请求，为应用实例1提供目标服务，得到目标服务执行结果，并将该目标服务执行结果发送给envoy组件2。
[0160]
s417：envoy组件2向envoy组件1发送目标服务执行结果。相应的，envoy组件1接收该目标服务执行结果。
[0161]
s418：envoy组件1向应用实例1发送目标服务执行结果。相应的，应用实例1接收该目标服务执行结果。
[0162]
上述本技术提供的实施例中，分别从各组件之间交互的角度对本技术实施例提供的方法进行了介绍。本技术实施例提供的对接istio服务网格方法可以应用于agent组件，该agent组件可以运行在电子设备中。该电子设备可以是计算机集群、服务器(如云端服务器、或服务器集群等)、车机、车载扬声器、车载麦克风、手机、平板电脑、桌面型、膝上型、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，umpc)、手持计算机、上网本、个人数字助理(personal digital assistant，pda)、可穿戴电子设备、或虚拟现实设备等电子设备。或者，本技术实施例所涉及的电子设备也可以是设置在如上的任一种电子设备中的功能模块，例如芯片或芯片系统。
[0163]
为了实现上述本技术实施例提供的方法中的各功能，agent组件可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。
[0164]
图6示出了一种通信装置600的结构示意图，该通信装置可以部署在电子设备中，能够实现本技术实施例提供的方法中应用实例1的agent组件所实现的功能。通信装置600可以是硬件结构、软件模块、或硬件结构加软件模块。通信装置600可以由芯片系统实现。本技术实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
[0165]
通信装置600可以包括处理模块601和通信模块602。
[0166]
示例性的，处理模块601，用于拦截微服务系统中的第一应用实例发出的服务发现请求，所述服务发现请求用于获取所述微服务系统中的一个或多个第二应用实例对应的ip地址集，其中，第二应用实例用于提供目标服务。
[0167]
通信模块602，用于向所述第一应用实例发送服务发现响应，其中，所述服务发现响应包括所述ip地址集对应的域名。所述ip地址集对应的域名可以为kubernetes域名。
[0168]
其中，agent组件与第一应用实例运行在同一进程中，且agent组件未集成在所述第一应用实例中。
[0169]
可选的，第一应用实例为基于dubbo架构开发的应用，或者为基于spring cloud架构开发的应用。
[0170]
在一种可能的实施方式中，所述第一服务发现请求包括所述第二应用实例的标识信息；所述处理模块601，进一步用于根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名；以及，根据所述域名生成所述服务发现响应。
[0171]
其中，所述标识信息包括第二应用实例的应用名，或者包括目标服务的服务名，或者包括第二应用实例的应用名和目标服务的服务名。
[0172]
在一种可能的实施方式中，标识信息包括第二应用实例的应用名，则处理模块601具体用于：根据所述第二应用实例的应用名和所述第一应用实例的环境变量，构建所述域名。
[0173]
在一种可能的实施方式中，标识信息包括目标服务的服务名，则处理模块601具体用于：根据所述第二应用实例的标识信息和所述第一应用实例的环境变量，构建所述域名可以为：agent组件根据配置文件和目标服务的服务名，获取第二应用实例的应用名，并根据第二应用实例的应用名和第一应用实例的环境变量构建所述域名；其中，该配置文件包括目标服务的服务名与提供所述目标服务的应用实例的应用名的对应关系。
[0174]
在一种可能的实施方式中，所述微服务系统还包括接口服务器组件；所述处理模块601，进一步用于拦截所述第一应用实例发出的第一服务注册请求；以及，根据所述第一服务注册请求，生成第二服务注册请求，所述第二服务注册请求包括所述第一应用实例的应用名；所述通信模块602，进一步用于向所述接口服务器组件发送所述第二服务注册请求。
[0175]
在一种可能的实施方式中，通信模块602进一步用于：接收来自所述接口服务器组件发送的第二服务注册响应，该第二服务注册响应可用于指示第一应用实例注册成功或失败。处理模块601进一步用于：根据第二服务注册响应生成第一服务注册响应；通信模块602进一步用于将第一服务注册响应发送给第一应用实例，该第一服务注册响应用于指示第一应用实例注册成功或失败。其中，若第二服务注册响应用于指示第一应用实例注册成功，则第一服务注册响应也用于指示第一应用实例注册成功。若第二服务注册响应用于指示第一应用实例注册失败，则第一服务注册响应也用于指示第一应用实例注册失败。
drive，hdd)或固态硬盘(solid-state drive，ssd)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，ram)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本技术实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
[0187]
本技术实施例提供的方法中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，简称dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，简称dvd))、或者半导体介质(例如，ssd)等。
[0188]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。