CN113596110B - 一种面向异构云的云原生微服务平台 - Google Patents

Abstract

本发明涉及一种面向异构云的云原生微服务平台，包括：微服务应用子系统，基于Kubernetes云管理平台、CloudFoundry云管理平台和IaaS云虚拟机部署的微服务应用，结合微服务平台基础支撑子系统和ServiceMesh技术构建异构云的云原生微服务适配操作；微服务平台基础支撑子系统，与微服务应用子系统进行交互，接收微服务应用子系统的注册和订阅请求，并为管理用户端提供信息配置、信息监控以及服务管理渠道；管理用户端通过ServiceMesh管理和维护Kubernetes云管平台部署的微服务应用，实现微服务基本组件功能管理；服务调用方从注册中心订阅全量的服务列表信息，根据负载均衡算法，选择一个服务提供方发送请求。与现有技术相比，本发明具有实现异构云管平台的统一微服务治理等优点。

Description

一种面向异构云的云原生微服务平台

技术领域

本发明涉及容器服务技术领域，尤其是涉及一种面向异构云的云原生微服务平台。

背景技术

随着微服务技术的快速发展，国内有很多企业包括政府部门的IT系统都做了微服务化改造，并结合CloudFoundry、OpenStack等云计算管理平台技术将微应用部署到容器中；随着开源容器管理技术Kubernetes的不断成熟和普及，以及国产软件化的不断推进，多数企业在尝试引入Kubernetes容器管理技术，并逐步将微应用迁移到Kubernetes管理的容器运行。

在逐步迁移过程中，企业内部面临着需将微服务部署在多种异构虚拟化平台上，由于计算、存储、网络三大资源被隔离在不同的异构的虚拟化平台中，现有的微服务技术应用至企业内部存在技术架构不统一、无法支持优先同集群访问且交易耗时长的问题。

此外，现有技术中，微服务在注册时，使用自身的网络地址信息发起注册，一般均是利用本机的IP+端口信息，而在各自云管理平台的内部，默认容器的IP对外是不可访问的。为实现异构云平台间的微服务打通，常用的做法有：

(1)修改网络方案，将容器中的网络与外部虚拟机上网络打通，需要对底层基础IaaS网络进行配置；

(2)在Kubernetes中，一般是通过创建Service，使用NodePort的方式，将端口固定住，即可解决端口的问题；因为需要对外提供服务，采用ClusterIP无法实现，可通过Kubernetes的downward api动态传入主机的IP或者传固定loadbalancer的地址，例如所有node之外有一个F5。

然而上述两种方法都是妥协办法，无法实现“云原生”，也不方便后续扩展与服务网格的集成。因目前异构云管理平台上部署的微服务没有一套统一微服务平台规范，导致不同云管理平台上部署的微服务之间，无法实现统一的服务注册与发现、统一的服务调用、统一的服务治理等功能，进而无法适配多种异构云的成熟微服务治理方案。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种面向异构云的云原生微服务平台，该微服务平台仅采用一套微服务平台，技术架构统一，在满足云原生及可扩展的前提上，能够实现统一的服务注册与发现、统一的服务调用、统一的服务治理功能，并支持优先同集群访问，显著缩短交易耗时。

本发明的目的可以通过以下技术方案来实现：

一种面向异构云的云原生微服务平台，包括：

微服务应用子系统，基于Kubernetes云管理平台、CloudFoundry云管理平台和IaaS云虚拟机，结合微服务平台基础支撑子系统和ServiceMesh技术构建异构云的云原生微服务适配操作；

微服务平台基础支撑子系统，与微服务应用子系统进行交互，接收微服务应用子系统的注册和订阅请求，并为管理用户端提供信息配置、信息监控以及服务管理渠道；

管理用户端，通过ServiceMesh管理和维护Kubernetes云管平台部署的微服务应用，实现微服务基本组件功能管理；

