CN116112569B - 微服务调度方法及管理*** - Google Patents

Abstract

本发明提供了一种微服务调度方法及微服务调度管理***，微服务调度方法包括：基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系；建立注册中心与服务端之间的心跳检测，以通过心跳检测探测出异常的服务端，以基于集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系。通过本发明，避免了每个微服务的所有服务端均与所有集群均保持长连接，降低了服务端基于集群的资源信息变动时因通知组件执行通知事件所导致的资源开销，简化了微服务的拓扑结构，确保了微服务对用户发起的服务请求具有实时性。

Description

微服务调度方法及管理***

技术领域

本发明涉及微服务技术领域，尤其涉及一种微服务调度方法及管理***。

背景技术

Kubernetes为美国谷歌公司开发的基于开源的容器集群管理***。云原生涉及微服务、DevOps及容器化；其中，现有技术中的微服务主要有三种角色：提供者、消费者(即，服务客户端)和注册中心。提供者用于提供服务，启动时根据服务发布文件中的配置的信息，向注册中心注册自身服务，并向注册中心定期发送心跳汇报存活状态。提供者将其注册到注册中心，以注册服务并发布服务。消费者执行订阅操作以订阅所需服务并获取提供者提供的信息。注册中心作为服务实例的存储仓库，是提供者与消费者执行服务交互的中介机构。

参图1所示，云原生场景中在资源变化情况时，服务端40可以通过其部署的Inform组件Informer机制与基于Kubernetes构建的集群30建立长连接。服务端40与通知组件31建立长连接，当资源发生变动时，通知组件(即，Informer)通知Handler组件41，通知组件31监听ETCD组件32中所保存的资源信息。当集群30后端所挂载的资源池(未示出)中的资源发生新增、修改或者删除时，资源信息发生变更并通知Handler组件41基于Informer机制通知服务端40执行自定义处理。

参图2所示，在多云场景中，逻辑上相互隔离的机房(即，机房100与机房200)中分别部署微服务1与微服务2。机房100与机房200或者更多的机房逻辑上独立形成一个云服务。微服务1部署注册中心10、服务端-1、服务端-2及多个集群(即，集群21与集群22)，微服务2部署注册中心20、服务端-3、服务端-4及多个集群(即，集群23与集群24)。服务端-1～服务端-4需要与集群21～集群24分别建立长连接，以监测各个集群的资源信息的变动。首先，在现在技术中，如果微服务1～微服务2均与集群21～集群24建立长连接的话，四个服务端与四个集群之间形成16条长连接，由此基于该拓扑结构会导致微服务的开销过大，并导致微服务基于各个集群后端资源信息变动所导致的微服务重启时间过长，从而严重地影响了基于分布式架构的微服务响应用户的响应性能。当机房中的集群数量日益庞大后，会进一步加剧前述问题。其次，由于集群21～集群24均与微服务1～微服务2建立长连接，而为了提高微服务性能通常将多个微服务(至少两个)部署成分布式架构。当某个机房中的某(些)个集群的资源信息发生变动时，需要通过集群的通知组件31频繁地向微服务中所部署的服务端的Handler组件41执行通知，由此存在资源消耗过大的问题，并且存在通知行为的无序性及非必要性的技术问题，当集群在扩缩容过程中，集群与服务端之间所存在的海量的通知行为将进一步消耗物理节点的计算资源与网络资源。最后，在跨机房或者跨数据中心(均视为跨物理节点)场景中，服务端与集群之间所建立的长连接会进一步无序且无谓的消耗网络资源，这对于提供网络服务的微服务(例如，在线小程序或者网络游戏)而言，进一步导致了用户体验的下降，并严重影响微服务性能。

有鉴于此，有必要对现有技术中的逻辑上相互隔离的机房等逻辑上相互隔离的物理节点间所组建的基于分布式架构的微服务基于集群资源信息变动时的通知方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示微服务调度方法及管理***，用以解决前述技术问题，并尤其地旨在解决单个物理节点内或者跨物理节点间形成多云场景中，降低分布式架构的微服务基于集群资源信息变动时的通知的资源开销并简化微服务的拓扑结构，并确保微服务对用户发起的服务请求具有实时性。

为实现上述目的之一，本发明提供了一种微服务调度方法，包括：

基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系；

建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系。

作为本发明的进一步改进，包括：

基于分片算法对分别部署于逻辑上相互独立的两个或者两个以上物理节点中的集群划分以形成若干集群分组，并在每个物理节点中单独建立服务端与集群分组所含集群的映射关系；

建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系。

作为本发明的进一步改进，所述基于分片算法对部署于物理节点中的集群划分以形成若干集群分组包括：

在服务端首次连接集群时将集群的唯一标识与服务端的HostIP进行绑定，并在与集群基于HostIP建立映射关系的服务端之间基于所述唯一标识将集群划分以形成若干集群分组，以将所述集群关联至唯一且剩余正常的服务端。

作为本发明的进一步改进，所述服务端的HostIP保存于微服务数据库，所述集群基于IP建立映射关系包括：

自所述微服务数据库获取服务端的HostIP，通过集群部署的通知组件基于Inform机制通知服务端部署的Handler组件，以建立映射关系并将所述映射关系保存至所述注册中心。

