支持服务集群弹性伸缩的微服务架构及其服务调用方法

技术领域

本公开涉及微服务技术领域，尤其涉及一种支持服务集群弹性伸缩的微服务架构及其服务调用方法。

背景技术

随着云计算和虚拟化技术的不断成熟，软件应用的规模和复杂度不断增加，对于应对不断变化的工作负载和用户需求提出了更高的要求。弹性伸缩技术可以根据实际需求动态地调整系统资源的分配，使软件应用能够快速适应不同负载水平和变化的用户需求。通过弹性伸缩，可以实现资源的高效利用和成本的优化，提升系统的可伸缩性和可靠性。

相关技术中，虚拟化技术通过在不同虚拟机之间进行隔离，保证了应用程序的安全性。然后，容器化技术逐渐成熟，它提供了更轻量级和灵活的隔离特性，使得容器可以共享操作系统。容器化技术对于大规模集群管理提供了支持，可以容纳数千个节点。发明人发现相关技术中存在以下技术问题：并不是所有应用都能运行在容器中，并且集群的架构复杂，管理成本也较高，对基础设施有较多限制，如果服务节点中存在无法运行在容器中的应用，容器化技术将无法提供有效的支持。虽然容器化技术为集群弹性伸缩和调度提供了支持，但它的架构复杂，需要构建多个组件来实现集群，以及对平台进行管理，部署成本较高。因此，如何在降低使用成本的前提下提升服务调度的弹性伸缩能力和通用能力，成为需要解决的技术问题。

发明内容

为克服相关技术中存在的问题，本公开提供一种支持服务集群弹性伸缩的微服务架构及其服务调用方法。

根据本公开实施例的第一方面，提供一种支持服务集群弹性伸缩的微服务架构。上述微服务架构包括：服务集群、注册中心和调度中心。上述服务集群包含多个服务节点，每个服务节点包含代理桩，上述代理桩用于管理所在节点内的服务并将所在节点内的可用服务向注册中心进行注册；上述代理桩中的目标代理桩还用于响应调度中心对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例，并将上述目标服务实例的处理结果转发给调度中心；上述可用服务包含容器化服务和/或非容器化服务。上述注册中心用于与上述代理桩进行通信，实现上述多个服务节点内的可用服务的注册和管理。上述调度中心用于接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由。

根据本公开实施例的第二方面，提供一种支持服务集群弹性伸缩的微服务架构。上述微服务架构包括：服务集群和注册中心。上述服务集群包含多个服务节点，每个服务节点包含代理桩和调度模块，上述代理桩用于管理所在节点内的服务并将所在节点内的可用服务向注册中心进行注册，上述代理桩中的目标代理桩还用于响应第一调度模块对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例，并将上述目标服务实例的处理结果转发给上述第一调度模块；上述可用服务包含容器化服务和/或非容器化服务；上述第一调度模块用于接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由；上述第一调度模块与上述目标代理桩位于同一个服务节点或不同的服务节点。上述注册中心用于与上述代理桩进行数据交互，实现上述多个服务节点内的可用服务的注册和管理。

在一些实施例中，上述第一方面或第二方面提供的微服务架构中，上述预设调度策略包括以下策略中的一种：第一调度策略、第二调度策略和第三调度策略。上述第一调度策略用于表示根据服务调用请求与可用节点之间的分配对应频率进行请求调度，使得各节点之间分配均匀。上述第二调度策略用于表示根据服务调用请求与可用节点的可用服务之间的分配对应频率进行请求调度，使得各可用服务之间分配均匀。上述第三调度策略用于表示根据可用节点的运行状态进行请求调度，使得资源利用率较低的可用节点相较于资源利用率较高的可用节点优先被调度。

在一些实施例中，上述第一方面或第二方面提供的微服务架构中，上述预设调度策略包括以下至少一种：轮询策略、加权轮询策略、平滑加权轮询策略、最少连接策略。

在一些实施例中，上述第一方面或第二方面提供的微服务架构中，上述代理桩包括：服务代理模块、服务管理模块和资源管理模块。上述服务代理模块用于管理和路由所在节点上的服务，并将其提供给调度中心或第一调度模块，以便调度中心或第一调度模块将服务提供给服务调用对象。上述服务管理模块用于服务的部署和管理，通过配置文件或API接口来管理所在节点上的服务，包括服务的部署、启动、停止和更新。上述资源管理模块用于实时监控节点的资源使用状态。上述服务管理模块还用于根据上述资源使用状态对所在节点上的服务运行情况进行调整，以优化资源分配。