服务调用方，从微服务平台基础支撑子系统的注册中心订阅全量的服务列表信息，根据负载均衡算法，选择一个服务提供方发送请求。

所述微服务平台基础支撑子系统包括：

注册中心，用以接收来自不同云管理平台的云容器及IaaS云虚拟机部署微服务的注册请求，并实现各云容器的微应用的注册或订阅；

配置中心，用以通过不同云管理平台的云容器拉取或更新配置项，管理用户端与配置中心交互执行配置变更；

监控中心，用以对微服务应用子系统的运行进行数据采集及监控；

服务治理中心，用以对Kubernetes云管理平台、CloudFoundry云管理平台执行服务治理，包括各云管理平台对应的云容器发布的接口管理、接口上线、下线、请求关系维护和限流熔断策略维护。

所述微服务应用子系统中，所述IaaS云虚拟机部署微服务，并根据主机IP+端口的方式对不同云管理平台的微服务进行访问。所述Kubernetes云管理平台设有K8S云容器，所述CloudFoundry云管理平台设有PCF云容器，所述IaaS云虚拟机的微服务与PCF云容器的微服务之间、所述PCF云容器的微服务与所述K8S云容器的微服务之间均通过Invoke实现调用。

对于CloudFoundry云管理平台，所述IaaS云虚拟机采用在宿主机上指定PCF云容器端口映射的方式，外部节点根据PCF云容器所在宿主机的IP和宿主机分配的映射到容器的端口，访问PCF云容器中部署的微应用；在微应用启动时，通过获取宿主机的IP及宿主机分配至PCF云容器的端口注册到注册中心，外部应用从注册中心拉取到提供者列表实现直接访问。

对于Kubernetes云管理平台，采用Kubernetes内部虚拟化网络方式，K8S云容器内部直接访问外部节点，外部节点通过Ingress与Kubernetes集群进行交互，集群内通过Service方式进行交互。

K8S内部容器部署微应用启动时，获取微应用对外可访问的Ingress地址，注册到注册中心，K8S集群外应用从注册中心拉取订阅列表为ingress地址，直接根据ingress地址访问K8S集群内部的服务；K8S集群内应用订阅到的ingress地址后，将ingress地址信息转换为service后，缓存至本地提供者列表中。

当注册中心接收到所述IaaS云虚拟机和所述PCF云容器的注册申请时，将接收到的IP+端口作为一个提供者，并对该注册请求赋予初始权重。

当注册中心接收到K8S云容器的注册请求时，将接收到的对外可访问的Ingress作为一个提供者，并对该注册请求赋予初始权重，当同一个Ingress具有新的容器启动时，初始权重增加一倍。

本发明微服务平台实现适配异构云管平台部署微服务的具体步骤包括：

1)注册中心接收来自IaaS云虚拟机的注册请求，并赋予初始权重w；

2)注册中心接收来自CloudFoundry云管理平台的多个PCF云容器的注册请求，并赋予初始权重w；

3)注册中心接收来自K8S云容器发送的注册请求，并赋予权重值w*n，n为K8S云容器的个数；

4)服务消费者通过调用代理从注册中心订阅提供者的信息，利用权重负载均衡策略，将请求平均的分发到每个容器中；若服务消费者在K8S云容器内部，则将订阅到的K8S云容器的提供者的Ingress转换为K8S云容器内部的Service的地址，在服务调用时，通过service优先访问同集群内的服务提供者；

5)在服务治理中心，根据每条提供者记录执行包括禁用、上线、下线、降级和修改权重在内的管理操作。

本发明提供的面向异构云的云原生微服务平台，相较于现有技术至少包括如下有益效果：

