CN114884956B - 多集群架构的实现方法、装置及多集群架构系统 - Google Patents

Abstract

本公开提供一种多集群架构的实现方法、装置及多集群架构系统，其中该多集群架构的实现方法应用于多集群架构系统的业务服务实例，包括：在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持注册请求，业务服务实例中包括业务容器和预先注入的代理容器；通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，原始注册信息为单集群架构时的注册信息；将包括目标注册信息的注册请求发送至注册中心。本公开实施例快速高效地在已有单集群地基础上实现多集群架构系统的升级，进而提升了系统容灾能力、资源管理能力和可用性。

Description

多集群架构的实现方法、装置及多集群架构系统

技术领域

本公开涉及计算机技术领域，尤其涉及一种多集群架构的实现方法、装置及多集群架构系统。

背景技术

随着业务的高速发展，单集群架构因其在容灾能力、可用性以及资源管理上的缺陷已经无法满足现有的业务需求，同时一旦出问题，每次故障造成的损失和影响更是会加速增长。

为了解决单集群架构的缺陷，相关技术中可以采用多集群架构来进行业务服务，但是相关技术中的多集群架构在基于实现时通常是在业务内部进行调整或基于统一的控制中心实现，内部调整周期长，并且统一的控制中心需要重新进行集群的架构，在已经具有单集群架构的基础上调整实现多集群架构时，上述方式在调整效率和成本上都存在缺陷。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种多集群架构的实现方法、装置及多集群架构系统。

根据本公开的一方面，提供了一种多集群架构的实现方法，应用于多集群架构系统的业务服务实例，包括：

在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持所述注册请求，所述业务服务实例中包括所述业务容器和预先注入的所述代理容器；

通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，所述原始注册信息为单集群架构时的注册信息；

将包括所述目标注册信息的注册请求发送至所述注册中心。

根据本公开的另一方面，提供了一种多集群架构系统，包括：多个Kubernetes集群，每个所述Kubernetes集群中包括多个所述业务服务实例，每个所述业务服务实例包括所述业务容器和预先注入的代理容器，所述业务服务实例用于实现上述多集群架构的实现方法。

根据本公开的另一方面，提供了一种多集群架构的实现装置，设置于多集群架构系统的业务服务实例，包括：

获取模块，用于在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持所述注册请求，所述业务服务实例中包括所述业务容器和预先注入的所述代理容器；

变更模块，用于通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，所述原始注册信息为单集群架构时的注册信息；

发送模块，用于将包括所述目标注册信息的注册请求发送至所述注册中心。

本公开实施例中提供的上述多集群架构的实现方法，多集群架构系统的业务服务实例在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持注册请求，业务服务实例中包括业务容器和预先注入的代理容器；通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，原始注册信息为单集群架构时的注册信息；将包括目标注册信息的注册请求发送至注册中心。采用上述技术方案，在已有的单集群的基础上实现多集群架构系统时，针对多集群架构系统中的业务服务实例，可以通过代理容器将其注册请求中原始注册信息变更为包括互联网协议地址的目标注册信息，再发送至注册中心进行注册，实现了将业务服务实例的注册方式从单集群的服务变更为互联网协议注册，为后续多集群之间的相互通讯打好基础，相较于相关技术中的内部调整或统一控制，减少改造周期和成本，快速高效地在已有单集群地基础上实现多集群架构系统的升级，进而提升了系统容灾能力、资源管理能力和可用性。

本公开实施例中提供地上述多集群架构系统，包括：多个Kubernetes集群，每个所述Kubernetes集群中包括多个所述业务服务实例，每个所述业务服务实例包括所述业务容器和预先注入的代理容器，每个业务服务实例可以执行上述多集群架构的实现方法，以快速进行注册信息修改，进而能够基于多集群架构系提升容灾能力、资源管理能力和可用性。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1为本公开实施例提供的一种多集群架构的实现方法的流程示意图；

图2为本公开实施例提供的一种注册信息修改的示意图；

图3为本公开实施例提供的一种多集群架构系统的结构示意图；

图4为本公开实施例提供的一种不同Kubernetes集群相互通讯的示意图；

图5为本公开实施例提供的一种单集群架构系统的结构示意图；

图6为本公开实施例提供的一种多集群架构的实现装置的结构示意图；

图7为本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本公开使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在单集群架构的基础上，当出现网络故障等因素时，可能造成整个业务集群的瘫痪，对业务的可用性造成严重影响，并且单集群的资源管理能力存在瓶颈。初期故障损失和影响小于技术投入，随着高速发展当故障造成的损失和影响高于技术上的投入时，就需要加大技术上的投入使用更加高可用的技术架构来避免故障。为了解决单集群架构的缺陷，相关技术中可以采用多集群架构来进行业务服务，但是相关技术中的多集群架构在基于实现时通常是在业务内部进行调整或基于统一的控制中心实现，内部调整周期长，并且统一的控制中心需要重新进行集群的架构，在已经具有单集群架构的基础上调整实现多集群架构时，上述方式在调整效率和成本上都存在缺陷。

为了解决上述技术问题，本公开实施例提供了一种多集群架构的实现方法、装置、多集群架构系统、设备及介质，下面结合具体的实施例进行介绍。

图1为本公开实施例提供的一种多集群架构的实现方法的流程示意图，该方法可以由多集群架构的实现装置执行，其中该装置可以采用软件和/或硬件实现，一般可集成在电子设备中。如图1所示，该方法应用于多集群架构系统的业务服务实例，包括：

步骤101、在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持注册请求，业务服务实例中包括业务容器和预先注入的代理容器。

其中，多集群架构系统可以是本公开实施例中基于已有的单集群架构改造得到的系统，该多集群结构系统可以包括多个Kubernetes集群，每个Kubernetes集群中包括多个业务服务实例。Kubernetes，简称K8s，是一个用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效。业务服务实例（pod），又称业务服务容器，可以是k8s集群中的最小部署单元，是一个环境，可以包括容器、存储、网络资源、容器配置等。其中，代理容器，又称sidecar容器,可以是本公开实施例中通过引入服务网格框架（istio）在每个业务服务实例中新注入的容器，服务网络框架中携带的envoy作为代理容器，该代理容器用于接管业务容器的出向流量中的注册请求。业务容器可以是业务服务实例中用于实现业务的已有容器。

在本公开实施例中，每个业务服务实例接入Kubernetes集群时，可以启动内部的业务容器，并按照服务注册的通用标准向注册中心发送注册请求，并且在发送注册请求的过程中，内部的代理容器可以劫持该注册请求，以备后续的修改。

步骤102、通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，原始注册信息为单集群架构时的注册信息。

其中，原始注册信息可以是已有的单集群架构进行注册时的注册信息，原始注册信息中使用Kubernetes中的服务（service）名称作为注册的域名（host）。目标注册信息可以是基于业务服务实例的互联网协议地址（Internet Protocol Address，IP地址）实现注册的注册信息。

在本公开实施例中，通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，包括：通过代理容器将原始注册信息中域名从服务名称变更为业务服务实例的互联网协议地址，得到包含域名为业务服务实例的互联网协议地址的目标注册信息。

业务服务实例中的代理容器劫持注册请求之后，可以将原始注册信息中的域名从服务名称变更为当前业务服务实例的IP地址，例如原始注册信息的域名为“service-1”，修改之后的域名为Pod IP（10.1.2.3），仅为实例，得到目标注册信息。

在一些实施例中，代理容器中包括代理过滤器，在将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息之前，多集群架构的实现方法还包括：在业务服务实例启动之后，通过代理过滤器从配置文件中拉取注册变更逻辑的文件，并在代理容器中加载生效，其中，注册变更逻辑的文件预先存储至Kubernetes集群的配置文件中。

其中，代理过滤器（envoyfilter）可以是设置在代理容器中用于在代理容器中动态加载上述注册变更逻辑的器件，注册变更逻辑的文件用于执行将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息。配置文件（configmap）可以是Kubernetes中的资源对象，配置文件中可以包括注册变更逻辑的文件，注册变更逻辑的文件的格式不限，例如可以将注册变更逻辑的脚本编辑为wasm文件，该wasm文件即为注册变更逻辑的文件。并且，注册变更逻辑的文件可以根据业务需求动态修改。