作为本发明的进一步改进，在将所述集群关联至唯一且剩余正常的服务端之后，还包括：

更新集群分组所含集群与服务端之间的映射关系，刷新服务端与集群分组所含集群之间的映射关系，以将刷新后的映射关系替换微服务数据库在先所保存的映射关系。

作为本发明的进一步改进，还包括：

获取包含服务端HostIP的配置文件，以根据所述配置文件确定服务端的唯一标识。

作为本发明的进一步改进，所述分片算法包括：

确定服务端数量n；

确定待建立映射关系的唯一标识数S；

由所述注册中心分别对各服务端获取服务端的资源规格，并确定各服务端的资源权重Q，以根据所述资源权重Q确定各服务端与集群之间所建立的包含唯一标识数的连接数T，所述连接数其中，Q_i为任一服务端的资源权重，所述连接数T向上取整。

作为本发明的进一步改进，还包括：

监听多个物理节点所属集群的资源信息变动，通过所述长连接将变动后的资源信息对微服务数据库所保存的历史资源信息进行更新，由服务端形成推送至云管理平台的前端页面中并予以可视化展示，并在多个物理节点所部署的注册中心之间建立RPC连接。

作为本发明的进一步改进，还包括：

由所述服务端实时且主动地向云管理平台的前端页面推送实时统计页面并予以可视化展示，所述实时统计页面用于可视化展示单一集群中的资源信息，所述前端页面部署于逻辑上独立于部署所述注册中心的前端微服务。

作为本发明的进一步改进，还包括：

响应于用户和/或管理员发起的可视化展示请求，以由所述服务端被动地向所述前端页面推送所述非实时统计页面，并由所述服务端实时且主动地向云管理平台的前端页面推送实时统计页面并予以可视化展示，以在所述前端页面中可视化展示所述实时统计页面与非实时统计页面，所述非实时统计页面用以可视化展示集群列表。

基于相同发明思想，本发明还提供了一种微服务调度管理***，对部署于物理节点中的微服务进行调度管理，所述物理节点中部署若干集群及若干服务端；

所述微服务调度管理***包括：注册中心，所述注册中心部署运行分片算法的分片单元，以及微服务数据库；

所述分片单元基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系，建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系。

与现有技术相比，本发明的有益效果是：

在本申请中，分片算法对部署于物理节点中的集群划分以形成若干集群分组，以当心跳检测探测出异常的服务端后，可基于集群分组将异常的服务端对应的集群关联至剩余正常的服务端并保持剩余正常的服务端在先形成的映射关系，从而避免了每个微服务中的各服务端与所有集群均保持长连接，避免了无序且数量庞大的长连接对物理节点及微服务的资源消耗，并同时降低了服务端基于集群的资源信息变动时因通知组件执行通知事件所导致的资源开销，简化微服务的拓扑结构，确保了微服务对用户发起的服务请求具有实时性。

附图说明

图1为现有技术中服务端与基于Kubernetes构建的Kubernetes集群建立长连接以监听Kubernetes集群的集群资源信息变动的示意图；

图2为现有技术中逻辑上相互隔离的两个机房的两微服务中部署的四个服务端与多个集群之间建立长连接的拓扑图；

图3为本发明微服务调度方法的整体流程图；

图4为集群动态管理流程图；

图5为本发明所揭示的分片算法的示意图；

图6为启动微服务的详细流程图；

图7为单个机房中场景中执行本发明微服务调度方法的详细拓扑图，且图7中示出了本发明微服务调度管理***的一种具体实例；

图8为逻辑上相互独立的两个机房中场景中执行本发明微服务调度方法的详细拓扑图，且图8中示出了本发明微服务调度管理***的另一种具体实例；

图9为两个逻辑上相互隔离的机房之间分别部署微服务并执行本发明微服务调度方法的详细拓扑图，其中，两个机房均省略示出微服务数据库及部署前端页面的云管理平台，且图9中示出了本发明微服务调度管理***的又一种具体实例；

图10为实时统计页面的一种具体实例；

图11为控制节点统一纳管两个机房的示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

简要而言，本发明所揭示的微服务调度方法及实现并运行该微服务调度方法的微服务调度管理***旨在对单个物理节点或者通过网络连接(例如，RCP或者HTTP)的多个物理节点之间所建立的多个服务或者组成分布式架构的微服务中的任意一个微服务中的一个或者多个服务端与一个或者多个物理节点中的集群之间在任意状态中基于集群分组仅建立数量有限且可靠的长连接，避免所有的微服务中的服务端与所有集群之间建立数量众多且无序的长连接，以高效可靠地管理物理节点中所部署的集群，并在集群因弹性伸缩导致集群的资源信息发生变动时，将微服务中所部署的用以响应用户发起的访问请求所依赖的服务端所对应的集群关联至剩余正常的服务端(即，健康服务端)，从而确保了服务端或者微服务对用户访问请求的响应，以确保能够取得良好的用户体验。分布式架构的微服务可形成于单一物理节点中，也可形成于相互通信的两个或者更多的物理节点之间。