1)本发明根据不同云管理平台的特性，采用不同的网络策略：对于CloudFoundry，采用在宿主机上指定容器端口映射的方式，直接根据宿主机IP+容器映射端口访问容器内部服务，可有效减少由于经过Router代理流量造成的通信消耗，降低交易耗时；对于Kubernetes，采用Ingress+Service的方式，即集群外访问集群内部通过Ingress，集群内部服务间的调用通过Service的方式，在保留云原生特性及扩展能力基础上，同时打通了集群外部与集群内部统一服务注册与发现的技术方案，并在进行服务调用时，根据调用方的所在集群，实现了优先选择同集群内部的服务提供方。

2)本发明采用一套微服务平台，通过微服务应用子系统、与微服务应用子系统交互的微服务平台基础支撑子系统以及与微服务平台基础支撑子系统对接的主机的设计，并通过打通IaaS云虚拟机、CloudFoundry云管理平台及Kubernetes云管理平台部署的微服务的服务注册与发现、服务调用及服务治理三个方面，在满足云原生及可扩展的前提上，能够实现统一的服务注册与发现、统一的服务调用、统一的服务治理功能。

3)IaaS云虚拟机和CloudFoundry中的每个容器作为一个提供者，赋予初始权重；K8S中的容器启动时Ingress标记为在线提供者，赋予初始权重，当同一个Ingress，有新的容器启动时，初始权重增加一倍；本发明按此设计逻辑，在进行服务调用时，可以将请求平均负载到每个容器中，并能够实现动态调整。

附图说明

图1为实施例中微服务平台基本功能及原理示意图；

图2为实施例中面向异构云的云原生微服务平台的结构框架图；

图3为实施例中面向异构云的云原生微服务平台实现适配异构云管理平台部署微服务的流程示意图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

实施例

本发明涉及一种面向异构云的云原生微服务平台，该平台将微服务平台与云容器进行结合，实现统一的服务注册与发现、统一的服务调用、统一的服务治理等。

微服务平台基本功能及原理如图1所示，其中LB(Load Balancing)为负载均衡集群，负载均衡集群中有一个分发器(调度器)，将其称之为Director，它处在多台服务器的上面，分发器根据内部锁定义的规则或调度方式从下面的服务器群中选择一个以此来响应客户端发送的请求。现有微服务平台通常只能采用一种集群访问方式。

微服务基本功能包括：服务注册与发现、服务的负载均衡、服务容错、认证鉴权、分布式配置中心、监控告警、服务治理(管理)、服务调用链等相关功能，本发明重点从服务注册与发现、服务调用、服务治理(管理)3个方面阐述对异构云的适配实现。

1、服务注册与发现：

服务发现的原则包括(1)各个微服务在启动时，将自己的网络地址等信息注册到服务发现组件，服务发现组件记录并存储这些信息；(2)服务消费者可以从服务发现组件中查询到服务提供者的网络地址，并使用该地址来远程调用服务提供者的接口；(3)各个微服务与服务发现组件间使用一定的机制(如：心跳)通信；(4)服务发现组件长时间无法与某微服务实例通信，就会注销该实例；(5)当某个微服务网络地址发生变更(例如实例增减或IP端口发生变化等)时，会重新注册到服务发现组件。

2、服务调用：

在微服务架构中，服务之间的相互调用一般是通过HTTP协议来实现，网络往往具有不可靠性，为了保证服务的高可用，服务单元往往是集群化部署，这样就涉及到服务的负载均衡；在微服务架构中一般在调用方集成了负载均衡的功能，即客户端负载均衡，客户端通过采取某种策略选择一个服务端，从而尽可能减少对于服务端的压力，达到负载均衡的效果。

3、服务治理：服务治理包括每个微服务发布的接口管理、接口上线、下线、请求关系维护、限流熔断策略维护等。

微服务在注册时，会使用自己的网络地址信息发起注册，一般都是用本机的IP+端口信息，而在各自云管理平台内部，默认容器的IP对外是不可访问的。为实现异构云平台间的微服务打通，常用的做法有：

(1)修改网络方案，将容器中的网络与外部虚拟机上网络打通，需要对底层基础IaaS网络进行配置；

(2)在Kubernetes中，一般是通过创建Service，使用NodePort的方式，把端口固定住，这样端口的问题就解决了，因为需要对外提供服务，用ClusterIP肯定是不行的，可以通过Kubernetes的downward api动态传入主机的IP或者传固定loadbalancer的地址，例如所有node之外有一个F5；

不管哪种方法，都是一种妥协的办法，很不“云原生”，也不方便后续扩展与服务网格的集成。

基于上述微服务的适配方式，本发明提供的面向异构云的云原生微服务平台如图2所示，该微服务平台包括LB、微服务应用子系统、与微服务应用子系统交互的微服务平台基础支撑子系统、与微服务平台基础支撑子系统对接的管理用户端以及服务调用方。

微服务平台基础支撑子系统，与微服务应用子系统进行交互，接收微服务应用子系统的注册和订阅请求，并为管理用户端提供信息配置、信息监控以及服务管理渠道。微服务应用子系统，基于Kubernetes云管理平台、CloudFoundry云管理平台和IaaS云虚拟机，结合微服务平台基础支撑子系统和ServiceMesh技术构建异构云的云原生微服务适配操作。

微服务应用子系统包括IaaS云虚拟机、Kubernetes云管理平台、CloudFoundry云管理平台，Kubernetes云管理平台设有K8S(kubernetes)云容器，CloudFoundry云管理平台设有PCF(Pivotal Cloud Foundry)云容器；IaaS云虚拟机的微服务与PCF云容器的微服务之间、PCF云容器的微服务和K8S云容器的微服务之间均通过Invoke实现调用。

微服务平台基础支撑子系统包括注册中心、配置中心、监控中心和治理中心，注册中心用于接收来自不同云容器及IaaS云虚拟机部署微服务的注册请求，实现各云容器的微应用的注册或订阅；配置中心用于通过PCF云容器或K8S云容器拉取或更新配置项，管理用户端与配置中心交互执行配置变更；监控中心用于对微服务应用子系统的运行进行数据采集及监控；治理中心用于对PCF云容器、K8S云容器执行服务治理，包括各云容器发布的接口管理、接口上线、下线、请求关系维护、限流熔断策略维护等。

管理用户端，通过ServiceMesh管理和维护Kubernetes云管平台部署的微服务应用，实现微服务基本组件功能管理。具体用于对微服务平台基础支撑子系统发起请求，实现访问，并通过Service Mesh与微服务应用子系统之间对接，实现微服务基本组件功能管理。Service Mesh为服务网格，是用于处理服务和服务之间通信的基础设施层，负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在本发明中，管理用户端通过ServiceMesh执行对微服务应用子系统的服务治理(管理)功能。作为优选方案，管理用户端通过Isito服务网格执行对微服务应用子系统的服务治理功能。

服务调用方，从微服务平台基础支撑子系统的注册中心订阅全量的服务列表信息，根据负载均衡算法，选择一个服务提供方发送请求。

上述原生微服务平台着重从打通IaaS云虚拟机、CloudFoundry云管理平台及Kubernetes云管理平台部署的微服务的服务注册与发现、服务调用及服务治理3个方面，具体地：

本申请中，IaaS云虚拟机部署微服务，根据主机IP+端口进行访问；对于CloudFoundry中的网络方案，采用在宿主机上指定容器端口映射的方式，即外部节点可以根据容器所在宿主机的IP和宿主机分配的映射到容器的端口，访问容器中部署的微应用，基于这个前提，在微应用启动时，获取到宿主机的IP，和宿主机分配给容器的端口注册到注册中心。这样外部应用从注册中心拉取到提供者列表可以直接访问。

本申请中，对于Kubernetes，为了能复用Kubernetes中service的能力、符合云原生标准及后续对ServiceMesh能力的扩展，采用Kubernetes内部虚拟化网络的方案，即容器内部可以访问外部节点，外部节点无法直接访问Kubernetes集群内的容器，外部节点需通过Ingress与Kubernetes集群进行交互，集群内则通过Service的方式进行交互，基于这个前提，K8S内部容器部署微应用启动时，获取到微应用对外可访问的Ingress地址，注册到注册中心。K8S集群外应用，从注册中心拉取到订阅列表为ingress地址，可以直接根据ingress地址访问K8S集群内部的服务；K8S集群内应用订阅到的ingress地址后，根据一定的规则，将ingress地址信息转换为service后，缓存在本地提供者列表中。这样就可以在保留原有注册中心功能和K8S的Service能力基础上，满足集群内外间服务的相互调用。

进一步地，本发明中，注册中心接收来自不同云管理平台及IaaS云虚拟机部署微服务的注册请求，对于IaaS云虚拟机和CloudFoundry容器的注册申请，将接收到的IP+端口作为一个提供者；对于K8S云容器的注册请求，将接收到的对外可访问的Ingress作为一个提供者(Ingress是K8S的资源对象，用于对外暴露服务，该资源对象定义了不同主机名(域名)及URL和对应后端Service(K8S Service)的绑定，根据不同的路径路由http和https流量，即Ingress就是为进入集群的请求提供路由规则的集合)。IaaS云虚拟机和CloudFoundry中的每个容器作为一个提供者，赋予初始权重；K8S中的容器启动时Ingress标记为在线提供者，赋予初始权重，当同一个Ingress，有新的容器启动时，初始权重增加一倍。根据这个逻辑，在进行服务调用时，可以将请求平均负载到每个容器中，并支持动态调整。

在本实施例中，设定初始权重为100，则本发明面向异构云的云原生微服务平台实现适配异构云管理平台部署微服务的具体步骤如图3所示，包括：

(1)注册中心接收来自IaaS云虚拟机的注册请求(IP+端口)，并赋予初始权重100；

(2)注册中心接收来自多个CloudFoundry容器的注册请求(宿主机IP+宿主机映射容器端口)，并赋予初始权重100；

(3)注册中心接收来自K8S云容器发送的注册请求(对外可访问的Ingress地址)，并赋予权重值100*n(n表示K8S云容器的个数)；

(4)服务消费者通过调用代理从注册中心订阅提供者的信息，利用权重负载均衡策略，将请求平均的分发到每个容器中。若服务消费者在K8S内部，则将订阅到的K8S提供者的Ingress根据一定规则转换为K8S内部Service的地址，在服务调用时，通过service优先访问同集群内的服务提供者。

(5)在服务治理中心，可以根据每条提供者记录进行禁用、上线、下线、降级、修改权重等操作。

本发明根据不同云管理平台的特性，采用不同的网络策略；对于CloudFoundry，采用在宿主机上指定容器端口映射的方式，直接根据宿主机IP+容器映射端口访问容器内部服务，减少由于经过Router代理流量造成的通信消耗；对于Kubernetes，采用Ingress+Service的方式，即集群外访问集群内部通过Ingress，集群内部服务间的调用通过Service的方式，在保留云原生特性及扩展能力基础上，同时打通集群外部与集群内部统一服务注册与发现的技术方案，并在进行服务调用时，根据调用方的所在集群，优先选择同集群内部的服务提供方。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的工作人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (6)

1.一种面向异构云的云原生微服务平台，其特征在于，包括：

微服务应用子系统，基于Kubernetes云管理平台、CloudFoundry云管理平台和IaaS云虚拟机，结合微服务平台基础支撑子系统和ServiceMesh技术构建异构云的云原生微服务适配操作；

微服务平台基础支撑子系统，与微服务应用子系统进行交互，接收微服务应用子系统的注册和订阅请求，并为管理用户端提供信息配置、信息监控以及服务管理渠道；

管理用户端，通过ServiceMesh管理和维护Kubernetes云管平台部署的微服务应用，实现微服务基本组件功能管理；

