用于控制水平扩展软件应用中的利用率的方法和装置

摘要

本发明包括用于水平扩展应用中的分布式业务控制的装置和方法，其中，基于软件的应用被实现为多个对等应用实例，每一个应用实例提供应用的总能力或容量的一部分。在每一个应用实例处实例化或以其他方式实现包括分布式业务控制器的装置，并且这些装置共同操作以根据例如服务水平协议或SLA限制各个客户端或附属客户端组对应用的总利用率，并且还操作以防止应用实例中的任意一个的不成比例利用率。有利地，根据本文的教导在分布式业务控制器之间使用有效信息传播协议来完成这些操作。

说明书

技术领域

本发明大体上涉及分布式处理，具体地，涉及水平扩展 (horizontally scaled)处理系统。

背景技术

在本文设想的类型的水平扩展系统中，在多个对等应用实例中实 现整个软件应用，每一个对等应用实例提供了应用的整个功能并且每 一个对等应用实例表示总应用容量或性能能力的一部分。然而，用于 管理来自客户端池的应用业务的现有解决方案基于通常对于水平扩展 系统不成立的大量假设。

这种操作源自以下传统假设：在单个实例中执行针对客户端池的 业务控制，例如，通过单个硬件服务器建立整个系统，并且通过单个 点来路由所有业务，其中可以在该单个点处对业务进行观测和控制。 然而，在水平扩展系统中，例如由于故障、升级等，硬件和/或软件实 例可能在任意时间点来去。

可能更关键的是，从客户端池向水平扩展应用中的对等应用实例 分发业务可能导致一些应用实例被过度利用而一些应用实例未被充分 利用。例如，给定客户端或至少源自相同客户端上下文的给定连接可 能比其他客户端或连接“更具粘性”。在这一方面，“粘性”连接是持 久的并且与持续的应用业务相关联。

本文认为以循环“负载分发”方案向各个应用实例指派来自不同 客户端池的应用业务未考虑以下事实：由分布式应用业务引起的粘性 连接可能聚合在应用实例中的一个或多个处。此外，在对等应用实体 之间同步业务控制参数的状态在可用网络带宽和达到和/或维护同步 状态所需的消息数量方面可能是昂贵的。

发明内容

本发明包括用于水平扩展应用中的分布式业务控制的装置和方 法，其中，基于软件的应用被实现为多个对等应用实例，每一个应用 实例提供应用的总能力或容量的一部分。在每一个应用实例处实例化 或以其他方式实现包括分布式业务控制器的装置，并且这些装置共同 操作以根据例如服务水平协议或SLA限制各个客户端或附属客户端 组对应用的总利用率，并且还操作以防止应用实例中的任意一个的不 成比例利用率。有利地，根据本文的教导在分布式业务控制器之间使 用有效信息传播协议来完成这些操作。

在更详细的示例中，本文的教导公开了控制单独客户端对软件应 用的利用率的方法。应用被实现为多个对等应用实例，这些对等应用 实例从多个客户端中的任意一个或多个客户端接收应用业务，并且在 每一个应用实例处实现所述方法。

有了该理解，所述方法包括：将进入进入所述应用实例的应用业 务分类为与所述客户端中的不同客户端和/或不同类型的应用业务相 对应的流；以及关于所述应用实例估计每一个流的本地需求值。所述 方法还包括：与所述应用实例中的一个或多个其他应用实例交换本地 需求信息。所述交换包括：发送针对所述应用实例处的所述流所估计 的本地需求值，以及接收所述应用实例中的其他应用实例处的所有相 似流的相似估计的本地需求值。

根据该方法，在每一个应用实例处使用交换的本地需求信息来确 定应用实例处的每一个流的总体需求值。关于应用确定总体需求值。 在这个意义上，在非限制性示例中可以将针对给定应用实例处的给定 流所确定的总体需求值理解为针对该应用实例处的该流所估计的本地 需求值和针对其他应用实例处的所有相似流所估计的本地需求值之和。

有利地，所述方法继续使用针对每一个流所确定的总体需求值来 计算应用实例处的流的本地利用率限制。

相应地，所述方法还包括：根据是否超出所述流的本地利用率限 制，将每一个流中的应用业务标记为不符合策略业务或符合策略业务。 该操作可以被理解为第一级监管，在该第一级监管中应用了逐流利用 率限制。

作为第二步或第二级监管，所述方法附加地包括：确定所述应用 实例处的所有流的应用业务的聚合是否超出本地聚合利用率限制。根 据所述方法，基于是否超出所述本地聚合利用率限制和/或基于对符合 策略业务和不符合策略业务的区分，控制对去往所述应用实例的聚合 应用业务的缓存。例如，虽然可以响应于不符合策略业务来约束单独 流，但是也可以是以下情况：对聚合应用业务进行缓存涉及：至少在 超出本地聚合利用率限制期间向符合策略业务和不符合策略业务应用 不同的缓存优先级。

在本文教导的一个或多个实施例中使用包括分布式业务控制器 和通信控制器的装置实现上述方法及其变形或扩展。装置可以是基于 软件的，例如，根据存储在计算机可读介质中的计算机程序指令的执 行被实现为逻辑或功能电路。在示例性情况下，装置被实现为每一个 应用实例的一部分，或者被实现为联合主机操作系统环境中的应用实 例执行的伴随程序。

在示例性配置中，分布式业务控制器将进入进入其相关联的应用 实例的应用分类为流，并且对每一个流应用第一级基于令牌桶的监管。 也即是说，将逐流令牌桶监管方案应用于每一个流中的业务，以根据 是否超出流的本地利用率限制将流中的应用业务标记为符合策略的或 不符合策略的，并且可选择地，以每一个流为基础应用第一级业务调 节(例如，通过丢弃来自流的应用业务中的一些)。

根据由分布式业务控制器针对与该分布式业务控制器配对的应 用实例处的流所估计的本地需求值和由其他分布式业务控制器在其他 应用实例处针对所有相似流所估计的本地需求值来确定这些逐流利用 率限制。也即是说，通过每一个应用实例处的每一个流的分类参数—— 例如，业务类型、客户端域等——来定义该流，并且具有相同分类参 数的另一应用实例处的任意流是相似流。因此，与任意给定流相关联 的总需求或总体需求取决于所有应用实例之间的所有相似流的本地需 求。

与分布式业务控制器配对的通信控制器交换本地需求信息，从而 提供本地需求值在所有分布式业务控制器之间的传播，从而使得能够 在考虑所有其他应用实例处的相应流需求的情况下计算准确的总体需 求值并且以每一个流为基础动态地调节本地利用率限制。

作为另一优点，每一个分布式业务控制器向每一个应用实例处的 应用业务的聚合——即，组合应用实例处的所有各流的聚合流——应 用第二级监管。聚合级的监管可以涉及：根据是否超出本地聚合利用 率限制来选择性地调节聚合流。

根据独立权利要求的本发明的效果是针对给定应用实例处的给 定流所准许的容量或其他应用资源的比例随着与该流相关联的总体需 求而改变。当然，本发明不限于这些或其他前述特征和优点。实际上， 本领域技术人员在阅读以下详细描述之后并且在查看附图之后将认识 到附加特征和优点。

附图说明

图1是实现水平扩展应用的分布式处理系统的一个实施例的框图。

图2是示出了图1的分布式处理系统的示例性细节的框图。

图3是本文设想的分布式业务控制器的一个实施例的框图。

图4是图3的分布式业务控制器的其他示例性细节的框图。

图5是本文设想的分布式业务控制方法的一个实施例的逻辑流程 图。

图6A和图6B是提供可以在分布式业务控制器中实现的业务分类 器和逐流(per-flow)监管布置的其他示例性细节的框图。

图7是图示了基于将应用业务标记为符合策略或不符合策略的逐 流监管的一个实施例的框图。

图8A、图8B以及图9-11是由分布式业务控制器根据本文教导 的一个或多个实施例执行的基于令牌桶的业务监管的逻辑流程图。

图12是在分布式业务控制器之间交换本地需求信息的一个实施 例的信号流程图。

图13是产生并发送同步(SYN)消息作为交换本地需求信息的 一部分的一个实施例的逻辑流程图。

图14是接收并处理在分布式业务控制器处接收的特定消息类型 作为交换本地需求信息的一部分的一个实施例的逻辑流程图。

图15是图示了本文的分布式业务控制教导规定的分布式业务控 制的示例的示意图。

具体实施方式

图1示出了基于软件的应用10，其在该讨论中被称作“应用10”。 客户端池12-1、12-2等使用应用10，并且将理解的是，每一个客户端 12-1、12-2等将在使用应用10时消耗其总容量或能力的特定部分。为 了便于参考，在没有后缀的情况下使用附图标记12来一般地指代客户 端12-1、12-2等中的任意一个或多个。因此，术语“客户端12”和“多 个客户端12”分别是指客户端中的任意一个和客户端中的任意两个或 更多个。

此外，如本文所使用的术语客户端是“多含义”术语。通常，客 户端12包括某一软件组件实例——该软件组件实例在系统设备或系 统中被实例化——该软件组件实例产生去往应用10的一种或多种应 用业务。示例性客户端12可以产生多个不同消息类型，例如，创建、 读取、更新等，并且每一个消息类型可以被视为关于应用10的各个业 务“流”，其中每一个此类流可以通过服务水平协议或SLA来管理， 其中，服务水平协议或SLA是在提供应用10的组织与经由一个或多 个客户端12利用应用的订制组织之间协商的。附属于订制组织的多个 用户可以运行多个相似客户端12或多个不同类型的客户端12，每一 个客户端12根据SLA条款利用应用10，其中，SLA条款可应用于由 所有此类客户端12对应用10的共同利用。

记住上面提及的方案，可以看到，应用10被实现为多个对等应 用实例14-1、14-2等。除非为了清楚起见而需要后缀，否则该讨论将 使用术语“应用实例14”来一般地指代应用实例14-1、14-2等中的任 意给定应用实例，并且将类似地使用术语“多个应用实例14”来指代 应用实例14-1、14-2等中的任意给定两个或更多个应用实例。

每一个应用实例14作为应用10的副本操作，因此提供应用10 的整个功能，但是仅提供总应用能力或容量的一部分。通过对等应用 实例14的集合以水平扩展形式表示可以根据每秒事务量等来测量的 总能力或容量。应用10(全体地)以及每一个应用实例14将被理解 为包括以下各项或由以下各项表示：在数字处理电路中实现的功能电 路配置和一个或多个计算机系统上的相关联存储器，例如，运行操作 系统的服务器，其中，应用实例14在该操作系统中执行。附图以全体 意义描绘了该处理电路，其被称作“分布式处理系统16”。

客户端12中的单个客户端经由通过一个或多个计算机网络18(例 如，一个或多个公共数据网络或私有数据网络，可以包括互联网，并 且可以包括在其中支持虚拟专用网(VPN)连接)的通信耦合与应用 实例14中的单个应用实例进行通信。每一个客户端12向应用10发送 应用业务，其中，该业务包括例如根据定义协议发送的请求消息。负 载均衡器20接收从客户端池12输入的应用业务，并且使用例如循环 分发功能将其分发给应用实例14中的相应应用实例，其中，进入进入 负载均衡器20的每一个新应用消息或一批新的应用消息被分发给应 用实例14中的下一个。

因此，进入进入应用实例14中的任意一个的应用业务包括任意 数量的应用业务流22，如上所述。也即是说，针对任意给定应用实例 14，输入的应用业务可以包括来自客户端12中的多个客户端的多种类 型的消息。

稍后将在本文中详细描述的处理在逻辑上将进入进入每一个应 用实例14的应用业务分离为各个流22，其中每一个流22通常表示给 定类型的应用业务并且具有给定的客户端关联。客户端关联可以是特 定的，例如，来自客户端12-1或12-2的业务等，或者客户端关联可 以是域方面的关联，例如，与相同的SLA与其他订制许可相关联的任 何客户端12，其中所述其他订制许可给予所有此类客户端12对应用 10的访问权。在这一方面，还应当注意的是，从负载均衡器20进入 进入任何给定应用实例14的应用业务通常还未在逻辑上分类为流 22——这种分类是结合本文教导的分布式业务控制执行的。因此，图 1中的标签“22”的布置并不旨在如同该术语在本文被定义的一样仅 是指输入业务包括与任意数量的流22相关联的业务。

虽然负载均衡器20采取的业务分发方法可以“公平地”向各个 应用实例14分发初始请求消息，但是这些请求中的一些请求被快速地 服务，同时请求涉及与后续业务的“粘性”或持久连接，其中，后续 业务锚定到该粘性连接。因此，不是每一个输入请求消息或其他类型 的业务都在接收应用实例14处导致相同的处理负载。因此，当在不考 虑该业务的粘性的情况下分发应用业务时，可以出现负载失衡。

因为从各种客户端12到应用实例14中的任意一个的应用业务的 混合流表示粘性事务和非粘性事务的任意可能的组合，因此每一个应 用实例14包括被配置为控制应用业务的特定流对软件应用10的最大 总利用率的装置28或者与该装置28配对。简而言之，装置28提供了 对应用实例14的集合的复杂形式的分布式业务控制，而未妨碍应用 10的性能并且无需其之间的大量信令。

将理解的是，装置28可以表示例如通过执行存储的计算机程序 指令在分布式处理系统16的数字处理电路中实现的功能电路布置，其 中，存储的计算机程序指令具体实现本文针对装置28所述的处理逻辑。 还将理解的是，装置28可以在每一个应用实例处被复制，使得针对包 括整个应用10的相应应用实例14实现相似的装置28。每一个此类装 置28可以实现在包括应用实例14的计算机程序中，或者可以实现为 关于应用实例14的附属或“伴随”程序。

装置28包括分布式业务控制器30，在附图中将该分布式业务控 制器30缩写为“DTC”。为了方便起见，在下文中将使用缩写词“DTC”。 DTC 30被配置为关于应用实例14针对应用实例14处的应用业务的每 一个流22估计本地需求值。

装置28还包括通信控制器32，在附图中根据缩写词CC对通信 控制器32进行描绘。在下文中将使用该缩写词。CC 32被配置为与应 用实例14中的一个或多个其他应用实例交换本地需求信息。交换本地 需求信息包括：发送在应用实例14处针对应用实例14处的应用业务 的每一个流22估计的本地需求值，以及接收应用实例14中的其他应 用实例处的相似流22的相似估计的本地需求值。

如本文稍后将详细描述的，如果两个不同应用实例14处的应用 业务的两个流22包括相同类型的应用业务并且源自相同的客户端12 或者源自相同的客户端域或上下文，则它们被认为是“相似流”。术语 “域”是指以下情况：使用单个订制实体标识潜在很多客户端12，使 得源自这些客户端12的所有应用业务属于相同的客户端域或者上下 文，从而作为整体符合由订制实体签订的SLA。更简单的说，如果应 用实例14之一处的流22和另一应用实体14处的另一流22的分类是 相同的(例如，两个流22包括相同类型的应用业务并且两个流22与 相同的客户端上下文相关联)，则应用实例14之一处的流22与另一应 用实体14处的另一流22“相似”。

还需要注意的是，图1中针对装置28提议的逻辑或功能电路分 离可以具有某些优点，例如，布置将装置28分离为逻辑控制器30和 32，其中一个此类控制器在其相应应用实例14处处理分布式业务控制， 另一个此类控制器处理装置28之间的信息交换从而维持所有DTC 30 之间的状态同步。然而，也可以实现组合的控制电路和/或可以使用其 他功能划分来实现装置28。因此，所描绘的布置不应当被理解为限制 性的。

DTC 30被进一步配置为在整体意义上关于应用10确定应用实例 14处的每一个流22的总体需求值。这可以被理解为评定在应用实例 14处确定的每一个流22的本地需求值、以及评估其他应用实例14处 的所有相似流22的本地需求值。因此，与每一个流22相关联的总体 需求值的确定基于CC 32之间对本地需求信息的交换。

DTC 30被进一步配置为：根据针对每一个流22所确定的总体需 求值来计算该流22的本地利用率限制；根据是否超出流22的本地利 用率限制来将每一个流中的应用业务标记为不符合策略业务或符合策 略业务；确定应用业务14处的所有流22中的应用业务的聚合是否超 出本地聚合利用率限制；以及基于是否超出本地聚合利用率限制以及 对符合策略业务和不符合策略业务的区分，以每一流和/或聚合流为基 础控制对去往应用实例14的聚合应用业务的缓存。

因此，在至少一些实施例中，DTC 30可以被理解为基于使用针 对DTC 30处的流22和其他应用实例14处的相似流22所确定的利用 率(需求)信息来确定应用实例14处的每一个流22的本地利用率限 制，对每一个单独流22中的应用业务流进行监管，其中，流22的本 地利用率限制与流22和其所有相似流22所表示的总需求成正比。这 允许对所有应用实例14之间的所有相似流22的应用业务进行共同监 管，并且对客户端的应用业务施加总体控制或网络控制，而无需集中 式的流控制机制。

在一些实施例中，DTC 30被配置为与CC 32协作以通过经由基 于gossip的逆熵协议与应用实例14中的一个或多个其他应用实例进 行通信来交换本地需求信息，其中，经由基于gossip的逆熵协议将在 应用实例14中的任意一个处估计的本地需求值传播到应用实例14的 所有其他应用实例。参见例如Van Renesse,R.,Dumitriu,D.,Gough,V., &Thomas,C.,“Efficient Reconciliation and Flow Control for  Anti-Entropy Protocols,”Second Workshop on Large-Scale Distributed  Systems and Middleware(LADIS 2008),Yorktown Heights,NY:ACM (ISBN:978-1-60558-296-2)。此外，参见Bailly F,Longo G.,Biological  organization and anti-entropy,J BiolSyst 17(1):63–96(2009)。这两个参 考文献提供了基于gossip的信息交换的示例性细节，并且它们通过引 用的方式并入本文。

返回DTC 30的示例性细节，本文设想了多种用于估计每一个流 22的本地需求值的方法。在非限制性示例中，DTC 30被配置为通过 以下至少一种方式来估计每一个流22的本地需求值：对应用实例14 处针对流22活动的协议会话的数量进行计数；基于在定义间隔内在流 22中是否存在任何新业务来估计预期的流速率；以及基于测量流22 中的应用业务的到达速率来估计预期流速率。

每一个DTC 30还被配置为确定其相应的应用实例14处的每一个 流22的总体需求值。该总体需求值当然是关于整个应用10来确定的， 并且例如通过对针对流22估计的本地需求值和其他应用实例14处的 DTC 30针对相似流22估计的本地需求值进行求和来确定该总体需求 值。通过经由CC 32在DTC 30之间交换本地需求信息来获知该信息。

关于确定应用实例14中的任何给定应用实例处的每一个流22的 本地利用率限制，在一些实施例中，相应的DTC 30被配置为通过计 算每一个流22中的应用业务的本地流速率限制来计算该流22的本地 利用率限制。在这一方面，需要记住的是，每一个应用实例14观测到 来自各个客户端12的由负载均衡器20动态分发的应用业务的混合； 因此，任何给定应用实例处的DTC 30可以被配置为基于业务类型、 与请求相关联的起源标识等将输入的应用业务归类或以其他方式分类 为不同的流22。例如，流22可以是soap/http或远程登录消息中包含 的来自给定客户端12的所有应用请求，其中，所有请求具有相同的用 户标识。每一个流22可以与特定服务水平协议或SLA相关联。因此， DTC 30必须以分散方式操作，但是履行应用10关于客户端12及其相 应或组合的应用业务流22要整体满足的SLA承诺。

在一些实施例中，每一个给定DTC 30还被配置为通过以下方式 计算每一个流22中的应用业务的本地流速率限制：用比例因子缩放所 有相似流22的已知总最大流速率限制来计算本地流速率限制，其中， 比例因子被确定为流22的本地需求值与该流22和其他应用实例处的 其所有相似流22的总体需求值之比。总最大流速率限制可能源自SLA 或其他预配置的约束，并且可以是存储器中存储的配置数据项，其中， 存储器包括在每一个装置28中或者可以由每一个装置28访问。还应 当注意的是，DTC 30还可以被配置为进一步通过计算流22中的应用 业务的本地突发大小限制来计算流22的本地利用率限制。

因此，在每一个应用实例14处，从负载均衡器20进入进入应用 实例14的应用业务可以被分类为流22，其中，每一个流22服从监管 ——例如，最大流速率和/或突发大小限制——并且根据聚合利用率限 制对应用实例14处的此类流22的应用业务的聚合流进行进一步约束。 每一个DTC 30关于应用实例14中的相应应用实例的此类操作允许以 以下方式对应用利用率进行分散控制：防止各个客户端12或附属多个 客户端12使给定的应用实例14超负荷，同时仍然确保应用10满足关 于这些客户端12的SLA要求。

关于控制对去往应用实例14的应用业务的聚合流的缓存，在一 些实施例中，DTC 30被配置为将聚合的应用业务缓存在一个或多个延 迟缓存中，并且根据优先级划分方案对针对应用实例14的一个或多个 延迟缓存进行清空，其中，与不符合策略业务相比，该优先级划分方 案通常对符合策略业务施加更短的缓存延迟。

例如，如果超出本地聚合利用率限制，则DTC 30例如通过根据 优先级划分方案清空缓存来调节去往应用实例14的应用业务的聚合 流，其中，与符合策略应用业务相比，优先级划分方案不喜欢不符合 策略应用业务。由于不符合策略应用业务表示给定流22的本地过度利 用，因此这具有以下影响：对应用实例14处的一个或多个流22进行 节流或抑制。

当然，如上所述，DTC 30可以被进一步配置为根据可用于各个 流22的任何SLA中定义的一个或多个服务参数来对一个或多个延迟 缓存中的任何聚合应用业务划分优先级。此外，如上所述，以每一个 流为基础将应用业务标记为符合策略或不符合策略。因此，一个流22 可能在任意时刻过度利用应用实例14，使得该流22中的业务被标记 为不符合策略，而处于其本地利用率限制以下的另一流22中的业务被 标记为符合策略业务。

通过将输入的应用业务分类为流22以及将每一个流22的应用业 务标记为符合策略业务或不符合策略业务，DTC 30可以被进一步配置 为根据需要对流22中的各个流中的应用消息进行节流或选择性丢弃， 从而维持与在可用于流22的相应SLA中保证的最大服务水平的符合 性。因此，可以在每一个应用实例14处针对各个流22以及通过各个 流22的组合表示的聚合流应用业务整形、选择性分组丢弃或者其他类 型的应用业务速率限制或调节。

图2示出了应用实例14及其相应装置28可以实现在相同或分离 的计算系统——例如，相同或分离的服务器硬件——上，并且还可以 使用虚拟化服务器来实现。在该示例性示意图中，应用实例14-1和 14-2被实现在驻留在第一物理服务器上的虚拟化服务器上，该虚拟化 服务器为其执行提供了操作系统环境。当然，其相应装置28驻留在该 相同的操作系统环境中。

应用实例14-3和14-4及其相应装置28也驻留在该相同的服务器， 但是它们是在托管应用实例14-1和14-2的虚拟化服务器之外实现的。 两个附加服务器中的每一个托管图示中所示的两个附加应用实例14-5 和14-6中的相应应用实例。这些附加服务器可以或不可以与其他服务 器位于同一位置处，但是它们至少可通信地链接，以提供在相应的装 置28中的CC 32之间交换本地需求信息。

图3示出了结合每一个应用实例14实现的装置28中包括的DTC 30的示例性功能电路实现。在所示的示例中，DTC 30包括SLA分类 器40、SLA限制器42、需求存储设备33、速率计算器46、以及需求 分发器加接收机48，其可以被理解为包括整个CC 32或CC 32的元件， 以用于交换本地需求信息。

DCT 30的输入应用业务是由负载均衡器20(未示出)向应用实 例发送的所有应用业务的聚合，并且因此包括来自任意数量的流22 的业务的混合。同样地，流出DTC 30并且流入应用实例14的应用业 务表示聚合流。然而，与DTC 30观测到的来自负载均衡器20的输入 聚合相比，可以对从DTC 30到应用实例的业务的聚合流进行监管、 整形、或以其他方式调节。例如，与流入DTC 30的聚合应用业务相 比，可以对流出DTC 30的聚合应用业务进行速率限制或其他方式整 形。

为了更好地理解示例性配置中的SLA限制器42的操作，图4示 出了根据一个实施例的SLA限制器42的功能电路配置。在所示的实 施例中，SLA限制器42包括令牌桶选择器50，在附图及下文中简称 为“TB选择器50”。SLA限制器42还包括业务监管器52，该业务监 管器52在逻辑上包括针对相应流22(标记为“A”、“B”、“C”等) 的令牌桶“A”、“B”、“C”等，并且使用这些令牌桶操作。此外，SLA 限制器42包括TB监管SLA限制器54、队列处理器56、以及相应的 高优先级队列58和低优先级队列60，相应的高优先级队列58和低优 先级队列60实际上可以包括多个高优先级队列和低优先级队列并且 可以在主机操作环境中在装置28可用的工作存储器中被实现。这些实 体可以作为整体被理解为SLA实施器62。

虽然针对这些详细功能电路布置的操作给出了示例性细节，但是 这有助于参考每一个装置28实现的整个操作方法。图5提供了该方法 的示例，在示意图中将该方法表示为“方法500”。方法500将被理解 为控制单独客户端12对软件应用10的最大总利用率的方法，其中， 跨越多个对等应用实例14实现应用10，所述多个对等应用实例14接 收从多个客户端12动态地分发给它们的应用业务。

每一个应用实例14处的方法500包括：将进入进入应用实例14 的应用业务划分为流22(框502)；关于应用实例14对每一个流22 的本地需求值进行估计(框504)；与应用实例14中的一个或多个其 他应用实例交换本地需求信息(框506)，包括：发送在应用实例14 处针对应用实例14处的每一个流22估计的本地需求值，以及接收其 他应用实例处的相似流22的相似估计的本地需求值；基于交换的本地 需求信息关于应用10确定流22的总体需求值(框508)；根据针对每 一个流22所确定的总体需求值来计算该流22的本地利用率限制(框 510)；以及根据是否超出流22的本地利用率限制将每一个流22中的 应用业务标记为不符合策略业务或符合策略业务(框512)。

方法500还包括：确定应用实例14处的所有流22的应用业务的 聚合是否超出本地聚合利用率限制(框514)；以及基于是否超出本地 聚合利用率限制和/或基于例如根据缓存优先级对符合策略业务和不 符合策略业务的区分，来控制对去往应用实例的聚合应用业务的缓存。

方法500以分散方式控制任意数量的服务器/应用实例14之间的 应用业务，并且其主要优点是产生任意数量的客户端12对应用资源的 受控共享。概括地说，利用本文设想的装置28和方法500，不存在对 资源分配进行实施或控制的中心点。更确切地说，每一个装置28用作 应用实例14中的相应应用实例的业务调节器，并且运行两个主要算法： 由DTC 30提供的本地业务控制算法以及由CC 32提供的状态传播算 法。