需要说明的是，例如，图7中的集群21～集群26均可采用图1中的拓扑架构。示例性地，集群21～集群26可为Kubernetes集群(以下或简称“集群”)，且集群可由物理服务器等物理装置部署形成。图7中的微服务数据库3独立于集群21～集群26所分别部署的ETCD组件32。图7中的机房100与图9中的机房200均为物理节点的一种下位概念，例如，物理节点还可选自数据中心。机房100与机房200中至少部署一个微服务(例如，图9中机房100部署的微服务1与机房200部署的微服务2)，以在一个物理节点中或者多个物理节点之间形成分布式微服务架构。

参图1、图7与图8所示，本实施例所揭示的一种微服务调度方法，包括如下步骤S1至步骤2。该微服务调度方法运行于一个物理节点(即，机房100的上位概念)的技术场景中。机房100支持前端与后端分离的技术场景中(例如，参图7所示)，或者，也可支持前端(即，前端页面110)与后端集成在一个微服务的技术场景中(例如，参图8所示的微服务1a)，并优选为图7所示出的拓扑架构。本申请中的前端是指包含前端页面的并能够为用户或者管理员提供可视化操作的web界面，后端是指包含云管理平台、微服务、集群、微服务数据库及redis缓存等后台逻辑***。前端页面110部署于云管理平台(Cloud ManagementPlatform,CMP)中。云管理平台可纳管一个或者多个机房，以对机房100和/或机房200中的物理资源或者由物理资源通过虚拟化技术所形成的虚拟资源并挂载至集群的资源执行统一调度与管理。前述资源包括但不限于物理CPU资源，虚拟CPU资源，物理存储资源，虚拟存储资源，物理内存资源，虚拟内存资源，带宽资源，虚拟内网IP资源，用户命名空间或者插件等。通过Kubectl命名直接对集群的资源执行创建操作或者删除操作。

步骤S1、基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系。分片算法用于预先确定物理节点中提供服务的服务端与集群之间所形成的连接数。

示例性地，如图7所示，机房100包含六个集群(即，集群21～集群26)，当然机房100也可包含更多的集群，多个集群通过分片算法将多个集群划分形成与服务端数量匹配的多个集群分组，服务端只能与其所属集群分组中的集群建立长连接并禁止与其他集群分组中的集群建立跨集群分组的长连接，从而避免了建立过多的长连接，从而简化微服务及微服务中的服务端与集群之间建立长连接的拓扑架构，并确保每个集群分组中至少分配一个集群并优选为至少分配两个集群，以满足性能冗余需求，且每个集群分组中所含集群数量可以相同也可以不相同。示例性地，微服务1(或者微服务2)是指由一个或者多个服务端所组成的微服务架构。

示例性地，配合图1所示，在图7中，将六个集群划分为三个集群分组，每个集群分组包含两个集群。分片算法通过注册中心10所部署的分片单元103予以执行。位于后端的全部集群组成容器集群。每个集群参图1所示均独立包含一个ETCD组件32与通知组件31，服务端-1～服务端-3的HostIP分别为10.10.10.11、10.10.10.12、10.10.10.13。鉴于ETCD组件32与通知组件31为现有技术，故在本实施例中省略展开阐述。

步骤S2、建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至正常的服务端，并保持剩余正常的服务端在先形成的映射关系。

具体而言，在本申请中，任何集群分组中的任何一个集群在任何时间点中只与一个服务端建立长连接，优选为建立长连接的集群所在的集群分组中包含一个、两个或者两个以上的集群，以后续因为建立长连接的服务端出现宕机等异常情况时，能够将异常的服务端对应的集群关联至正常的服务端，从而动态地建立服务端与集群之间的映射关系并实现长连接的切换操作，从而降低了整个物理节点中服务端与集群之间既能够保证服务端运行应用或者业务的需求，又能够极大地降低长连接数量，以简化拓扑结构，实现了对容器集群所含集群的动态管理。

微服务在启动时，需要将微服务及其微服务所含的服务端的网络地址等信息注册到注册中心10，并可进一步将注册信息保存至微服务数据库3中。注册中心10保存服务注册表(未示出)，服务注册表记载微服务包含的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于微服务的注册与注销。同时，注册中心10执行对服务端的心跳检测，以确定心跳线是否在正常。

具体而言，在本实施例中，基于分片算法对集群划分以形成若干集群分组包括：在服务端首次连接集群时将集群的唯一标识与服务端的HostIP进行绑定，并在与集群基于HostIP建立映射关系的服务端之间基于唯一标识将集群划分以形成若干集群分组，以将集群关联至唯一且剩余正常的服务端。