服务调用方，从微服务平台基础支撑子系统的注册中心订阅全量的服务列表信息，根据负载均衡算法，选择一个服务提供方发送请求；

所述微服务平台基础支撑子系统包括：

注册中心，用以接收来自不同云管理平台的云容器及IaaS云虚拟机部署微服务的注册请求，并实现各云容器的微应用的注册或订阅；

配置中心，用以通过不同云管理平台的云容器拉取或更新配置项，管理用户端与配置中心交互执行配置变更；

监控中心，用以对微服务应用子系统的运行进行数据采集及监控；

服务治理中心，用以对Kubernetes云管理平台、CloudFoundry云管理平台执行服务治理，包括各云管理平台对应的云容器发布的接口管理、接口上线、下线、请求关系维护和限流熔断策略维护；

所述微服务应用子系统中，所述IaaS云虚拟机部署微服务，并根据主机IP+端口的方式对不同云管理平台的微服务进行访问；

所述Kubernetes云管理平台设有K8S云容器，所述CloudFoundry云管理平台设有PCF云容器，所述IaaS云虚拟机的微服务与PCF云容器的微服务之间、所述PCF云容器的微服务与所述K8S云容器的微服务之间均通过Invoke实现调用；

对于CloudFoundry云管理平台，所述IaaS云虚拟机采用在宿主机上指定PCF云容器端口映射的方式，外部节点根据PCF云容器所在宿主机的IP和宿主机分配的映射到容器的端口，访问PCF云容器中部署的微应用；在微应用启动时，通过获取宿主机的IP及宿主机分配至PCF云容器的端口注册到注册中心，外部应用从注册中心拉取到提供者列表实现直接访问。

2.根据权利要求1所述的面向异构云的云原生微服务平台，其特征在于，对于Kubernetes云管理平台，采用Kubernetes内部虚拟化网络方式，K8S云容器内部直接访问外部节点，外部节点通过Ingress与Kubernetes集群进行交互，集群内通过Service方式进行交互。

3.根据权利要求2所述的面向异构云的云原生微服务平台，其特征在于，K8S内部容器部署微应用启动时，获取微应用对外可访问的Ingress地址，注册到注册中心，K8S集群外应用从注册中心拉取订阅列表为ingress地址，直接根据ingress地址访问K8S集群内部的服务；K8S集群内应用订阅到的ingress地址后，将ingress地址信息转换为service后，缓存至本地提供者列表中。

4.根据权利要求3所述的面向异构云的云原生微服务平台，其特征在于，当注册中心接收到所述IaaS云虚拟机和所述PCF云容器的注册申请时，将接收到的IP+端口作为一个提供者，并对该注册请求赋予初始权重。

5.根据权利要求4所述的面向异构云的云原生微服务平台，其特征在于，当注册中心接收到K8S云容器的注册请求时，将接收到的对外可访问的Ingress作为一个提供者，并对该注册请求赋予初始权重，当同一个Ingress具有新的容器启动时，初始权重增加一倍。

6.根据权利要求5所述的面向异构云的云原生微服务平台，其特征在于，该微服务平台实现适配异构云管平台部署微服务的具体步骤包括：

1)注册中心接收来自IaaS云虚拟机的注册请求，并赋予初始权重w；

2)注册中心接收来自CloudFoundry云管理平台的多个PCF云容器的注册请求，并赋予初始权重w；

3)注册中心接收来自K8S云容器发送的注册请求，并赋予权重值w*n，n为K8S云容器的个数；

4)服务消费者通过调用代理从注册中心订阅提供者的信息，利用权重负载均衡策略，将请求平均的分发到每个容器中；若服务消费者在K8S云容器内部，则将订阅到的K8S云容器的提供者的Ingress转换为K8S云容器内部的Service的地址，在服务调用时，通过service优先访问同集群内的服务提供者；

5)在服务治理中心，根据每条提供者记录执行包括禁用、上线、下线、降级和修改权重在内的管理操作。