在一些实施例中，上述第一方面或第二方面提供的微服务架构中，上述服务调用请求包括：用于请求调用仿真服务的第一服务调用请求；上述可用服务节点包含多个仿真服务节点。在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置相同的情况下，调度中心或第一调度模块依序调度每个仿真服务节点中的GPU资源作为目标服务实例，直到所有仿真服务节点都被分配到一次仿真任务。在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置不同的情况下，调度中心或第一调度模块根据各仿真服务节点的GPU资源配置分配各自的权重，并根据上述权重确定目标仿真节点的目标GPU资源作为目标服务实例，使得各个仿真服务节点的GPU资源负载均衡。

在一些实施例中，上述第二方面提供的微服务架构中，在包含多个第一调度模块的情况下，将上述服务调用请求按照时间顺序轮流分配给各个第一调度模块；或者，根据服务调用请求的所需资源和请求发起位置，将上述服务调用请求划分至与上述所需资源相匹配且空间传输距离较近的第一调度模块。

在一些实施例中，上述第一方面或第二方面提供的微服务架构中，上述目标服务实例在裸机上运行或在容器内运行。

根据本公开实施例的第三方面，提供一种基于第一方面所示的微服务架构的服务调用方法。上述服务调用方法包括：上述调度中心接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由，基于上述网络路由向目标代理桩发起对目标服务实例的调用；上述目标代理桩响应调度中心对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例；上述目标代理桩接收来自上述目标服务实例反馈的处理结果，并将上述处理结果转发给上述调度中心；上述调度中心将上述处理结果转发给上述服务调用对象。

根据本公开实施例的第四方面，提供一种基于第二方面所示的微服务架构的服务调用方法。上述服务调用方法包括：上述第一调度模块接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由，基于上述网络路由向目标代理桩发起对目标服务实例的调用；上述目标代理桩响应上述第一调度模块对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例；上述目标代理桩接收来自上述目标服务实例反馈的处理结果，并将上述处理结果转发给上述第一调度模块；上述第一调度模块将上述处理结果转发给上述服务调用对象。

本公开的实施例提供的技术方案可以包括以下有益效果：

在包含服务集群、注册中心和调度中心的微服务架构中，通过在服务集群的每个服务节点中设置代理桩，基于代理桩能够管理所在节点内的服务向注册中心的注册以及响应调度中心对目标服务实例的调用并进行路由中转；注册中心通过与代理桩通信实现对多个服务节点内的可用服务的注册和管理；调度中心在接收到服务调用对象的服务调用请求后，能够根据预设调度策略从注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由；这一过程中支持容器化服务和/或非容器化服务的注册和对外提供服务，能够根据服务调用请求适配进行目标服务实例和对应目标服务节点的灵活调整，实现服务集群的弹性伸缩管理。

本公开实施例提供的技术方案可以包括以下有益效果：

在包含服务集群和注册中心的微服务架构中，通过在服务集群的每个服务节点中设置代理桩和调度模块，这种分布式调度机制将调度能力分散到多个服务节点，使得该微服务架构具备高度的容错性，即使某个服务节点出现故障或者失效，整个系统仍然能够通过其他正常服务节点中调度模块的调度保证对外提供正常的服务和系统运行；同时，分布式调度还能够充分利用多个服务节点的并行处理能力，提升系统的性能和资源利用效率，从而降低整体的等待时间和资源浪费。在每个服务节点中，基于代理桩能够管理所在节点内的服务向注册中心的注册以及响应第一调度模块对目标服务实例的调用进行路由中转；注册中心通过与代理桩通信实现对多个服务节点内的可用服务的注册和管理；第一调度模块在接收到服务调用对象的服务调用请求后，能够根据预设调度策略从注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由；这一过程中支持容器化服务和/或非容器化服务的注册和对外提供服务，能够根据服务调用请求适配进行目标服务实例和对应目标服务节点的灵活调整，实现服务集群的弹性伸缩管理。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

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

图1是根据一示例性实施例示出的支持服务集群弹性伸缩的微服务架构的框图。

图2是根据一示例性实施例示出的代理桩的框图。

图3是根据另一示例性实施例示出的支持服务集群弹性伸缩的微服务架构的框图。

具体实施方式

下面将结合附图详细地对示例性实施例进行描述说明。

应当指出，相关实施例及附图仅为描述说明本公开所提供的示例性实施例，而非本公开的全部实施例，也不应理解本公开受相关示例性实施例的限制。

应当指出，本公开中所用术语“第一”、“第二”等仅用于区别不同步骤、设备或模块等。相关术语既不代表任何特定技术含义，也不表示它们之间的顺序或者相互依存关系。