当对多个集群基于分片算法执行划分以形成若干集群分组后，图7中微服务数据库3保存集群分组中的一个或者多个集群仅与对应服务端之间所建立的映射关系，且同一个集群分组中的每一个集群均与服务端之间长连接，而三个服务端(即，服务端-1～服务端-3)均与注册中心10之间建立心跳检测，以通过注册中心10监测服务端是否发生宕机、挂起、超时等异常情形，并在某个服务端异常时，以将出现异常的服务端对应的集群关联至剩余正常的服务端。具体而言，图7中集群21的IP地址为10.10.10.11，集群22的IP地址为10.10.10.12，集群23的IP地址为10.10.10.13，集群24的IP地址为10.10.10.14，集群25的IP地址为10.10.10.15，集群26的IP地址为10.10.10.16。集群21与集群22被作为一个集群分组并与服务端-1建立长连接，集群23与集群24被作为一个集群分组并与服务端-2建立长连接，集群25与集群26被作为一个集群分组并与服务端-3建立长连接。服务端-1的HostIP为10.10.10.11，服务端-2的HostIP为10.10.10.12，服务端-2的HostIP为10.10.10.13。由此所建立的集群与服务端的HostIP之间的映射关系为：将集群21的IP地址与集群22的IP地址与服务端-1的HostIP(即，10.10.10.11)建立第一个映射关系，将集群23的IP地址与集群24的IP地址与服务端-2的HostIP(即，10.10.10.12)建立第二个映射关系，将集群25的IP地址与集群26的IP地址与服务端-3的HostIP(即，10.10.10.13)建立第三个映射关系。前述三个映射关系均被保存至微服务数据库3，且在本实施例中，随着某个集群的资源信息发生变动或者用户发起的访问请求所依赖的某个微服务所关联的集群所形成的资源不适配用户的访问请求时或者响应用户请求的服务端出现异常时，将异常的服务端对应的集群关联至剩余正常的服务端，并重新建立前述映射关系，并将重新建立的映射关系对微服务数据库3中在先保存的映射关系予以更新或者修改。

参图9所示，本申请还揭示了微服务调度方法的一种合理变形，该微服务调度方法应用于多个相互物理上相互隔离，并可用基于RPC连接等通信方式建立连接的物理集群。

微服务调度方法包括如下步骤：

首先，基于分片算法对分别部署于逻辑上相互独立的两个或者两个以上物理节点中的集群划分以形成若干集群分组，并在每个物理节点中单独建立服务端与集群分组所含集群的映射关系；

然后，建立注册中心10(或者注册中心20)与服务端(即，服务端-1～服务端-3，或者，服务端-5～服务端-7)之间的心跳检测，以通过心跳检测探测出异常的服务端，以基于集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端与集群分组所含集群的映射关系。

如图9所示，在多个物理节点所部署的注册中心(即，注册中心10与注册中心20)之间建立RPC连接，即，在机房100与机房200中分别部署服务端-1～服务端-3与服务端-5～服务端-7，注册中心10与注册中心20之间建立RPC连接(即，远程过程调用)。机房100中部署微服务1，机房200中部署微服务2，且可选地，还可在任意一个机房中部署两个或者更多的微服务，以形成分布式微服务架构，每个机房中均可参图7所示分别独立部署一个微服务数据库3，或者同时部署一个微服务数据库3以实现横向分布式事务处理，或者在第三方云平台或者管理集群(例如，图11中的控制节点50)中独立部署一个总的微服务数据库(未示出)，以通过该总的微服务数据库保存各个机房中服务端与集群分组中所含集群之间的映射关系并管理分布于各个机房中的微服务数据库3。可选地，前述总的微服务数据库可部署于图11中的控制节点50中。基于RPC连接可实现两个或者多个注册中心(例如，注册中心10与注册中心20)之间执行相互通信，以在物理上隔离的两个或者多个机房之间相互通信，以执行分布式事务管理。

在图9中，机房100中至少部署一个微服务1及服务端-1～服务端-3，服务端-1～服务端-3的HostIP分别为10.10.10.11、10.10.10.12、10.10.10.13，集群201与集群202被作为一个集群分组并与服务端-1建立长连接，集群203与集群204被作为一个集群分组并与服务端-2建立长连接，集群205与集群206被作为一个集群分组并与服务端-3建立长连接；机房200中至少部署一个微服务2及服务端-5～服务端-7，服务端-5～服务端-7的HostIP分别为11.10.10.11、11.10.10.12、11.10.10.13，集群207与集群208被作为一个集群分组并与服务端-5建立长连接，集群209与集群210被作为一个集群分组并与服务端-6建立长连接，集群211与集群212被作为一个集群分组并与服务端-7建立长连接。用户或者管理员可通过部署于机房100的微服务1中所部署的前端页面(图9未示出，并可参考图7所示)查看实时统计页面101或者非实时统计页面102，或者，通过部署于机房200的微服务2中所部署的前端页面(图9未示出，并可参考图7所示)查看实时统计页面101或者非实时统计页面102。

作为图9的另一种合理变形，参图11所示，还可独立设置一个统一纳管机房100与机房200的控制节点50，并将诸如图7中的前端微服务4部署于控制节点50，控制节点50通过RPC或者HTTP分别连接机房100的注册中心10与机房200的注册中心20。控制节点50可物理服务器部署形式。服务端在启动及初始化过程中所需的配置文件可由管理员通过控制节点50以批量形式向各个机房中所部署的微服务予以自动下发，或者，配置文件通过用户或者管理员以手动形式予以下发，用户分别访问机房100或者机房200所分别部署的微服务中的服务端。

