CN112463366A - 面向云原生的微服务自动扩缩容和自动熔断方法及系统 - Google Patents

面向云原生的微服务自动扩缩容和自动熔断方法及系统 Download PDF

Info

Publication number
CN112463366A
CN112463366A CN202011300768.2A CN202011300768A CN112463366A CN 112463366 A CN112463366 A CN 112463366A CN 202011300768 A CN202011300768 A CN 202011300768A CN 112463366 A CN112463366 A CN 112463366A
Authority
CN
China
Prior art keywords
service
interface
module
sub
copy
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.)
Granted
Application number
CN202011300768.2A
Other languages
English (en)
Other versions
CN112463366B (zh
Inventor
林许亚伦
戚正伟
郑宇宸
任锐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Jiaotong University
Original Assignee
Shanghai Jiaotong University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shanghai Jiaotong University filed Critical Shanghai Jiaotong University
Priority to CN202011300768.2A priority Critical patent/CN112463366B/zh
Publication of CN112463366A publication Critical patent/CN112463366A/zh
Application granted granted Critical
Publication of CN112463366B publication Critical patent/CN112463366B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明提供了一种面向云原生的微服务自动扩缩容和自动熔断方法及系统，设置云原生系统中集群内部的网关规则，接管集群的入口流量；针对每一个微服务，将所有的服务副本集合抽象成一个独立的逻辑概念，其中每一个逻辑概念对应一个子网关服务；流量在进入每一个逻辑概念前，均先通过子网关服务进行L7层面的流量转发；子网络服务根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或对当前服务请求进行扩缩容处理，并结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断。本发明实现微服务自动扩容/缩容以及基于L7层面的自动熔断，保证了服务的高可用。

Description

面向云原生的微服务自动扩缩容和自动熔断方法及系统
技术领域
本发明涉及云计算及其云原生技术领域，具体地，涉及一种面向云原生的微服务自动扩缩容和自动熔断方法及系统，在Kubernetes场景下基于网络情况的微服务，保证了服务的高可用。
背景技术
Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetes的服务、支持和工具广泛可用。作为一种可自动实施Linux容器操作的开源平台，它可以帮助用户省去应用容器化过程的许多手动部署和扩展操作。也就是说，用户可以将运行Linux容器的多组主机聚集在一起，由Kubernetes帮助用户轻松高效地管理这些集群。而且，这些集群可跨公共云、私有云或混合云部署主机。因此，对于要求快速扩展的云原生应用而言(例如借助Apache Kafka进行的实时数据流处理)，Kubernetes是理想的托管平台。
Kubernetes这类云平台令使用它们的公司受益匪浅。但不可否认的是，上云会给DevOps团队带来压力。为了可移植性，开发人员必须使用微服务来构建应用，同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。运维人员需要有一种方法更好的连接和保护服务。因此，提出了服务网格的术语。
服务网格作为一种逻辑概念，用来描述组成这些应用程序的微服务网络以及它们之间的交互。
以业界目前最为主流的服务网格Istio为例，Istio以统一的方式提供了许多跨服务网络，比如流量管理，安全和可观察性。Istio提供了流量的自动负载均衡，提供了丰富的路由规则、重试、故障转移和故障注入等细粒度控制，简化了部署的复杂性，并减轻开发团队压力。
尽管如此，以Istio为代表的服务网格仍然存在以下共通问题亟待解决：
首先，尽管各个服务网格系统都提供了服务熔断的功能，但是这些熔断器都只作用于L4，这意味着当流量超过服务能支撑的程度时，熔断器会直接将整个服务熔断，使整个服务不可达。对于集群而言，这的确有效保护了服务，但是对于用户而言，这种不可达意味着整个服务的宕机，实际情况来说，往往是因为服务的某几个接口的井喷式增长导致了整个服务的不可用。这意味着集群更需要的其实是可以允许某些接口的服务降级，但是保证整体服务的可用性。遗憾的是，目前的服务网格并不提供这样的功能，服务降级和熔断一般由开发人员进行开发和配置，这和开发人员专注于业务逻辑开发的初衷相违背，开发人员不应当去负责服务所在集群可能会面临的状况。
服务网格遵循配置即服务的原则通过配置文件的方式来对集群内部的服务网络定义和维护，服务网格确实降低了部署的复杂性，但同样的增加了运维人员的心智负担。运维人员需要定义服务网格中的一切行为。一个理想的系统应当是使用用户尽可能少的进行配置，一切交给系统自动管理和维护。
服务网格目前没办法控制服务的自动扩容/缩容。从资源粒度的角度来说，服务网格不应当去处理服务的自动扩缩容，但是一个服务的CPU或内存突然出现指数式增长往往是因为大量请求的同时访问，服务没办法同时处理如此高的并发，导致大量请求被挂起。从这个角度来说，通过了解服务的并发情况可以侧面描述当前服务承受的压力，利用这一点来完成服务的扩缩容。但是目前还没有相关技术的说明或报道，也尚未收集到国内外类似技术的资料。
发明内容
本发明针对现有技术中存在的上述不足，提供了一种面向云原生的微服务自动扩缩容和自动熔断方法及系统，针对Kubernetes场景下基于网络情况的微服务，保证了服务的高可用。
根据本发明的一个方面，提供了一种面向云原生的微服务自动扩缩容和自动熔断方法，包括：
设置云原生系统中集群内部的网关规则，接管集群的入口流量；
针对每一个微服务，将所有的服务副本集合抽象成一个独立的逻辑概念，其中每一个逻辑概念对应一个子网关服务；流量在进入每一个逻辑概念前，均先通过子网关服务进行L7层面的流量转发；
子网络服务根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或对当前服务请求进行扩缩容处理，并结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断。
优选地，所述设置云原生系统中集群内部的网关规则，接管集群的入口流量，包括：
基于Poseidon系统，将Poseidon系统通过Kubernetes部署在集群中，实现Kubernetes Ingress Gateway的规则，从而接管集群的入口流量。
优选地，所述Poseidon系统同时运行多份服务副本，用于保证系统本身各个组件的稳定性。
优选地，所述Poseidon系统内部部署有一个Etcd集群，用于保证数据的一致性和可用性。
优选地，所述子网关服务基于Envoy实现。
优选地，所述丢弃后续服务请求和/或对当前服务请求进行扩缩容处理的方法，包括：
对于每一个逻辑概念，子网关服务确认所有请求的返回情况，当单位时间内某一个服务副本接口x返回的错误率超过MAX_ERROR_RATE时，子网关服务发起一个扩容请求，并在收到扩容成功的申请前，预更新当前集群的网络状态；
当子网关服务接收到扩容成功的申请后，更新当前集群的网络状态，并对该服务副本接口x进行分流，新生成的服务只服务于该服务副本接口x，原服务副本不再接收该服务副本接口x的流量，实现接口粒度上的流量隔离；
当子网关服务发现错误率超过MAX_ERROR_RATE的服务副本本身专有于该服务副本接口x，子网关服务同样会触发申请扩容的流程，并更新当前集群的网络状态，该服务副本接口x采用轮询的方式，将流量发送给准备用于该服务副本接口x的服务副本；
子网关服务根据服务副本接口x熔断情况申请扩容，对于只被单独服务副本服务的接口，维护一个当前集群网络状态动态更新的最高并发阈值；
当单位时间内并发请求数超过阈值时，子网关服务将后续的请求丢弃，以保证先前请求的服务质量；
当丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发子网关服务申请扩容流程；
当服务副本接口x有多个服务副本时，在一段时间内，该服务副本接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，子网关服务申请缩容请求；子网关服务收到缩容成功的申请后，更新当前集群的网络状态；
当服务副本接口x仅有一个服务副本时，子网关服务首先检查是否有同样满足缩容条件的服务，如果不存在相应服务，拒绝本次缩容，否则，触发申请缩容的流程。
优选地，所述结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断，包括：
针对被单独服务的接口，子网关服务根据当前逻辑概念下的微服务，获取每一个被单独服务的接口所有的最大并发阈值；当流量进入子网关服务时，子网关服务根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发阈值，如果已达到，则请求不再发送到实际服务中，子网关服务直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断；
针对接收多个接口的服务副本的接口，当单位时间内该接口返回的错误率超过MAX_ERROR_RATE时，子网关服务发起扩容申请，并确定该服务副本的最高分接口，所有进入该服务副本最高分接口的请求被丢弃，其余请求正常发送；
当子网关服务接收到扩容成功的申请后，该服务部分的最高分接口的请求发送到分流后的服务副本。
优选地，所述确定该服务副本的最高分接口的方法，包括：
子网关服务检查各个接口过去多个单位时间内的调用次数，并给每个接口x计算一个分数xscore：
Figure BDA0002786814600000041
其中，ci表示接口x在单位时间i内被调用的次数，n表示当前单位时间内前n个单位时间，ki为相关系数，0<ki<1，随着单位时间i的增大单调递减；b表示该接口x是否返回错误，若是，则值为1，若否，则值为0；h为相关系数，h>1，e表示错误率；
子网关服务将当前时间下分数最高的接口x记录下来，新生成的服务副本将单独服务于该接口，然后等待返回的申请结果。
优选地，所述方法还包括：
子网关服务根据流量状态，周期性地更新当前集群的网络状态。
优选地，所述子网关服务根据流量状态，周期性地更新当前集群的网络状态，包括：
对于服务副本接口x，其最高并发阈值在第一次被分流时设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值将对应时刻的请求并发数设置为单个服务副本的最高并发阈值；之后，子网关服务不断调整该单个服务副本的最高并发阈值，使之尽可能的趋近于真实的最高并发阈值；
当服务副本返回错误情况时，子网关服务按一定步长降低该单个服务副本的最高并发阈值，直至没有错误情况返回；
当出现较多的请求丢弃时，子网关服务申请资源占用查看请求，若发现内存和CPU使用均未过半时，则按一定步长增大该单个服务副本的最高并发阈值；
后续若服务副本接口x合并后又分流，则直接使用增大后的单个服务副本的最高并发阈值，完成对当前集群网络状态的更新。
根据本发明的另一个方面，提供了一种面向云原生的微服务自动扩缩容和自动熔断系统，包括：
主模块，该主模块用于设置云原生系统中集群内部的网关规则，接管集群的入口流量；
每一个微服务所对应的子网关服务模块，该子网关服务模块用于代理L7层面的流量，并根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或执行基于网络情况的自动扩缩容机制，并结合对当前服务请求的扩缩容处理结果和所代理的L7层面流量，实现L7层面的自动熔断机制。
优选地，所述主模块包括：本地DNS服务模块、记录状态模块、Etcd集群模块、Dispatch Controller模块、Metric模块以及通讯模块a；其中：
所述本地DNS服务模块，用于同步集群中Kubernetes CoreDNS的服务名及其地址；
所述记录状态模块，用于记录所有子网关服务的状态，包括：当前集群中每一个子网关服务模块对应服务的接口情况、数据模型以及配置参数；
所述Etcd集群模块，用于数据持久化，将所述记录状态模块记录的所有子网关服务的状态内容反序列化保存到Etcd集群中；
所述Dispatch Controller模块，用于分发新的子网关服务，并且检查服务的状态；
所述Metric模块，用于周期性的获取各个服务副本的CPU和内存情况；
所述通讯模块a，用以和子网关服务模块通讯，并接收子网关服务模块发出的配置文件内容；
每一个所述子网关服务模块均包括：计数器模块、接口数据模型模块、代理通信模块以及通讯模块b；其中：
所述计数器模块，用于记录单位时间内不同接口访问的次数；
所述接口数据模型模块，用于记录当前时间下子网关服务模块所对应的服务接口数据；
所述代理通信模块，用于L7层面的流量转发；
所述通讯模块b，用于将所述接口数据模型模块所记录的服务接口配置发送给主模块。
根据本发明的第三个方面，提供了一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时可用于执行上述任一项所述的方法。
根据本发明的第四个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可用于执行上述任一项所述的方法。
由于采用了上述技术方案，本发明与现有技术相比，具有如下有益效果：
1、本发明提供的面向云原生的微服务自动扩缩容和自动熔断方法，根据单位时间内的并发情况实现了基于网络情况的自动扩缩容机制，同时提供了基于L7接口粒度层面的自动熔断功能，用户只需提供很少的配置文件即可使用系统的所有功能，最大程度保证了服务的可用性。
2、本发明提供的面向云原生的微服务自动扩缩容和自动熔断系统，使用一种统一的方式妥善处理逻辑概念下服务副本ip变化的情况，并通过主模块和子网关服务模块保障当出现上述变化时依旧保持服务的稳定。
3、本发明提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，实现了一种基于网络情况的扩容缩容机制和一种基于L7层面的自动熔断机制，且两种机制均以自动化的形式运行在集群中，用户只需要提供入口流量的转发规则以及每个服务的接口情况即可，所有基于网络情况的自动扩容/缩容策略以及基于L7层面的自动熔断机制对于用户来说均是透明的。
4、通过本发明提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，实现了完整的自动化机制。
实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1为本发明一实施例中面向云原生的微服务自动扩缩容和自动熔断方法流程图；
图2为本发明一优选实施例中面向云原生的微服务自动扩缩容和自动熔断系统的架构示意图；
图3为本发明一优选实施例中面向云原生的微服务自动扩缩容和自动熔断系统的运行流程示意图。
具体实施方式
下面对本发明的实施例作详细说明：本实施例在以本发明技术方案为前提下进行实施，给出了详细的实施方式和具体的操作过程。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。
图1为本发明一实施例中面向云原生的微服务自动扩缩容和自动熔断方法的流程图。
如图1所示，本实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法，可以包括以下步骤：
S100，设置云原生系统中集群内部的网关规则，接管集群的入口流量；
S200，针对每一个微服务，将所有的服务副本集合抽象成一个独立的逻辑概念，其中每一个逻辑概念对应一个子网关服务；流量在进入每一个逻辑概念前，均先通过子网关服务进行L7层面的流量转发；
S300，子网络服务根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或对当前服务请求进行扩缩容处理，并结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断。
在该实施例的S100中，所述设置云原生系统中集群内部的网关规则，接管集群的入口流量，可以包括：
基于Poseidon系统，将Poseidon系统通过Kubernetes部署在集群中，实现Kubernetes Ingress Gateway的规则，从而接管集群的入口流量。
进一步地，所述Poseidon系统同时运行多份服务副本，用于保证系统本身各个组件的稳定性；和/或
所述Poseidon系统内部部署有一个Etcd集群，用于保证数据的一致性和可用性。
在该实施例的S200中，所述子网关服务可以基于Envoy实现。
在该实施例的S300中，所述丢弃后续服务请求和对当前服务请求进行扩缩容处理的方法，可以包括：
对于每一个逻辑概念，子网关服务确认所有请求的返回情况，当单位时间内某一个服务副本接口x返回的错误率超过MAX_ERROR_RATE时，子网关服务发起一个扩容请求，并在收到扩容成功的申请前，预更新当前集群的网络状态；
当子网关服务接收到扩容成功的申请后，更新当前集群的网络状态，并对该服务副本接口x进行分流，新生成的服务只服务于该服务副本接口x，原服务副本不再接收该服务副本接口x的流量，实现接口粒度上的流量隔离；
当子网关服务发现错误率超过MAX_ERROR_RATE的服务副本本身专有于该服务副本接口x，子网关服务同样会触发申请扩容的流程，并更新当前集群的网络状态，该服务副本接口x采用轮询的方式，将流量发送给准备用于该服务副本接口x的服务副本；
子网关服务根据服务副本接口x熔断情况申请扩容，对于只被单独服务副本服务的接口，维护一个当前集群网络状态动态更新的最高并发阈值；
当单位时间内并发请求数超过阈值时，子网关服务将后续的请求丢弃，以保证先前请求的服务质量；
当丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发子网关服务申请扩容流程；
当服务副本接口x有多个服务副本时，在一段时间内，该服务副本接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，子网关服务申请缩容请求；子网关服务收到缩容成功的申请后，更新当前集群的网络状态；
当服务副本接口x仅有一个服务副本时，子网关服务首先检查是否有同样满足缩容条件的服务，如果不存在相应服务，拒绝本次缩容，否则，触发申请缩容的流程。
在该实施例的S300中，所述结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断，包括：
针对被单独服务的接口，子网关服务根据当前逻辑概念下的微服务，获取每一个被单独服务的接口所有的最大并发阈值；当流量进入子网关服务时，子网关服务根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发阈值，如果已达到，则请求不再发送到实际服务中，子网关服务直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断；
针对接收多个接口的服务副本的接口，当单位时间内该接口返回的错误率超过MAX_ERROR_RATE时，子网关服务发起扩容申请，并确定该服务副本的最高分接口，所有进入该服务副本最高分接口的请求被丢弃，其余请求正常发送；
当子网关服务接收到扩容成功的申请后，该服务部分的最高分接口的请求发送到分流后的服务副本。
在上述实施例的一个具体应用实例中，所述确定该服务副本的最高分接口的方法，可以包括：
子网关服务检查各个接口过去多个单位时间内的调用次数，并给每个接口x计算一个分数xscore：
Figure BDA0002786814600000091
其中，ci表示接口x在单位时间i内被调用的次数，n表示当前单位时间内前n个单位时间，ki为相关系数，0<ki<1，随着单位时间i的增大单调递减；b表示该接口x是否返回错误，若是，则值为1，若否，则值为0；h为相关系数，h>1，e表示错误率；
子网关服务将当前时间下分数最高的接口x记录下来，新生成的服务副本将单独服务于该接口，然后等待返回的申请结果。
该实施例提供的的面向云原生的微服务自动扩缩容和自动熔断方法，还可以包括以下步骤：
S400，子网关服务根据流量状态，周期性地更新当前集群的网络状态。
在该实施例的S400中，所述子网关服务根据流量状态，周期性地更新当前集群的网络状态，可以包括：
对于服务副本接口x，其最高并发阈值在第一次被分流时设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值将对应时刻的请求并发数设置为单个服务副本的最高并发阈值；之后，子网关服务不断调整该单个服务副本的最高并发阈值，使之尽可能的趋近于真实的最高并发阈值；
当服务副本返回错误情况时，子网关服务按一定步长降低该单个服务副本的最高并发阈值，直至没有错误情况返回；
当出现较多的请求丢弃时，子网关服务申请资源占用查看请求，若发现内存和CPU使用均未过半时，则按一定步长增大该单个服务副本的最高并发阈值；
后续若服务副本接口x合并后又分流，则直接使用增大后的单个服务副本的最高并发阈值，完成对当前集群网络状态的更新。
本发明另一实施例提供了一种面向云原生的微服务自动扩缩容和自动熔断系统，该系统可以包括：主模块和每一个微服务所对应的子网关服务模块；其中：
主模块，该主模块用于设置云原生系统中集群内部的网关规则，接管集群的入口流量；
每一个微服务所对应的子网关服务模块，该子网关服务模块用于代理L7层面的流量，并根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或执行基于网络情况的自动扩缩容机制，并结合对当前服务请求的扩缩容处理结果和所代理的L7层面流量，实现L7层面的自动熔断机制。
作为该实施例的一优选实施例，所述主模块可以包括：本地DNS服务模块、记录状态模块、Etcd集群模块、Dispatch Controller模块、Metric模块以及通讯模块a；其中：
所述本地DNS服务模块，用于同步集群中Kubernetes CoreDNS的服务名及其地址；
所述记录状态模块，用于记录所有子网关服务的状态，包括：当前集群中每一个子网关服务模块对应服务的接口情况、数据模型以及配置参数；
所述Etcd集群模块，用于数据持久化，将所述记录状态模块记录的所有子网关服务的状态内容反序列化保存到Etcd集群中；
所述Dispatch Controller模块，用于分发新的子网关服务，并且检查服务的状态；
所述Metric模块，用于周期性的获取各个服务副本的CPU和内存情况；
所述通讯模块a，用以和子网关服务模块通讯，并接收子网关服务模块发出的配置文件内容；
每一个所述子网关服务模块均包括：计数器模块、接口数据模型模块、代理通信模块以及通讯模块b；其中：
所述计数器模块，用于记录单位时间内不同接口访问的次数；
所述接口数据模型模块，用于记录当前时间下子网关服务模块所对应的服务接口数据；
所述代理通信模块，用于L7层面的流量转发；
所述通讯模块b，用于将所述接口数据模型模块所记录的服务接口配置发送给主模块。
作为该实施例的一优选实施例，所述子网关服务模块中：
基于网络情况的自动扩缩容机制，可以包括：
对于每一个逻辑概念，子网关服务确认所有请求的返回情况，当单位时间内某一个服务副本接口x返回的错误率超过MAX_ERROR_RATE时，子网关服务发起一个扩容请求，并在收到扩容成功的申请前，预更新当前集群的网络状态；
当子网关服务接收到扩容成功的申请后，更新当前集群的网络状态，并对该服务副本接口x进行分流，新生成的服务只服务于该服务副本接口x，原服务副本不再接收该服务副本接口x的流量，实现接口粒度上的流量隔离；
当子网关服务发现错误率超过MAX_ERROR_RATE的服务副本本身专有于该服务副本接口x，子网关服务同样会触发申请扩容的流程，并更新当前集群的网络状态，该服务副本接口x采用轮询的方式，将流量发送给准备用于该服务副本接口x的服务副本；
子网关服务根据服务副本接口x熔断情况申请扩容，对于只被单独服务副本服务的接口，维护一个当前集群网络状态动态更新的最高并发阈值；
当单位时间内并发请求数超过阈值时，子网关服务将后续的请求丢弃，以保证先前请求的服务质量；
当丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发子网关服务申请扩容流程；
当服务副本接口x有多个服务副本时，在一段时间内，该服务副本接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，子网关服务申请缩容请求；子网关服务收到缩容成功的申请后，更新当前集群的网络状态；
当服务副本接口x仅有一个服务副本时，子网关服务首先检查是否有同样满足缩容条件的服务，如果不存在相应服务，拒绝本次缩容，否则，触发申请缩容的流程。
作为该实施例的一优选实施例，L7层面的自动熔断机制，可以包括：
所述子网关服务模块根据接口数据模型模块的数据模型单元以及计数器模块实现基于L7层面的自动熔断，根据当前逻辑概念下的最大并发数以及数据模型单元中各个接口在所有接口中被调用的比重，得到一个各个接口所允许的最大并发数，当流量进入子网关服务模块时，判断当前请求是否已经超过对应接口所允许的最大并发数，如果已达到，则请求不再发送到实际服务中，子网关服务模块直接丢弃该请求，并返回给外部用户定制化的服务降级结果。
该实施例提供的系统，可以用于执行本发明上一个实施例中所提供的方法。
下面结合该实施例所提供的系统以及本发明上一个实施例中所提供的方法，对该实施例所提供的系统的具体工作过程以及所实现的功能进一步详细描述如下。
Poseidon系统使用一种统一的方式妥善处理Palace下服务副本ip变化的情况，可能出现服务副本出现增加或删除；服务副本崩溃，生成一个新的服务副本等其他一些特殊情况。Poseidon使用两方面技术保障当出现上述状况时依旧保持服务的稳定。首先，Poseidon主模块的本地DNS服务模块会监控Kubernetes DNS服务，随时检测DNS发生的变化，并将一份完整的集群内DNS保存在自身模块中，当本地DNS服务模块检测到变化时，它会将变化后的新配置通过通讯模块a发送到涉及相关变化的Trident(子网关服务)模块中，Trident模块再更新自身的模型。由于所述本地DNS服务模块的存在，即使Trident模块数量的不断增长，Kubernetes服务的压力维持不变，最大程度的降低了对Kubernetes服务组件的压力。其次，每当Trident数据模型模块的数据模型发生变化时，Trident会将新的模型发送给Poseidon主模块。当某个Trident服务被终止后，Poseidon主模块会通过DispatchController带着相关配置信息创建一个新的Trident服务。Poseidon将模型反序列化存储在Etcd集群中，由于每一次都是写操作，而新的模型直接覆盖旧模型，因此Poseidon主模块不会马上将数据写入Etcd，而是间隔较长的时间段以后再一次性写入Etcd集群中。
作为该实施例的一优选实施例，在Kubernetes场景下基于网络情况的微服务自动扩容/缩容以及基于L7层面的自动熔断的方法，实现了基于L7接口粒度层面的自动熔断功能，用户只需提供很少的配置文件即可使用系统的所有功能，最大程度保证了服务的可用性，包括：
基于网络情况的扩容缩容：Trident模块中的接口数据模型模块会维护一个数据模型，包括各个接口的历史调用情况以及接口所属的服务副本。Poseidon通过以下方式进行服务的自动扩容。对于每个Palace，Trident模块会确认所有请求的返回情况，当发现单位时间内某服务副本接口返回的错误率超过MAX_ERROR_RATE时，Trident模块向Poseidon主模块发起一个扩容请求。Trident模块收到扩容成功的申请前，会预更新自身的数据模型模块，然后等待Poseidon主模块返回的申请结果。Trident模块收到扩容成功的申请后，Trident数据模块更新预更新模型，Trident将对接口x进行分流，新生成的服务只服务副本于接口x，而原来的服务副本不再收到接口x的流量，实现接口粒度上的流量隔离。如果Trident模块发现错误率超过MAX_ERROR_RATE的服务副本本身专有于单个接口x，Trident模块同样会触发申请扩容的流程，Trident数据模块更新模型，后续接口x会采用轮询的方式将流量发送给准备用于接口x的副本，降低每个服务副本的压力。Trident同样会根据服务接口熔断情况申请扩容，对于只被单独服务副本服务的接口，Trident数据模型模块会为其维护一个动态更新的最高并发阈值。当单位时间内并发请求数超过阈值时，Trident会将后续的请求丢弃，以保证先前请求的服务质量。当Trident模块发现丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发Trident申请扩容流程，后续流程与之前叙述类似。自动缩容仅会发生在那些服务于单个接口x的服务。有两种情况，一种是接口x有多个服务副本，一种是接口x仅有一个服务副本。对于前者，在一段时间内，接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，Trident模块向Poseidon主模块申请缩容请求。Trident模块收到缩容成功的申请后，Trident数据模块更新预更新模型。对于后者，Trident模块首先会检查是否有同样满足缩容条件的服务，如果不存在类似服务，拒绝本次缩容，否则，同样会触发申请缩容的流程。
基于L7层面的自动熔断机制：Trident模块中根据接口数据模型模块的数据模型以及计数器模块实现基于L7层面的自动熔断，自动熔断分为两种，第一种针对被单独服务的接口，Trident模块会根据当前Palace下的数据模型获取每个被单独服务的接口所有的最大并发阈值。当流量进入Trident模块时，计数器会根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发数，如果已达到，则请求不再发送到实际服务中，Trident直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断。第二种针对接受多个接口的服务副本，当Trident模块发现单位时间内该服务副本接口返回的错误率超过MAX_ERROR_RATE时，Trident模块会发起扩容申请，同时Trident模块会确定该服务副本的最高分接口x，接下来，所有进入该副本的接口x请求将被丢弃，而其余请求正常发送。当Trident模块收到扩容成功的申请后，后续接口x的请求发送到分流后的服务副本。
作为一优选实施例，Trident模块确定该服务副本的最高分接口x的方法，包括：
Trident模块收到扩容成功的申请前，会预更新自身的接口数据模型模块，包含两步：第一步，Trident模块会检查各个接口过去多个单位时间内的调用次数，第二步，Trident模块会给每个接口x计算一个分数，分数xscore为：
Figure BDA0002786814600000131
其中，ci表示接口x在单位时间i内被调用的次数，n表示当前单位时间内前n个单位时间，ki为相关系数(0<ki<1)，随着单位时间i的增大单调递减；b表示该接口是否返回错误，若有值为1，否则为0；h为相关系数(h>1)，e表示错误率。
Trident模块会将当前时间下分数最高的接口x记录下来，新生成的服务副本将单独服务于该接口，然后等待Poseidon主模块返回的申请结果。
作为一优选实施例，Trident模块中的接口数据模型模块会周期性的更新数据模型每个接口的最高并发阈值，流程如下：
初始情况下，只有拥有专有服务副本服务的接口才会设立最高并发阈值，当一些接口合并后，原定的最高并发阈值仍然保留，用做后续使用。对于接口x而言，其最高并发阈值在第一次被分流时会被先设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值会将对应时刻的请求并发数设置为单个服务副本的最高并发阈值。之后，Trident数据模型模块会不断的调整该值，使之尽可能的趋近于真实的最高并发阈值。一方面，当服务副本返回错误情况时，Trident会按一定步长降低最高并发阈值，直至没有错误情况返回。另一方面，当出现较多的请求丢弃时，Trident模块会向Poseidon模块申请资源占用查看请求，若发现内存和CPU使用均未过半时，Trident又会按一定步长增大最高并发阈值。后续若接口合并后又分流，则直接使用该历史最高并发阈值。实践证明，最高并发阈值在设定后往往经过多个时间周期的震荡后趋于稳定，最终在一个小幅度返回内波动。
该实施例所提供的系统Poseidon，是一个主从架构的分布式系统，Poseidon通过Kubernetes部署在集群中，实现了Kubernetes Ingress Gateway的规则从而接管了集群的入口流量，Poseidon运行多份副本保证系统本身各个组件的稳定性，并在内部部署了一个Etcd集群保证数据的一致性和可用性。对于每一个微服务，Poseidon将每个服务的所有副本集合抽象成一个独立的逻辑概念Palace，每个Palace对应一个基于Envoy实现的子网关服务，称作Trident。流量在进入每个Palace前，会先通过Trident进行L7的流量代理，Trident内部运行着一个数据模型，根据该模型以及当前集群的流量状态，Trident会决定将该请求发送到哪一个副本，是否丢弃该请求以及扩容和缩容策略。Trident还会根据流量状态周期性的更新数据模型，确保模型尽可能确实的描述当前集群网络状况。
作为一优选实施例，在Kubernetes场景下基于网络情况的微服务自动扩容/缩容以及基于L7层面的自动熔断的方法，采用上述系统，包括：
基于网络情况和硬件资源利用率的自动扩容/缩容：Trident模块中的接口数据模型模块会维护一个数据模型，包括各个接口的历史调用情况以及接口所属的服务副本。Poseidon通过以下方式进行服务的自动扩容。对于每个Palace，Trident模块会确认所有请求的返回情况，当发现单位时间内某服务副本接口返回的错误率超过MAX_ERROR_RATE(默认为3％)时，Trident模块向Poseidon主模块发起一个扩容请求，Poseidon主模块会根据Trident提供的元信息调用Metric模块来检查所对应的服务是否CPU和内存超过MAX_CPU_UTILIZATION或MAX_MEMORY_UTILIZATION预设值。若是则Poseidon主模块通过DispatchController模块增加副本数，并在完成后通知Trident模块，否则，Poseidon主模块拒绝此次扩容申请。Trident模块收到扩容成功的申请前，会预更新自身的数据模型模块，包含两步：第一步，Trident模块会检查各个接口过去多个单位时间内的调用次数，Trident模块会给每个接口x计算一个分数，分数xscore为
Figure BDA0002786814600000151
其中ci表示接口x在单位时间i内被调用的次数，n表示当前单位时间内前n个单位时间，ki为相关系数(0<ki<1)，随着i的增大单调递减。b表示该接口是否返回错误，若有值为1，否则为0。h为相关系数(h>1)，e表示错误率。Trident模块会将当前时间下分数最高的接口x记录下来，新生成的服务副本将单独服务于该接口，然后等待Poseidon主模块返回的申请结果。Trident模块收到扩容成功的申请后，Trident数据模块更新预更新模型，Trident将对接口x进行分流，新生成的服务只服务副本于接口x，而原来的服务副本不再收到接口x的流量，实现接口粒度上的流量隔离。如果Trident模块发现错误率超过MAX_ERROR_RATE的服务副本本身专有于单个接口x，Trident模块同样会触发申请扩容的流程，该扩容的服务副本将专用于接口x。Trident数据模型只是简单的预更新接口x所对应的服务副本信息。Trident模块收到扩容成功的申请后，Trident数据模块更新预更新模型，后续接口x会采用轮询的方式将流量发送给准备用于接口x的副本，降低每个服务副本的压力。理论上来说，如果服务每一个接口压力足够大的话，最后每个服务副本都将单独服务单个接口。Trident同样会根据服务接口熔断情况申请扩容，对于只被单独服务副本服务的接口，Trident数据模型模块会为其维护一个动态更新的最高并发阈值。当单位时间内并发请求数超过阈值时，Trident会将后续的请求丢弃，以保证先前请求的服务质量。当Trident模块发现丢弃请求数超过最高并发阈值的DROP_PERCENTAGE(默认是10％)时，触发Trident申请扩容流程，后续流程与之前叙述类似，不再叙述。
自动缩容仅会发生在那些服务于单个接口x的服务。有两种情况，一种是接口x有多个服务副本，一种是接口x仅有一个服务副本。对于前者，在一段时间内，接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG(默认为25％)时，Trident模块向Poseidon主模块申请缩容请求，Poseidon主模块会根据Trident提供的元信息调用Metric模块来检查所对应的服务是否CPU和内存低于MIN_CPU_UTILIZATION或MIN_MEMORY_UTILIZATION预设值。若是则Poseidon主模块通过Dispatch Controller模块减少副本数，并在完成后通知Trident模块，否则，Poseidon主模块拒绝此次缩容申请。Trident模块收到缩容成功的申请前，会预更新自身的数据模型模块，调整服务副本数，然后等待Poseidon主模块返回的申请结果。Trident模块收到缩容成功的申请后，Trident数据模块更新预更新模型。对于后者，Trident模块首先会检查是否有同样满足缩容条件的服务，如果不存在类似服务，拒绝本次缩容，否则，同样会触发申请缩容的流程。Trident模块收到缩容成功的申请前，会预更新自身的数据模型模块，Trident数据模块将满足条件的接口服务合并到一个服务中，调整服务转发模型，然后等待Poseidon主模块返回的申请结果。Trident模块收到缩容成功的申请后，Trident数据模块更新预更新模型。
不论是扩容还是缩容，Trident都会通过通讯模块b发送一个Event给Poseidon主模块，Poseidon主模块中的Dispatch Controller模块会将该事件发送给Kubernetes APIServer，由Kubernetes来管理副本的数量，Poseidon只需确保事件正确到达KubernetesAPI Server即可。
基于L7层面的自动熔断：Trident模块中根据接口数据模型模块的数据模型以及计数器模块实现基于L7层面的自动熔断，自动熔断分为两种，第一种针对被单独服务的接口，Trident模块会根据当前Palace下的数据模型获取每个被单独服务的接口所有的最大并发阈值。当流量进入Trident模块时，计数器会根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发数，如果已达到，则请求不再发送到实际服务中，Trident直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断。第二种针对接受多个接口的服务副本，当Trident模块发现单位时间内该服务副本接口返回的错误率超过MAX_ERROR_RATE时，Trident模块会发起扩容申请，同时Trident模块会确定该服务副本的最高分接口x，接下来，所有进入该副本的接口x请求将被丢弃，而其余请求正常发送。当Trident模块收到扩容成功的申请后，后续接口x的请求发送到分流后的服务副本。
进一步地，Trident模块中的接口数据模型模块会周期性的更新数据模型每个接口的最高并发阈值，流程如下：
初始情况下，只有拥有专有服务副本服务的接口才会设立最高并发阈值，当一些接口合并后，原定的最高并发阈值仍然保留，用做后续使用。对于接口x而言，其最高并发阈值在第一次被分流时会被先设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值会将对应时刻的请求并发数设置为单个服务副本的最高并发阈值。之后，Trident数据模型模块会不断的调整该值，使之尽可能的趋近于真实的最高并发阈值。一方面，当服务副本返回错误情况时，Trident会按一定步长降低最高并发阈值，直至没有错误情况返回。另一方面，当出现较多的请求丢弃时，Trident模块会向Poseidon模块申请资源占用查看请求，若发现内存和CPU使用均未过半时，Trident又会按一定步长增大最高并发阈值。后续若接口合并后又分流，则直接使用该历史最高并发阈值。实践证明，最高并发阈值在设定后往往经过多个时间周期的震荡后趋于稳定，最终在一个小幅度返回内波动。由于利用本发明实施例所提供的方法和系统所实现的服务会长时间跑在集群中，因此这种前期短期的震动带来的服务不稳定是可以接受的。
以下结合附图对本发明上述实施例作进一步的详细说明。
如图2所示，为本发明一优选实施例中提供的一种在Kubernetes场景下基于网络情况的微服务自动扩容/缩容以及基于L7层面的自动熔断的系统，包括Poseidon主模块以及每个服务各一个的Trident模块。其中：
所述Poseidon主模块包括，一个本地DNS服务模块，一个记录所有Trident状态的模块，一个Etcd集群，一个Dispatch Controller模块，一个Metric模块以及一个通讯模块a。所述本地DNS服务模块用于同步集群中Kubernetes CoreDNS的服务名及其地址；所述记录所有Trident状态的模块记录了当前集群中每个Trident对应服务的接口情况，数据模型以及配置参数；所述Etcd集群用于数据持久化，将所述记录所有Trident状态的模块中的内容反序列化保存到Etcd集群中；所述Dispatch Controller用于分发新的Trident服务，并且检查服务的状态；所属Metric模块周期性的获取各个服务副本的CPU和内存情况；所述通讯模块用以和Trident通讯，并接收Trident发出的配置文件内容。
所述Trident模块包括，一个计数器模块，一个接口数据模型模块，一个基于Envoy实现的代理通信模块以及一个通讯模块b。所述计数器模块用于记录单位时间内不同接口访问的次数；所述接口数据模型模块记录了当前时间下Trident对应服务接口的数据模型；所述基于Envoy实现的代理通信模块负责L7层面的流量转发；所述通讯模块b负责将数据模型配置发送给Poseidon主模块和事件通知。
图3为本发明一优选实施例中面向云原生的微服务自动扩缩容和自动熔断系统的运行流程示意图，以下将结合图3对工作流程进行详细描述：
首先，流量进入集群后，流量被Poseidon主模块接管，用户需要配置一些路由规则，确保流量根据规则转发到正确的Palace中，如图2示，流量分别转发到Palace A和Palace B。
接下来，以进入Palace A的流量继续展开。Palace A的流量实质上是由不同接口组成的HTTP请求组成，假设在该时刻下，Palace A下有三个副本，其中两个副本由于扩缩容策略只服务于接口/hello，另外1个副本则是服务除/hello接口外的所有接口，并且此时刻，集群正在创建一个只服务于/new接口的服务副本。
假设接口/hello请求到达Trident，则Trident将该接口请求计数器加1，请求转发到仅服务接口/hello的服务A副本。Trident会采取轮询的方式将请求发到服务副本中。对于超出计数器阈值的请求，Trident会将请求直接丢弃。假设其他接口请求到达Trident，Trident会将对应接口请求转发到对应的副本中。此刻，负责其他接口流量的服务开始返回错误请求，到底一定上限后，Trident开始创建新的服务副本。通过分数计算Trident计算出/new接口将是接下来被专用服务的接口，Trident向Poseidon主模块发起扩容请求，Poseidon主模块通知创建完成后，后续/new的接口将发送到仅服务于/new接口的服务副本。
Palace B的流量实质上是由不同接口组成的HTTP请求组成，假设在该时刻下，Palace B下有三个副本，其中一个副本由于扩缩容策略只服务于接口/foo，其中一个副本由于扩缩容策略只服务于接口/bar，另外两个副本则是服务除/foo接口和/bar接口外的所有接口。
假设接口/foo请求到达Trident，则Trident将该接口请求计数器加1，请求转发到仅服务接口/foo的服务B副本，Trident会将对应接口请求计数器加1，将请求转发到专有服务的服务副本中。对于超出最高并发计数器阈值的请求，Trident会将请求直接丢弃。
本发明上述实施例提供面向云原生的微服务自动扩缩容和自动熔断方法及系统，基于网络情况的自动扩容/缩容，Trident模块中的接口数据模型模块会维护一个数据模型，包括各个接口的历史调用情况以及接口所属的服务副本。Poseidon通过以下方式进行服务的自动扩容。对于每个Palace，Trident模块会确认所有请求的返回情况，当发现单位时间内某服务副本接口返回的错误率超过MAX_ERROR_RATE时，Trident模块向Poseidon主模块发起一个扩容请求。Trident模块收到扩容成功的申请前，会预更新自身的数据模型模块，然后等待Poseidon主模块返回的申请结果。Trident模块收到扩容成功的申请后，Trident数据模块更新预更新模型，Trident将对接口x进行分流，新生成的服务只服务副本于接口x，而原来的服务副本不再收到接口x的流量，实现接口粒度上的流量隔离。如果Trident模块发现错误率超过MAX_ERROR_RATE的服务副本本身专有于单个接口x，Trident模块同样会触发申请扩容的流程，Trident数据模块更新模型，后续接口x会采用轮询的方式将流量发送给准备用于接口x的副本，降低每个服务副本的压力。Trident同样会根据服务接口熔断情况申请扩容，对于只被单独服务副本服务的接口，Trident数据模型模块会为其维护一个动态更新的最高并发阈值。当单位时间内并发请求数超过阈值时，Trident会将后续的请求丢弃，以保证先前请求的服务质量。当Trident模块发现丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发Trident申请扩容流程，后续流程与之前叙述类似。自动缩容仅会发生在那些服务于单个接口x的服务。有两种情况，一种是接口x有多个服务副本，一种是接口x仅有一个服务副本。对于前者，在一段时间内，接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，Trident模块向Poseidon主模块申请缩容请求。Trident模块收到缩容成功的申请后，Trident数据模块更新预更新模型。对于后者，Trident模块首先会检查是否有同样满足缩容条件的服务，如果不存在类似服务，拒绝本次缩容，否则，同样会触发申请缩容的流程。
本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，基于L7层面的自动熔断机制，Trident模块中根据接口数据模型模块的数据模型以及计数器模块实现基于L7层面的自动熔断，自动熔断分为两种，第一种针对被单独服务的接口，Trident模块会根据当前Palace下的数据模型获取每个被单独服务的接口所有的最大并发阈值。当流量进入Trident模块时，计数器会根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发数，如果已达到，则请求不再发送到实际服务中，Trident直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断。第二种针对接受多个接口的服务副本，当Trident模块发现单位时间内该服务副本接口返回的错误率超过MAX_ERROR_RATE时，Trident模块会发起扩容申请，同时Trident模块会确定该服务副本的最高分接口x，接下来，所有进入该副本的接口x请求将被丢弃，而其余请求正常发送。当Trident模块收到扩容成功的申请后，后续接口x的请求发送到分流后的服务副本。
本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，Trident模块中的接口数据，利用多种维度，构建了模型中每个接口的最高并发阈值，初始情况下，只有拥有专有服务副本服务的接口才会设立最高并发阈值，当一些接口合并后，原定的最高并发阈值仍然保留，用做后续使用。对于接口x而言，其最高并发阈值在第一次被分流时会被先设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值会将对应时刻的请求并发数设置为单个服务副本的最高并发阈值。之后，Trident数据模型模块会不断的调整该值，使之尽可能的趋近于真实的最高并发阈值。一方面，当服务副本返回错误情况时，Trident会按一定步长降低最高并发阈值，直至没有错误情况返回。另一方面，当出现较多的请求丢弃时，Trident模块会向Poseidon模块申请资源占用查看请求，若发现内存和CPU使用均未过半时，Trident又会按一定步长增大最高并发阈值。后续若接口合并后又分流，则直接使用该历史最高并发阈值。实践证明，最高并发阈值在设定后往往经过多个时间周期的震荡后趋于稳定，最终在一个小幅度返回内波动。
本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，采用统一的方式妥善处理Palace下服务副本ip变化的情况，使用两方面技术保障当出现上述状况时依旧保持服务的稳定。一方面根据本地DNS服务监控Kubernetes DNS服务，随时检测DNS发生的变化，当本地DNS服务模块检测到变化时，它会将变化后的新配置通过通讯模块a发送到涉及相关变化的Trident模块中，Trident模块再更新自身的模型。一方面每当Trident数据模型模块的数据模型发生变化时，Trident会将新的模型发送给Poseidon主模块。当某个Trident服务被终止后，Poseidon主模块会通过Dispatch Controller带着相关配置信息创建一个新的Trident服务。Poseidon将模型反序列化存储在Etcd集群中，由于每一次都是写操作，而新的模型直接覆盖旧模型，因此Poseidon主模块不会马上将数据写入Etcd，而是间隔较长的时间段以后再一次性写入Etcd集群中。本发明通过上述方法尽可能降低服务对于集群的压力。
在本发明部分实施例中：
系统Poseidon是一个主从架构的分布式系统，Poseidon通过Kubernetes部署在集群中，实现了Kubernetes Ingress Gateway的规则从而接管了集群的入口流量，Poseidon运行多份副本保证系统本身各个组件的稳定性，并在内部部署了一个Etcd集群保证数据的一致性和可用性。对于每一个微服务，Poseidon将每个服务的所有副本集合抽象成一个独立的逻辑概念Palace，每个Palace对应一个基于Envoy实现的子网关服务，称作Trident。流量在进入每个Palace前，会先通过Trident进行L7的流量代理，Trident内部运行着一个数据模型，根据该模型以及当前集群的流量状态，Trident会决定将该请求发送到哪一个副本，是否丢弃该请求以及扩容和缩容策略。Trident还会根据流量状态周期性的更新数据模型，确保模型尽可能确实的描述当前集群网络状况。
基于L7层面的自动熔断：Trident模块中根据接口数据模型模块的数据模型以及计数器模块实现基于L7层面的自动熔断，Trident模块会根据当前Palace下的最大并发数目以及数据模型中各个接口在所有接口中被调用的比重得到一个各个接口所允许的最大并发数，当流量进入Trident模块时，判断当前请求是否已经超过对应接口的最大并发数，如果已达到，则请求不再发送到实际服务中，Trident直接丢弃该请求，并返回给外部用户定制化的服务降级结果。
Trident模块中的接口数据模型模块周期性的更新数据模型：初始情况下，只有拥有专有服务副本服务的接口才会设立最高并发阈值，当一些接口合并后，原定的最高并发阈值仍然保留，用做后续使用。对于接口x而言，其最高并发阈值在第一次被分流时会被先设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值会将对应时刻的请求并发数设置为单个服务副本的最高并发阈值。之后，Trident数据模型模块会不断的调整该值，使之尽可能的趋近于真实的最高并发阈值。一方面，当服务副本返回错误情况时，Trident会按一定步长降低最高并发阈值，直至没有错误情况返回。另一方面，当出现较多的请求丢弃时，Trident模块会向Poseidon模块申请资源占用查看请求，若发现内存和CPU使用均未过半时，Trident又会按一定步长增大最高并发阈值。后续若接口合并后又分流，则直接使用该历史最高并发阈值。
Poseidon系统使用一种统一的方式妥善处理Palace下服务副本ip变化的情况。Poseidon使用两方面技术保障当出现上述状况时依旧保持服务的稳定。首先，Poseidon主模块的本地DNS服务模块会监控Kubernetes DNS服务，本地DNS服务模块检测到变化时，它会将变化后的新配置通过通讯模块a发送到涉及相关变化的Trident模块中，Trident模块再更新自身的模型。其次，每当Trident数据模型模块的数据模型发生变化时，Trident会将新的模型发送给Poseidon主模块。当某个Trident服务被终止后，Poseidon主模块会通过Dispatch Controller模块带着相关配置信息创建一个新的Trident服务。Poseidon将模型反序列化存储在Etcd集群中。
本发明第三个实施例提供了一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时可用于执行本发明上述实施例中任一项所述的方法。
可选地，存储器，用于存储程序；存储器，可以包括易失性存储器(英文：volatilememory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)，如静态随机存取存储器(英文：static random-access memory，缩写：SRAM)，双倍数据率同步动态随机存取存储器(英文：Double Data Rate Synchronous Dynamic Random Access Memory，缩写：DDR SDRAM)等；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)。存储器用于存储计算机程序(如实现上述方法的应用程序、功能模块等)、计算机指令等，上述的计算机程序、计算机指令等可以分区存储在一个或多个存储器中。并且上述的计算机程序、计算机指令、数据等可以被处理器调用。
上述的计算机程序、计算机指令等可以分区存储在一个或多个存储器中。并且上述的计算机程序、计算机指令、数据等可以被处理器调用。
处理器，用于执行存储器存储的计算机程序，以实现上述实施例涉及的方法中的各个步骤。具体可以参见前面方法实施例中的相关描述。
处理器和存储器可以是独立结构，也可以是集成在一起的集成结构。当处理器和存储器是独立结构时，存储器、处理器可以通过总线耦合连接。
本发明第四个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可用于执行本发明上述实施例中任一项所述的方法。
本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法，采用本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断系统接管集群中的入口流量，利用Poseidon根据单位时间内的并发情况实现了自动的扩缩容机制，提供了基于L7接口粒度层面的自动熔断功能，用户只需提供很少的配置文件即可使用系统的所有功能，最大程度保证了服务的可用性。
本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，是一种在Kubernetes场景下基于网络情况的微服务自动扩容/缩容以及基于L7层面的自动熔断技术，从而保证了服务的高可用。系统Poseidon通过Kubernetes部署在集群中，实现了Kubernetes Ingress Gateway的规则从而接管了集群的入口流量，系统Poseidon运行多份副本保证系统本身各个组件的稳定性，并在内部部署了一个Etcd集群保证数据的一致性和可用性。对于每一个微服务，系统Poseidon将每个服务的所有副本集合抽象成一个独立的逻辑概念Palace，每个Palace对应一个基于Envoy实现的子网关服务，称作Trident。流量在进入每个Palace前，会先通过Trident进行L7的流量代理，Trident内部运行着一个数据模型，根据该模型以及当前集群的流量状态，Trident会决定将该请求发送到哪一个副本，是否丢弃该请求以及扩容和缩容策略。Trident还会根据流量状态周期性的更新数据模型，确保模型尽可能确实的描述当前集群网络状况。Poseidon根据单位时间内的并发情况实现了基于网络情况的自动扩缩容机制，提供了基于L7接口粒度层面的自动熔断功能，用户只需提供很少的配置文件即可使用系统的所有功能，最大程度保证了服务的可用性。本发明上述实施例提供的面向云原生的微服务自动扩缩容和自动熔断方法及系统，针对目前服务网格的缺陷，在Kubernetes场景下基于网络情况实现微服务自动扩容/缩容以及基于L7层面的自动熔断，保证了服务的高可用。
需要说明的是，本发明提供的方法中的步骤，可以利用系统中对应的模块、装置、单元等予以实现，本领域技术人员可以参照方法的技术方案实现系统的组成，即，方法中的实施例可理解为构建系统的优选例，在此不予赘述。
本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (13)