应当指出，本公开中所用术语“一个”、“多个”、“至少一个”的修饰是示意性而非限制性的。除非在上下文另有明确指出，否则应该理解为“一个或多个”。

应当指出，本公开中所用术语“和/或”，用于描述关联对象之间的关联关系，一般表示至少存在三种关联关系。例如，A和/或B，至少可以表示：单独存在A，同时存在A和B，单独存在B这三种关联关系。

应当指出，本公开的方法实施例中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。除非特别说明，本公开的范围不受相关实施例中步骤的描述顺序限制。

需要说明的是，本公开中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。

技术用语说明

弹性伸缩(Elastic Scaling)：是指根据实际需求动态调整系统资源的分配，以适应不断变化的工作负载和用户需求。通过弹性伸缩，系统可以根据负载情况自动添加或移除资源或服务，以提高系统的性能和可用性。

虚拟化(Virtualization)：指通过软件技术将一台物理计算机划分为多个虚拟计算机的过程。虚拟化技术可以将计算、存储和网络资源等进行虚拟化，将其提供给不同的应用程序和用户。通过虚拟化，可以提高资源的利用率和灵活性，降低硬件成本。

容器化(Containerization)：指将应用程序及其所有依赖项打包到一个或多个独立的容器中的过程。容器化可以将应用程序和其依赖项与底层的操作系统和硬件隔离开来，使其能够在不同的环境中运行。容器化技术可以提供更轻量级的部署和管理方式，并提高应用程序的可移植性和可扩展性。

容器化服务：是指打包为容器的应用作为向外部应用程序提供服务的对象。

服务集群(Cluster)：指由多个服务节点组成的分布式系统，用于向外部应用程序或需求端提供计算、存储等服务。集群中的服务节点可以通过网络相互通信和协作，共同完成复杂的计算任务。上述服务节点可以是物理机器，也可以是虚拟机或容器。

代理桩(Proxy Stub)：是一种代理模式，通过将一个对象(代理对象)提供给客户端，代替原始对象来进行操作。代理桩可以在不改变客户端代码的情况下，通过代理对象对原始对象进行控制和管理。

宿主机(Host Machine)：指在虚拟化或容器化环境中，运行虚拟机或容器的物理计算机。宿主机负责提供计算、存储和网络资源，并管理虚拟机或容器的生命周期。宿主机通常运行着一个虚拟化或容器化管理程序，用于管理和调度虚拟机或容器的创建、销毁和资源分配。

非容器化服务：是指一些无法通过容器化实现的应用，这些应用向外提供服务；例如这些应用需要与底层操作系统和硬件进行直接交互，无法通过容器化来实现，这些应用可能需要运行在物理服务器上，或者使用虚拟化技术来进行部署。

一种示例性微服务架构及其服务调用方法

图1是根据一示例性实施例示出的支持服务集群弹性伸缩的微服务架构的框图。

参照图1所示，在一种实施例中，支持服务集群弹性伸缩的微服务架构100包括：服务集群110、注册中心120和调度中心130。

上述服务集群110包含多个服务节点，例如图1中示例的节点1～节点K，每个节点内包含一个或多个服务，例如节点1包含服务11、服务12、……、服务1M，节点2包含服务21、服务22、……、服务2N，节点K包含服务K1、服务K2、……、服务KT。

参照图1所示，每个服务节点包含代理桩，上述代理桩用于管理所在节点内的服务并将所在节点内的可用服务向注册中心进行注册。例如节点1中包含代理桩101，节点2中包含代理桩102，……，节点K中包含代理桩10K。

上述代理桩中的目标代理桩还用于响应调度中心130对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例，并将上述目标服务实例的处理结果转发给调度中心。上述可用服务包含容器化服务和/或非容器化服务。例如参照图1所示，采用点划线椭圆示意目标代理桩，采用虚线框示意目标服务实例，目标服务实例为服务22，位于上述节点1～节点K中的节点2中。通过节点2中的代理桩102响应于调度中心130的调用，将针对服务22(作为目标服务实例的一种示例)的服务实例调用请求转发给服务22，并通过代理桩102将服务22的处理结果转发给调度中心130。

上述注册中心120用于与上述代理桩(包含代理桩101、代理桩102、……、代理桩10K等)进行通信，实现上述多个服务节点内的可用服务的注册和管理。

上述调度中心130用于接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心120所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由。