虽然以下细节可以在某些方面改变，但是在一个或多个实施例中， 每一个应用实例14处的DTC 30基于在一个或多个分类流22中针对 应用实例14输入的应用业务定期地计算并存储“需求”。使用传播算 法将这些估计的需求值定期地且有效地传播到其他DTC 30——即，将 每一个DTC 30处计算的本地需求信息与其他DTC 30共享。此外，每 一个DTC 30基于其自己的需求计算和其他DTC 30的需求计算以及用 相同的测量项表示总应用容量的配置或已知的值来计算资源限制值— —例如，速率。每一个DTC 30基于调节应用实例处的应用业务流22 来限制每一个流22中由其相应应用实例14处理的应用业务，而不论 其对等体如何，从而提供应用容量的公平或均衡共享。

因此，应用实例14本身不需要共享状态信息，并且应用实例14 与其对等应用实例14相比不具有特殊作用。类似地，装置28与其对 等装置28相比不具有特殊作用。每一个装置28简单地使用在装置28 之间传播的本地需求值以相似的方式操作，以在每一个应用实例处提 供独立的业务调节功能，但是这允许整个应用10满足针对各个客户端 12的SLA要求，而不允许这些客户端中的任意一个过度利用应用10。 因此，装置28在应用实例14之间提供了足够的协调以在应用级别实 施SLA。

如上所述，可以基于与针对任意给定应用实例14输入的应用业 务相关联的起源标识将该业务分类为不同的流。例如，流可以是 soap/http或远程登录消息中包含的来自客户端12的请求，其中，所有 此类请求具有相同的用户标识。因此，每一个流可以与特定SLA相关 联，例如，应用10要整体满足的最小请求速率和/或最大突发大小。

为了进一步讨论示例性操作细节，转回图3，SLA分类器40读取 或以其他方式确定针对给定应用业务——例如，给定输入请求消息— —的客户端标识，并且针对该客户端12使用适合的SLA分类器对业 务加标签。注意，SLA分类器40还可以实现在应用实例14中，使得 输入的应用业务由应用实例14识别和加标签，被传递到装置28以进 行受控缓存(如本文所教导的)，然后DTC 30将得到的经调节的应用 业务返回应用实例14以进行处理。

应用客户端标识(ID)可以存储在需求存储设备44中。SLA限 制器42通过实施由SLA分类器40设置的SLA标签作为业务整形器 操作，其中，SLA标签可以被理解为类型流分类或标识符。在这一点 上，可以使用令牌桶方案来实现业务整形。参见例如Kim,Han Seok； Park,Eun-Chan；Heo,Seo Weon,“A Token-Bucket Based Rate Control  Algorithm with Maximum and Minimum Rate Constraints,”IEICE  Transactions on Communications,Volume E91.B,Issue 5,pp.1623-1626 (2010)，其通过引用的方式并入本文。

速率计算器46以给定间隔“A”读取需求存储设备44中的信息， 并且与TB选择器50相关联地更新SLA限制器42中的所有令牌桶速 率——参见例如客户端A、B和C的令牌桶，如图4中的业务监管器 52中所示。需求分发器和接收机48以给定间隔“B”读取需求存储设 备44，并且使用基于gossip的逆熵协议算法对其他应用实例14处的 本地需求信息进行同步。间隔A和B无需相等，例如，间隔B可以 比间隔A更长，并且可以在特定应用的上下文中根据需要或期望对这 两个间隔的绝对值进行设置。更短的间隔提供更好的“系统”响应， 但是增加了对等装置28之间的信令开销。然而，存在明显的灵活性， 这是因为与CC 32相比，速率计算器46和DTC 30通常作为装置28 内的分离进程操作。

转向图4中所示的示例性SLA限制器实现，可以看出，SLA限 制器42基于多个功能电路的操作来执行业务整形。SLA限制器42可 操作地对到达的每一个应用消息实施计算出的本地利用率限制——例 如，本地速率限制——以便由应用实例14处理。SLA限制器42对进 入进入应用实例14的每一个应用消息执行以下逻辑处理操作：(1)由 TB选择器50读取来自应用消息的SLA标签，以及基于SLA标签从 业务监管器52中的现有TB监管实例集合中挑选专用令牌桶监管实例。 换言之，识别应用消息所属的流22，并且例如针对流A、B、C等识 别适合的令牌桶。

通过业务监管器52中的TB监管实例中的适当TB监管实例来评 估应用消息。根据流22的应用业务是否超出针对该流22计算出的本 地利用率限制，将应用消息标记为符合策略的或不符合策略的。相应 地，队列处理器56使用来自业务监管器52的监管结果来选择正确的 队列(低优先级或高优先级)。如上所述，还可以根据其他优先级划分 (例如，基于SLA的最小服务速率，其导致某些缓存的应用业务以比 其他缓存的应用业务更高的优先级被缓存)来组织SLA实施器62中 包括的队列58和60。

业务监管器52可以被理解为施加第一级或第一步业务监管，其 是以每一流为基础执行的。相应地，SLA实施器62可以被理解为施 加第二级或第二步业务监管，其中关键区别是由SLA实施器62实施 的监管对装置28/应用实例14处的所有业务流22的聚合操作。在示 例性配置中，SLA实施器62基于是否超出本地聚合利用率限制和/或 基于符合策略业务和不符合策略业务之间的区分，来控制对去往应用 实例14的聚合应用业务的缓存。例如，控制缓存可以是指只要未超出 本地聚合利用率限制，就不缓存消息，或者消息可以终止于不同的缓 存，其中以不同的优先级排空每一个缓存。

此外，可以例如根据一个或多个流参数来表达本地聚合利用率限 制，例如，最大聚合流速率和/或最大聚合突发大小。

在一个方法中，队列处理器56检查缓存58、60是否包含任何应 用业务。如果所有此类队列是空的，则SLA实施器62不施加业务调 节，并且在没有经优先级划分的缓存延迟的情况下将给定的应用消息 传递到应用实例14。

另一方面，如果缓存58、60不为空，则队列处理器56根据定义 的优先级方案排空缓存58、60，例如，以速率0.99*R_tot排空高优先 级缓存中缓存的应用业务，而以速率0.01*R_tot排空低优先级缓存中 的应用业务，其中R_tot表示最大聚合流速率。

因此，在本文所述的至少一些实施例中，可以将不同的流22映 射到不同的缓存。由缓存58和60表示的高优先级和低优先级是其示 例。可以将所有应用业务放置于此类缓存中，然后根据本地利用率限 制和/或根据本地聚合利用率限制来排出这些应用业务。

图6A示出了SLA分类器40的示例性操作，该SLA分类器40 对例如来自负载均衡器20或其他源的针对应用实例输入的所有应用 业务进行“滤波”或以其他方式进行逻辑处理。作为其处理的结果， 例如经由上述SLA加标签将输入应用业务分类为流22，其中，每一 个流22包括与相同的客户端上下文相关联的所有应用业务。在该示例 中，可以看出SLA分类器40将输入应用业务归类为多个流22，例如， FLOWA、FLOWB、FLOWC直到FLOWN。

图6B根据一个实施例通过示出了SLA限制器42对各个流22的 操作扩展了该相同的流处理示例。然而，在深入研究细节之前，介绍 用于此类处理的标记将是有帮助的：