1.一种面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，包括：
设置云原生系统中集群内部的网关规则，接管集群的入口流量；
针对每一个微服务，将所有的服务副本集合抽象成一个独立的逻辑概念，其中每一个逻辑概念对应一个子网关服务；流量在进入每一个逻辑概念前，均先通过子网关服务进行L7层面的流量转发；
子网络服务根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或对当前服务请求进行扩缩容处理，并结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断。
2.根据权利要求1所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述设置云原生系统中集群内部的网关规则，接管集群的入口流量，包括：
基于Poseidon系统，将Poseidon系统通过Kubernetes部署在集群中，实现KubernetesIngress Gateway的规则，从而接管集群的入口流量。
3.根据权利要求2所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述Poseidon系统同时运行多份服务副本，用于保证系统本身各个组件的稳定性；和/或
所述Poseidon系统内部部署有一个Etcd集群，用于保证数据的一致性和可用性。
4.根据权利要求1所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述子网关服务基于Envoy实现。
5.根据权利要求1所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述丢弃后续服务请求和/或对当前服务请求进行扩缩容处理的方法，包括：
对于每一个逻辑概念，子网关服务确认所有请求的返回情况，当单位时间内某一个服务副本接口x返回的错误率超过MAX_ERROR_RATE时，子网关服务发起一个扩容请求，并在收到扩容成功的申请前，预更新当前集群的网络状态；
当子网关服务接收到扩容成功的申请后，更新当前集群的网络状态，并对该服务副本接口x进行分流，新生成的服务只服务于该服务副本接口x，原服务副本不再接收该服务副本接口x的流量，实现接口粒度上的流量隔离；
当子网关服务发现错误率超过MAX_ERROR_RATE的服务副本本身专有于该服务副本接口x，子网关服务同样会触发申请扩容的流程，并更新当前集群的网络状态，该服务副本接口x采用轮询的方式，将流量发送给准备用于该服务副本接口x的服务副本；
子网关服务根据服务副本接口x熔断情况申请扩容，对于只被单独服务副本服务的接口，维护一个当前集群网络状态动态更新的最高并发阈值；
当单位时间内并发请求数超过阈值时，子网关服务将后续的请求丢弃，以保证先前请求的服务质量；
当丢弃请求数超过最高并发阈值的DROP_PERCENTAGE时，触发子网关服务申请扩容流程；
当服务副本接口x有多个服务副本时，在一段时间内，该服务副本接口x的请求并发数低于对应接口的最高并发阈值的SHRINK_FLAG时，子网关服务申请缩容请求；子网关服务收到缩容成功的申请后，更新当前集群的网络状态；
当服务副本接口x仅有一个服务副本时，子网关服务首先检查是否有同样满足缩容条件的服务，如果不存在相应服务，拒绝本次缩容，否则，触发申请缩容的流程。
6.根据权利要求1所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述结合对当前服务请求的扩缩容处理结果和所转发的L7层面流量，实现L7层面的自动熔断，包括：
针对被单独服务的接口，子网关服务根据当前逻辑概念下的微服务，获取每一个被单独服务的接口所有的最大并发阈值；当流量进入子网关服务时，子网关服务根据接口内容给对应的接口数加一，同时判断当前请求是否已经超过对应接口的最大并发阈值，如果已达到，则请求不再发送到实际服务中，子网关服务直接丢弃该请求，并返回给外部用户定制化的服务降级结果，从而实现L7层面的自动熔断；
针对接收多个接口的服务副本的接口，当单位时间内该接口返回的错误率超过MAX_ERROR_RATE时，子网关服务发起扩容申请，并确定该服务副本的最高分接口，所有进入该服务副本最高分接口的请求被丢弃，其余请求正常发送；
当子网关服务接收到扩容成功的申请后，该服务部分的最高分接口的请求发送到分流后的服务副本。
7.根据权利要求6所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述确定该服务副本的最高分接口的方法，包括：
子网关服务检查各个接口过去多个单位时间内的调用次数，并给每个接口x计算一个分数xscore：
Figure FDA0002786814590000021
其中，ci表示接口x在单位时间i内被调用的次数，n表示当前单位时间内前n个单位时间，ki为相关系数，0<ki<1，随着单位时间i的增大单调递减；b表示该接口x是否返回错误，若是，则值为1，若否，则值为0；h为相关系数，h>1，e表示错误率；
子网关服务将当前时间下分数最高的接口x记录下来，新生成的服务副本将单独服务于该接口，然后等待返回的申请结果。
8.根据权利要求1-7中任一项所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，还包括：
子网关服务根据流量状态，周期性地更新当前集群的网络状态。
9.根据权利要求8所述的面向云原生的微服务自动扩缩容和自动熔断方法，其特征在于，所述子网关服务根据流量状态，周期性地更新当前集群的网络状态，包括：
对于服务副本接口x，其最高并发阈值在第一次被分流时设置为无限，当专有服务副本请求出现扩容请求时，最高并发阈值将对应时刻的请求并发数设置为单个服务副本的最高并发阈值；之后，子网关服务不断调整该单个服务副本的最高并发阈值，使之尽可能的趋近于真实的最高并发阈值；
当服务副本返回错误情况时，子网关服务按一定步长降低该单个服务副本的最高并发阈值，直至没有错误情况返回；
当出现较多的请求丢弃时，子网关服务申请资源占用查看请求，若发现内存和CPU使用均未过半时，则按一定步长增大该单个服务副本的最高并发阈值；
后续若服务副本接口x合并后又分流，则直接使用增大后的单个服务副本的最高并发阈值，完成对当前集群网络状态的更新。
10.一种面向云原生的微服务自动扩缩容和自动熔断系统，其特征在于，包括：
主模块，该主模块用于设置云原生系统中集群内部的网关规则，接管集群的入口流量；
每一个微服务所对应的子网关服务模块，该子网关服务模块用于代理L7层面的流量，并根据当前集群的网络状态和流量状态，将当前服务请求发送至对应接口、丢弃后续服务请求和/或执行基于网络情况的自动扩缩容机制，并结合对当前服务请求的扩缩容处理结果和所代理的L7层面流量，实现L7层面的自动熔断机制。
11.根据权利要求10所述的面向云原生的微服务自动扩缩容和自动熔断系统，其特征在于，所述主模块包括：本地DNS服务模块、记录状态模块、Etcd集群模块、DispatchController模块、Metric模块以及通讯模块a；其中：
所述本地DNS服务模块，用于同步集群中Kubernetes CoreDNS的服务名及其地址；
所述记录状态模块，用于记录所有子网关服务的状态，包括：当前集群中每一个子网关服务模块对应服务的接口情况、数据模型以及配置参数；
所述Etcd集群模块，用于数据持久化，将所述记录状态模块记录的所有子网关服务的状态内容反序列化保存到Etcd集群中；
所述Dispatch Controller模块，用于分发新的子网关服务，并且检查服务的状态；
所述Metric模块，用于周期性的获取各个服务副本的CPU和内存情况；
所述通讯模块a，用以和子网关服务模块通讯，并接收子网关服务模块发出的配置文件内容；
每一个所述子网关服务模块均包括：计数器模块、接口数据模型模块、代理通信模块以及通讯模块b；其中：
所述计数器模块，用于记录单位时间内不同接口访问的次数；
所述接口数据模型模块，用于记录当前时间下子网关服务模块所对应的服务接口数据；
所述代理通信模块，用于L7层面的流量转发；
所述通讯模块b，用于将所述接口数据模型模块所记录的服务接口配置发送给主模块。
12.一种设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时可用于执行权利要求1-8中任一项所述的方法。
13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时可用于执行权利要求1-8中任一项所述的方法。
CN202011300768.2A 2020-11-19 2020-11-19 面向云原生的微服务自动扩缩容和自动熔断方法及系统 Active CN112463366B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011300768.2A CN112463366B (zh) 2020-11-19 2020-11-19 面向云原生的微服务自动扩缩容和自动熔断方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011300768.2A CN112463366B (zh) 2020-11-19 2020-11-19 面向云原生的微服务自动扩缩容和自动熔断方法及系统

Publications (2)

Publication Number Publication Date
CN112463366A true CN112463366A (zh) 2021-03-09
CN112463366B CN112463366B (zh) 2022-12-06

Family

ID=74837505

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011300768.2A Active CN112463366B (zh) 2020-11-19 2020-11-19 面向云原生的微服务自动扩缩容和自动熔断方法及系统

Country Status (1)

Country Link
CN (1) CN112463366B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114125055A (zh) * 2021-11-30 2022-03-01 神州数码系统集成服务有限公司 多协议自动适配云原生网关系统控制方法、系统、设备及应用
CN114143313A (zh) * 2021-11-30 2022-03-04 招商局金融科技有限公司 基于云原生的集群通信装置、方法及相关设备
CN114357239A (zh) * 2022-01-07 2022-04-15 重庆紫光华山智安科技有限公司 一种自动化视图库服务保障系统和方法
US11388253B1 (en) 2021-03-30 2022-07-12 Teso LT, UAB Proxy selection by monitoring quality and available capacity
CN114979276A (zh) * 2022-05-13 2022-08-30 深信服科技股份有限公司 一种资源动态调度方法、装置、设备及存储介质
CN116069264A (zh) * 2023-03-13 2023-05-05 南京飓风引擎信息技术有限公司 一种应用程序数据信息存储控制系统
US11652890B1 (en) 2022-07-13 2023-05-16 Oxylabs, Uab Methods and systems to maintain multiple persistent channels between proxy servers
CN116932231A (zh) * 2023-09-18 2023-10-24 北京睿企信息科技有限公司 一种分布式集群的扩缩容系统
CN116932290A (zh) * 2023-09-18 2023-10-24 北京睿企信息科技有限公司 一种获取目标模型的数据处理系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107566508A (zh) * 2017-09-19 2018-01-09 广东电网有限责任公司信息中心 一种自动化运维的短信微服务系统
CN109274547A (zh) * 2018-08-17 2019-01-25 中国平安人寿保险股份有限公司 基于网络安全的服务熔断方法、装置、设备及存储介质
US20190179720A1 (en) * 2017-12-07 2019-06-13 Red Hat, Inc. Reducing service disruptions in a micro-service environment
CN110209492A (zh) * 2019-03-21 2019-09-06 腾讯科技（深圳）有限公司 一种数据处理方法及装置
CN110990245A (zh) * 2019-12-04 2020-04-10 北京明略软件系统有限公司 基于调用链数据的微服务运行状态判断方法及装置
CN111600807A (zh) * 2020-04-14 2020-08-28 网宿科技股份有限公司 一种基于api网关设备的流量控制方法和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107566508A (zh) * 2017-09-19 2018-01-09 广东电网有限责任公司信息中心 一种自动化运维的短信微服务系统
US20190179720A1 (en) * 2017-12-07 2019-06-13 Red Hat, Inc. Reducing service disruptions in a micro-service environment
CN109274547A (zh) * 2018-08-17 2019-01-25 中国平安人寿保险股份有限公司 基于网络安全的服务熔断方法、装置、设备及存储介质
CN110209492A (zh) * 2019-03-21 2019-09-06 腾讯科技（深圳）有限公司 一种数据处理方法及装置
CN110990245A (zh) * 2019-12-04 2020-04-10 北京明略软件系统有限公司 基于调用链数据的微服务运行状态判断方法及装置
CN111600807A (zh) * 2020-04-14 2020-08-28 网宿科技股份有限公司 一种基于api网关设备的流量控制方法和系统

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11817946B2 (en) 2021-03-30 2023-11-14 Oxylabs, Uab Proxy selection by monitoring quality and available capacity
US11388253B1 (en) 2021-03-30 2022-07-12 Teso LT, UAB Proxy selection by monitoring quality and available capacity
US11463537B1 (en) 2021-03-30 2022-10-04 Teso LT, UAB Proxy selection by monitoring quality and available capacity
WO2022208175A1 (en) * 2021-03-30 2022-10-06 Teso LT, UAB Proxy selection by monitoring quality and available capacity
US11606438B2 (en) 2021-03-30 2023-03-14 Oxylabs, Uab Proxy selection by monitoring quality and available capacity
CN114143313A (zh) * 2021-11-30 2022-03-04 招商局金融科技有限公司 基于云原生的集群通信装置、方法及相关设备
CN114125055A (zh) * 2021-11-30 2022-03-01 神州数码系统集成服务有限公司 多协议自动适配云原生网关系统控制方法、系统、设备及应用
CN114143313B (zh) * 2021-11-30 2024-03-19 招商局金融科技有限公司 基于云原生的集群通信装置、方法及相关设备
CN114125055B (zh) * 2021-11-30 2023-12-12 神州数码系统集成服务有限公司 多协议自动适配云原生网关系统控制方法、系统、设备及应用
CN114357239A (zh) * 2022-01-07 2022-04-15 重庆紫光华山智安科技有限公司 一种自动化视图库服务保障系统和方法
CN114979276A (zh) * 2022-05-13 2022-08-30 深信服科技股份有限公司 一种资源动态调度方法、装置、设备及存储介质
CN114979276B (zh) * 2022-05-13 2024-02-23 深信服科技股份有限公司 一种资源动态调度方法、装置、设备及存储介质
US11652890B1 (en) 2022-07-13 2023-05-16 Oxylabs, Uab Methods and systems to maintain multiple persistent channels between proxy servers
US11936742B2 (en) 2022-07-13 2024-03-19 Oxylabs, Uab Methods and systems to maintain multiple persistent channels between proxy servers
CN116069264A (zh) * 2023-03-13 2023-05-05 南京飓风引擎信息技术有限公司 一种应用程序数据信息存储控制系统
CN116932290A (zh) * 2023-09-18 2023-10-24 北京睿企信息科技有限公司 一种获取目标模型的数据处理系统
CN116932231A (zh) * 2023-09-18 2023-10-24 北京睿企信息科技有限公司 一种分布式集群的扩缩容系统
CN116932290B (zh) * 2023-09-18 2023-12-08 北京睿企信息科技有限公司 一种获取目标模型的数据处理系统
CN116932231B (zh) * 2023-09-18 2023-12-22 北京睿企信息科技有限公司 一种分布式集群的扩缩容系统