在一些实施例中，目标服务实例在裸机上运行或在容器内运行。其中，基于REST(Representational State Transfer，资源表现层状态转化)API(API是指应用程序编程接口，REST API被广泛应用于Web服务的设计和开发，提供了一种灵活、可扩展和易于集成的方式来访问和操作远程资源)实现代理桩对外的服务暴露，再依托操作系统的命令启动裸机服务或者容器化服务。代理桩向注册中心注册的信息中，包含服务类型、服务地址、服务状态等内容。本公开的实施例中提出的裸机部署，是对比云原生技术来说的，在云原生技术中，为了管理的规范化和一致性，将所有的服务均封装到容器里面；因此本公开实施例提供了一种针对非容器化服务支持裸机部署的微服务架构，支持在裸机上进行对应服务实例的部署和运行。

图2是根据一示例性实施例示出的代理桩的框图。

参照图2所示，每个服务节点中的代理桩(诸如代理桩101、代理桩102、……、代理桩10K等)包括：服务代理模块210、服务管理模块220和资源管理模块230。

上述服务代理模块210用于管理和路由所在节点上的服务，并将其提供给调度中心130，以便调度中心130将服务提供给服务调用对象。服务代理模块是代理桩中的一个核心组成部分。服务代理模块210通常使用代理服务器来实现服务路由和转发功能。在一些实施例中，服务代理模块可以根据调度中心的调度策略将请求路由到合适的节点上的目标服务实例，从而实现负载均衡和故障迁移等功能。

上述服务管理模块220用于服务的部署和管理，通过配置文件或API接口来管理所在节点上的服务，包括服务的部署、启动、停止和更新。

上述资源管理模块230用于实时监控节点的资源使用状态。

上述服务管理模块220还用于根据上述资源使用状态对所在节点上的服务运行情况进行调整，以优化资源分配。上述资源包含但不限于是：CPU、GPU、内存等。例如，根据设定的资源使用限额，通过服务管理模块220对服务进行节点的重新分配，这可以确保服务能够充分利用节点的资源，并防止资源过载导致服务崩溃。

在代理桩中，节点的注册也是一个重要的功能。节点注册是指将节点加入到代理桩的管理体系中，以便代理桩能够对其进行管理和调度。服务节点可以是物理机器，也可以是虚拟机或容器。通过节点注册，代理桩可以获得节点的基本信息，并将其纳入到服务管理和资源管理的范围之内。在一些实施例中，每个节点只有一个代理桩，所谓的节点启动和节点注册过程，就是在节点上，根据该节点可提供的服务信息，在代理桩中进行配置后，启动代理桩的过程。此过程中，代理桩将节点上能向外提供的服务向注册中心120进行注册。

为了实现灵活的部署方式，代理桩支持裸机部署和容器化部署等多种部署方式。裸机部署是指直接在物理机器上运行服务实例，而容器化部署则是将服务实例打包成容器，然后在容器平台上运行。这些部署方式都可以通过代理桩来管理和分配服务实例。

通过横向扩展多个服务节点，代理桩实现无状态服务的弹性伸缩。在一种弹性扩容方式中，当服务负载增加时，代理桩可以自动地将请求路由到新增的服务节点上，从而实现服务的水平扩展。这种扩展方式可以提高系统的容错性和可用性，并充分利用服务集群中各个服务节点的计算资源。

在一些实施例中，注册中心120用于存储节点和服务的信息，并通过与代理桩之间的通信，对节点进行监测，实现服务注册和服务管理。当一个节点启动时，它会通过代理桩向注册中心注册自己的信息，包括节点的唯一标识符、IP地址、端口以及支持的服务等。注册中心将会保存这些信息，并对节点进行定时的健康检查，以确保节点的可用性。

注册中心120还负责响应调度中心130的资源调配需求。调度中心130向注册中心发送资源需求请求，例如需要一个具有一定资源配置的节点来运行某个服务。注册中心会根据已注册节点的资源情况，选择一个最符合需求的节点，并将其提供给调度中心。调度中心可以将该节点作为目标节点，将任务分配给它。

除了节点信息的注册和监测，注册中心120还可以存储和管理服务的信息。当一个服务启动时，它也会向注册中心注册自己的信息，包括服务名称、版本、支持的协议等。注册中心将会保存这些信息，并根据需求提供服务的路由信息给调度中心或其他服务消费者。

通过注册中心的使用，可以实现对节点及服务的集中管理和监控，提高系统的可用性和可扩展性。注册中心120还可以支持一些高级的功能，如负载均衡、故障恢复、服务发现等，以进一步提升代理桩的性能和可靠性。

在一些实施例中，调度中心130的核心功能是调度功能和路由功能，调度中心的服务路由，支持HTTP(超文本传输协议，是一个简单的请求-响应协议，它通常运行在TCP之上；它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应)/TCP(传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议)/UDP(用户数据报协议，UDP为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法)/WEBRTC(可通过简单的API为浏览器和移动应用程序提供实时通信(RTC)功能)等多种通信协议。

调度功能是指将服务调用对象(例如需要服务的外部应用程序)的请求分配给合适的服务实例。调度中心130根据预设调度策略，如轮询策略、权重策略、最少连接策略等，将请求分配到各个节点上的服务实例。通过合理的调度算法，可以实现负载均衡，确保服务实例的资源利用率均衡，提高系统的性能和稳定性。

在一些实施例中，上述预设调度策略包括以下策略中的一种：第一调度策略、第二调度策略和第三调度策略。

上述第一调度策略用于表示根据服务调用请求与可用节点之间的分配对应频率进行请求调度，使得各节点之间分配均匀。例如，第一调度策略为轮询策略，可用节点共有3个，分别为节点A、节点B和节点C，均匀分配各个节点被调度的频次，则可以按照服务调用请求的先后，依序调度这3个可用节点，第1个服务调用请求分配给节点A，第2个服务调用请求分配给节点B，第3个服务调用请求分配给节点C，第4个服务调用请求分配给节点A，第5个服务调用请求分配给节点B，第6个服务调用请求分配给节点C，以此类推。

上述第二调度策略用于表示根据服务调用请求与可用节点的可用服务之间的分配对应频率进行请求调度，使得各可用服务之间分配均匀。例如均匀分配可用节点中可用服务被调度的频次，节点A中具有3个可用服务，节点B中有1个可用服务，节点C中有4个可用服务；采用加权轮询策略，将节点A的权重设置为3，节点B的权重设置为1，节点C的权重设置为4，权重总和为8；在服务调用请求到来时，随机生成一个在总权重范围内的索引值或者按照时序依序生成各个索引值(1-8依序变化)，基于该索引值匹配到用于进行服务调用请求处理的目标节点。例如，服务调用请求的索引值为3，则将该服务调用请求分配给节点A；服务调用请求的索引值为6，则将该服务调用请求分配给节点C。由于可用服务对应的数量越多，所在节点被分配到的概率越大，这样实现对可用服务的均匀调度。这里也可以采用平滑加权轮询策略替换加权轮询策略，通过引入动态权重，使得调度更加均衡。

上述第三调度策略用于表示根据可用节点的运行状态进行请求调度，使得资源利用率较低的可用节点相较于资源利用率较高的可用节点优先被调度。例如，如果检测到可用节点的运行状态中显示连接数较少，说明该可用节点存在较多空闲服务和资源，可以将服务调用请求优先分配给这样的可用节点进行处理。

在一些实施例中，上述预设调度策略包括以下至少一种：轮询策略、加权轮询策略、平滑加权轮询策略、最少连接策略。

在一些实施例中，上述服务调用请求包括：用于请求调用仿真服务的第一服务调用请求；上述可用服务节点包含多个仿真服务节点。

在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置相同的情况下，上述调度中心依序调度每个仿真服务节点中的GPU资源作为目标服务实例，直到所有仿真服务节点都被分配到一次仿真任务。例如，服务集群110(也可以描述为节点池)中包含10台配置完全相同的仿真服务器，在这种情况下，可以采用轮询策略。该策略会按照顺序依次调度每个仿真服务器，直到所有仿真服务器都被分配到一次任务，然后再回到第一台仿真服务器继续循环。使用轮询策略可以确保服务请求均匀地分配到节点池中的每个仿真节点上，提供最强的服务能力的同时也能保障服务质量。

在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置不同的情况下，上述调度中心根据各仿真服务节点的GPU资源配置分配各自的权重，并根据上述权重确定目标仿真节点的目标GPU资源作为目标服务实例，使得各个仿真服务节点的GPU资源负载均衡。例如，服务集群110中包含5台具有4块GPU和5台只有1块GPU的仿真服务器，且单块GPU性能一致。对于这种情况，可以采用加权轮询或者平滑加权轮询策略。在加权轮询策略中，将4块GPU的仿真服务器的权重设置为4，1块GPU的仿真服务器的权重设置为1，然后求和所有的权重值。当服务调用请求到来时，随机生成一个在总权重范围内的索引值，并遍历之前配置的仿真服务器列表。与每个节点的权重值进行比较判断，最终选出一个仿真服务器的索引，然后返回该服务器。这样就可以保持资源的平衡，避免4块GPU的仿真服务器资源大量空闲，而单块GPU的仿真服务器资源耗尽。平滑加权轮询策略通过引入动态权重，使得调度更加均衡。