结合图1所示，服务端40(图9中服务端1～服务端9的上位概念)的HostIP保存于微服务数据库3，集群基于IP建立映射关系包括：自微服务数据库3获取服务端的HostIP，通过集群部署的通知组件31基于Inform机制通知服务端40部署的Handler组件41，以建立映射关系并将映射关系保存至注册中心10(或者注册中心20)。示例性地，前述映射关系在保存至注册中心10后，将进一步保存至微服务数据库3中，从而在某个服务端出现异常并重新建立映射关系以形成更新后的映射关系，并将更新后的映射关系替换注册中心10在先保存的映射关系。

在本实施例中，在将集群关联至唯一且剩余正常的服务端之后，还包括：更新集群分组所含集群与服务端之间的映射关系，刷新服务端与集群分组所含集群之间的映射关系，以将刷新后的映射关系替换微服务数据库3在先所保存的映射关系。参图7所示，在本实施例中，具体为基于分片算法所形成的三个集群分组，例如，第一集群分组包含集群21与集群22，且集群21与集群22与服务端-1建立映射关系。第二个集群分组包含集群23与集群24，且集群23与集群24与服务端-2建立映射关系。第三个集群分组包含集群25与集群26，且集群25与集群26与服务端-3建立映射关系。集群21～集群26均属于图1中集群40的一种实例，服务端-1～服务端-6也均属于图1中服务端30的一种实例。

参图4所示，申请人示出了在一个机房所形成的任意一个微服务中的四个服务端与位于后端的十二个集群建立映射关系的一种范例性实例。本实例场景中，机房中部署服务端-1～服务端-4，共四个服务端。参图6所示，机房100首先部署微服务1，并包括如下子步骤。获取服务端的HostIP，自微服务数据库3中获取集群与服务端的HostIP的映射关系，启动通知机制以在服务端与集群之间建立长连接，并上报映射关系至注册中心10(或者注册中心20)。

首先，判断检测服务端-1～服务端-4与注册中心10之间所分别形成的心跳，以判断心跳线是否正常。如果检测到某个心跳线异常，则判定位于该异常心跳线上的服务端出现了异常。若心跳线正常(即，Y)，则跳转结束；若心跳线异常(即，N)，则执行重试超时机制，以确保在预设时间段(例如，10分钟)内不作任何处理，并只有在超过预设时间段内跳转执行下一个判断逻辑。重试超时机制根据下文所揭示的配置文件中timeout配置项(例如，600：10分钟)及retrytime配置项(3：3次)而定。心跳线是否正常与否被注册中心10所感知。超过预设时间段(即，timeout)及重试次数(即，retrytime)后，判断服务端是否恢复正常，若是(即，服务端已经恢复正常)，则跳转结束；若否(即，服务端依然不正常)，注册中心10向服务端(即，服务端-1～服务端-4中的任意一个服务端)发送一次中止服务信号，以使得被中止的服务端上所运行的服务或者应用被停止，被停止服务的服务端的数据及配置依然保留，以在后续恢复正常后依然可以确保服务或者应用可以被运行。然后，获取异常服务端的HostIP所对应的集群的唯一标识。根据分片算法选择适配的服务端。在选择适配的服务端的过程中是指将出现异常的服务端对应的集群关联至剩余正常的服务端，例如，如果图7中的服务端-2出现了异常，则将服务端-2在先关联的集群，即，集群23与集群24关联至服务端1和/或服务端-3，至于将集群23与集群24关联至哪一个剩余且正常的服务端，则根据分片算法所确定的连接数进行确定，并防止服务端-1及服务端-3超过基于分片算法所预先确定的连接数，从而确保被重新建立映射关系的集群23与集群24能够被调度至合理的服务端并予以管理，并避免造成对服务端-1及服务端-3中运行的应用或者程序无法满足用户需求的不良情形。

例如，参图7所示，如果服务端-2发生异常且在出现异常前服务端-2与集群23、集群24建立了长连接，那么在检测到服务端-2与注册中心10之间的心跳线出现异常时且超过重试时间(每次10分钟)及重试次数(3次)。需要说明的是重试时间与重试次数可根据服务端-2中运行的业务或者应用的性质或者用户需求予以延长或者缩短，则将已经发生异常的服务端-2与集群23、集群24之间的长连接予以断开。获取异常服务端-2的HostIP所对应的集群的唯一标识(即，集群23、集群24的唯一标识)，然后，注册中心10根据分片算法重新计算服务端-1与服务端-3的连接数，在此过程中服务端-1与服务端-3的连接数将发生变化，以通过服务端-1或者服务端-3承担服务端-2在发生异常前与位于后端的集群所建立的连接数，以确定服务端-1及服务端-3中所出现的异常服务端-2中正在运行的程序或者应用所需资源的一个或者多个集群(即，集群23与集群24)。例如，如果集群23满足服务或者应用所需要的资源规格，则将服务端-1与集群23重新建立长连接并重新建立映射关系，以通过集群23中的资源支持服务或者应用的正常运行。然后，注册中心10根据已经执行的分片算法将获取到最新的连接数，将服务端-1与服务端-3(即，剩余正常的服务端)与集群21～集群26(其中，包含服务端-1在先已经建立映射关系的若干集群，例如，集群21～集群22)，以计算服务端-1与服务端-3所形成的新的连接数，以根据新的连接数形成新的映射关系，并基于新的映射关系在服务端-1及服务端-3与集群21～集群26之间重新建立映射关系，以将服务端-2中运行的应用或者程序转移到服务端-1或者服务端3中运行。从而在集群21～集群26中的一个或者多个集群与服务端-1(或者服务端-3)之间建立长连接，从而将适配的服务端与异常服务端所对应的集群(即，集群23与集群24)的集群的唯一标识重新建立映射关系，并将重新形成的新的映射关系写入微服务数据库3中，并对微服务数据库3在服务端-2发生异常前所保存的映射关系进行更新。最后，结束。在将服务端-2对应的集群(即，集群23与集群24)关联至服务端-1和/或服务端-3的过程中，剩余正常的服务端(即，服务端-1与服务端-3)在先形成的映射关系保持不变。因此无论在将集群23与集群24关联至服务端-1，还是关联至服务端-3，或者集群23关联至服务端-1而集群24关联至服务端-3的过程中，服务端-1与集群21～集群22之间以及服务端-3与集群25～集群26之间在先建立的映射关系(即，在服务端-2发生异常前)保持不变，以确保服务端-1与集群21～集群22之间所建立的长连接以及服务端-3与集群25～集群26之间所建立的长连接状态不发生变化，以确保集群22～集群23被关联至剩余正常的服务端的过程中避免对剩余正常的服务端所运行的应用或者程序造成影响，同时也避免降低机房100中剩余正常的服务端与其建立长连接的集群之间的拓扑结构发生变动，从而避免了网络资源的无谓消耗。

