一种多集群场景下服务的域名解析方法及系统与流程

1.本技术涉及云原生技术领域，特别涉及一种多集群场景下服务的域名解析方法、系统、计算机可读存储介质、电子设备。


背景技术：

2.随着云原生技术的普及，越来越多的企业开始采用同城多活或者异地多活的部署方式来搭建应用，即建立多个数据中心，每个数据中心设置多个服务器节点，使用以kubernetes系统为代表的容器编排系统将数据中心中的全部服务器节点作为一个集群进行管理，并将服务所对应的多个服务实例部署在多个集群中，同时对访问请求进行响应，降低了单一数据中心带来的风险，保障了业务的高可用性。
3.然而，相关技术中，在多集群环境下多个服务之间相互访问时，会出现跨集群访问服务实例的情况，造成网络延迟和资源开销过高。
4.因此，需要提供一种针对上述现有技术不足的改进技术方案。


技术实现要素：

5.本技术的目的在于提供一种多集群场景下服务的域名解析方法、系统、计算机可读存储介质、电子设备，以解决或缓解上述现有技术中存在的问题。
6.为了实现上述目的，本技术提供如下技术方案：
7.本技术提供了一种多集群场景下服务的域名解析方法，包括：
8.在多集群中第一服务和第二服务分别对应有至少一个服务实例，在第一集群中部署有所述第一服务对应的第一服务实例，所述方法由第一集群的域名解析组件执行；所述方法包括：
9.响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址；所述第二服务实例为部署在所述第一集群中的所述第二服务对应的服务实例；
10.使用所述第二服务实例的ip地址代替所述第二服务的虚拟ip地址，作为所述域名解析请求的响应，反馈给所述第一服务实例。
11.上述方案中，所述第二服务对应的至少一个服务实例的ip地址清单通过以下方式建立：
12.通过访问所有集群的api-server组件，获取并在所述ip地址清单中记录所述第二服务对应的所有服务实例所在的集群和ip地址；
13.相应地，所述根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址，包括：
14.从所述ip地址清单中查询是否存在所述第二服务实例；
15.响应于存在所述第二服务实例，从所述ip地址清单中查询所述第二服务实例的ip地址。
16.上述方案中，还包括：持续监听并在所述ip地址清单中记录所述第二服务对应的所有服务实例的运行状态；
17.相应地，在所述从所述ip地址清单中查询所述第二服务实例的ip地址之前，还包括：
18.从所述ip地址清单中查询所述第二服务实例的运行状态。
19.上述方案中，还包括：
20.响应于所述第二服务实例处于可用状态，从所述ip地址清单中查询所述第二服务实例的ip地址；
21.响应于所述第二服务实例处于不可用状态，从所述ip地址清单中查询第三服务实例的ip地址；所述第三服务实例为部署在第二集群中的所述第二服务对应的服务实例；使用所述第三服务实例的ip地址代替所述第二服务的虚拟ip地址，作为所述域名解析请求的响应，反馈给所述第一服务实例。
22.上述方案中，所述持续监听所述第二服务对应的所有服务实例的运行状态，包括：
23.通过所述api-server组件监听所述第二服务对应的所有服务实例所在容器组的运行状态；或者，
24.通过访问监控组件获取所述第二服务对应的所有服务实例的运行状态；或者，
25.根据服务实例发送的心跳数据包获取所述第二服务对应的所有服务实例的运行状态。
26.上述方案中，所述第一服务和第二服务分别对应的至少一个服务实例部署在位于不同区域的多个集群中。
27.上述方案中，所述第一集群的域名解析组件中设置有多集群域名解析插件，所述多集群域名解析插件用于建立和维护所述ip地址清单，以及对所述域名解析请求进行响应。
28.本技术实施例还提供一种多集群场景下服务的域名解析系统，包括：
29.在多集群中第一服务和第二服务分别对应有至少一个服务实例，在第一集群中部署有所述第一服务对应的第一服务实例；所述系统包括：
30.响应单元，配置为响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址；所述第二服务实例为部署在所述第一集群中的所述第二服务对应的服务实例；
31.反馈单元，配置为使用所述第二服务实例的ip地址代替所述第二服务的虚拟ip地址，作为所述域名解析请求的响应，反馈给所述第一服务实例。
32.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的多集群场景下服务的域名解析方法。
33.本技术实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的多集群场景下服务的域名解析方法。
34.有益效果：
35.本技术提供的技术方案中，当第一集群的域名解析组件接收到第一服务实例指向第二服务的域名解析请求时，通过预先建立第二服务对应的至少一个服务实例的ip地址清
单，确定第二服务实例的ip地址，其中，第二服务实例为部署在第一集群中的第二服务对应的服务实例，并使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。如此，在第一服务实例尝试访问第二服务时，将第二服务实例的ip地址代替第二服务的虚拟ip地址作为指向第二服务的域名解析请求的响应，返回给第一服务实例，实现优先返回部署在同一集群中的第二服务实例的ip地址的目的，保证多个服务之间相互访问时，发起服务访问的第一服务实例能够就近直接访问同一集群中的第二服务实例，避免了跨集群访问服务实例产生额外的网络延迟和资源开销。
附图说明
36.构成本技术的一部分的说明书附图用来提供对本技术的进一步理解，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。其中：
37.图1为相关技术中多集群场景下第一服务实例访问第二服务实例的逻辑示意图；
38.图2为本技术的一些实施例提供的多集群场景下服务的域名解析方法的实现逻辑示意图；
39.图3为本技术的一些实施例提供的多集群场景下服务的域名解析方法的流程示意图；
40.图4为本技术的一些实施例提供的多集群场景下第一服务实例访问第二服务实例的逻辑示意图；
41.图5为本技术的一些实施例提供的多集群场景下第一集群中的第二服务实例处于不可用状态时第一服务实例访问第二服务实例的逻辑示意图；
42.图6为本技术的一些实施例提供的多集群场景下服务的域名解析系统的结构示意图；
43.图7为根据本技术的一些实施例提供的电子设备的结构示意图；
44.图8为根据本技术的一些实施例提供的电子设备的硬件结构图。
具体实施方式
45.下面将参考附图并结合实施例来详细说明本技术。各个示例通过本技术的解释的方式提供而非限制本技术。实际上，本领域的技术人员将清楚，在不脱离本技术的范围或精神的情况下，可在本技术中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本技术包含归入所附权利要求及其等同物的范围内的此类修改和变型。
46.在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
47.除另有定义，本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本公开实施例的目的，不是旨在限制本公开。
48.为了便于理解本技术的技术方案，下面对相关技术中多集群部署环境下服务之间
相互访问的处理流程进行说明。
49.随着云原生技术的普及，越来越多的企业开始采用同城多活或者异地多活的部署方式来搭建应用，即建立多个数据中心，每个数据中心设置多个服务器节点，使用以kubernetes系统为代表的容器编排系统将数据中心中的全部服务器节点作为一个集群进行管理。
50.每个集群中运行有多个容器组，容器组是集群中创建和管理的、最小的可部署的计算单元，是一组(一个或多个)容器，容器之间共享资源和依赖、彼此通信。
51.将应用部署在集群中，实际上就是把应用部署在集群中的容器中。为了实现应用的高可用，通常会在集群中部署该应用的多个应用实例，同时对访问请求进行响应。
52.在容器组创建时，集群将为其分配一个唯一的ip地址，用于与其他容器组进行通信。应当理解，每个容器组被分配有唯一ip地址，运行其中的应用实例也能够通过该唯一ip地址被访问，也就是说，应用实例的ip地址即为该应用实例所在容器组的ip地址。
53.考虑到以kubernetes系统为代表的容器编排系统能够对容器组进行自动部署和管理，当容器组运行异常时即采用重调度机制，将运行其中的应用实例调度至创建新的容器组中，导致应用实例的ip地址经常发生变化，以kubernetes系统为代表的容器编排系统引入了服务(service)机制，服务是一种为一组功能相同的容器组提供单一不变的接入点资源，当某个容器组具有服务的选择器指定的标签(label)时，该容器组即成为服务的成员，运行在容器组中的应用实例即又被称为服务实例。
54.当服务创建时，通过服务配置文件中的选择符确定服务与容器组之间的对应关系，由于服务实例运行在容器中，一旦服务与容器组之间的对应关系确定，服务与服务实例之间的对应关系也随之确定。同时，每一个被创建的服务均会分配服务域名以及虚拟ip地址，用于对外提供接入功能，服务域名和虚拟ip地址的生命周期与服务的生命周期相同。也就是说，不管服务所对应的服务实例部署位置如何改变(比如容器组重新调度)，服务域名和虚拟ip地址就固定不变，以此实现服务的单一不变接入。
55.此外，在建立服务与服务实例之间的对应关系之后，还会在服务的虚拟ip地址与服务实例的ip地址之间建立对应关系，并且服务实例部署位置发生变化后，自动更新对应关系中服务实例的ip地址。
56.由于同一个服务对应的多个服务实例功能相同，因此可以由任意一个服务实例对指向该服务的访问请求进行响应，访问请求方无需知晓实际被访问的服务实例的ip地址，只需要知晓服务的虚拟ip地址，并向该虚拟ip地址发送访问请求，就会根据虚拟ip地址与服务实例的ip地址的对应关系，将该访问请求发送至该服务对应的某个服务实例进行响应。
57.具体来说，发起访问的服务对应的服务实例向域名解析组件(比如coredns)发送包含待访问服务域名的域名解析请求，以获取待访问服务的虚拟ip地址，向待访问服务的虚拟ip地址发出访问请求，由集群内的负载均衡组件(比如kubernetes系统的kube-proxy组件)根据虚拟ip地址与服务实例的ip地址的对应关系，以及每个服务实例的负载情况，将访问请求分发至某个服务实例进行响应。
58.在多集群场景下，同一个服务对应的多个服务实例将会被部署至多个集群中，同时对访问请求进行响应，以防单个数据中心发生故障或毁损、灭失导致服务不可用，降低了
单一数据中心带来的风险，保障了业务的高可用性。
59.具体地，参见图1，相关技术中，当客户端从外部向多集群中的第一服务发送访问请求时，集群外部的负载均衡器根据预先设置的负载策略(比如本地优先、负载优化、轮询、随机等)将该访问请求分发至某一集群上的服务实例进行处理，比如第一集群上的第一服务实例。此时，如果第一服务实例在处理该请求时依赖于第二服务的功能，会先向所在集群(即第一集群)的域名解析组件(图中未画出)发送指向第二服务的域名解析请求，以获取第二服务的虚拟ip地址。
60.第一集群的域名解析组件根据第二服务的域名，向第一服务实例返回第二服务的虚拟ip地址，第一服务实例随即发出指向第二服务的虚拟ip地址的访问请求，以对第二服务进行访问。基于前述说明可知，第二服务的虚拟ip地址与多个服务实例相对应，且服务实例分布在不同集群中，因此指向虚拟ip地址的访问请求将被分发到某个服务实例进行处理，而且，这个过程由集群内的负载均衡组件(图中未画出)根据每个服务实例的负载情况实现，是不可控的。一旦访问请求被分发到第一集群之外的其他集群，将会出现跨集群访问，造成网络延迟和资源开销过高。
61.申请人对上述技术问题进行深入研究和分析后发现，目前多集群场景下多服务之间相互访问出现跨集群访问的核心在于域名解析组件对服务的域名解析请求返回的是虚拟ip地址。当客户端发出指向虚拟ip地址访问请求时，集群内的负载均衡组件会根据该虚拟ip地址与服务实例的ip地址的对应关系，以及每个服务实例的负载情况，从服务对应的多个服务实例中选择一个服务实例，并将访问请求重定向到该服务实例的ip地址，且该选择完全由集群内的负载均衡组件自动完成，无法人为控制，导致可能出现跨集群访问。
62.为此，本技术提供一种多集群场景下服务的域名解析方法、系统、计算机可读存储介质和电子设备，该方法由域名解析组件执行，并为域名解析组件提供服务地址解析优化的能力，当域名解析组件接收到位于第一集群的第一服务访问第二服务的域名解析请求时，能够使用第一集群上第二服务对应的第二服务实例的ip地址代替第二服务的虚拟ip地址返回给第一服务应用，从而使集群内的负载均衡组件能够将访问请求重定向到第二服务实例的ip地址，避免了现有技术导致的跨集群服务访问，节约了网络开销，缩短了服务的响应时间，提高了访问请求的处理效率。
63.示例性方法
64.本技术实施例提供一种多集群场景下服务的域名解析方法，如图1-5所示，在多集群中第一服务和第二服务分别对应有至少一个服务实例，在第一集群中部署有第一服务对应的第一服务实例，该方法由第一集群的域名解析组件执行；该方法包括：
65.步骤s101、响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址。
66.其中，第二服务实例为部署在第一集群中的第二服务对应的服务实例。
67.本技术实施例中，多集群至少包括两个集群，第一集群为多集群中的任一集群，第一集群上部署有第一服务对应的至少一个服务实例。
68.第二服务为与第一服务相关的服务，在一些业务场景中，第一服务需要访问第二服务以对客户端的访问请求进行反馈。可以理解，第二服务也对应有至少一个服务实例。
69.基于前述说明可知，如果第一服务实例在处理客户端的访问请求时依赖于第二服
务的功能，第一服务实例会先向所在集群(即第一集群)的域名解析组件发送域名解析请求，以获取第二服务的访问地址。在传统的处理方式中，域名解析组件将第二服务的虚拟ip地址作为第二服务的访问地址返回给第一服务实例。第一服务实例通过虚拟ip地址访问第二服务时，由集群内的负载均衡组件从第二服务对应的所有服务实例中选择一个服务实例来处理第一服务实例的访问请求，导致所选择的服务实例可能与第一服务实例位于不同集群上，此时便出现了跨集群访问。
70.本技术实施例中，为了避免选择服务实例导致的跨集群访问，在向第一服务实例返回第二服务的ip地址之前，第一集群的域名解析组件预先建立的第二服务对应的至少一个服务实例的ip地址清单。
71.在建立服务实例的ip地址清单后，当接收到第一服务实例指向第二服务的域名解析请求时，第一集群的域名解析组件能够根据第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址。
72.其中，第二服务实例为部署在第一集群中的第二服务对应的服务实例。由于第二服务实例与第一服务实例均部署在第一集群中，使得第一服务实例能够直接使用第二服务实例的ip地址访问相同集群中的第二服务实例，从而避免第一服务实例跨集群访问第二服务的问题，提升了访问效率。
73.需要说明的是，第一集群中可能同时部署有第二服务对应的多个服务实例，第一服务实例访问其中任意一个都不会出现跨集群访问的情况，因此，既可以从中随机选择某个服务实例作为第二服务实例，也可以使用负载均衡机制，根据服务实例的负载情况，从中选择负载最小的服务实例作为第二服务实例，本技术实施例对此不做限定。
74.在一些实施例中，第二服务对应的至少一个服务实例的ip地址清单通过以下方式建立：通过访问所有集群的api-server组件，获取并在ip地址清单中记录第二服务对应的所有服务实例所在的集群和ip地址；相应地，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址，包括：从ip地址清单中查询是否存在第二服务实例；响应于存在第二服务实例，从ip地址清单中查询第二服务实例的ip地址。
75.本技术实施例中，多集群场景下包括多个kubernetes集群，每个kubernetes集群上均部署有api-server组件。
76.需要说明的是，在多集群环境中包含两类集群：控制面集群和成员集群。其中，控制面集群中部署有多集群管理组件，用于接受用户提交的应用部署需求，将这些部署需求同步到各成员集群，并从成员集群同步应用部署后的运行状态。
77.并且，控制面集群上除了部署多集群管理组件以外，还部署有成员集群的各种组件，即控制面集群实质上是在成员集群中额外部署了多集群管理组件。
78.应当理解，在一个kubernetes集群注册成为多集群的成员集群时，多集群管理组件会为新加入的成员集群配置相应的访问权限，使其能够与多集群内的其他任一集群进行相互访问，从而使得不同成员集群的组件能够相互访问和通信。
79.一种实施例中，第一集群的域名解析组件通过主动访问所有集群的api-server组件，即可获取多集群中第二服务对应的所有服务实例所在的集群和ip地址，并将所获取的集群和ip地址记录在ip地址清单中，从而使得接到访问第二服务的请求时，第一集群的域名解析组件能够基于该ip地址清单查找到第二服务对应的所有服务实例所在的集群和ip
地址。
80.另一实施例中，多集群中的每个集群中部署有代理组件，用于向其他集群中的域名解析组件推送所在集群中第二服务对应的服务实例的ip地址，第一集群的域名解析组件通过被动接收代理组件的推送信息，即可获取多集群中第二服务对应的所有服务实例所在的集群和ip地址，并将所获取的集群和ip地址记录在ip地址清单中。
81.对于多集群中的任一服务，服务所在集群的域名解析组件均可以通过上述方式为其建立对应的服务实例的ip地址清单。
82.实际应用中，为了保持ip地址清单中的记录与多集群中服务实例的ip地址同步，还可以设置ip地址清单的更新机制，例如，域名解析组件以特定的时间间隔访问所有集群的api-server组件，以对ip地址清单进行更新，或者，还可以让代理组件对所在集群的api-server组件进行监听，一旦监听到服务实例发生变化，即将服务实例的变化情况推送给域名解析组件，本技术实施例对此不做限定。
83.在建立ip地址清单后，当接收到第一服务实例指向第二服务的域名解析请求时，第一集群的域名解析组件先从ip地址清单中查询第一集群中是否存在第二服务对应的服务实例(即第二服务实例)，如果ip地址清单中存在第二服务实例，那么第一服务实例直接访问同一集群中的第二服务实例即可实现对第二服务的访问，则从ip地址清单中确定第二服务实例的ip地址。
84.步骤s102、使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
85.本技术实施例中，在确定第二服务实例的ip地址之后，第一集群的域名解析组件使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。如此，使用第二服务实例的ip地址代替第二服务的虚拟ip地址，使第一服务实例能够优先就近访问第一集群的第二服务实例，降低了网络延迟。
86.应当理解，在第一集群的域名解析组件从ip地址清单中查询是否存在第二服务实例时，如果ip地址清单中不存在第二服务实例，则第一集群的域名解析组件能够获取第二服务对应的其他服务实例的ip地址，作为域名解析请求的响应，反馈给第一服务实例。
87.进一步地，为了确定第二服务实例的可用性，第一服务实例在访问第二服务实例之前，该方法还包括：持续监听并在ip地址清单中记录第二服务对应的所有服务实例的运行状态；相应地，在从ip地址清单中查询第二服务实例的ip地址之前，还包括：从ip地址清单中查询第二服务实例的运行状态。
88.本技术实施例中，第一集群的域名解析组件持续监听并在ip地址清单中记录第二服务对应的所有服务实例的运行状态，这里，服务实例的运行状态用于指示相应的服务实例的健康状况，以确定相应的服务实例是否能够正常处理访问请求。因此，在从ip地址清单中查询第二服务实例的ip地址之前，为了确定第二服务实例的运行状态，第一集群的域名解析组件先从ip地址清单中查询第二服务实例的运行状态，从而确保第二服务实例能够正确处理第一服务实例的访问请求。
89.具体来说，由于服务实例运行在容器中，服务实例的运行状态可以由运行该服务实例的容器组的状态、容器(container)的状态和服务实例本身的运行状态来确定，无论是容器组还是容器、服务实例本身出现异常，均会导致服务实例处于不可用状态。
90.实际应用中，持续监听第二服务对应的所有服务实例的运行状态有多种实现方式，包括：通过api-server组件监听第二服务对应的所有服务实例所在容器组的运行状态；或者，通过访问监控组件获取第二服务对应的所有服务实例的运行状态；或者，根据服务实例发送的心跳数据包获取第二服务对应的所有服务实例的运行状态。
91.可以理解，当容器组的运行出现异常，其中运行的服务实例必然也会出现异常。具体来说，kubernetes集群中的每个节点部署有kubelet组件，用于管理所在节点的容器组，kubelet组件将通过api-server组件主动上报所管理的容器组的运行状态，并记录在etcd中。
92.基于此，第一集群的域名解析组件通过api-server组件能够监听到第二服务对应的所有服务实例所在容器组的运行状态，从而确定容器组上各服务实例的运行状态。具体地，第一集群的域名解析组件可以通过逐个访问所有集群的api-server组件来获取第二服务对应的所有服务实例所在容器组的运行状态。基于前述说明可知，第一集群的域名解析组件可以通过主动访问所有集群的api-server组件，来获取多集群中第二服务对应的所有服务实例所在的集群和ip地址，并且以特定的时间间隔访问所有集群的api-server组件，以对ip地址清单进行更新。也就是说，为了能够建立和维护ip地址清单，第一集群的域名解析组件需要不断访问所有集群的api-server组件，因此通过访问api-server组件来确定服务实例所在容器组的运行状态，可以在同一次访问过程中一并完成对服务实例所在的集群、ip地址和运行状态信息的获取，充分利用kubernetes集群自身的监控能力，降低了集群管理的复杂度。
93.虽然依据容器组的运行状态与其中运行的服务实例的关联性，从而能够使用容器组的运行状态反映其中运行的服务实例的运行状态，但是，仍有可能会出现服务实例所在的容器组状态正常、服务实例本身运行异常的情况，此时，如果通过容器组的运行状态判断其中运行的服务实例的运行状态，将会导致误判。为此，在一些应用场景中，第二服务对应的所有服务实例的运行状态可以通过访问监控组件获取，其中，监控组件可以是metrics-server、prometheus等。通过访问这些监控组件，能够直接获取第二服务对应的所有服务实例本身的运行状态，避免了服务实例所在容器组运行正常、服务实例本身出现异常的情况下对服务实例的运行状态产生误判。
94.在另一些应用场景中，第二服务对应的所有服务实例的运行状态还可以根据服务实例主动发送心跳数据包获取。本技术实施例中，第二服务对应的各服务实例可以通过定期发送心跳数据包来告知第一集群的域名解析组件自己的运行状态。如此，第一集群的域名解析组件只需根据接收到的心跳数据包，即可直接判断第二服务对应的所有服务实例的运行状态，提高了服务实例的运行状态的准确度。
95.在获取第二服务实例的运行状态之后，该方法还包括：响应于第二服务实例处于可用状态，从ip地址清单中查询第二服务实例的ip地址；响应于第二服务实例处于不可用状态，从ip地址清单中查询第三服务实例的ip地址；第三服务实例为部署在第二集群中的第二服务对应的服务实例；使用第三服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
96.需要说明的是，服务实例的运行状态包括可用状态和不可用状态。当服务实例处于可用状态时，表示服务实例运行正常，能够正确处理下发送到本服务实例的访问请求；反
之，当服务实例处于不可用状态时，表示服务实例运行异常，无法对发送到本服务实例的访问请求进行正确处理。
97.本技术实施例中，在对域名解析请求进行响应之前，第一集群的域名解析组件从ip地址清单中获取的第二服务实例的运行状态，并根据运行状态判断第二服务实例是否处于可用状态。
98.当第二服务实例处于可用状态时，说明第二服务实例能够正确处理访问请求，此时，第一集群的域名解析组件从ip地址清单中查询第二服务实例的ip地址，并使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
99.当第二服务实例处于不可用状态时，说明第二服务实例无法对访问请求作出响应，此时，为了确保第二服务的可用性，第一集群的域名解析组件从ip地址清单中查询第三服务实例的ip地址，使用第三服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
100.其中，第三服务实例为部署在第二集群中的第二服务对应的服务实例。这里，第二集群可以是多集群中的任一集群。
101.需要说明的是，在查询第三服务实例的ip地址之前，第一集群的域名解析组件先从ip地址清单中查询第二服务对应的所有服务实例中处于可用状态的服务实例，作为第三服务实例，即将第一集群之外部署的第二服务对应的某一处于可用状态的服务实例作为第三服务实例，以确保第三服务实例能够正确处理访问请求。
102.如此，在第一集群上的第二服务实例处于不可用状态时，通过返回其他集群上处于可用状态的服务实例的ip地址，保证了服务的可用性。
103.应当理解，当第一集群上的第二服务实例的运行状态从不可用状态恢复到可用状态时，第一集群的域名解析组件通过前述的持续监听能够及时感知第二服务实例的运行状态的变化，并在接收到第一服务实例指向第二服务的域名解析请求时，能够作出相应的域名解析请求的响应，即使用第二服务实例的ip地址作为域名解析请求的响应，反馈给第一服务实例。如此，通过持续监听第二服务实例的运行状态，根据该运行状态确定域名解析请求的响应，在实现地区亲和性规则的同时，兼顾了第二服务的可用性和访问效率。
104.进一步地，在选择第三服务实例时，可以根据预先采集的网络通信情况，从部署有第二服务对应的服务实例且该服务实例处于可用状态的所有集群中，选择与第一集群网络通信最好的集群作为第二集群，并在第二集群中选择第三服务实例，从而尽可能降低第一服务实例和第三服务实例之间因跨集群访问而产生的网络延迟和资源开销。
105.为了提高域名解析组件的灵活性和可扩展性，在一些实施例中，第一集群的域名解析组件中设置有多集群域名解析插件，多集群域名解析插件用于建立和维护ip地址清单，以及对域名解析请求进行响应。
106.需要说明的是，本技术实施例中的第一集群的域名解析组件基于标准开放插件机制构建，包括核心服务模块、流量转发插件和多集群域名解析插件。
107.其中，核心服务是域名解析组件的核心模块，用于接收域名解析请求和实现域名解析组件的核心功能。
108.流量转发插件用于对域名解析请求进行拦截并将域名解析请求转发至多集群域
名解析插件，以由多集群域名解析插件对该域名解析请求进行处理。
109.多集群域名解析插件用于建立和维护ip地址清单，以及在接收到流量转发插件转发的域名解析请求时，根据所建立和维护的ip地址清单，对域名解析请求进行响应，以增强第一集群的域名解析组件的服务地址解析能力。
110.如此，通过多集群域名解析插件实现服务的域名解析，由于插件可以单独使用，也可以与其他插件配合使用，使得本技术实施例提供的方法在部署和应用时更加灵活，提高了该方法的适用性。
111.应当理解，第一服务和第二服务分别对应的至少一个服务实例可以部署在同一区域的同一集群中，也可以部署在位于不同区域的多个集群中。
112.在一些实施例中，第一服务和第二服务分别对应的至少一个服务实例部署在位于不同区域的多个集群中。
113.这里，区域(region)是从地理位置和网络时延维度划分的，同一个区域内共享弹性计算、块存储、对象存储、vpc网络、弹性公网ip、镜像等公共服务。
114.实际应用中，区域可以对应行政区划单元所划定的地域空间，比如省、市等，也可以是不同位置上与行政区划单元无关的地域空间。
115.在一些应用场景中，区域可以划分为多个可用区(az，availability zone)可用区是电力和网络互相隔离的物理区域，一个可用区不受其他可用区故障的影响。多个可用区间通过高速网络相连，以满足用户跨可用区构建高可用性系统的需求。
116.本技术实施例中，第一服务和第二服务分别对应的至少一个服务实例部署在位于不同区域的多个集群中。例如，第一服务在区域a的第一集群、区域b的第二集群、区域c的第三集群上均部署有对应的服务实例；同样地，第二服务在区域a的第一集群、区域b的第二集群、区域c的第三集群上均部署有对应的服务实例。
117.应当理解，虽然有高速网络连接，不同区域中部署的集群之间的相互访问仍面临更多的资源开销，也导致更长的网络延迟。
118.相关技术中，对于多集群外部的访问请求，可以通过在集群外部设置负载均衡器对访问请求进行调度，并且为负载均衡器设置本地优先的负载策略，使客户端访问多集群上的服务时能够就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
119.然而，当访问请求由多集群内部的第一服务实例发起时，第一服务实例先进行域名解析以获取第二服务的虚拟ip地址；然后，第一服务实例将访问请求发往该虚拟ip地址。集群内的负载均衡组件在处理该访问请求时，可能会将该访问请求转发至第二服务对应的任一服务实例的ip地址，而该服务实例可能部署在与第一服务实例所在区域不同的另一区域集群中，比如，第一服务部署在区域a的第一集群上，访问请求被路由到区域b中第二服务对应的服务实例上，导致出现跨区域调度。
120.通过本技术实施例提供的多集群场景下服务的域名解析方法，即便是第一服务和第二服务分别对应的至少一个服务实例部署在位于不同区域的多个集群中，也能够优先返回第一集群上第二服务的第二服务实例的ip地址，也就是说，第一集群中的第一服务实例总能访问到位于第一集群中的第二服务实例，从而改变了原有基于虚拟ip地址的访问请求分发策略，实现基于区域亲和性的就近调度策略，避免了跨区域调度。
121.综上所述，本技术提供的技术方案中，当第一集群的域名解析组件接收到第一服
务实例指向第二服务的域名解析请求时，通过预先建立第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址，其中，第二服务实例为部署在第一集群中的第二服务对应的服务实例，并使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。如此，通过使用第二服务实例的ip地址代替第二服务的虚拟ip地址返回给第一服务实例，实现优先返回第一集群的第二服务实例的ip地址的目的，保证多个服务之间相互访问时，发起服务访问的第一服务能够就近访问到与其在同一集群的第二服务实例，避免了跨集群访问服务实例导致的网络延迟和资源开销。
122.示例性系统
123.本技术实施例提供一种多集群场景下服务的域名解析系统，在多集群中第一服务和第二服务分别对应有至少一个服务实例，在第一集群中部署有第一服务对应的第一服务实例；该系统包括：响应单元601、反馈单元602。其中：
124.响应单元601，配置为响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址；第二服务实例为部署在第一集群中的第二服务对应的服务实例。
125.反馈单元602，配置为使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
126.本技术实施例提供的多集群场景下服务的域名解析系统，能够实现上述任一实施例的多集群场景下服务的域名解析方法的流程、步骤，并达到相同的技术效果，在此不再一一赘述。
127.示例性设备
128.图7为根据本技术的一些实施例提供的电子设备的结构示意图；如图7所示，该电子设备包括：
129.一个或多个处理器701；
130.计算机可读介质，可以配置为存储一个或多个程序702，一个或多个处理器701执行一个或多个程序702时，实现如下步骤：响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址；第二服务实例为部署在第一集群中的第二服务对应的服务实例；使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
131.图8为根据本技术的一些实施例提供的电子设备的硬件结构；如图8所示，该电子设备的硬件结构可以包括：处理器801、通信接口802、计算机可读介质803和通信总线804。
132.其中，处理器801、通信接口802、计算机可读存储介质803通过通信总线804完成相互间的通信。
133.可选地，通信接口802可以为通信模块的接口，如gsm模块的接口。
134.其中，在多集群中第一服务和第二服务分别对应有至少一个服务实例，在第一集群中部署有第一服务对应的第一服务实例，处理器801具体可以包括第一集群的域名解析组件，该第一集群的域名解析组件执行如下步骤：响应于接收到第一服务实例指向第二服务的域名解析请求，根据预先建立的第二服务对应的至少一个服务实例的ip地址清单，确定第二服务实例的ip地址；第二服务实例为部署在第一集群中的第二服务对应的服务实
例；使用第二服务实例的ip地址代替第二服务的虚拟ip地址，作为域名解析请求的响应，反馈给第一服务实例。
135.处理器801可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等，还可以是数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
136.本技术实施例的电子设备以多种形式存在，包括但不限于：
137.(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iphone)、多媒体手机、功能性手机，以及低端手机等。
138.(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：pda、mid和umpc设备等，例如ipad。
139.(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：ipod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。
140.(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
141.(5)其他具有数据交互功能的电子装置。
142.需要指出，根据实施的需要，可将本技术实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本技术实施例的目的。
143.上述根据本技术实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如cd rom、ram、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如asic或fpga)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，ram、rom、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的多集群场景下服务的域名解析方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。
144.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术实施例的范围。
145.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，
相关之处参见方法实施例的部分说明即可。
146.以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
147.以上所述仅为本技术的优选实施例，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。