在包含服务集群、注册中心和调度中心的微服务架构100中，通过在服务集群的每个服务节点中设置代理桩，基于代理桩能够管理所在节点内的服务向注册中心的注册以及响应调度中心对目标服务实例的调用并进行路由中转；注册中心通过与代理桩通信实现对多个服务节点内的可用服务的注册和管理；调度中心在接收到服务调用对象的服务调用请求后，能够根据预设调度策略从注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由；这一过程中支持容器化服务和/或非容器化服务的注册和对外提供服务，能够根据服务调用请求适配进行目标服务实例和对应目标服务节点的灵活调整，实现服务集群的弹性伸缩管理。

参照图1中示意的序号所示，本公开的实施例还提供一种基于上述微服务架构100的服务调用方法。

上述服务调用方法包括：参照图1中①～⑤所示的流程，上述调度中心130接收服务调用对象的服务调用请求(参照图1中序号①所示)，根据预设调度策略从上述注册中心120所管理的可用服务中确定目标服务实例(参照图1中序号②-1所示)，并建立与上述目标服务实例对应的目标代理桩之间的网络路由，基于上述网络路由向目标代理桩发起对目标服务实例的调用(参照图1中序号②-2所示)；上述目标代理桩响应调度中心对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例(参照图1中序号③所示的从代理桩102指向服务22的路径)；上述目标代理桩接收来自上述目标服务实例反馈的处理结果(参照图1中序号③所示从服务22指向代理桩102的路径)，并将上述处理结果转发给上述调度中心130(参照图1中序号④所示)；上述调度中心将上述处理结果转发给上述服务调用对象(参照图1中序号⑤所示)。

通过调度中心的调度和路由功能，服务调用对象(例如各类应用程序)可以方便地访问到所需要的服务实例，无需关注具体的服务实例的地址和细节。调度中心在整个系统中起到了关键的作用，保证了服务的高效、可靠运行。同时，调度中心也可以根据注册中心提供的资源情况进行负载均衡和故障处理，提高系统的稳定性和可用性。

上述微服务架构100具有极度轻量化的特点，它对硬件资源没有特殊要求，可以在虚拟服务器或物理服务器上运行。整个系统只需要一个调度中心、一个注册中心和每个节点上的一个代理桩，对资源的需求非常低。该微服务架构100具有很强的适用性，它可以适应不同的服务部署方式，可以在裸机环境或容器化环境中运行。对于网络和存储等方面也没有特殊要求，可以与任何网络架构和存储系统兼容。这些特点使得其成为一个通用的解决方案，适用于各种不同的应用场景。它可以帮助企业节省硬件资源和部署成本，同时为应用的扩展和性能提供强大的支持。无论是小型企业还是大型企业，调度中心都能够满足其不同的需求，并提供灵活的部署和配置选项。

在一些应用场景中，由于支持非容器化服务和/或容器化服务，具有低资源需求，可以在小型软件系统中使用，例如可以将所有组件部署在一台服务器上，从而有效降低成本。适用场景包含：对节点和服务有一定的弹性伸缩要求的软件系统，尤其是受到资源和容器化部署方式限制的情况下；通过调度中心的管理，可以对节点和服务进行灵活的调度和伸缩，以满足系统的需求。无论是在资源有限的环境下，还是在容器化部署的场景中，调度中心都能帮助软件系统实现更有效的资源利用和任务分配。

另一种示例性微服务架构及其服务调用方法

图3是根据另一示例性实施例示出的支持服务集群弹性伸缩的微服务架构的框图。

参照图3所示，在另一实施例中，支持服务集群弹性伸缩的微服务架构300包括：服务集群310和注册中心320。本实施例与上一个实施例相比，差异在于，上一个实施例是基于调度中心进行调度；本实施例是将调度功能分散在各个服务节点中，实现分布式调度。这种分布式调度机制将调度能力分散到多个服务节点，使得该微服务架构具备高度的容错性，即使某个服务节点出现故障或者失效，整个系统仍然能够通过其他正常服务节点中调度模块的调度保证对外提供正常的服务和系统运行；同时，分布式调度还能够充分利用多个服务节点的并行处理能力，提升系统的性能和资源利用效率，从而降低整体的等待时间和资源浪费。在处理服务调用请求的过程中，实施调度功能的调度模块描述为第一调度模块。