本实施例所揭示的一种微服务调度方法还包括：获取包含服务端HostIP的配置文件，以根据配置文件确定服务端的唯一标识。前述配置文件包含了服务端(例如，图7中的服务端-1)在微服务1中启动时的配置参数，配置文件包括服务端-1的HostIP、服务端-1的端口号、日志记录目录、ETCD组件访问超时策略配置信息、消息中间件(例如，rabbitmq)等。

服务端-2的配置文件可由注册中心10下发，申请人示出示出配置文件的一种具体实例，其中，双斜杠后为代码注释。

run_mode:debug//开发模式(例如，debug、release或者test模式)；

name:kuber//服务端-2的名称；

listen_address::11468//服务端-2的端口号；

intra_address:10.10.10.12//服务端-2的HostIP；

logs:/var/log/haihe/kuber/business-kuber.log//日志记录目录；

timeout:600//注册中心心跳检测超时时间；

retrytime:3//注册中心超时检测重试次数；

db://微服务数据库；

addr:178.106.2.23//微服务数据库的内网地址；

port:3306//微服务数据库端口号；

name:xu_kuber//微服务数据库名称；

user:root//微服务数据库账号；

password:cloudsuite@Passw0rd//微服务数据库登录密码；

redis://连接机房100中全部微服务的redis缓存；

endpoint:178.106.2.23:6379//redis缓存的内网地址；

db:1//组成redis缓存的一个数据库的编号；

timeout:10000//redis缓存的超时时间(单位：秒)；

readTimeout:10000//redis缓存的读取超时时间(单位：秒)；

writeTimeout:10000//redis缓存的写入超时时间(单位：秒)。

结合图5与图7所示，本实施例所揭示的分片算法包括如下步骤。

确定服务端数量n，确定过程由注册中心10执行。

确定待建立映射关系的唯一标识数S；

由注册中心10分别对各服务端获取服务端的资源规格，并确定各服务端的资源权重Q，以根据资源权重Q确定各服务端与集群之间所建立的包含唯一标识数的连接数T，连接数其中，Q_i为任一服务端的资源权重，连接数T向上取整。参图5所示，当一个微服务中运行四个服务端时，资源权重Q的下标i＝4。同时，每个服务端中的资源规格视服务端中所运行的程序或者应用而定，并可根据需要建立与符合服务端中所运行的程序或者应用所需资源的一个或者多个集群。

假设，微服务1管理的由服务端所形成的服务实例数量为M，集群数量为N，则在对N个集群进行分片前所形成的长连接数量为M*N个，而执行分片算法之后，每个服务端只需要与N/M个集群保持长连接，因此相对于现有技术而言，只需要M倍分之一数量的长连接即可，从而极大地降低了服务端与集群之间所建立的长连接的数量，从而避免了每个微服务中的所有服务端与所有集群均保持长连接，从而降低了服务端基于集群的资源信息变动时因通知组件31执行通知事件所导致的资源开销，简化了微服务的拓扑结构，且由于图7中的服务端-1～服务端-3分别只需要与两个集群建立长连接，由此显著地降低了服务端-1～服务端-3的开销。同时，本实施例所揭示的微服务调度方法还能够降低整个物理节点中的资源消耗，尤其是网络资源消耗将有M倍的下降，这对于提供网络服务的微服务(例如，在线小程序或者网络游戏)而言的技术场景中，有效地避免了用户体验的下降，从而确定了微服务的响应用户发起的访问请求的服务性能。当物理节点所部署的微服务以及组成微服务的服务端与集群数量非常庞大时，本申请所揭示的微服务调度方法所实现的简化微服务的拓扑结构并确保微服务对用户发起的服务请求具有实时性的技术效果将更为显著。

前述资源规格是指CPU规格、内存规格、存储规格或者带宽规格。参图5所示，服务端-1需要的资源规格为CPU2核，内存4G，服务端-2需要的资源规格为CPU6核，内存12G，服务端-3需要的资源规格为CPU4核，内存8G，服务端-4需要的资源规格为CPU4核，内存8G。假设机房100中部署了十二个集群，每一个集群均具有唯一的唯一标识。此时，服务端-1的资源权重Q_i为1，服务端-2的资源权重Q_i为3，服务端-3的资源权重Q_i为2，服务端-4的资源权重Q_i为2。因此，服务端-1需要分配的连接数T＝12*(1/(1+3+2+2))＝1.5，连接数T向上取整，得到服务端-1的连接数T＝2，服务端-2～服务端-4的连接数T分别为4、3、3。从而使得服务端-1的唯一标识数S＝2并具有两个唯一标识，服务端-2的唯一标识数S＝4并具有四个唯一标识，服务端-3的唯一标识数S＝3并具有三个唯一标识，服务端-4的唯一标识数S＝3并具有三个唯一标识。

参图7所示，微服务调度方法还包括：监听多个物理节点(机房100或者机房200的上位概念)所属集群的资源信息变动，通过长连接将变动后的资源信息对微服务数据库3所保存的历史资源信息进行更新，由服务端形成推送至云管理平台的前端页面110中并予以可视化展示。对多个物理节点执行监听的动作可由服务端-1～服务端-3中的任何一个服务端执行，并在监听到物理节点所属的集群(例如，集群21)的资源信息发生变动时，将变动后的当前资源信息自动推送到前端页面110中，从被用户或者管理员以可视化形式予以展现。

可选地，参图8所示，云管理平台的前端页面110可部署于微服务1a中，且此时前端与后端不分离；或者，参图7所示，由服务端实时且主动地向云管理平台的前端页面110推送实时统计页面101并予以可视化展示，实时统计页面101用于以表单形式可视化展示单一集群中的资源信息，前端页面110部署于逻辑上独立于部署注册中心10的前端微服务4。参图10所示，申请人示出了实时统计页面101的一种具体实例。例如，服务端-1与两个集群建立了长连接，实时统计页面101包含了名称、集群健康状态、归属项目、集群版本、架构、可用区、初始化状态、应用数量、容器组数量及操作。图7中的服务端-1～服务端-3均可独立且主动地向云管理平台的前端页面110推送实时统计页面101并予以可视化展示。云管理平台的前端页面110可部署于前端微服务4中，且此时前端与后端相互分离，且为最优先的实施方式。前端页面110形成用户界面与数据访问层，数据访问层基于RPC或者HTTP与位于后端的微服务1(或者微服务2)建立连接。

在图7中，非实时统计页面102通过用户或者管理员向前端页面110发起请求而发生。前端页面110可向任意一个服务端(即，服务端-1～服务端-3)发起获取非实时统计页面102的请求，并由服务端-3向前端页面110返回非实时统计页面102，并在前端微服务4中作可视化展示。当然，以被动方式向前端页面110推送非实时统计页面102并作可视化展示是一种可选方式，并可被省略。以被动方式向云管理平台的前端页面110返回非实时统计页面102的事件也可发生于服务端-1～服务端-3中的任何一个服务端。因此，通过实时统计页面101和/或非实时统计页面102，可便于用户或者管理员感知到任何一个物理节点中的任何一个集群所具有的资源状态，并实现资源状态数据进行实时的统计与更新，并为后续的对集群所挂载的资源执行资源创建或者资源调度提高了准确的依据。同时，当机房所部署的微服务执行重启或者在机房中添加微服务时，由于建立的长连接的数量相对于现有技术大为降低，因此降低微服务的资源开销与计算开销，从而缩短了微服务因执行重启或者创建过程的时间。

微服务调度方法还包括：响应于用户和/或管理员发起的可视化展示请求，以由服务端被动地向前端页面110推送非实时统计页面102，并由服务端实时且主动地向云管理平台的前端页面110推送实时统计页面101并予以可视化展示，以在前端页面110中可视化展示实时统计页面101与非实时统计页面102，非实时统计页面102用以可视化展示集群列表。集群列表中包含位于同一集群分组中所包含的两个独立的集群，也可为位于不同集群分组中所包含的两个独立集群。

本申请所揭示前述微服务调度方法的各种实施例及变形实施例所含揭示的技术方案可在同一物理节点(例如，机房100)内部建立本地连接或者在建立RPC连接的多个物理节点(例如，机房100与机房200)之间实现分布式连接，从而有助于提高数据吞吐量，降低服务端的响应延迟并缩短往返时间(Round-Trip Time，RTT)，以实现通过提高网络质量提升服务水平协议的技术效果。同时，在本申请中，当某个机房中的某(些)个集群的资源信息发生变动时，不需要通过集群的通知组件31频繁地向微服务中所部署的服务端的Handler组件41执行通知，从而进一步消除了资源消耗过大的技术问题，并解决了通知组件31执行通知行为的无序性及非必要性的技术问题。