在业务服务实例启动之后，内部的代理容器中的代理过滤器可以通过预先存储的配置文件的地址拉取配置文件，并从配置文件中拉取注册变更逻辑的文件到代理容器中并进行加载生效。上述方案中通过配置文件中预先设置的注册变更逻辑的文件，动态拉取并加载至代理容器之后，可以快速实现注册信息的修改，并且由于配置文件支持修改，使得各种逻辑的修改更加灵活。

示例性的，图2为本公开实施例提供的一种注册信息修改的示意图，如图2所示，图中展示了一个Kubernetes集群中的业务服务实例201和注册中心202，业务服务实例201中可以包括代理滤波器2011、业务容器2013和代理容器2012，代理容器2012可以劫持业务容器2013发送至注册中心202的注册请求，并将注册请求中的原始注册信息变更为目标注册信息；注册变更逻辑使用了代理滤波器2011的动态加载的技术，注册变更逻辑的文件可以放入配置文件203中，了代理滤波器201中配置了配置文件203的地址，就会把其中的注册变更逻辑的文件拉取到代理容器2012中加载生效。

步骤103、将包括目标注册信息的注册请求发送至注册中心。

业务服务实例通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息之后，可以将包括该目标注册信息的注册请求发送的注册中心，以进行服务注册或续约等，注册中心中可以包括目标注册信息。

综上，本公开实施例中提供的上述多集群架构的实现方法，多集群架构系统的业务服务实例在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持注册请求，业务服务实例中包括业务容器和预先注入的代理容器；通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，原始注册信息为单集群时的注册信息；将包括目标注册信息的注册请求发送至注册中心。采用上述技术方案，在已有的单集群的基础上实现多集群架构系统时，针对多集群架构系统中的业务服务实例，可以通过代理容器将其注册请求中原始注册信息变更为包括互联网协议地址的目标注册信息，再发送至注册中心进行注册，实现了将业务服务实例的注册方式从单集群的服务变更为互联网协议注册，为后续多集群之间的相互通讯打好基础，相较于相关技术中的内部调整或统一控制，减少改造周期和成本，快速高效地在已有单集群地基础上实现多集群架构系统的升级，避免对业务服务内部的任何侵入和破坏，进而提升了系统容灾能力、资源管理能力和可用性。

示例性的，图3为本公开实施例提供的一种多集群架构系统的结构示意图，如图3所示，该多集群架构系统300可以包括：多个Kubernetes集群，每个Kubernetes集群中包括多个业务服务实例，每个业务服务实例包括业务容器和预先注入的代理容器，业务服务实例用于实现上述多集群架构的实现方法，也即实现：在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持注册请求，业务服务实例中包括业务容器和预先注入的代理容器；通过代理容器将注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，原始注册信息为单集群时的注册信息；将包括目标注册信息的注册请求发送至注册中心。

如图3所示，图中以包括两个Kubernetes集群为例，该多集群架构系统300中可以包括集群301、集群302和域名解析器303，集群301中可以包括Kubernetes集群1、网关1和注册中心1，集群302中可以包括Kubernetes集群2、网关2和注册中心2，Kubernetes集群1和Kubernetes集群2均示例性的包括了两个业务服务实例，每个业务服务实例中包括业务容器和代理容器。上述域名解析器303用于对外部请求进行域名解析之后转发至网关1和网关2。

每个代理容器中包括代理过滤器，代理过滤器用于将原始注册信息中的域名从服务名称变更为实例互联网协议地址，得到域名为实例互联网协议地址的目标注册信息。具体修改过程参见上述实施例，在此不进行赘述。

在一些实施例中，每个Kubernetes集群设置对应的注册中心（Eureka），不同注册中心之间将包括的注册信息进行双向同步。参见图3，Kubernetes集群1对应注册中心1，Kubernetes集群2对应注册中心2，注册中心1中存储Kubernetes集群1包括的多个业务服务实力的注册信息，注册中心2中存储Kubernetes集群2包括的多个业务服务实力的注册信息，注册中心1和注册中心2之间的双向箭头表示通过同步服务来完成注册信息的双向同步，具体的同步服务采用的技术方式不限。