参照图3所示，上述服务集群310包含多个服务节点，例如图3中示例的节点1～节点K，每个节点内包含一个或多个服务，例如节点1包含服务11、服务12、……、服务1M，节点2包含服务21、服务22、……、服务2N，节点K包含服务K1、服务K2、……、服务KT。

参照图3所示，每个服务节点包含代理桩和调度模块。上述代理桩用于管理所在节点内的服务并将所在节点内的可用服务向注册中心进行注册。例如节点1中包含代理桩301和调度模块311，节点2中包含代理桩302和调度模块312，……，节点K中包含代理桩30K和调度模块31K。

上述代理桩中的目标代理桩还用于响应第一调度模块对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例，并将上述目标服务实例的处理结果转发给上述第一调度模块。上述可用服务包含容器化服务和/或非容器化服务。例如，参照图3中点划线椭圆和虚线六边形所示，将代理桩302作为目标代理桩的示例，将调度模块311作为第一调度模块的示例，将服务22作为目标服务实例的示例。上述目标服务实例在裸机上运行或在容器内运行。

上述第一调度模块用于接收服务调用对象的服务调用请求，根据预设调度策略从上述注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由。上述第一调度模块与上述目标代理桩位于同一个服务节点或不同的服务节点。服务调用对象例如为各种应用程序。

上述注册中心用于与上述代理桩进行数据交互，实现上述多个服务节点内的可用服务的注册和管理。

在一些实施例中，上述预设调度策略包括以下策略中的一种：第一调度策略、第二调度策略和第三调度策略。上述第一调度策略用于表示根据服务调用请求与可用节点之间的分配对应频率进行请求调度，使得各节点之间分配均匀。上述第二调度策略用于表示根据服务调用请求与可用节点的可用服务之间的分配对应频率进行请求调度，使得各可用服务之间分配均匀。上述第三调度策略用于表示根据可用节点的运行状态进行请求调度，使得资源利用率较低的可用节点相较于资源利用率较高的可用节点优先被调度。

在一些实施例中，上述预设调度策略包括以下至少一种：轮询策略、加权轮询策略、平滑加权轮询策略、最少连接策略。

在一些实施例中，参照图2所示，上述代理桩(例如为代理桩301、代理桩302、代理桩30K)包括：服务代理模块210、服务管理模块220和资源管理模块230。

上述服务代理模块用于管理和路由所在节点上的服务，并将其提供给第一调度模块，以便第一调度模块将服务提供给服务调用对象。

上述服务管理模块用于服务的部署和管理，通过配置文件或API接口来管理所在节点上的服务，包括服务的部署、启动、停止和更新。上述资源管理模块用于实时监控节点的资源使用状态。

上述服务管理模块还用于根据上述资源使用状态对所在节点上的服务运行情况进行调整，以优化资源分配。

在一些实施例中，上述服务调用请求包括：用于请求调用仿真服务的第一服务调用请求；上述可用服务节点包含多个仿真服务节点。在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置相同的情况下，第一调度模块依序调度每个仿真服务节点中的GPU资源作为目标服务实例，直到所有仿真服务节点都被分配到一次仿真任务。

在上述多个仿真服务节点中每个仿真服务节点的GPU资源配置不同的情况下，第一调度模块根据各仿真服务节点的GPU资源配置分配各自的权重，并根据上述权重确定目标仿真节点的目标GPU资源作为目标服务实例，使得各个仿真服务节点的GPU资源负载均衡。

在一些实施例中，在微服务架构300中，在包含多个第一调度模块的情况下，将上述服务调用请求按照时间顺序轮流分配给各个第一调度模块；或者，根据服务调用请求的所需资源和请求发起位置，将上述服务调用请求划分至与上述所需资源相匹配且空间传输距离较近的第一调度模块。

本实施例的大部分细节与第一个实施例的相同，差异点仅在于分布式调度功能，因此其他相同内容的具体细节和示例等可以参照第一个实施例的详细描述，这里不再赘述，下面仅详细描述下分布式调度的内容。

在一些实施例中，上述第一调度模块通过以下方式得到：

由上述多个服务节点根据全部调度模块的运行状态进行选举得到上述第一调度模块；或者，

将接收到服务调用请求的服务节点内运行正常的调度模块确定为第一调度模块；或者，

在接收到服务调用请求的第一服务节点内调度模块异常的情况下，由上述第一服务节点根据其他调度模块的运行状态确定能进行服务调用请求处理的第一调度模块。