Also Published As

Publication number Publication date
CN112463366B (zh) 2022-12-06

Similar Documents

Publication Publication Date Title
CN112463366B (zh) 面向云原生的微服务自动扩缩容和自动熔断方法及系统
US11360854B2 (en) Storage cluster configuration change method, storage cluster, and computer system
WO2020253266A1 (zh) 一种提供边缘服务的方法、装置和设备
CN105607954B (zh) 一种有状态容器在线迁移的方法和装置
US9999030B2 (en) Resource provisioning method
CN105376303B (zh) 一种Docker实现系统及其通信方法
US8375001B2 (en) Master monitoring mechanism for a geographical distributed database
US7870419B2 (en) Subscription-based management and distribution of member-specific state data in a distributed computing system
CN104601680B (zh) 一种资源管理方法及装置
WO2012065426A1 (zh) 一种分布式缓存系统中负荷分配方法、装置及服务器
JP2001051890A (ja) 仮想分散ファイルサーバシステム
CN111338806B (zh) 一种业务控制方法及装置
CN111585887B (zh) 基于多个网络的通信方法、装置、电子设备及存储介质
CN108228393A (zh) 一种可扩展的大数据高可用的实现方法
WO2021120633A1 (zh) 一种负载均衡方法及相关设备
Chang et al. Write-aware replica placement for cloud computing
Dustdar et al. Dynamic replication and synchronization of web services for high availability in mobile ad-hoc networks
CN103140851A (zh) 包括中间件机环境的系统
CN112540827A (zh) 一种基于k8s平台的负载均衡系统及实现方法
CN115225645B (zh) 一种服务更新方法、装置、系统和存储介质
CN112822062A (zh) 一种用于桌面云服务平台的管理方法
CN114615268B (zh) 基于Kubernetes集群的服务网络、监控节点、容器节点及设备
JP6591045B2 (ja) ネットワークサービスを移行するための方法及びネットワークサービス装置
WO2023077791A1 (zh) 一种业务处理的方法、系统以及装置
JP2015041938A (ja) ネットワーク制御方法

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
GR01 Patent grant
GR01 Patent grant