在一些实施例中，每个Kubernetes集群设置对应的网关（Api-Gateway），每个Kubernetes集群的网关从该集群的注册中心获取其他Kubernetes集群的注册信息，以将外部请求转发至其他Kubernetes集群。如图3所示，Kubernetes集群1对应网关1，Kubernetes集群2对应网关2，在注册中心1和注册中心2将注册信息双向同步的基础上，网关1可以从注册中心1获取Kubernetes集群1和Kubernetes集群2的注册信息，可以在获取到外部请求之后，不仅可以将外部请求发送至Kubernetes集群1，也可以将外部请求转发至Kubernetes集群2，外部请求可以是用户发送的对Kubernetes中的业务服务实例进行访问的请求。

在一些实施例中，不同Kubernetes集群之间的传输协议为网际互连协议，以使不同Kubernetes集群之间可以通过互联网协议地址相互通讯。经过每个业务服务实例对注册信息的修改，目标注册信息中包括IP地址，本公开实施例中可以将不同Kubernetes集群之间的传输协议为网际互连协议（IP协议），以构建使用IP地址进行通讯的网络环境，进而可以打通不同Kubernetes集群之间的通讯网络，使得不同Kubernetes集群之间可以相互通讯。

示例性的，图4为本公开实施例提供的一种不同Kubernetes集群相互通讯的示意图，如图4所示，图中Kubernetes集群3和Kubernetes集群4均展示了6个业务服务实例，打通不同Kubernetes集群之间的通讯网络之后，Kubernetes集群3的业务服务实例401就可以直接通过Pod IP与集群Kubernetes集群4的业务服务实例402进行通讯，Kubernetes集群3对应的网关3也可以把外部请求转发到Kubernetes集群4中的业务服务实例402上面去，Kubernetes集群4对应的网关4也可以把外部请求转发到Kubernetes集群3中的业务服务实例401上面去，图中仅为实例，而非限定。

每个网关可以从本Kubernetes集群的注册中心中获取到当前多集群架构系统中包括的多个Kubernetes集群的注册信息，这样就可以把外部的请求流量按照自己的负载均衡策略，负载到自己的Kubernetes集群或者其他的Kubernetes集群中，提升了负载均衡的效果。负载均衡是一种服务器或网络设备的集群技术，可以将特定的业务分担给多个服务器或网络设备，从而提高业务能力，保证业务的高可用性。

示例性的，图5为本公开实施例提供的一种单集群架构系统的结构示意图，如图5所示，图中展示了一个已有的单集群架构系统500，本公开实施例的多集群架构系统可以在图5的单集群架构系统500的基础上改造得到。如图5所示，业务服务实例502、业务服务实例503和业务服务实例504在启动时会将注册信息注册到注册中心505-507中；网关501可以定时从注册中心505-507同步注册信息，并维护一个包括请求url和host之间的关联关系的注册列表，例如URL“a/b/c”对应“host:service-1”和“host:service-2”，当外部请求请求经过网关501，通过请求中的url查询注册列表，就可以获取当前请求要转发的服务host，host经过Kubernetes集群的解析，就可以把请求轮询负载到后端的业务服务实例上。每个业务服务实例可以使用Kubernetes中的service作为服务注册的域名进行服务注册，一个service会映射关联多个业务服务实例，例如注册中心505-507在注册业务服务实例502-504之后，可以使用相同的service-1作为域名进行注册。

本公开实施例中提供地上述多集群架构系统，包括多个Kubernetes集群，每个Kubernetes集群中包括多个业务服务实例，每个业务服务实例包括业务容器和预先注入的代理容器，每个业务服务实例可以执行上述多集群架构的实现方法，多集群架构系统可以提高整体业务系统的容灾能力，多个集群互为灾备，即使一个集群出问题，可以快速将流量迁移至另外一个集群；并且系统的资源管理容量得到了提升，相较于相关技术中单集群各种资源（例如IP资源、node管理数量、pod管理数量等）都存在上限，升级到多活集群架构，集群可以无限扩容，按业务需求在集群级别扩容，提升资源管理能力；减少故障对业务造成的影响，提高系统的可用性，保障业务持续可用。