这种分布式调度机制将调度能力分散到多个服务节点，使得该微服务架构具备高度的容错性，即使某个服务节点出现故障或者失效，整个系统仍然能够通过其他正常服务节点中调度模块的调度保证对外提供正常的服务和系统运行；同时，分布式调度还能够充分利用多个服务节点的并行处理能力，提升系统的性能和资源利用效率，从而降低整体的等待时间和资源浪费，能够显著增强系统的稳定性和可扩展性。

在一些实施例中，由上述多个服务节点根据全部调度模块的运行状态进行选举得到上述第一调度模块，包括：

上述多个服务节点选举运行状态正常、网络连接正常且空闲运算资源满足设定指标的一个或多个调度模块作为第一调度模块；

其中，在包含多个第一调度模块的情况下，将上述服务调用请求按照时间顺序轮流分配给各个第一调度模块；或者，根据服务调用请求的所需资源和请求发起位置，将上述服务调用请求划分至与上述所需资源相匹配且空间传输距离较近的第一调度模块。

在包含服务集群和注册中心的微服务架构300中，通过在服务集群的每个服务节点中设置代理桩和调度模块，这种分布式调度机制将调度能力分散到多个服务节点，使得该微服务架构具备高度的容错性，即使某个服务节点出现故障或者失效，整个系统仍然能够通过其他正常服务节点中调度模块的调度保证对外提供正常的服务和系统运行；同时，分布式调度还能够充分利用多个服务节点的并行处理能力，提升系统的性能和资源利用效率，从而降低整体的等待时间和资源浪费。在每个服务节点中，基于代理桩能够管理所在节点内的服务向注册中心的注册以及响应第一调度模块对目标服务实例的调用进行路由中转；注册中心通过与代理桩通信实现对多个服务节点内的可用服务的注册和管理；第一调度模块在接收到服务调用对象的服务调用请求后，能够根据预设调度策略从注册中心所管理的可用服务中确定目标服务实例，并建立与上述目标服务实例对应的目标代理桩之间的网络路由；这一过程中支持容器化服务和/或非容器化服务的注册和对外提供服务，能够根据服务调用请求适配进行目标服务实例和对应目标服务节点的灵活调整，实现服务集群的弹性伸缩管理。

参照图3中示意的序号所示，本公开的实施例还提供一种基于上述微服务架构300的服务调用方法。

上述服务调用方法包括：参照图3中序号①～⑤所示，上述第一调度模块(以调度模块311作为示例)接收服务调用对象的服务调用请求(参照图3中序号①所示)，根据预设调度策略从上述注册中心120所管理的可用服务中确定目标服务实例(参照图3中序号②-1所示)，并建立与上述目标服务实例对应的目标代理桩之间的网络路由，基于上述网络路由向目标代理桩发起对目标服务实例的调用(参照图3中序号②-2所示)；上述目标代理桩响应上述第一调度模块对目标服务实例的调用，将服务实例调用请求转发给对应的目标服务实例(参照图3中序号③所示)；上述目标代理桩接收来自上述目标服务实例(以服务22作为示例)反馈的处理结果，并将上述处理结果转发给上述第一调度模块(参照图3中序号④所示)；上述第一调度模块将上述处理结果转发给上述服务调用对象(参照图3中序号⑤所示)。

上述微服务架构300具有极度轻量化的特点，它对硬件资源没有特殊要求，可以在虚拟服务器或物理服务器上运行。整个系统只需要一个调度中心、一个注册中心和每个节点上的一个代理桩，对资源的需求非常低。该微服务架构300具有很强的适用性，它可以适应不同的服务部署方式，可以在裸机环境或容器化环境中运行。对于网络和存储等方面也没有特殊要求，可以与任何网络架构和存储系统兼容。这些特点使得其成为一个通用的解决方案，适用于各种不同的应用场景。它可以帮助企业节省硬件资源和部署成本，同时为应用的扩展和性能提供强大的支持。无论是小型企业还是大型企业，调度中心都能够满足其不同的需求，并提供灵活的部署和配置选项。

在一些应用场景中，由于支持非容器化服务和/或容器化服务，具有低资源需求，可以在小型软件系统中使用，例如可以将所有组件部署在一台服务器上，从而有效降低成本。适用场景包含：对节点和服务有一定的弹性伸缩要求的软件系统，尤其是受到资源和容器化部署方式限制的情况下；通过调度中心的管理，可以对节点和服务进行灵活的调度和伸缩，以满足系统的需求。无论是在资源有限的环境下，还是在容器化部署的场景中，调度中心都能帮助软件系统实现更有效的资源利用和任务分配。

本领域技术人员在考虑说明书及实践本公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。