-“flow_x”表示所有应用实例14之间针对相同客户端上下文的 所有应用业务；

-“flow_x,i”表示任意给定应用实例14处针对相同客户端上下 文的所有应用业务，即，“i”指示应用实例14中的特定应用实例，因 此将理解的是，应用实例14-i处的DTC 30估计flow_x,i的本地需求 值，并且基于接收到flow_x,y、flow_x,z等来估计flow_x的相关联的 总体需求值，其中，“y”和“z”表示flow_x在相应其他应用实例14-y 和14-z处的其他实例；

-“d_x,i”表示针对flow_x,i所估计的本地需求值；

-“r_x,i”表示在流速率方面针对flow_x,i的本地流利用率限制， 并且其他限制可以附加地或备选地适用，例如，最大突发大小，其被 表示为“b_x,i”；

-“r_tot,i”和“b_tot,i”表示用流速率限制和突发大小限制表示 的可应用于给定应用实例14-i处的所有流的聚合的本地聚合利用率限 制——例如，r_tot,i＝r_x,i+r_y,i+r_z,i，其中，r_y,i和r_z,i表示应 用实例14-i处的flow_y和flow_z的最大流速率限制；

利用上面的标记，“R_x”可以用于表示针对flow_x的所有实例 flow_x,i的最大总利用率。类似地，“B_x”可以用于表示针对flow_x 的所有实例flow_x,i的最大总突发大小限制。

此外，“R_tot”可以用于表示所有应用实例14之间的所有流实例 的聚合的最大聚合流速率。同样地，“B_tot”可以用于表示所有应用 实例之间的所有流实例的聚合的最大突发大小限制。

记住上面的标记，装置28在每一个应用实例i处例如以定期间隔 执行以下操作：通过以下方式来估计每一个flow_x的d_x,i：例如对 flow_x使用的协议会话的数量进行计数或者估计flow_x近期的预期 流速率(例如，假设将来的流速率等于当前到达速率)，或者如果最近 已经在flow_x中观测到任何应用消息，则将d_x,i设置为“1”，否则 将d_x,i设置为“0”，其中，该二进制方法可以特别有利于对来自负 载均衡器20的业务进行完全平均分发。

此外，每一个装置28在每一个应用实例i以定期间隔——但是不 一定是与用于需求估计的间隔相同的间隔——执行以下操作：

-“公布”应用实例i处的所有流22的所有d_x,i值，其中，可 以使用基于gossip的逆熵协议来完成公布；

-基于来自其他应用实例的已知需求估计来计算应用实例i处的 所有流22的总体需求值，例如，给定flow_x的总体需求是D_x＝所有 应用实例i＝1至N上的所有d_x,i之和；以及

-调整应用实例i处的每一个flow_x,i流的r_x,i，以进行与其他 实例处的状态(需求)成比例的本地分配，例如，按照r_x,i＝R_x* (d_x,i/D_x)来计算按流速率表达的每一个flow_x,i的本地利用率限制。

注意，上面的调整步骤表示了简单的示例性本地利用率限制确定。 给定应用实例14处的每一个流22的本地利用率限制可以包括：实施 最小和最大流速率。此外，注意，还可以以类似地方式(例如，使用 类似的线性表达)来更新b_x,i和B_x。此外，在一些实施例中，例如， 针对在每秒最大事务量限制情况下的业务整形，还可以调整r_tot和 b_tot，例如，r_tot,i＝R_tot*d_x,i针对所有x之和除以d_x,i针对所 有x和所有N之和。

上面的操作对分布式系统16实施R_tot限制——即，在关于应用 10的整体意义上。可以关于最大聚合突发大小等来完成类似的实施。

因此，仍然在图6B的上下文中，将理解的是，SLA限制器42 执行多个操作步骤，包括第一操作步骤：根据关于相应本地利用率速 率定义的优先级对应用业务进行分类——一种形式的“监管”。在缓存 58、60中实现的给定优先级队列之一中聚合来自所有应用业务流22 的每一个分类的应用消息。优先级队列是由装置28执行的聚合应用业 务调节的单个检查站。优先级队列业务参数——例如，最大流速率和 最大突发大小——实施可达业务，包括所有输入流22，本文示例为流 22-1、22-2等，其中每一个流22对应于不同的客户端上下文。本文， “可达业务”可以是最大可能利用率，其可以由最大可能“负载”给 出，或者通过尺寸标注(dimensioning)和/或经营策略来管理地定义， 例如，许可配额。此类速率总计高达例如R_tot。

将FLOWA的业务参数值与来自具有类似FLOWA——即，具有 相同的应用业务类型和客户端域——的其他应用实例14的参数值进 行快速同步。利用先前介绍的标记，可以将相似的流22表示为给定 flow_x的不同实例，例如，应用实例14-i处的flow_x,i、应用实例14-j 处的flow_x,j、以及应用实例14-k处的flow_x,k。本文，“x”表示公 共客户端上下文，并且“i”、“j”和“k”表示接收属于该客户端上下 文的应用业务的应用实例14中的不同应用实例。

图7图示了在业务监管器52和/或TB监管SLA限制器54的实 例“内”执行的处理。在一个或多个实施例中，由两个此类处理单元 使用的监管算法是相同的。

图8A和图8B描述了令牌桶算法的示例性细节，其中令牌桶算法 在业务监管器52和TB监管SLA限制器54内的子功能块内执行。在 图示中，算法被表示为“方法800”。此外，在这些子功能块中运行的 算法可以是相同的，区别在于实体52以每一个客户端流为基础操作用 户的每客户端流利用率限制，而实体54使用聚合利用率限制操作聚合 业务流。因此，可以看到令牌桶处理方法800的两个入口点，即，入 口点“B”(在图8A中，针对实体52)和入口点“K”(在图8B中， 针对实体54)，以及相应的两个出口点“C”(针对实体52)和“L” (针对实体54)。

方法800中的处理从以下步骤“开始”：接收指示到时间执行令 牌桶更新的信号(步骤1)。确定针对给定流22要添加到令牌桶的令 牌的数量，并且这表示针对流22实施本地利用率限制(步骤2)。基 于多个因素来对该确定作出决策，其中，多个因素包括例如自从最近 更新以来的增量时间、业务服务或流类别等。步骤3包括：基于例如 自从最近更新以来的时间、业务服务类别、当前令牌桶缓存大小、最 大突发速率等来确定要在涉及的令牌桶中设置的令牌的数量。利用做 出的这些确定，步骤4-11概述了用于确定应用消息是符合策略的还是 不符合策略的示例性方法。

图9描绘了在一个或多个实施例中在队列处理器56中运行的算 法，其中该算法一般地被表示为“方法900”。所示的方法900包括处 理步骤1-11，并且对每一个给定装置28中的聚合消息流操作，并针 对进入进入装置28的应用业务的每一项执行，例如，对每一个新输入 的应用消息执行。

注意，流示意图中的项“R”与图11中所述的方法1100相对应， 其是作为单独过程被执行的并且用于移除应用业务的各项——例如， 包括进入进入装置28和/或应用实例14的应用业务的各个请求或其他 应用消息——如果队列处理器56的队列中的任意一个中存在多于一 个消息的话。

在图9中所示的处理的更详细示例性解释中，每一个输入消息具 有相关联的优先级，在算法中使用该相关联的优先级来确定消息的服 务的特性(例如，延迟、丢弃、重排序)。算法在两个模式中操作。当 新消息到达时，以下情况发生：

如果已经存在排队消息，则立即对消息进行排队。基于消息的优 先级来选择队列。

如果所有队列为空，则检查最近观测到的业务(＝消息的到达过 程)以确定当前消息是否在当前消息所属的流22的本地聚合利用率限 制内。该检查基于本文详细描述的令牌桶算法。该动作对在彼此之后 立即到达的消息实施可持续速率和最大突发大小。如果消息在本地聚 合利用率限制内，则直接释放该消息以便由应用实例14进行处理。如 果消息违反限制，则将消息放入与其优先级相匹配的队列中。

当对第一消息进行排队时，计算直到可以将该消息释放的时间段。 根据速率限制(来自本地聚合利用率限制的r_tot,i)和自从允许上一 个消息通过所经过的时间来得到该时间段。(考虑经过的时间防止施加 太低的速率)。然后，该算法将调度睡眠，直到该时间段过去为止。

当时间段已经过去时，从队列之一中释放请求。通过队列的优先 级来确定从哪个队列进行释放，与较低优先级的队列相比，以较高的 概率选择较高优先级的队列。如果所选择的队列为空，则选择较低优 先级的队列(重复该过程，直到找到消息为止，如果需要的话，“回绕” 至较高优先级)。

如果在任何队列中仍然存在消息，则调度新的睡眠，否则不进行 任何操作。

图10示出了例如在速率计算器46内执行的更新会话表和令牌桶 策略参数的方法1000。可以看到处理步骤1-6，其中，基于装置28与 其对等装置中的一个或多个之间的本地需求值交换来更新给定装置 28处的逆熵数据结构(aEDS)(步骤1)，并且将更新的信息与标识应 用/服务器、时间戳和版本信息一起写入相应会话表(步骤2和3)。 处理继续更新连接的客户端12的本地利用率限制(其是经由在业务监 管器52中实现的令牌桶处理来实施的)(步骤4)，等待定义的aEDS 更新间隔期满(步骤5)，并且发信号通知/触发新的更新(步骤6)。

此类处理包括例如在装置28之间定期或周期性地交换本地需求 信息。此外，应当理解的是，在一个或多个实施例中，aEDS包括数 据结构，该数据结构包含应用实例14处的流22的所有相关需求估计。

估计装置28中的任意给定装置处的给定流22的需求的一种方法 是基于当前在应用实例14处针对流22打开的客户端会话的数量来估 计需求。考虑到每一个附加会话给出了发出去往该特定应用实例14 的更多请求的可能性，针对每一个流22打开的会话的计数用作流22 对应用实例14施加的需求的粗略估计。

当前，可以使用其他度量来表示需求。例如，可以使用由应用实 例14支持/分配的会话、连接的数量、或事务计数或速率和/或可以使 用应用消息的观察到达时间或应用实例14住宿在其上的服务器的当 前负载。在每一个应用实例14处操作的装置28中的DTC 30基于设 置本地业务控制参数(例如，本地利用率限制)定期地计算配置的应 用容量的适当/公平共享，以便在业务监管器52处以每一流为基础进 行分配。配置的应用容量可以被理解为配置的全系统速率，该全系统 速率在应用实例14之间在本地划分并且在每一个应用实例14处由伴 随装置28在本地实施。

如上所述，针对应用业务的每一个流22的容量计算(r_x,i和r_tot,i) 可以基于：针对其他应用实例14处的相似流22的已知需求以及针对 客户端12配置的SLA。在一种方法中，用于监管应用实例14中的任 意给定应用实例中的给定流22的应用业务的本地利用率限制用于与 本地需求和总需求之比成比例地计算容量分配，例如，流的本地利用 率限制＝针对此类流所分配的应用容量*(流的本地需求/流的总体需 求)。根据先前的标记，按照下式给出应用实例i处的流x的本地利用 率限制：

r_x,i＝R_x*(d_x,i/D_x)。

例如根据与流22相关联的客户端标识，分配的容量可以是已知 的。此外，如上所述，可以按照在涉及的应用实例14处估计的本地需 求值与针对其他应用实例处的所有相似流22估计的本地需求值之和 来计算流22的总体需求。当然，其他算法可以用于计算每一个流的本 地利用率限制。可以通过针对应用实例14处的每一个流22的最小容 量分配和最大容量分配来获得公平性的整体提高。

关于在不同的应用实例14处的装置28之间交换本地需求值的细 节，图12示出了两个对等装置28之间的示例性三次协调握手。假设 在应用实例14-1处的装置28与应用实例14-2处的装置28之间交换 消息，三个消息是SYN、ACK和ACK2。SYN消息包括具有ID和版 本信息的所有条目，而不具有来自应用实例14-1的需求表的需求数据。 ACK消息包含基于应用实例14-2处的需求表信息的相应新的内容条 目以及缺失的版本条目。

也即是说，应用实例14-2处的装置28将其需求数据与从应用实 例14-1处的装置28接收的需求数据进行比较，并且在ACK消息中提 供更新以及对任何缺失条目的请求，即，在应用实例14-1处的装置 28中维护的信息中未考虑的任何流22的需求数据。类似地，向应用 实例14-2返回的ACK2消息包括在应用实例14-2处可用但是在应用 实例14-1处缺失的信息。通过这种方式，在相应应用实例14的所有 装置28之间传播所有应用实例14处的所有流22的所有信息，而不必 需要在装置28的所有可能的配对之间直接交换本地需求信息。

因此，图12可以被理解为由装置28中的CC 32采用以共享本地 需求值的基于gossip的逆熵协议的非限制性示例。优选地，被选择用 于交换此类信息的任何逆熵算法将使用三次协调握手。始终在两个相 互了解的对等体之间执行协调。不是所有对等体都需要相互了解，但 是必须存在至少一个所有应用实例最初已知的应用实例14，其被称作 “种子”。

更具体地，存在具有所有其他装置28的本地需求值的至少一个 装置28，使得被添加以支持整个应用10的每一个新的应用实例/装置 28可以开始与该种子装置28进行协调握手。仅在启动时才需要该操 作，使得对等体可以开始相互通信。在每一个逆熵群集中应当存在至 少两个种子，以避免单个故障点。在群集中的几个消息来回之后，所 有对等体相互了解。

一将新的应用实例14放入群集中，就开始与已知的对等体进行 协调握手。选择种子的过程是随机的，这是确保快速分发的有效方式。

图13和图14更详细地描述了用于在装置28之间交换本地需求 信息的示例性逆熵算法。这些算法例如在每一个此类装置28处实现的 CC32中运行。

在图13中，看到处理步骤1-4，其被概括地表示为“方法1300”。 方法1300包括第一步骤：算法等待指示到时间交换本地需求信息(例 如通过发送来自先前提到的aEDS的信息)的信号。步骤2包括：可 能随机地选择与之交换本地需求信息的对等CC 32，而步骤3和步骤 4包括：向所选择的对等CC 32发送SYN信号以及发送用于发送aEDS 的信号。

也即是说，步骤3向随机对等体发送aEDS并且步骤4使算法回 到步骤1中所述的等待状态。显而易见，可以在步骤3和步骤4之间 施加等待步骤——例如，间隔定时器——以控制可以发出SYN请求的 速率。

在图14中，看到用于处理各种类型的接收的握手消息的处理步 骤1-11。这些步骤被概括地表示为“方法1400”并且处理从以下步骤 开始：等待从对等体接收aEDS信号(步骤1)，并且继续决定已经接 收到哪种类型的aEDS消息(步骤2)。例如，消息可以是包括aEDS 请求(即，对包括接收CC 32的装置28处的本地需求信息的请求) 的SYN消息。对于该消息，方法1400包括处理接收的SYN消息，确 定要发送哪些本地条目，要请求哪些远程条目，以及发送得到的ACK 消息(步骤3、6、和9)。

对于接收的ACK消息，方法1400包括：处理ACK消息，确定 在ACK2消息中要返回哪些本地条目，使用来自ACK的数据更新本 地需求信息，然后将ACK2消息发送回接收的ACK消息所源自的CC 32(步骤4、7和10)。示出了用于接收ACK2消息的类似处理(步骤 5和8)。

作为本文的教导的很多示例性应用之一，水平扩展应用10可以 使用所公开的装置28及其功能等同物来对用户利用电信供应系统设 置保证的服务水平协议，其中，电信供应系统使多个用户共享相同的 硬件平台。在电信行业中，很多电信运营商已经开始将事务其划分为 更小的组织单元。这些电信运营商希望在所有此类子运营商之间共享 硬件投资。本文教导的用于控制水平扩展装置10中的利用率的方法 500和装置28允许任何电信运营商使用本发明来在任意数量的更小组 织单元之间共享给定的硬件投资。此外，本文的教导使得可以收集业 务模型数据，以设置此类系统的每一个客户的正确尺寸。

在另一示例中，在“每秒事务量”或“按需付费”处理模型中使 用方法500和装置28。在此类模型中，客户支付许可费，从而向客户 准许定义的最大数量的每秒事务量(TPS)。因此，给定的客户可能具 有产生去往应用10的应用业务的任意数量的客户端12，并且装置28 将关于包括应用10的应用实例14操作，以限制应用10向客户提供的 最大TPS并且均衡事务处理在应用实例14之间的分布。

在另一示例中，本文的教导规定了用户分离的软件利用率作为可 扩展“云”服务。这是可能的，其原因在于这些教导使得可以在水平 扩展的任何给定的硬件/软件系统上分离由用户名、应用ID、IP地址 或任何其他标识所标识的每用户应用利用率。通过向用户软件准许每 用户利用率限制，云提供商避免了任何单个用户不公平地垄断云服务。 显而易见，这使流受益，而不论主机操作系统是否允许施加用户限制。

在提供本文教导的另一示例性应用的情况下，图15提供了本文 教导的分布式业务控制的简单应用。存在两个应用实例14，其具有四 个连接的客户端A、AS、B和C，其中，AS表示“粘性”客户端。 本文的目的是对整个应用实施应用消息速率，其中，整个应用是由运 行在两个不同的服务器上的两个应用实例14表示的。

配置的总应用实例速率是1000应用消息每秒(msg/sec)。该值针 对整个两节点群集给出了2000msg/sec。针对冗余场景的每虚拟服务 器的多余容量是200msg/sec，总计为400。在应用中向应用客户端12 提供以下速率：向用户A的应用客户端提供600msg/sec、向用户B 的应用客户端提供800msg/sec，并且向用户C的应用客户端提供600 msg/sec。针对所示场景假设的其他属性包括以下事实：未分配多余容 量200msg/sec，即，在故障的情况下将其用作冗余。

用户客户端As——参见示意图中的“p1”——稍后启动同步循环， 并且将理解的是，As表示多个粘性客户端连接。应用客户端C在第 二同步循环上将负载——在示意图中参见“p3”——从400msg/sec 增加到600msg/sec。本文，每一个同步循环应当被理解为基于来自应 用实例14已知的本地需求信息和远程需求信息的输入在本地重新计 算需求信息。

在另一示例中，由较大的电信运营商组织来使用水平扩展的应用 10。组织被划分为更小的部分，例如，19个不同的组织单元。分布式 处理系统16包括运行应用的十个不同的服务器，经由输入请求的负载 均衡在这些服务器之间水平扩展该应用。系统的总供应容量是10*400 ＝4000个供应请求/秒。每一个组织子单元得到4000个请求/秒容量的 可配置共享，其中，该共享基于每一个子单元负责多少个订户。供应 请求创建、修改、或删除归属位置寄存器(HLR)订户数据库中的移 动订制。

十个服务器(其中每一个运行供应软件应用10的应用实例14) 形成由负载均衡器20馈送的“群集”。群集中的每一个应用实例14 从负载均衡器接收业务，其中负载均衡器在十个服务器之间分发输入 的供应业务请求。由于与应用实例14中的相应应用实例配对的装置 28提供的复杂利用率限制，因此负载均衡器20可以非常简单，例如， 业务请求的循环分发。

在该实施例中使用两个不同的协议，即，TELNET和HTTP。基 于会话/寿命较长的TELNET连接使得更难在群集上平均分发整个负 载。HTTP是可以使用负载均衡器以每一请求为基础进行分发的无状 态协议。可以通过仅添加新的服务器来将供应容量每服务器增加400 个请求/秒。然而，这些协议的组合使得业务负载分布不均匀。有利地， 因为在装置28执行的本地需求值估计中考虑了粘性连接，因此即使在 群集中利用非常简单的业务分发方案，也可以实现负载均衡。

在另一示例中，应用实例14包括二十个异构负载均衡器，其在 具有16000个虚拟化服务器和非虚拟化服务器的大型网络中分发负载。 在该示例中，本文教导的分布式处理方法基于应用消息的应用ID将 负载均衡器容量划分为不同的流。在该情况下，负载均衡器的目的是 基于可用负载均衡器容量在主机服务器提供商上下文中对负载均衡器 的用户进行计费，而不是针对专用硬件成本对用户进行计费。

显而易见，在受益于前述描述和相关联的附图中给出的教导的情 况下，本领域技术人员将想到所公开的发明的修改和其他实施例。因 此，应当理解的是，本发明并不限于所公开的具体实施例，并且修改 和其他实施例旨在包含在本公开的范围内。虽然可以在本文采用特定 术语，但是这些术语仅在一般的描述性意义上被使用而不用于限制的 目的。