基于前述实施例所揭示的微服务调度方法的各实施例，参图7所示，本申请还揭示了一种微服务调度管理***，对部署于物理节点中的微服务进行调度管理，物理节点中部署若干集群(即，集群21～集群26)及若干服务端(即，服务端-1～服务端-3)。微服务调度管理***包括：注册中心10，注册中心10部署运行分片算法的分片单元103，以及微服务数据库3。分片单元103基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系，建立注册中心10与服务端之间的心跳检测，以通过心跳检测探测出异常的服务端，以基于集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系。

同理所述，参图8所示，本申请还揭示了微服务调度管理***的一种变形实施例。在本实施例中，前端页面110与注册中心10及三个服务端均部署于微服务1a中。同理所述，参图9所示，微服务调度管理***同时部署于两个物理节点中，且两个物理节点之间通过RPC建立连接。同时，微服务1的注册中心10与微服务2的注册中心20均部署一个运行分片算法的分片单元103，以独立地对分片单元103所属机房中的集群进行划分以形成若干集群分组。

本实施例所揭示的微服务调度管理***与前述各实施例所揭示的微服务调度方法中所含相同方案，参前述实施例所述，在此不再赘述。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.一种微服务调度方法，其特征在于，包括：

基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系；

建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端在先形成的映射关系；

所述基于分片算法对部署于物理节点中的集群划分以形成若干集群分组包括：在服务端首次连接集群时将集群的唯一标识与服务端的HostIP进行绑定，并在与集群基于HostIP建立映射关系的服务端之间基于所述唯一标识将集群划分以形成若干集群分组，以将所述集群关联至唯一且剩余正常的服务端。

2.根据权利要求1所述的微服务调度方法，其特征在于，包括：

基于分片算法对分别部署于逻辑上相互独立的两个或者两个以上物理节点中的集群划分以形成若干集群分组，并在每个物理节点中单独建立服务端与集群分组所含集群的映射关系；

建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端与集群分组所含集群的映射关系。

3.根据权利要求1所述的微服务调度方法，其特征在于，所述服务端的HostIP保存于微服务数据库，所述集群基于IP建立映射关系包括：

自所述微服务数据库获取服务端的HostIP，通过集群部署的通知组件基于Inform机制通知服务端部署的Handler组件，以建立映射关系并将所述映射关系保存至所述注册中心。

4.根据权利要求1所述的微服务调度方法，其特征在于，在将所述集群关联至唯一且剩余正常的服务端之后，还包括：

更新集群分组所含集群与服务端之间的映射关系，刷新服务端与集群分组所含集群之间的映射关系，以将刷新后的映射关系替换微服务数据库在先所保存的映射关系。

5.根据权利要求1所述的微服务调度方法，其特征在于，还包括：

获取包含服务端HostIP的配置文件，以根据所述配置文件确定服务端的唯一标识。

6.根据权利要求2至5中任一项所述的微服务调度方法，其特征在于，

所述分片算法包括：

确定服务端数量n；

确定待建立映射关系的唯一标识数S；

由所述注册中心分别对各服务端获取服务端的资源规格，并确定各服务端的资源权重Q，以根据所述资源权重Q确定各服务端与集群之间所建立的包含唯一标识数的连接数T，所述连接数其中，Q_i为任一服务端的资源权重，所述连接数T向上取整。

7.根据权利要求6所述的微服务调度方法，其特征在于，还包括：

监听多个物理节点所属集群的资源信息变动，通过长连接将变动后的资源信息对微服务数据库所保存的历史资源信息进行更新，由服务端形成推送至云管理平台的前端页面中并予以可视化展示，并在多个物理节点所部署的注册中心之间建立RPC连接。

8.根据权利要求7所述的微服务调度方法，其特征在于，还包括：

由所述服务端实时且主动地向云管理平台的前端页面推送实时统计页面并予以可视化展示，所述实时统计页面用于可视化展示单一集群中的资源信息，所述前端页面部署于逻辑上独立于部署所述注册中心的前端微服务。

9.根据权利要求7所述的微服务调度方法，其特征在于，还包括：

响应于用户和/或管理员发起的可视化展示请求，以由所述服务端被动地向所述前端页面推送非实时统计页面，并由所述服务端实时且主动地向云管理平台的前端页面推送实时统计页面并予以可视化展示，以在所述前端页面中可视化展示所述实时统计页面与非实时统计页面，所述非实时统计页面用以可视化展示集群列表。

10.一种微服务调度管理***，对部署于物理节点中的微服务进行调度管理，所述物理节点中部署若干集群及若干服务端；

其特征在于，所述微服务调度管理***包括：注册中心，所述注册中心部署运行分片算法的分片单元，以及微服务数据库；

所述分片单元基于分片算法对部署于物理节点中的集群划分以形成若干集群分组，并建立服务端与集群分组所含集群的映射关系，建立注册中心与服务端之间的心跳检测，以通过所述心跳检测探测出异常的服务端，以基于所述集群分组将异常的服务端对应的集群关联至剩余正常的服务端，并保持剩余正常的服务端与集群分组所含集群的映射关系；

所述基于分片算法对部署于物理节点中的集群划分以形成若干集群分组包括：在服务端首次连接集群时将集群的唯一标识与服务端的HostIP进行绑定，并在与集群基于HostIP建立映射关系的服务端之间基于所述唯一标识将集群划分以形成若干集群分组，以将所述集群关联至唯一且剩余正常的服务端。