对应于上述多集群架构的实现方法，本公开实施例还提供了一种多集群架构的实现装置，图6为本公开实施例提供的一种多集群架构的实现装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在电子设备中。如图6所示，多集群架构的实现装置600设置于多集群架构系统的业务服务实例，包括：

获取模块601，用于在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持所述注册请求，所述业务服务实例中包括所述业务容器和预先注入的所述代理容器；

变更模块602，用于通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，所述原始注册信息为单集群架构时的注册信息；

发送模块603，用于将包括所述目标注册信息的注册请求发送至所述注册中心。

在上述装置中，通过代理容器将其注册请求中原始注册信息变更为包括互联网协议地址的目标注册信息，再发送至注册中心进行注册，实现了将业务服务实例的注册方式从单集群的服务变更为互联网协议注册，为后续多集群之间的相互通讯打好基础，相较于相关技术中的内部调整或统一控制，减少改造周期和成本，快速高效地在已有单集群地基础上实现多集群架构系统的升级，避免对业务服务内部的任何侵入和破坏，进而提升了系统容灾能力、资源管理能力和可用性。

在一些实施方式中，所述变更模块602具体用于：

通过所述代理容器将所述原始注册信息中域名从服务名称变更为所述业务服务实例的互联网协议地址，得到包含域名为所述业务服务实例的互联网协议地址的目标注册信息。

在一些实施方式中，所述代理容器中包括代理过滤虑器，所述装置还包括文件模块，用于：在将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息之前，

在所述业务服务实例启动之后，通过所述代理过滤器从配置文件中拉取注册变更逻辑的文件，并在所述代理容器中加载生效，其中，所述注册变更逻辑的文件预先存储至所述Kubernetes集群的配置文件中。

在一些实施方式中，所述注册变更逻辑的文件用于执行所述将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，并且所述注册变更逻辑的文件根据业务需求动态调整。

本公开实施例所提供的多集群架构的实现装置可执行本公开任意实施例所提供的多集群架构的实现方法，具备执行方法相应的功能模块和有益效果。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置实施例的具体工作过程，可以参考方法实施例中的对应过程，在此不再赘述。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

本公开示例性实施例还提供一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器。所述存储器存储有能够被所述至少一个处理器执行的计算机程序，所述计算机程序在被所述至少一个处理器执行时用于使所述电子设备执行根据本公开实施例的方法。

本公开示例性实施例还提供一种存储有计算机程序的非瞬时计算机可读存储介质，其中，所述计算机程序在被计算机的处理器执行时用于使所述计算机执行根据本公开实施例的方法。

本公开示例性实施例还提供一种计算机程序产品，包括计算机程序，其中，所述计算机程序在被计算机的处理器执行时用于使所述计算机执行根据本公开实施例的方法。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本公开的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本公开实施例所提供的XYZ方法。所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

示例性的，图7为本公开实施例提供的一种电子设备的结构示意图。参考图7，现将描述可以作为本公开的服务器或客户端的电子设备700的结构框图，其是可以应用于本公开的各方面的硬件设备的示例。电子设备旨在表示各种形式的数字电子的计算机设备，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，电子设备700包括计算单元701，其可以根据存储在只读存储器（ROM）702中的计算机程序或者从存储单元708加载到随机访问存储器（RAM）703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出（I/O）接口705也连接至总线704。

电子设备700中的多个部件连接至I/O接口705，包括：输入单元706、输出单元707、存储单元708以及通信单元709。输入单元706可以是能向电子设备700输入信息的任何类型的设备，输入单元706可以接收输入的数字或字符信息，以及产生与电子设备的用户设置和/或功能控制有关的键信号输入。输出单元707可以是能呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。存储单元708可以包括但不限于磁盘、光盘。通信单元709允许电子设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据，并且可以包括但不限于调制解调器、网卡、红外通信设备、无线通信收发机和/或芯片组，例如蓝牙TM设备、WiFi设备、WiMax设备、蜂窝通信设备和/或类似物。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元（CPU）、图形处理单元（GPU）、各种专用的人工智能（AI）计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器（DSP）、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理。例如，在一些实施例中，多集群架构的实现方法均可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到电子设备700上。在一些实施例中，计算单元701可以通过其他任何适当的方式（例如，借助于固件）而被配置为执行多集群架构的实现方法。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

如本公开使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置（例如，CRT（阴极射线管）或者LCD（液晶显示器）监视器）；以及键盘和指向装置（例如，鼠标或者轨迹球），用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈（例如，视觉反馈、听觉反馈、或者触觉反馈）；并且可以用任何形式（包括声输入、语音输入或者、触觉输入）来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统（例如，作为数据服务器）、或者包括中间件部件的计算系统（例如，应用服务器）、或者包括前端部件的计算系统（例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互）、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信（例如，通信网络）来将系统的部件相互连接。通信网络的示例包括：局域网（LAN）、广域网（WAN）和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种多集群架构的实现方法，应用于多集群架构系统的业务服务实例，包括：

在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持所述注册请求，所述业务服务实例中包括所述业务容器和预先注入的所述代理容器；

通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，所述原始注册信息为单集群架构时的注册信息；

将包括所述目标注册信息的注册请求发送至所述注册中心。

2.如权利要求1所述的多集群架构的实现方法，其中，通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，包括：

通过所述代理容器将所述原始注册信息中域名从服务名称变更为所述业务服务实例的互联网协议地址，得到包含域名为所述业务服务实例的互联网协议地址的目标注册信息。

3.如权利要求1所述的多集群架构的实现方法，其中，所述代理容器中包括代理过滤器，在将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息之前，所述方法还包括：

在所述业务服务实例启动之后，通过所述代理过滤器从配置文件中获取注册变更逻辑的文件，并在所述代理容器中加载生效，其中，所述注册变更逻辑的文件预先存储至所述Kubernetes集群的配置文件中。

4.如权利要求3所述的多集群架构的实现方法，其中，所述注册变更逻辑的文件用于执行所述将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，并且所述注册变更逻辑的文件根据业务需求动态调整。

5.一种多集群架构系统，包括：多个Kubernetes集群，每个所述Kubernetes集群中包括多个业务服务实例，每个所述业务服务实例包括业务容器和预先注入的代理容器，所述业务服务实例用于实现上述权利要求1-4中任一所述的多集群架构的实现方法。

6.如权利要求5所述的多集群架构系统，其中，所述代理容器中包括代理过滤器，所述代理过滤器用于将原始注册信息中的域名从服务名称变更为所述业务服务实例的互联网协议地址，得到包含域名为所述业务服务实例的互联网协议地址的目标注册信息。

7.如权利要求5所述的多集群架构系统，其中，每个所述Kubernetes集群设置对应的注册中心，不同注册中心之间将包括的注册信息进行双向同步。

8.如权利要求7所述的多集群架构系统，其中，每个所述Kubernetes集群设置对应的网关，每个所述Kubernetes集群的网关从该集群的注册中心获取其他Kubernetes集群的注册信息，以将外部请求转发至其他Kubernetes集群。

9.如权利要求5所述的多集群架构系统，其中，不同所述Kubernetes集群之间的传输协议为网际互连协议，以使不同所述Kubernetes集群之间可以通过互联网协议地址相互通讯。

10.一种多集群架构的实现装置，设置于多集群架构系统的业务服务实例，包括：

获取模块，用于在接入Kubernetes集群并通过业务容器发送注册请求至注册中心的过程中，通过预先注入的代理容器劫持所述注册请求，所述业务服务实例中包括所述业务容器和预先注入的所述代理容器；

变更模块，用于通过所述代理容器将所述注册请求中的原始注册信息变更为包括互联网协议地址的目标注册信息，所述原始注册信息为单集群架构时的注册信息；

发送模块，用于将包括所述目标注册信息的注册请求发送至所述注册中心。

Images