CN117914948A - 服务实例调度方法、装置、电子设备及存储介质 - Google Patents
服务实例调度方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN117914948A CN117914948A CN202410168211.XA CN202410168211A CN117914948A CN 117914948 A CN117914948 A CN 117914948A CN 202410168211 A CN202410168211 A CN 202410168211A CN 117914948 A CN117914948 A CN 117914948A
- Authority
- CN
- China
- Prior art keywords
- service
- instance
- service instance
- target
- target service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Power Engineering (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Mathematical Physics (AREA)
- Environmental & Geological Engineering (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
本公开实施例提供一种服务实例调度方法、装置、电子设备及存储介质,通过基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,微服务访问数据表征目标服务的至少两个上游服务针对目标服务的服务实例的访问记录;根据微服务访问数据,得到目标服务对应的至少一个服务实例的评估指标,评估指标表征服务实例的健康度;根据服务实例的评估指标,对服务实例进行熔断。通过以旁路模式获得目标服务的至少两个上游服务针对目标服务的服务实例的访问记录,生成针对服务实例的评估指标来对服务实例的健康度进行表征,实现全局视野下的服务实例的健康度评估,之后基于该评估指标对异常服务实例进行熔断,提高服务的整体性能和运行稳定性。
Description
技术领域
本公开实施例涉及计算机技术领域,尤其涉及一种服务实例调度方法、装置、电子设备及存储介质。
背景技术
微服务(Microservice)是一种应用程序开发架构和组织方法,基于微服务的应用由基于明确定义的接口进行通信的小型独立服务组成,当前,通过对服务进行分布式部署,使其具有高度的可用性和可扩展性,从而提高程序性能。
在对服务进行分布式部署的应用场景中,服务的个别服务实例会由于负载、网络等原因,在被上游服务调用时出现调用异常,可以通过将出现异常的服务实例熔断,来提高上游服务的运行稳定性。
然而,现有技术中的方案,存在对服务实例的熔断调度不合理,从而导致服务的整体性能下降的问题。
发明内容
本公开实施例提供一种服务实例调度方法、装置、电子设备及存储介质,以克服由于服务实例熔断不合理而导致的服务整体性能下降的问题。
第一方面,本公开实施例提供一种服务实例调度方法方法,包括:
基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;根据所述服务实例的评估指标,对所述服务实例进行熔断。
第二方面,本公开实施例提供一种服务实例调度装置,包括:
获取模块,用于基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;
处理模块,用于根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;
调度模块,用于根据所述服务实例的评估指标,对所述服务实例进行熔断。
第三方面,本公开实施例提供一种电子设备,包括:处理器和存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
第四方面,本公开实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
第五方面,本公开实施例提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
本实施例提供的服务实例调度方法、装置、电子设备及存储介质,通过基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;根据所述服务实例的评估指标,对所述服务实例进行熔断。通过以旁路模式获得目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录,进而生成针对服务实例的评估指标来对服务实例的健康度进行表征,实现了全局视野下的服务实例的健康度评估,之后基于该评估指标对服务实例进行熔断,保证了对服务实例熔断的合理性,进而提高服务的整体性能和运行稳定性。
附图说明
为了更清楚地说明本公开实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的一种基于微服务的应用程序的结构示意图;
图2为本公开实施例提供的服务实例调度方法的流程示意图一;
图3为本公开实施例提供的一种旁路模式的示意图;
图4为图2所示实施例中步骤S101的具体实现方式的流程图;
图5为图4所示实施例中步骤S1013的具体实现方式的流程图;
图6为图2所示实施例中步骤S102的具体实现方式的流程图;
图7为本公开实施例提供的一种微服务架构示意图;
图8为图2所示实施例中步骤S103的具体实现方式的流程图;
图9为本公开实施例提供的服务实例调度方法的流程示意图二;
图10为本公开实施例提供的服务实例调度装置的结构框图;
图11为本公开实施例提供的一种电子设备的结构示意图;
图12为本公开实施例提供的电子设备的硬件结构示意图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本公开一部分实施例,而不是全部的实施例。基于本公开中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本公开保护的范围。
需要说明的是,本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准,并提供有相应的操作入口,供用户选择授权或者拒绝。
下面对本公开实施例的应用场景进行解释:
图1为本公开实施例提供的一种基于微服务的应用程序的结构示意图,参考图1中所示,在应用程序由多个功能模块构成,每一功能模块由对应的微服务(以下简称服务)来实现,同时服务可以作为上游服务(例如图中所示的上游服务S1、上游服务S2、上游服务S3等),进一步调用其下游服务(例如图中所示的下游服务SS1、下游服务SS2等),来实现更加具体的功能,不同服务之间通过HTTP等方式进行数据通信。其中,每一服务在对应的服务集群中,对应创建有多个服务实例(instance),上游服务通过调用下游服务的服务实例,来实现对应的功能调用。
本实施例提供的服务实例调度方法,可以应用于基于服务网格(Service Mesh)的应用程序部署的场景中,其中,服务网格是一种容器化架构,可以用于自动处理发现和连接服务,服务对应的服务实例可以部署在容器中。本公开实施例提供的方法可以由服务网格的数据面(Data Plant),或者部署在服务网格系统内的服务实例调度装置(组件)执行。进一步地,该装置可以由软件和/或硬件的方式实现,该装置也可以集成在有一定数据处理功能的电子设备(例如云服务器)中。其中,电子设备可以包括但不限于具备大数据处理能力的移动终端,以及台式计算机、超级计算机等具备大数据处理能力的固定终端。
现有技术中,在对服务进行分布式部署的应用场景中,服务的个别服务实例会由于负载、网络等原因,在被上游服务调用时出现调用异常,可以通过将出现异常的服务实例熔断,来提高上游服务的运行稳定性。然而,在微服务场景下,服务之间的调用复杂,一个服务往往对多个上游提供服务,现有技术中的方案,仅在某个客户端实例分析下游服务的服务实例的异常,因此,缺乏全局视角,造成当检测到下游服务的服务实例出现错误抖动时就触发熔断,从而导致服务的整体性能的下降。
本公开实施例提供一种服务实例调度方法以解决上述问题。
参考图2,图2为本公开实施例提供的服务实例调度方法的流程示意图一。本实施例的方法可以应用在云服务器中,该服务实例调度方法包括:
步骤S101:基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,微服务访问数据表征目标服务的至少两个上游服务针对目标服务的服务实例的访问记录。
示例性地,基于上述针对应用场景的介绍,服务网格是一种容器化架构,服务网格将可以配置的代理层和服务部署在一起,作为微服务基础设施层接管服务间的流量,并提供通用的服务注册发现、负载均衡、身份验证、精准路由、服务鉴权等基础功能,通过结合Kubernetes等用于管理容器的平台来实现应用程序的部署。进一步地,以实现应用程序的功能模块的一个目标服务为例,目标服务具有至少一个上游服务,上游服务通过对该位于下游的目标服务对应的服务实例进行访问,来调用该目标服务所对应的服务功能,并生成对应的访问记录,其中访问记录包括访问时间、访问内容(即针对目标服务的输入)和访问结果(服务服务的输出)等信息。
在应用程序部署后,服务网格以旁路(sidecar)的模式来获得目标服务的至少两个上游服务针对目标服务的服务实例的访问记录,即微服务访问数据。一种优选的实现方式,微服务访问数据表征目标服务的所有上游服务针对目标服务的服务实例的访问记录,更具体地,微服务访问数据中包括目标服务的所有上游服务针对目标服务的各服务实例的访问记录的集合。其中,旁路相当于一个部署在本地的代理服务器,其用于接管服务的入口流量和出口流量。旁路对应服务的非核心功能,通过将服务的网格数据面(MeshDataPlant)集成到旁路,可以实现收集和发送服务对应的日志数据、指标和性能数据到服务实例调度组件以便进行实时监控、故障排除和性能分析的作用。
图3为本公开实施例提供的一种旁路模式的示意图,如图3所示,图中caller_1和caller_2分别为调用目标服务callee的上游服务,在caller_1和caller_2调用callee中的某个服务实例后,会生成响应的访问记录,例如图中所示的DReport_1和DReport_2,通过集成在caller_1和caller_2的旁路的mesh数据面(MeshDataPlant),来获得上述访问记录DReport_1和DReport_2,并将该访问记录DReport_1和DReport_2向服务实例调度组件发送,服务实例调度组件获得上述访问记录DReport_1和DReport_2的集合,从而得到针对目标服务的微服务访问数据,该微服务访问数据中可以包括以目标服务callee的服务实例为调用目标进行调用的所有访问记录(DReport_1和DReport_2)的集合。
进一步地,在一种可能的实现方式中,如图4所示,步骤S101的一种可能的实现方式包括:
步骤S1011:通过服务网格以旁路模式获得上游服务的初始访问数据,初始访问数据表征针对目标服务的访问记录。
步骤S1012:通过服务网格进行服务发现,访问第一微服务组件,并将初始访问数据发送至第一微服务组件。
步骤S1013:通过第一微服务组件对初始访问数据进行一致性哈希计算,得到微服务访问数据。
示例性地,本实施例步骤中,服务实例调度组件内部署有第一微服务组件,首先,通过服务网格以旁路模式获得上游服务的初始访问数据,该初始访问数据即上游服务对所有下游服务进行调用的相关记录,例如,上游服务caller_1调用了Service_1、Service_2和Service_3三个下游服务(的服务实例),在以旁路模式获得的初始访问数据中,包含有上述上游服务caller_1调用Service_1、Service_2和Service_3三个下游服务的访问记录。之后,服务网格的数据面通过服务发现访问该第一微服务组件,并基于约定好的协议(例如Protocol Buffersover HTTP)向第一微服务组件发送上述初始访问数据。第一微服务组件接收到各上游服务发送的初始访问数据后,基于该初始访问数据的内容进行进行一致性哈希计算,以服务实例进行分组,得到针对不同的服务实例的访问记录,其中包括针对目标实例的不同服务实例的访问记录,即微服务访问数据。具体地,例如,第一微服务组件接收到各上游服务发送的初始访问数据后,以服务实例进行分组,得到多个下游服务(例如下游服务Service_1、下游服务Service_2、下游服务Service_3)对应的微服务访问数据,其中,以下游服务Service_2为目标服务,下游服务Service_2对应的微服务访问数据中,包含有下游服务Service_2的N个服务实例分别对应的访问记录,例如R_1、R_2……R_N。
进一步地,如图5所示,步骤S1013的具体实现方式包括:
步骤S1013A:基于初始访问数据,得到微服务访问指标,微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识。
步骤S1013B:根据微服务访问指标进行哈希计算,得到一致性哈希键,一致性哈希键用于指示服务实例。
步骤S1013C:根据一致性哈希键和对应的访问记录,生成微服务访问数据。
示例性地,在通过旁路模式获得的初始访问数据中,包含有微服务访问指标微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识。第一微服务组件从各上游服务对应的初始访问数据中,获得上述微服务访问指标,并进行一致性哈希计算,从而将微服务访问指标映射至对应的目标服务实例。具体地,由于以旁路模式上报的数据是以轮训或随机(因数据源行为而异)的方式输入到第一微服务组件(的不同实例)的,为了实现基于服务实例的至少两个上游服务对应的访问记录的分组,需要利用一致性哈希机制来进行映射,即对微服务访问指标进行哈希计算,并将哈希计算结果作为一致性哈希键来对不同的服务实例进行区分,即一致性哈希键用于指示一个服务实例。之后,将初始访问数据中的访问记录,以及初始访问数据对应的一致性哈希键,组成键值对数据,并基于键值对数据中的键进行分组,得到目标服务的各服务实例对应的键值对数据,即微服务访问数据。
步骤S102:根据微服务访问数据,得到目标服务对应的至少一个服务实例的评估指标,评估指标表征服务实例的健康度。
示例性地,在得到微服务访问数据之后,服务网格的服务实例调度组件根据该微服务访问数据,对该微服务访问数据所指示的至少一个服务实例的健康度进行评估,得到表征服务实例的健康度的评估指标,其中,一种可能的实现方式中,评估指标可以基于访问记录中的错误请求数量确定,错误请求即上述服务在调用下游的目标服务的服务实例后,由于调用、访问失败或异常而生成的信息。评估指标可以是反比与错误请求数量的数值,因此,评估指标越高,表征服务实例的健康度越高;在另一种可能的实现方式中,评估指标可以是数组、向量或矩阵,即评估指标对应多个评估维度,通过该多个评估维度来综合表现服务实例的健康度,具体可根据需要设置,此处不再详述。
在一种可能的实现方式中,服务网格的服务实例调度组件内部署有第二微服务组件和第三微服务组件,其中,示例性地,第二微服务组件作为时序数据库,存储微服务访问数据并对其进行处理,得到服务实例的评估指标以及对应的实例权重,第三微服务组件用于存储各服务实例的实例权重;在步骤S101执行完毕后,还包括:步骤S101A:将微服务访问数据存储至基于时序数据库的第二微服务组件。相应的,示例性地,目标服务对应的N个服务实例,N为大于0的整数,i为大于0,且小于等于N的整数。如图6所示,步骤S102的具体实现方式包括:
步骤S1021:通过第二微服务组件,获取目标服务的第i个服务实例对应的目标微服务访问数据。
步骤S1022:基于目标微服务访问数据,生成第i个服务实例的评估指标。
步骤S1023:若i小于N,则对i加1,并返回步骤S1021;若第i等于N,则结束循环,得到目标服务对应的各服务实例的评估指标。
针对目标服务对应的每一服务实例,依次通过第二微服务组件执行以上步骤后,完成了对每一服务实例的健康度评估,并得到对应的评估指标。由于使用了目标微服务访问数据来对目标服务实例的健康度进行了评估,而标微服务访问数据是所有访问了该目标服务实例的上游服务汇报的访问记录的集合,因此相当于实现了针对目标服务实例的全局性评估,从而使得到的评估指标能够更好的反映出目标服务实例的真实运行状态,避免由于针对个别上游服务产生性能波动而导致的误熔断问题。
步骤S103:根据服务实例的评估指标,对服务实例进行熔断。
示例性地,基于之前的步骤,在得到服务实例的评估指标之后,根据该表征服务实例的健康度的评估指标,对服务实例进程熔断,或者称为摘除,从而断开服务实例的网络流量,并通过服务网格针对未熔断的服务实例重新进行流量分配(负载均衡),示例性地,上述熔断步骤可以需要利用第三微服务组件来实现。其中,更具体地,步骤S103的实现方式,包括将评估指标满足第一条件的目标服务实例的实例权重置零来实现,其中,示例性地,所述第一条件可以为预设的用于识别服务实例处于异常状态的参考指标,实例权重用于控制服务实例的导入流程,当服务实例的实例权重为零时,该服务实例不再提供服务,相当于熔断。之后,可选地,在服务实例的实例权重更新后,通过服务网格,基于目标服务的各服务实例的实例权重对目标服务的各服务实例进行负载均衡,使其他实例权重不为零的非目标服务实例继续提供服务,从而完成对目标服务实例进行熔断的过程。
图7为本公开实施例提供的一种微服务架构示意图,下面结合图7对上述对服务实例进行熔断的过程进行详细介绍,如图7所示,服务实例调度组件内包括有第一微服务组件、第二微服务组件和第三微服务组件,连接关系如图中所示,其中,上游服务caller_1和caller_2调用下游服务callee后,通过基于旁路模式的网格数据面(MeshDataPlant)将初始访问数据发送给第一微服务组件,第一微服务组件基于初始访问数据中的服务名称、服务集群标识和机房标识对其进行一致性哈希计算,得到针对服务实例的微服务访问数据,并将其存储至第二微服务组件。之后,第二微服务组基于微服务访问数据并进行计算,得到服务实例的评估指标,并基于该评估指标,确定各服务实例的实例权重,并将服务实例的实例权重存储至第三微服务主键,之后例如结合例如Consul等服务发现工具,通过第三微服务组件得到各服务实例的实例权重,并通过实例权重来对服务实例的流量进行控制,从而设置下游服务callee对应的各服务实例的可使用状态(包括熔断状态和未熔断状态),从而达使上游服务caller_1和caller_2在调用下游服务callee时,仅调用处于未熔断状态的服务实例,从而实现服务实例的熔断控制。
进一步地,基于评估指标的不同实现方式,触发对服务实例进行熔断的实现方式也有多种,例如,评估指标为一个具体的评估值,相应的,第一条件包括评估值对应的参考指标,例如为健康度阈值,以及服务实例处于异常状态的判断逻辑,例如当该评估指标小于预设的健康度阈值,则判断该评估指标异常,以及服务实例处于异常状态,进而对该评估指标对应的服务实例进行熔断。再例如,当评估指标为一个高纬度的数据,例如向量、矩阵时,可以采用对应的基于向量、矩阵形式的第一条件对其进行验证,示例性地,评估指标可以包括至少两个子指标,通过第一条件所包含的验证规则和对应的子健康度阈值对各子指标进行验证并通过后,判断该评估指标异常,以及服务实例处于异常状态,并对其对应的服务实例进行熔断。
更具体地,在一种可能的实现方式中,评估指标包括服务实例的总请求量以及错误请求数量,如图8所示,步骤S103的具体实现方式包括:
步骤S1031:若第一服务实例的总请求量大于第一阈值,则获取第一服务实例的错误请求数量;否则,执行步骤S1034。
步骤S1032:若错误请求数量大于第二阈值,则获取目标服务对应的当前熔断量;否则,执行步骤S1034。
步骤S1033:若当前熔断量小于第三阈值,对第一服务实例进行熔断;否则,执行步骤S1034。
步骤S1034:结束对第一服务实例的处理过程。
示例性地,首先,第二微服务组件根据评估指标,得到例如服务实例instance_1在时间窗口(例如当前30分钟内)内的总请求量以及错误请求数量,即服务实例instance_1在时间窗口内被至少两个上游服务调用的总次数;并比较该总请求量和第一阈值,若总请求量小于或等于第一阈值,说明服务实例instance_1当前处于不活跃状态,其运行状态不会对目标服务的总体运行造成影响,此时,不对其做进一步处理,降低系统负载,并能够避免错误熔断而导致目标服务的总体性能降低的问题,保证目标服务的运行稳定性;而若总请求量大于或等于第一阈值,说明服务实例instance_1当前处于活跃状态,此时,其运行状态已会对应用程序的整体稳定性产生较大影响,因此,继续获取该服务实例的错误请求数量。之后,对比错误请求数量和第二阈值,若错误请求数量小于或等于第二阈值,说明从全局视角(所有调用该服务实例的上游服务)而言,服务实例instance_1当前具有较好的健康度,临时的性能波动不会对目标服务的整体造成影响,此时不对其进行处理,同样起到降低系统负载,并避免错误熔断而导致目标服务的总体性能降低的效果;若错误请求数量大于或等于第二阈值,服务实例instance_1当前的健康度较差,之后进一步获取当前熔断量,即当前目标服务对应的全部服务实例中,已处于熔断状态的服务实例的数量,当该当前熔断量过高,即大于第三阈值时,由于可用的服务实例的数量过少,而每一服务实例分配的负载过大,从而导致当前可用的服务实例的性能也开始下降,最终导致目标服务的整体性能急剧下降,为避免该问题,当前熔断量小于第三阈值,对服务实例进行熔断,而当当前熔断量大于第三阈值,则不再对服务实例进行熔断,从而保证目标服务的整体性能不会受到螺旋式承压而下降,提高目标服务的运行稳定性。
本实施例提供的服务实例调度方法、装置、电子设备及存储介质,通过基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,微服务访问数据表征目标服务的至少两个上游服务针对目标服务的服务实例的访问记录;根据微服务访问数据,得到目标服务对应的至少一个服务实例的评估指标,评估指标表征服务实例的健康度;根据服务实例的评估指标,对服务实例进行熔断。通过以旁路模式获得目标服务的至少两个上游服务针对目标服务的服务实例的访问记录,进而生成针对服务实例的评估指标来对服务实例的健康度进行表征,实现了全局视野下的服务实例的健康度评估,之后基于该评估指标对服务实例进行熔断,保证了对服务实例熔断的合理性,进而提高服务的整体性能和运行稳定性。
参考图9,图9为本公开实施例提供的服务实例调度方法的流程示意图二。本实施例在图2所示实施例的基础上,进一步对步骤S102-S103进行细化,并增加了对服务实例进行恢复的过程,该服务实例调度方法包括:
步骤S201:基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,微服务访问数据表征目标服务的至少两个上游服务针对目标服务的服务实例的访问记录。
步骤S202:将微服务访问数据存储至基于时序数据库的第二微服务组件。
步骤S203:通过第二微服务组件获取目标服务实例对应的目标微服务访问数据。
步骤S204:基于目标微服务访问数据,生成目标服务实例的评估指标。
示例性地,参考图7所示的微服务架构示意图,本实施例中,通过第一微服务组件获得微服务访问数据,之后,由第二微服务组件遍历存储的目标服务的所有服务实例,例如遍历目标服务对应的服务集群机房的所有实例。其中,目标服务实例(即当前服务实例)指代一次遍历过程中的作为处理目标的服务实例,例如,目标服务对应有100个服务实例,则从第一个服务实例遍历至最后一个实例的过程中,第i轮遍历时所涉及的服务实例i,即为目标服务实例(当前服务实例),其中i为大于等于1且小于等于100的整数。
进一步地,在每一次遍历过程中,针对目标服务实例,通过第二微服务组件获取目标服务实例对应的目标微服务访问数据,即所有调用目标服务实例(服务实例i)的访问记录的集合。之后,基于访问记录来生成对应的表征目标服务实例的健康度的评估指标,其中,评估指标的具体生成方式,在图2所示实施例中步骤S102部分已进行详细介绍,此处不再赘述。
步骤S205:若目标服务实例的评估指标满足第一条件,则将目标服务实例的实例权重置零,并获取目标服务的到熔断比;否则,执行步骤S207。
步骤S206:若熔断比满足第二条件,则对至少一个实例权重为0的服务实例进行恢复;否则,执行步骤S207。
进一步地,在对所述服务实例进行熔断时,通过控制实例权重归零方式实现熔断处理。其中,熔断比表征目标服务对应的实例权重为0的服务实例相对全部服务实例的熔断比例值,在获得目标服务实例的评估指标后,若该评估指标满足第一条件,则判断该目标服务实例处于异常状态,需要进行熔断,具体地,在针对目标服务实例进行熔断后,获取所述目标服务的到熔断比,所述熔断比表征所述目标服务对应的处于熔断状态的服务实例相对全部服务实例的比例值;之后,根据所述熔断比,控制对处于熔断状态的服务实例的恢复处理。具体地,在对所述服务实例进行熔断时,通过将目标服务实例的实例权重置0,从而使目标服务实例的流量为0而无法向外部提供服务,实现目标服务实例的熔断。另一方面,在将目标服务实例的实例权重置零之前或之后,进一步获取目标服务的到熔断比,熔断比表征目标服务对应的实例权重为0的服务实例相对全部服务实例的熔断比例值。
进一步地,当若熔断比满足第二条件,例如熔断比例值大于一个预设比例阈值或位于某个比例区间,则对之前进行熔断的服务实例进行恢复,避免由于熔断数量过多而导致目标服务的整体性能下降,难以提供服务的问题,除此之外,还可以进一步获取其他信息,用于在对服务实例进行恢复前,进行判断,例如系统负载率、系统访问量等,而第二条件中包含有对应的用于对系统负载率、系统访问量等信息进行验证的信息。其中,进一步地,在熔断比(或者,和上述其他信息一同)满足第二条件而触发对熔断的服务实例进行恢复时,可以对目标服务的全部处于熔断状态的服务实例进行恢复(回滚),即将处于熔断状态的服务实例的实例权重恢复至预设的配置值,也可以仅对目标服务的一部分处于熔断状态的服务实例进行恢复,例如基于熔断时长进行排序,将处于熔断状态最长的N个服务实例恢复,从而在保证目标服务的整体性能的基础上,最大概率的降低异常服务实例的概率,提高目标服务的运行稳定性。
步骤S207:若目标服务实例不是目标服务的最后一个服务实例,则将目标服务的下一服务实例设置为目标服务实例,并返回步骤S203。
之后,针对目标服务实例的处理步骤完毕后,若目标服务实例不是目标服务的最后一个服务实例,则步骤S203,针对目标服务的下一个服务实例进行处理,并重复上述过程;需要若目标服务实例是目标服务的最后一个服务实例,则结束循环。从而在熔断规则内,将目标服务的所有满足要求的服务实例熔断,从而达到服务实例调度的目的。
可选地,在步骤S207之后,还包括:
步骤S208:在预设时长后,对实例权重为0的目标服务实例进行恢复,以使目标服务实例的实例权重恢复为目标服务实例的初始权重。
示例性地,服务实例的异常,通常是由于网络波动、资源紧张、请求量过大等原因造成的,当将其熔断后,当网络波动等导致服务实例异常的因素消失后,该服务实例即可正常工作,因此,在服务实例被熔断一定时间后,对熔断的服务实例进行恢复,从而使目标服务的性能能够始终保持在较高的水平。其中,对处于熔断状态的服务实例进行恢复(也称为自愈),即对实例权重为0的目标服务实例进行恢复的过程。具体地,服务实例的熔断和恢复是由实例权重控制的,因此,可以通过恢复(增加)实例权重,来重新向服务实例导入流程,实现服务实例的恢复。
示例性地,步骤S208的具体实现方式包括:
步骤S2081:获取预设的目标倍数。
步骤S2082:在每一恢复周期内,基于目标倍数依次增加目标服务实例的实例权重,直至实例权重达到初始权重。
示例性地,在恢复服务实例的实例权重的过程中,以预设的目标倍数进行逐步恢复,例如,目标倍数为2%,在恢复处于熔断状态的服务实例instance_1时,将服务实例instance_1的实例权重由0(倍初始权重)设置为2%(倍初始权重),在一个恢复周期(例如1分钟)之后,在以2%为倍数进行累加,将服务实例instance_1的实例权重由2%设置为4%,再经过一个恢复周期,将服务实例instance_1的实例权重由4%设置为6%,以此类推,直至服务实例instance_1的实例权重恢复为100%,即实例权重的初始权重。
其中,本实施例中的步骤S208,即对服务实例进行恢复的步骤,由服务网格的服务实例调度组件执行,可以与上述步骤S201-S207,即对服务实例进行熔断的步骤异步进行,二者之间相互独立。
本实施例中,通过对熔断状态的服务实例的实例权重进行逐步恢复,避免由于权重一次性设置为初始权重而导致流量过大、再次触发服务实例的异常的问题,提高系统稳定性,同时,在服务实例的恢复阶段,通过会将服务实例的实例权重以预设的目标倍数提高,进行流量的放量,直至与服务实例注册时的初始权重相等,如果在服务实例恢复过程中,仍然出现问题,那么随着恢复周期的推进,本实施例会基于之前的步骤,会再次对该服务实例进行熔断,因此,该恢复阶段相当于服务实例的启动预热,可以避免在服务实例存在持续性问题时,大规模流量放量而出现大量报错,进一步提高目标服务的稳定性。
可选地,在步骤S205之后,还包括:
步骤S209:记录目标服务实例的累计熔断次数。
步骤S210:若累计熔断次数小于第四阈值,则将目标服务实例设置为可恢复状态;若累计熔断次数大于第四阈值,则将目标服务实例设置为不可恢复状态。
步骤S211:将处于可恢复状态的服务实例,设置为目标服务实例。
示例性地,另一方面,在上述遍历过程中,当目标服务实例的评估指标满足第一条件时,对该目标服务实例进行熔断,同时,记录该目标服务实例的累计熔断次数,在目标服务的所有服务实例遍历完成之后或遍历过程中,根据各处于熔断状态的服务实例的累计熔断次数,来设置其对应的恢复状态,若累计熔断次数大于第四阈值,则设置为不可恢复状态。之后,在对该服务实例进行恢复之前,首先判断其是否处于可恢复状态,若处于可恢复状态(即熔断次数小于第四阈值),则将其确定为目标服务实例,并执行后续的步骤S208,以使其恢复至工作状态;若其处于不可恢复状态,则不对其进行处理,或仅生成提示信息或日志信息返回用户终端进行提示,从而实现对由于软硬件问题导致的异常服务实例的排除,减少反复熔断、恢复服务实例造成的资源开销,进一步提高目标服务的稳定性。
本实施例中,步骤S201的实现方式与本公开图2所示实施例中的步骤S101的实现方式相同,在此不再一一赘述。
对应于上文实施例的服务实例调度方法,图10为本公开实施例提供的服务实例调度装置的结构框图。为了便于说明,仅示出了与本公开实施例相关的部分。参照图10,服务实例调度装置3包括:
获取模块31,用于基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,微服务访问数据表征目标服务的至少两个上游服务针对目标服务的服务实例的访问记录;
处理模块32,用于根据微服务访问数据,得到目标服务对应的至少一个服务实例的评估指标,评估指标表征服务实例的健康度;
调度模块33,用于根据服务实例的评估指标,对服务实例进行熔断。
在本公开的一个实施例中,获取模块31,具体用于:通过服务网格以旁路模式获得上游服务的初始访问数据,初始访问数据表征针对目标服务的访问记录;通过服务网格进行服务发现,访问第一微服务组件,并将初始访问数据发送至第一微服务组件;通过第一微服务组件对初始访问数据进行一致性哈希计算,得到微服务访问数据。
在本公开的一个实施例中,获取模块31在通过第一微服务组件对初始访问数据进行一致性哈希计算,得到微服务访问数据时,具体用于:基于初始访问数据,得到微服务访问指标,微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识;根据微服务访问指标进行哈希计算,得到一致性哈希键,一致性哈希键用于指示服务实例;根据一致性哈希键和对应的访问记录,生成微服务访问数据。
在本公开的一个实施例中,在以旁路模式获取针对目标服务的微服务访问数据之后,获取模块31,还用于:将微服务访问数据存储至基于时序数据库的第二微服务组件;处理模块32,具体用于:针对目标服务对应的每一服务实例,依次通过第二微服务组件执行以下步骤:获取目标服务实例对应的目标微服务访问数据;基于目标微服务访问数据,生成目标服务实例的评估指标。
在本公开的一个实施例中,调度模块33,具体用于:若目标服务实例的评估指标满足第一条件,则对目标服务实例进行熔断。
在本公开的一个实施例中,调度模块33,还用于:在目标服务实例熔断后,获取目标服务的到熔断比,熔断比表征目标服务对应的处于熔断状态的服务实例相对全部服务实例的比例值;若熔断比满足第二条件,则对至少一个处于熔断状态的服务实例进行恢复。
在本公开的一个实施例中,评估指标包括服务实例的总请求量以及错误请求数量;调度模块33,具体用于:若服务实例的总请求量大于第一阈值,则获取服务实例的错误请求数量;若错误请求数量大于第二阈值,则获取目标服务对应的当前熔断量;若当前熔断量小于第三阈值,对服务实例进行熔断。
在本公开的一个实施例中,调度模块33,具体用于:将评估指标满足第一条件的目标服务实例的实例权重置零;调度模块33,还用于:在预设时长后,对目标服务实例进行恢复,以使目标服务实例的实例权重恢复为目标服务实例的初始权重;和或,通过服务网格,基于实例权重对目标服务的各服务实例进行负载均衡。
在本公开的一个实施例中,调度模块33在对目标服务实例进行恢复时,具体用于:获取预设的目标倍数;在每一恢复周期内,基于目标倍数依次增加目标服务实例的实例权重,直至实例权重达到初始权重。
在本公开的一个实施例中,在将目标服务实例的实例权重置零之后,调度模块33,还用于:记录目标服务实例的累计熔断次数;根据累计熔断次数,若累计熔断次数小于第四阈值,则将目标服务实例设置为可恢复状态;调度模块33在对目标服务实例进行恢复时,具体用于:若目标服务实例处于可恢复状态,则对目标服务实例进行恢复。
其中,获取模块31、处理模块32和调度模块33依次连接。本实施例提供的服务实例调度装置3可以执行上述方法实施例的技术方案,其实现原理和技术效果类似,本实施例此处不再赘述。
图11为本公开实施例提供的一种电子设备的结构示意图,如图11所示,该电子设备4包括:
处理器41,以及与处理器41通信连接的存储器42;
存储器42存储计算机执行指令;
处理器41执行存储器42存储的计算机执行指令,以实现如图2-图9所示实施例中的服务实例调度方法。
其中,可选地,处理器41和存储器42通过总线43连接。
相关说明可以对应参见图2-图9所对应的实施例中的步骤所对应的相关描述和效果进行理解,此处不做过多赘述。
本公开实施例提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,计算机执行指令被处理器执行时用于实现本公开图2-图9所对应的实施例中任一实施例提供的服务实例调度。
本公开实施例提供一种计算机程序产品,包括计算机程序,计算机程序被处理器执行时实现本公开图2-图9所对应的实施例中任一实施例提供的服务实例调度。
为了实现上述实施例,本公开实施例还提供了一种电子设备。
参考图12,其示出了适于用来实现本公开实施例的电子设备900的结构示意图,该电子设备900可以为终端设备或服务器。其中,终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、个人数字助理(Personal Digital Assistant,简称PDA)、平板电脑(Portable Android Device,简称PAD)、便携式多媒体播放器(Portable MediaPlayer,简称PMP)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图12示出的电子设备仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图12所示,电子设备900可以包括处理装置(例如中央处理器、图形处理器等)901,其可以根据存储在只读存储器(Read Only Memory,简称ROM)902中的程序或者从存储装置908加载到随机访问存储器(Random Access Memory,简称RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中,还存储有电子设备900操作所需的各种程序和数据。处理装置901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。
通常,以下装置可以连接至I/O接口905:包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置906;包括例如液晶显示器(Liquid CrystalDisplay,简称LCD)、扬声器、振动器等的输出装置907;包括例如磁带、硬盘等的存储装置908;以及通信装置909。通信装置909可以允许电子设备900与其他设备进行无线或有线通信以交换数据。虽然图12示出了具有各种装置的电子设备900,但是应理解的是,并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地,根据本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信装置909从网络上被下载和安装,或者从存储装置908被安装,或者从ROM 902被安装。在该计算机程序被处理装置901执行时,执行本公开实施例的方法中限定的上述功能。
需要说明的是,本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:电线、光缆、RF(射频)等等,或者上述的任意合适的组合。
上述计算机可读介质可以是上述电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。
上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被该电子设备执行时,使得该电子设备执行上述实施例所示的方法。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码,上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LocalArea Network,简称LAN)或广域网(Wide Area Network,简称WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。其中,单元或模块的名称在某种情况下并不构成对该单元本身的限定。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如,非限制性地,可以使用的示范类型的硬件逻辑部件包括:现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
第一方面,根据本公开的一个或多个实施例,提供了一种服务实例调度方法,包括:
基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;根据所述服务实例的评估指标,对所述服务实例进行熔断。
根据本公开的一个或多个实施例,所述基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,包括:通过所述服务网格以旁路模式获得上游服务的初始访问数据,所述初始访问数据表征针对目标服务的访问记录;通过服务网格进行服务发现,访问第一微服务组件,并将所述初始访问数据发送至第一微服务组件;通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据。
根据本公开的一个或多个实施例,所述通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据,包括:基于所述初始访问数据,得到微服务访问指标,所述微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识;根据所述微服务访问指标进行哈希计算,得到一致性哈希键,所述一致性哈希键用于指示服务实例;根据所述一致性哈希键和对应的访问记录,生成微服务访问数据。
根据本公开的一个或多个实施例,在所述以旁路模式获取针对目标服务的微服务访问数据之后,所述方法还包括:将所述微服务访问数据存储至基于时序数据库的第二微服务组件;所述根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,包括:针对目标服务对应的每一服务实例,依次通过第二微服务组件执行以下步骤:获取目标服务实例对应的目标微服务访问数据;基于所述目标微服务访问数据,生成所述目标服务实例的评估指标。
根据本公开的一个或多个实施例,所述根据所述服务实例的评估指标,对所述服务实例进行熔断,包括:若所述目标服务实例的评估指标满足第一条件,则对所述目标服务实例进行熔断。
根据本公开的一个或多个实施例,所述方法还包括:在所述目标服务实例熔断后,获取所述目标服务的到熔断比,所述熔断比表征所述目标服务对应的处于熔断状态的服务实例相对全部服务实例的比例值;若所述熔断比满足第二条件,则对至少一个处于所述熔断状态的服务实例进行恢复。
根据本公开的一个或多个实施例,所述评估指标包括所述服务实例的总请求量以及错误请求数量;根据所述服务实例的评估指标,对所述服务实例进行熔断,包括:若所述服务实例的总请求量大于第一阈值,则获取所述服务实例的错误请求数量;若所述错误请求数量大于第二阈值,则获取所述目标服务对应的当前熔断量;若所述当前熔断量小于第三阈值,对所述服务实例进行熔断。
根据本公开的一个或多个实施例,所述根据所述服务实例的评估指标,对所述服务实例进行熔断,包括:将评估指标满足第一条件的目标服务实例的实例权重置零。
根据本公开的一个或多个实施例,所述对所述服务实例进行熔断,包括:通过控制实例权重归零方式实现熔断处理;所述方法还包括:在预设时长后,对所述目标服务实例进行恢复,以使所述目标服务实例的实例权重恢复为所述目标服务实例的初始权重;和/或,通过所述服务网格,基于所述实例权重对所述目标服务的各服务实例进行负载均衡。
根据本公开的一个或多个实施例,所述对所述目标服务实例进行恢复,包括:获取预设的目标倍数;在每一恢复周期内,基于所述目标倍数依次增加所述目标服务实例的实例权重,直至所述实例权重达到所述初始权重。
根据本公开的一个或多个实施例,在将目标服务实例的实例权重置零之后,还包括:记录所述目标服务实例的累计熔断次数;根据所述累计熔断次数,若所述累计熔断次数小于第四阈值,则将所述目标服务实例设置为可恢复状态;所述对所述目标服务实例进行恢复,包括:若所述目标服务实例处于所述可恢复状态,则对所述目标服务实例进行恢复。
第二方面,根据本公开的一个或多个实施例,提供了一种服务实例调度装置,包括:
获取模块,用于基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;
处理模块,用于根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;
调度模块,用于根据所述服务实例的评估指标,对所述服务实例进行熔断。
根据本公开的一个或多个实施例,所述获取模块,具体用于:通过所述服务网格以旁路模式获得上游服务的初始访问数据,所述初始访问数据表征针对目标服务的访问记录;通过服务网格进行服务发现,访问第一微服务组件,并将所述初始访问数据发送至第一微服务组件;通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据。
根据本公开的一个或多个实施例,所述获取模块在通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据时,具体用于:基于所述初始访问数据,得到微服务访问指标,所述微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识;根据所述微服务访问指标进行哈希计算,得到一致性哈希键,所述一致性哈希键用于指示服务实例;根据所述一致性哈希键和对应的访问记录,生成微服务访问数据。
根据本公开的一个或多个实施例,在所述以旁路模式获取针对目标服务的微服务访问数据之后,所述获取模块,还用于:将所述微服务访问数据存储至基于时序数据库的第二微服务组件;所述处理模块,具体用于:针对目标服务对应的每一服务实例,依次通过第二微服务组件执行以下步骤获取目标服务实例对应的目标微服务访问数据;基于所述目标微服务访问数据,生成所述目标服务实例的评估指标。
根据本公开的一个或多个实施例,所述调度模块,具体用于:若所述目标服务实例的评估指标满足第一条件,则对所述目标服务实例进行熔断。
根据本公开的一个或多个实施例,所述调度模块,还用于:在所述目标服务实例熔断后,获取所述目标服务的到熔断比,所述熔断比表征所述目标服务对应的处于熔断状态的服务实例相对全部服务实例的比例值;若所述熔断比满足第二条件,则对至少一个处于所述熔断状态的服务实例进行恢复。
根据本公开的一个或多个实施例,所述评估指标包括所述服务实例的总请求量以及错误请求数量;所述调度模块,具体用于:若所述服务实例的总请求量大于第一阈值,则获取所述服务实例的错误请求数量;若所述错误请求数量大于第二阈值,则获取所述目标服务对应的当前熔断量;若所述当前熔断量小于第三阈值,对所述服务实例进行熔断。
根据本公开的一个或多个实施例,所述调度模块,具体用于:将评估指标满足第一条件的目标服务实例的实例权重置零;所述调度模块,还用于:在预设时长后,对所述目标服务实例进行恢复,以使所述目标服务实例的实例权重恢复为所述目标服务实例的初始权重;和或,通过所述服务网格,基于所述实例权重对所述目标服务的各服务实例进行负载均衡。
根据本公开的一个或多个实施例,在将目标服务实例的实例权重置零之后,所述调度模块,还用于:记录所述目标服务实例的累计熔断次数;根据所述累计熔断次数,若所述累计熔断次数小于第四阈值,则将所述目标服务实例设置为可恢复状态;所述调度模块在对所述目标服务实例进行恢复时,具体用于:若所述目标服务实例处于所述可恢复状态,则对所述目标服务实例进行恢复。
第三方面,根据本公开的一个或多个实施例,提供了一种电子设备,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
第四方面,根据本公开的一个或多个实施例,提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
第五方面,根据本公开的一个或多个实施例,提供了一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现如上第一方面以及第一方面各种可能的设计所述的服务实例调度方法。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开中所涉及的公开范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述公开构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
此外,虽然采用特定次序描绘了各操作,但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下,多任务和并行处理可能是有利的。同样地,虽然在上面论述中包含了若干具体实现细节,但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地,在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题,但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反,上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
Claims (13)
1.一种服务实例调度方法,其特征在于,包括:
基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;
根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;
根据所述服务实例的评估指标,对所述服务实例进行熔断。
2.根据权利要求1所述的方法,其特征在于,所述基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,包括:
通过所述服务网格以旁路模式获得上游服务的初始访问数据,所述初始访问数据表征针对目标服务的访问记录;
通过所述服务网格进行服务发现,访问第一微服务组件,并将所述初始访问数据发送至第一微服务组件;
通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据。
3.根据权利要求2所述的方法,其特征在于,所述通过所述第一微服务组件对所述初始访问数据进行一致性哈希计算,得到所述微服务访问数据,包括:
基于所述初始访问数据,得到微服务访问指标,所述微服务访问指标包括目标服务的服务名称、服务集群标识和机房标识;
根据所述微服务访问指标进行哈希计算,得到一致性哈希键,所述一致性哈希键用于指示服务实例;
根据所述一致性哈希键和对应的访问记录,生成微服务访问数据。
4.根据权利要求1所述的方法,其特征在于,在所述以旁路模式获取针对目标服务的微服务访问数据之后,所述方法还包括:
将所述微服务访问数据存储至基于时序数据库的第二微服务组件;
所述根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,包括:
针对目标服务对应的每一服务实例,依次通过所述第二微服务组件执行以下步骤:
获取目标服务实例对应的目标微服务访问数据;
基于所述目标微服务访问数据,生成所述目标服务实例的评估指标。
5.根据权利要求4所述的方法,其特征在于,所述根据所述服务实例的评估指标,对所述服务实例进行熔断,包括:
若所述目标服务实例的评估指标满足第一条件,则对所述目标服务实例进行熔断;其中所述第一条件为预设的用于识别服务实例处于异常状态的参考指标。
6.根据权利要求5所述的方法,其特征在于,所述评估指标包括所述服务实例的总请求量以及错误请求数量;
若所述目标服务实例的评估指标满足第一条件,则对所述目标服务实例进行熔断,包括:
若所述服务实例的总请求量大于第一阈值,则获取所述服务实例的错误请求数量;
若所述错误请求数量大于第二阈值,则获取所述目标服务对应的当前熔断量;
若所述当前熔断量小于第三阈值,对所述服务实例进行熔断。
7.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在针对目标服务实例进行熔断后,获取所述目标服务的到熔断比,所述熔断比表征所述目标服务对应的处于熔断状态的服务实例相对全部服务实例的比例值;
根据所述熔断比,控制对处于熔断状态的服务实例的恢复处理。
8.根据权利要求1所述的方法,其特征在于,所述对所述服务实例进行熔断,包括:通过控制实例权重归零方式实现熔断处理;
所述方法还包括:
在预设时长后,对所述目标服务实例进行恢复,在每一恢复周期内,基于目标倍数依次增加所述目标服务实例的实例权重,直至所述实例权重达到初始权重;和/或,
通过所述服务网格,基于所述实例权重对所述目标服务的各服务实例进行负载均衡。
9.根据权利要求8所述的方法,其特征在于,还包括:
记录所述目标服务实例的累计熔断次数;
根据所述累计熔断次数,若所述累计熔断次数小于第四阈值,则将所述目标服务实例设置为可恢复状态;
所述对所述目标服务实例进行恢复,包括:
若所述目标服务实例处于所述可恢复状态,则对所述目标服务实例进行恢复。
10.一种服务实例调度装置,其特征在于,包括:
获取模块,用于基于服务网格,以旁路模式获取针对目标服务的微服务访问数据,其中,所述微服务访问数据表征所述目标服务的至少两个上游服务针对所述目标服务的服务实例的访问记录;
处理模块,用于根据所述微服务访问数据,得到所述目标服务对应的至少一个服务实例的评估指标,所述评估指标表征所述服务实例的健康度;
调度模块,用于根据所述服务实例的评估指标,对所述服务实例进行熔断。
11.一种电子设备,其特征在于,包括:处理器和存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,使得所述处理器执行如权利要求1至9任一项所述的服务实例调度方法。
12.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如权利要求1至9任一项所述的服务实例调度方法。
13.一种计算机程序产品,包括计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至9任一项所述的服务实例调度方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410168211.XA CN117914948A (zh) | 2024-02-05 | 2024-02-05 | 服务实例调度方法、装置、电子设备及存储介质 |
| US18/988,678 US12379961B1 (en) | 2024-02-05 | 2024-12-19 | Service instance scheduling method, an electronic device, and a storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410168211.XA CN117914948A (zh) | 2024-02-05 | 2024-02-05 | 服务实例调度方法、装置、电子设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117914948A true CN117914948A (zh) | 2024-04-19 |
Family
ID=90687815
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410168211.XA Pending CN117914948A (zh) | 2024-02-05 | 2024-02-05 | 服务实例调度方法、装置、电子设备及存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US12379961B1 (zh) |
| CN (1) | CN117914948A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119065795A (zh) * | 2024-10-31 | 2024-12-03 | 苏州元脑智能科技有限公司 | 一种容器实例的调度方法、装置、计算机设备及存储介质 |
| CN119629107A (zh) * | 2024-10-30 | 2025-03-14 | 招商银行股份有限公司 | 路由转发方法、装置、设备以及存储介质 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7155515B1 (en) * | 2001-02-06 | 2006-12-26 | Microsoft Corporation | Distributed load balancing for single entry-point systems |
| US9747133B2 (en) * | 2012-06-21 | 2017-08-29 | Microsoft Technology Licensing, Llc | Enhanced availability for message services |
| US10623514B2 (en) * | 2015-10-13 | 2020-04-14 | Home Box Office, Inc. | Resource response expansion |
| CA2993369C (en) * | 2017-01-30 | 2021-10-19 | Sandvine Incorporated Ulc | System and method for traffic steering and analysis |
| US10956849B2 (en) * | 2017-09-29 | 2021-03-23 | At&T Intellectual Property I, L.P. | Microservice auto-scaling for achieving service level agreements |
| US10637952B1 (en) * | 2018-12-19 | 2020-04-28 | Sap Se | Transition architecture from monolithic systems to microservice-based systems |
| US10936291B1 (en) * | 2019-04-17 | 2021-03-02 | EMC IP Holding Company LLC | Recommending the refactoring of microservices |
| US11604672B2 (en) * | 2020-04-02 | 2023-03-14 | Vmware, Inc. | Operational health of an integrated application orchestration and virtualized computing system |
| CN111698301A (zh) | 2020-05-29 | 2020-09-22 | 成都新希望金融信息有限公司 | 一种保证服务延续的服务管理方法、装置及存储介质 |
| US11431587B2 (en) * | 2020-09-09 | 2022-08-30 | At&T Intellectual Property I, L.P. | Systems and methods to deploy cloud-native microservices for communication services on scale |
| US11265236B1 (en) * | 2021-02-08 | 2022-03-01 | Sap Se | On-demand outages notification in a cloud environment |
| US11880296B2 (en) * | 2021-10-04 | 2024-01-23 | International Business Machines Corporation | Generating a test cluster for testing a container orchestration system |
| US11558265B1 (en) * | 2021-12-21 | 2023-01-17 | Intel Corporation | Telemetry targeted query injection for enhanced debugging in microservices architectures |
| US11561868B1 (en) * | 2021-12-23 | 2023-01-24 | Intel Corporation | Management of microservices failover |
| US20230259407A1 (en) * | 2022-02-17 | 2023-08-17 | Microsoft Technology Licensing, Llc | Exposing control to enable interactive schedulers for cloud cluster orchestration systems |
| US12019502B2 (en) * | 2022-05-31 | 2024-06-25 | Dell Products L.P. | Microservices anomaly detection |
| US20240289158A1 (en) * | 2023-02-23 | 2024-08-29 | VMware LLC | Health monitoring architecture for multi-tenant system |
| US12464002B2 (en) * | 2023-04-25 | 2025-11-04 | Citibank, N.A. | Microservices anomaly detection |
-
2024
- 2024-02-05 CN CN202410168211.XA patent/CN117914948A/zh active Pending
- 2024-12-19 US US18/988,678 patent/US12379961B1/en active Active
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119629107A (zh) * | 2024-10-30 | 2025-03-14 | 招商银行股份有限公司 | 路由转发方法、装置、设备以及存储介质 |
| CN119065795A (zh) * | 2024-10-31 | 2024-12-03 | 苏州元脑智能科技有限公司 | 一种容器实例的调度方法、装置、计算机设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| US12379961B1 (en) | 2025-08-05 |
| US20250251972A1 (en) | 2025-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111581291B (zh) | 数据处理方法、装置、电子设备及可读介质 | |
| CN110753112A (zh) | 云服务的弹性伸缩方法和装置 | |
| CN117914948A (zh) | 服务实例调度方法、装置、电子设备及存储介质 | |
| CN113127187B (zh) | 用于集群扩缩容的方法和装置 | |
| CN112507265A (zh) | 基于树结构进行异常侦测的方法、装置及相关产品 | |
| CN111092758A (zh) | 降低告警及恢复误报的方法、装置及电子设备 | |
| CN113760178B (zh) | 缓存数据处理方法、装置、电子设备和计算机可读介质 | |
| CN117725441B (zh) | 权限管理方法、装置、可读存储介质及电子设备 | |
| WO2025124273A1 (zh) | 一种应用于分布式数据库的安全审计方法及相关设备 | |
| CN111198853B (zh) | 数据处理方法、装置、电子设备及计算机可读存储介质 | |
| WO2025035872A1 (zh) | 数据库管理方法和装置 | |
| CN118484492A (zh) | 数据分析方法、系统、设备以及存储介质 | |
| CN118132313A (zh) | 微服务应用的故障处理方法、装置、电子设备及存储介质 | |
| CN117453415A (zh) | 数据审核方法、装置、设备及存储介质 | |
| CN112182002A (zh) | 数据容灾方法、装置、电子设备和计算机可读介质 | |
| CN114265643B (zh) | 执行代码的方法、装置、电子设备和存储介质 | |
| CN111930704B (zh) | 业务报警设备控制方法、装置、设备和计算机可读介质 | |
| CN116820354B (zh) | 数据存储方法、数据存储装置和数据存储系统 | |
| US12436797B2 (en) | Data delay detection method and apparatus, electronic device, and computer-readable medium | |
| CN114253755B (zh) | 日志处理方法、装置、设备及存储介质 | |
| CN119211057B (zh) | 基于多机房的数据同步回环流量检测方法及设备 | |
| CN115017547B (zh) | 一种权限确定方法、装置、设备及介质 | |
| CN112948159B (zh) | 服务故障的验证方法、装置、设备及存储介质 | |
| CN111639317B (zh) | 自动识别高危授权用户方法、装置、电子设备及存储介质 | |
| CN120144392A (zh) | 异常检测方法、装置、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |