代理服务器、分层次网络系统及分布式工作负载管理方法

摘要

本公开涉及代理服务器和分层次网络系统及其分布式工作负载管理方法。根据本公开的一个实施例，所述代理服务器包括：速率控制器，被配置成基于测量到的请求相关信息和与请求的服务等级有关的服务质量参数，周期性地确定每个服务等级的请求的分派速率，其中各个服务等级的分派速率之和小于或等于预定速率；以及请求分派器，被配置成按照由速率控制器确定的分派速率，分派对应服务等级的请求。本公开的一个方面实现了管理低开销、高可扩展性、简单但高效的工作负载管理系统，以进行QoS保证和过载保护。

说明书

技术领域

本公开涉及网络流量管理技术，尤其是，涉及分层次网络系统中网络应用的分布式工作负载管理方法和系统。 

背景技术

分层次网络系统，例如云计算环境，正在被越来越广泛地应用。象云计算环境这样的多层次系统通常包括，例如，前端的HTTP服务器、中间的代理层以及后端的应用服务器和/或数据库层。HTTP服务器层过滤掉无效的或恶意的请求，并且将合法的请求转发给代理层。然后，代理层将这些请求又路由到所选择的应用服务器和/或数据库层。 

随着云计算的发展，提出了将资源作为服务来提供的概念，其强调对于过载保护以及QoS保证的灵活控制的重要性。因此，在多层次网络系统中对工作负载的管理变得越来越重要。通常，工作负载管理大多数发生在代理层和后端服务器层之间。 

目前已经针对多层次网络系统中的工作负载管理做了很多工作。这些工作主要分为两类：集中式工作负载管理和分布式工作负载管理。 

目前在多层次网络系统中主要使用集中式管理。也就是，依赖于一个中心单元来在多层次网络系统中收集信息和做出请求分派决定。 

在集中式管理架构中，广泛使用集中式控制器来操控流经代理服务器的流量。集中式控制器中的中央管理单元负责收集和审核工作负载到达速率及其响应时间，从而管理给后端服务器的工作负载。在一些情况下，管理决定以集中方式做出，但是由多个代理层服务器来分布式执行。但是在大多数情况下，管理决定以集中方式做出并且以集 中方式执行。 

在这样的集中式管理中，需要预先收集后台应用服务器的信息，诸如CPU利用率和/或存储器利用率和每个请求的执行时间等，并对其进行处理从而建立几种统计数据的样本。然后，中央管理单元执行基于所述样本的训练/学习过程来建立一定的先验知识，然后才能基于所述先验知识对到来的流量进行工作负载管理。通常，这种集中式控制器的部署需要专业技能，用于工作负载管理的系统开销大，并且执行过程非常复杂且耗时。此外，使用集中方式，所有的管理功能都在一个服务器上，而任何服务器都有能力的限制，从而使得在这种情况下可扩展性难以得到提高。更进一步地，集中式管理单元还存在了一个很严重的问题，一旦中央管理单元发生故障，则在群集之间负载不均衡的情况下，会导致资源不被充分利用，甚至会导致整个系统的工作负载管理将不能进行。 

在分布式管理架构中，通常使用分布式控制器优化互联网中的流量工程。这种分布式控制器是在OSI协议栈中的传输层上实现的，并且不依赖于来自后端服务器的诸如后端服务器的CPU/存储器利用率信息等的信息。这种分布式控制器基于在传输层获得的信息，诸如分组的丢失率、数据传输速率等的硬件相关信息，而没有考虑基于服务应用的信息，诸如请求的优先权、请求的响应时间、发出请求的应用相关信息(诸如，客户类型、服务要求等)。因此，这种分布式控制器不能对前端的请求进行服务区分，从而不能为不同服务等级提供不同的QoS保证，并且也不能对后端的应用服务器进行过载保护。 

面对来自部署在云环境中的大量应用的流量，保证来自具有各种资源需求和负载特点的客户的服务等级协议(SLA)需求是具有挑战性的。 

因此，现有技术中需要一种分层次网络系统中能够对网络应用的工作负载进行分布式管理的改进的方法和系统。 

发明内容

由上述可知，现有技术中存在以下缺陷：难以实现服务区分、面向服务的工作负载管理的可扩展性差、系统用于工作负载管理的开销大以及部署复杂。为了解决现有技术中存在的上述问题中的至少一个，而提出了本公开。根据本公开的一个方面的实施例提供了一种利用非常有限的信息来简单但高效地实现工作负载管理优化的分布式工作负载管理方法和系统。 

根据本公开的实施例是在OSI协议栈中的应用层上实现的。根据本公开的一个实施例实现了以下中的至少一个：1)生成最少信息来在所选的前端代理服务器集合和后端资源管理器之间交换；2)应用独特有效的分配算法来分发服务器容量给不同的服务类以实现服务区分和公平；3)优化系统处理以在后端服务器上实现简单逻辑以便容易地进行部署；4)基于到达负载的特征，高效且快速地调整后端服务器的最大容量。 

本公开的实施例可以以包括方法或系统的多种方式实施。下面讨论本公开的几个实施例。 

作为一种代理服务器，本公开的一个实施例至少包括：速率控制器，被配置成基于测量到的请求相关信息和与请求的服务等级有关的服务质量参数，周期性地确定每个服务等级的请求的分派速率，其中各个服务等级的分派速率之和小于或等于预定速率；以及请求分派器，被配置成按照由速率控制器确定的分派速率，分派对应服务等级的请求。 

作为一种分层次网络系统，本公开的一个实施例至少包括：如上所述的代理服务器；以及应用服务器，被配置成为所述代理服务器提供服务，包括：资源检测器，被配置成周期性地检测应用服务器的资源的当前利用率和当前请求到达速率；最大速率计算器，被配置成基于检测到的资源的当前利用率和当前请求到达速率以及所述资源的目标使用率，为下一管理周期计算请求的最大允许速率；以及速率分配器，被配置成基于预定策略将所述最大允许速率分配给各个代理服务器作为其预定速率。 

作为一种分层次网络系统中的分布式工作负载管理方法，本公开的一个实施例至少包括：基于测量到的请求相关信息和与请求的服务等级有关的服务质量参数，周期性地确定每个服务等级的请求的分派速率，其中各个服务等级的分派速率之和小于或等于预定速率；以及按照所确定的分派速率，分派对应服务等级的请求。 

作为一种包含计算机可执行指令的计算机可读介质，根据本公开的一个实施例所述计算机可执行指令在被处理器执行时使所述处理器执行上述分布式工作负载管理方法。 

附图说明

图1示出了能够实施本发明的分层次系统的示意图。 

图2示出了根据本公开的一个实施例的能够进行工作负载管理的分层次系统的示意性结构框图。 

图3示出了使用效用函数获得的损失值与当前响应时间和目标响应时间以及重要度之间的关系曲线图。 

图4示出了根据本公开的一个实施例的在代理服务器上执行的工作负载管理流程的示意性流程图。 

图5示出了根据本公开的一个实施例的在应用服务器上执行的工作负载管理流程的示意性流程图。 

具体实施方式

在下列讨论中，提供了大量具体的细节以帮助彻底了解本公开。然而，很显然对于本领域技术人员来说，即使没有这些具体细节，也不影响对本发明的理解。应该认识到，使用如下的任何具体术语仅仅是为了描述方便，因此，本发明不应当局限于只用在这样的术语所表示和/或暗示的任何特定应用中。 

根据本公开的实施例提供了一种整体设计和处理架构，其使得能够基于有限信息进行本地判决，其中在代理服务器端，分配所允许的不同速率给不同的请求类别或服务等级以实现服务区分和公平性；而 在应用服务器端，基于有限信息来计算应用服务器所允许的请求的最大到达速率。 

在代理服务器端，本公开的实施例设计了效用函数来控制分配用于从不同队列给应用服务器分派请求的速率，以实现服务区分和公平。代理服务器端针对不同类别进行速率分配的目标是有区别地管理不同服务等级的QoS以实现服务区分，在优选实施例中使用了请求的目标响应时间和重要度来指示QoS需求。 

效用函数是用于将测量到的请求相关信息与QoS需求联系起来的函数，其约束条件为：各队列的速率之和小于等于来自后端应用服务器的总允许速率。在代理服务器端测量到的请求相关信息包括，诸如，例如每个队列的平均请求到达速率、平均队列长度、每个队列的当前响应时间等。 

可以通过排队模型来建立不同队列的分派速率和当前响应时间之间的联系，以便确定使得效用函数之和被最优化(例如，最小化)的每个队列的分派速率。本公开实现了如下目标：具有高重要度的服务等级将具有满足其响应时间要求的优先级，但是不会有任一服务等级的请求被忽视(即，不被处理或分派速率很低)。 

在应用服务器端，计算并向代理服务器分发针对该代理服务器的最大允许请求到达速率。在应用服务器端，使用自适应方法，而不是精确模型来估计资源需求。所述计算基于非常有限的关于服务器的信息，所述信息包括：资源的目标使用率(例如，90％的CPU)、资源的当前利用率(例如，CPU负载)、请求到达速率、和/或所需的其它信息。所述信息可用脚本实现。此外，进行所述计算的装置不必与应用服务器集成在一起。所述计算消耗非常有限的CPU资源，从而将不会干扰服务器负载。 

以下，结合附图，对本发明的优选实施例进行说明。 

图1示出了能够实施本公开的实施例的分层次系统的示意图。如图1所示，分层次系统包括客户端层(即，前端)、代理服务器层(即，中间层)和应用服务器层(即，后端)。根据本公开的工作负载管理 实现涉及中间层和后端。 

图2示出了根据本公开的一个实施例的能够进行工作负载管理的分层次系统的示意性结构框图。如图2所示，前端包括一个或多个客户机，这些客户机通过代理服务器向后端的应用服务器发送资源请求。 

中间层包括一个或多个代理服务器，每个代理服务器接收来自其所服务的客户机的资源请求，并且基于后端的应用服务器所提供的最大允许速率，以与接收到的请求的服务等级相对应的分派速率将该请求发送给相应的应用服务器。 

代理服务器中可以设置缺省分派速率，均匀地分配给所有服务等级。每个服务等级被设置有目标响应时间和重要度值。在请求到达代理服务器时，请求被分类到其服务等级中。每个服务等级维护一个队列和请求分派器(例如，基于额度)以管理其分派速率。如果系统没有过载，所有队列长度应为0。随着系统变得过载，具有低优先级服务等级的请求将使管理和队列的负荷更重，从而遭受更长的响应时间。按照内部计算周期来基于估计的当前分派速率和所接受的QoS要求之间的相关性，调整每个队列的分派速率。 

后端包括一个或多个应用服务器，每个应用服务器都基于自身的有限信息，计算出各自所允许的最大请求到达速率，并将其发送给对应的代理服务器。 

如本领域技术人员所知的那样，一个应用服务器可以服务于一个或多个代理服务器，而一个代理服务器也可以接受一个或多个应用服务器提供的服务。应用服务器可以自动获知代理服务器的存在。这可以通过首次接收到来自代理的请求时而自动获知。可替换地，应用服务器也可以以轮询的方式发送请求来获知需要使用其资源的代理服务器。 

如图2所示，代理服务器230包括请求分类器231、队列模块233、速率控制器235以及请求分派器237。 

请求分类器231接收来自客户端的请求，并将接收到的请求分类为不同的服务等级。所述分类可以基于各个请求的QoS需求来进行。 QoS需求可以用例如请求的目标响应时间及其重要度来表示。通常，请求的目标响应时间及其重要度是根据客户与服务提供商之间的服务等级协议(SLA)而预先确定的。 

例如，可以将请求分为三类，分别为：金、银和铜。对于金等级的请求，其目标响应时间可以为10ms并且重要度级别为高；对于银等级的请求，其目标响应时间可以为20ms并且重要度级别为中；而对于铜等级的请求，其目标响应时间可以为50ms并且重要度级别为低。 

值得注意的是，请求分类器231是可选的。来自服务等级的请求本身可以带有指示其服务等级的标签。 

队列模块233也是可选的，用于维护一个或多个请求队列，不同的队列对应于请求的不同服务等级。例如，队列模块233中可以设置三个请求队列Q1、Q2和Q3，用于维护分别为金、银和铜等级的请求。 

速率控制器235基于来自应用服务器210的信息和各个服务等级的QoS需求，周期性地为每个服务等级计算分派速率。速率控制器235的计算周期可以与后端的应用服务器的管理周期同步或不同步，但是这对于本发明而言不是关键性的。 

速率控制器235从给其提供服务资源的应用服务器210接收该应用服务器210允许来自该速率控制器235的请求的最大到达速率。速率控制器235还检测各个服务等级的请求的当前响应时间以及获取各个服务等级的请求的目标响应时间及其重要度。需要注意的是，这里使用的“当前响应时间”是指在当前计算周期中请求的实际响应时间。 

首先，为了建立各个服务等级的请求的当前响应时间与各个服务等级的分派速率之间的联系，速率控制器235基于现有技术的排队论原理，为对应于每个服务等级的请求队列建立排队模型。所述排队模型为每个请求队列建立其分派速率r与响应时间T之间的函数关系，T＝f(r)。 

需要注意的是：全部请求队列的分派速率之和应小于等于应用服务器210分配给该代理服务器230的请求的最大到达速率。该约束条 件可以被表示为： 

$\underset{i=1}{\overset{I}{\Sigma }}r=r_{\max }---\left(1\right)$

其中，i是1≤i≤I的整数，用于表示队列的索引；并且I是正整数，用于指示服务等级的数目，也就是，队列模块233中维护的队列的数目。 

其次，为了实现服务等级区分和公平性，本公开提出了效用函数的概念，该效用函数是把各个服务等级的请求的当前响应时间与其QoS需求联系起来的函数。在约束条件(1)下，使各个服务等级的该效用函数达到极值的分派速率r将是满足QoS需求的解。换言之，本公开提出了效用函数来控制给不同请求队列的分派速率。以下，将效用函数表示为D_i。 

使各个请求队列的效用函数之和最小化的解将使具有高重要度的服务等级在满足目标响应时间要求方面具有高优先级，同时每个服务等级都不会被忽视。 

根据本公开的效用函数可以用来表示由于不能满足某一服务等级的目标响应时间需求而带来的损失。效用函数的目的之一是要使在当前响应时间小于等于目标响应时间时没有损失，而在当前响应时间大于目标响应时间时，损失线性增长。在当前响应时间超过目标响应时间的数量相同时，对于具有相同目标响应时间的服务等级，服务等级的重要度越高，则该服务等级的损失越小。 

图3示出了使用效用函数获得的损失值与当前响应时间和目标响应时间以及重要度之间的关系曲线图。 

如图3所示，在当前响应时间小于等于5ms时，三个队列的损失值都为0。当当前响应时间大于5ms时，对于相同的当前响应时间，重要度越大，损失越大。 

根据本发明的优选实施例，本公开提出了一种如下所示的效用函数D_i： 

$D_i\left(T_i\right)=\frac{C_i}{2}((T_i-d_i)+\sqrt{{(T_i-d_i)}^2+0.5})---\left(2\right)$

其中，T_i是第i个队列的请求的当前响应时间，I_i是第i个队列的重要度，d_i是第i个队列的请求的目标响应时间。 

最后，在约束条件(1)下，使用以下的等式(3)来获得请求队列i的请求分派速率： 

minD_i(T_i) 

                                        (3) 

其中，min是用于求最小值的函数。 

通过将T＝f(r)以及等式(2)代入等式(3)并对其求解，所获得的解就是在下一计算周期中用于请求队列i的分派速率。 

虽然以上描述中使用各个服务等级的请求的当前响应时间来建立各个请求队列的分派速率和QoS参数(例如，目标响应时间和重要度等)之间的联系，但是本领域技术人员应当知道可以使用现有的排队模型建立请求队列的其它属性(诸如，不同时间的队列长度、分派速率、到达速率、等待时间等)和QoS参数之间的联系。此外，以上给出了效用函数的具体形式，但是本领域技术人员应当可以根据其具体需求而设计出其它形式的效用函数。例如，使用请求队列的其它属性来建立效用函数，给T_i、C_i和d_i不同的加权值，使用立方和开立方的形式等等。 

根据本发明的另一实施例，本公开提出了另一种如下所示的效用函数D_i。 

并且， 其中，L指示队列长度，L_{i，前一周期}指示在前一计算周期第i个队列的最大长度，而L_{i，当前周期}指示在当前计算周期第i个队列的最大长度。 

这个效用函数基于各个服务等级的QoS需求来在约束条件(1)下计算分派给相应请求队列的分派速率加权因子。例如，对于请求队列1，给其分配速率D1/(D1+D2+D3)×r_max；对于请求队列2，给其 分配速率D2/(D1+D2+D3)×r_max；而对于请求队列3，给其分配速率D3/(D1+D2+D3)×r_max。 

在为每个队列计算出分派速率之后，速率控制器235将计算出的速率值发送给请求分派器237。速率控制器235响应于从应用服务器210接收到最大速率更新而更新其存储的最大达到速率，但是每个控制周期只计算一次分派速率。 

值得注意的是，如果一个代理服务器接受来自多个应用服务器的资源服务，则该代理服务器的速率控制器235需要针对每个应用服务器计算各个请求队列的分派速率。然后该代理服务器将使用针对一应用服务器计算的速率将需要该应用服务器服务的请求分派给该应用服务器。 

请求分派器237使用来自速率控制器235的分派速率，将对应请求队列中的请求发送给应用服务器210。 

请求分派器237还可以使用现有技术中的方法来实施速率控制。例如，可以使用令牌桶算法来实现请求速率控制。例如，可以以RoundRobin方式来检查令牌，从而实现正确的请求分派速率控制。 

还如图2所示，后端的每个应用服务器210都包括资源监测器211、最大速率计算器213和速率分配器215。 

应用服务器210周期性地执行速率管理。所述周期可以是管理员根据经验设定的或者根据需要或以其它方式设定的。每个应用服务器210都会有资源目标使用率，其是应用服务器进行操作时的资源使用上限。例如，对于一个应用服务器，其CPU利用率可被设置为60％并且存储器利用率可被设置为95％。也就是，应用服务器执行操作所利用的CPU周期不能超过其全部周期的60％，而所利用的存储器空间不能超过其全部存储器空间的95％。 

资源监测器211周期性地检测应用服务器的资源的当前利用率和当前请求到达速率。所述资源包括CPU利用率、存储器利用率、I/O和带宽等等。所述周期指的是应用服务器的管理周期，在每一管理周期中执行上述检测。检测到的信息中的一些或全部以及资源目标使用 率可以用于调整整个控制周期的最大允许请求到达速率。 

最大速率计算器213基于来自资源监测器211的检测到的信息以及预先设置的资源目标使用率，计算应用服务器210在下一管理周期中可以接收请求的最大允许速率。 

下面，作为例子，本公开给出一个计算最大允许速率的实施例，该实施例基于以下假设：资源为CPU周期，资源目标利用率是CPU利用率的上限，应用服务器使用比例积分(proportional-integral，PI)控制器技术。对于该应用服务器而言，其所允许的请求的最大到达速率为： 

R(j)＝R(j-1)+(K_p+K_j)*e(j)-K_p*e(j-1)                    (5) 

其中，j表示第j个管理周期，R(j)表示为第j个管理周期计算的最大允许请求到达速率，e(j)表示目标利用率与第j个管理周期中测量到的实际资源利用率之差，Kp和Kj是PI控制器技术中常用的参数，其通常是根据实际使用设置的经验值。 

在这种工作负载管理系统中，一种非常典型的现象是在应用服务器的实际工作负载远远小于应用服务器的最大容量的情况下，总是观测到为正值的e(j)。这使得应用服务器的最大允许到达速率不断提高。当实际工作负载突然提高并且达到最近更新的最大允许速率时，这容易导致应用服务器发生严重的过载。在这种情况下，使用R′(j-1)来代替公式5中的R(j-1)，R’(j)表示在第j个管理周期中测量到的实际请求到达速率。也就是，使用在第j-1个管理周期中测量到的实际请求到达速率作为计算第j个管理周期的最大到达速率的基础。 

在这种工作负载管理系统中，还可以观测到采样到的实际允许速率与计算出的最大允许速率有轻微的不同。这是由于在进行描述时存在误差。当计算出的允许速率稍微高于采样到的允许速率时，这会使允许速率缓慢下降。这也容易导致系统过载。在这种情况下，上述公式(5)变为如下形式： 

R(j)＝Min(R(j-1)，R′(j-1))+(K_p+K_j)*e(j)-K_p*e(j-1)        (6) 

其中，Min是取R(j-1)，R′(j-1)中的最小值的函数。 

作为根据本公开的另一实施例，可以如下计算应用服务器的最大允许请求到达速率。速率计算器213基于应用服务器的资源目标利用率计算应用服务器所允许的阈值到达速率。然后，速率计算机213基于来自资源检测器211的当前资源利用率，成比例地计算所允许的最大请求到达速率。例如： 

R(j)＝前一周期资源利用率/目标资源利用率×R_阈值。 

以上描述仅仅示出了计算应用服务器的最大允许请求到达速率的例子。当然，本领域技术人员还可以以其它方式计算在满足目标资源利用率的情况下应用服务器所允许的最大请求到达速率。 

速率分配器215基于预定策略将所述最大允许速率分配给各个代理服务器作为其预定速率。由于应用服务器210可能为多个代理服务器提供服务，所以速率分配器215为各个代理服务器规定的请求到达速率之和应等于其计算出的最大允许到达速率。 

速率分配器215可以采用多种策略来给各个代理服务器分配其允许的到达速率。例如，所述预定策略是平均分配，即，将最大允许到达速率均匀地分配给代理服务器。例如，如果速率计算器213计算出的最大允许到达速率为100请求/秒且应用服务器210需要为5个代理服务器提供资源服务，那么资源管理器215给每个代理服务器规定的请求速率为20请求/秒。新的速率将基于策略被分配给不同的代理服务器230。 

可替换地，资源管理器215可以从代理服务器接收描述信息，诸如请求到达速率、排队描述或其它必要信息。资源管理器215可以基于接收到的信息，为每个代理服务器分配不同的请求到达速率。 

图4示出了根据本公开的一个实施例的在代理服务器上执行的工作负载管理流程的示意性流程图。 

在步骤411，确定是否是新的计算周期。如果不是，则继续等待。否则，进行到步骤413。 

在步骤413，基于测量到的请求相关信息和与请求的服务等级有关的服务质量参数，确定每个服务等级的请求的分派速率，其中各个 服务等级的分派速率之和小于或等于预定速率。 

在步骤415，按照所确定的分派速率，分派对应服务等级的请求。 

以上步骤413和415中的具体操作，已经参见图2中的代理服务器230进行了详细描述，在此不再重复。 

然后，处理过程返回到步骤411等待下一管理周期开始。 

图5示出了根据本公开的一个实施例的在应用服务器上执行的工作负载管理流程的示意性流程图。 

在步骤511，确定是否是新的控制周期。如果不是，则继续等待。否则，进行到步骤513。 

在步骤513，检测所述应用服务器的资源的当前利用率和当前请求到达速率。 

在步骤515，基于检测到的资源的当前利用率和当前请求到达速率以及所述资源的目标使用率，为下一管理周期计算请求的最大允许速率。 

在步骤517，基于预定策略将所述最大允许速率分配给各个代理服务器作为其预定速率。 

以上步骤513、515和517中的具体操作，已经参见图2中的应用服务器210进行了详细描述，在此不再重复。 

然后，处理过程返回到步骤511等待下一管理周期开始。 

根据本公开的一个方面的一个实施例至少提供了以下优点中的一个或多个： 

1.低开销：由于代理服务器和应用服务器之间传送非常少的信息，所以这种分布式方案避免了太多的开销。太多的开销会增大了系统在维护和管理方面的复杂度。 

2.优先级和公平性：这是工作负载管理的基本要求。具有高优先级的流得到更好的QoS保证；但是没有流会被忽视。 

3.在后端服务器上需要安装的工具软件更少。 

4.快速收敛：系统对于不同的负载特点都能够快速收敛。需要长的训练时间的管理方案可能不能很好地工作。本实施例还能够使用 更多或更少的不同系统组件来快速收敛。 

5.弹性和自适应性：能够处理不同工作负载类型的组合。另外，其需要更少的人的干预或配置。 

所属技术领域的技术人员知道，本公开可以体现为系统、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即，可以是完全的硬件、完全的软件(包括固件、驻留软件、微代码等)、或者本文一般称为“电路”、“模块”或“系统”的软件部分与硬件部分的组合。此外，本公开还可以采取体现在任何有形的表达介质(medium of expression)中的计算机程序产品的形式，该介质中包含计算机可用的程序码。 

可以使用一个或多个计算机可用的或计算机可读的介质的任何组合。计算机可用的或计算机可读的介质例如可以是——但不限于——电的、磁的、光的、电磁的、红外线的、或半导体的系统、装置、器件或传播介质。在本文件的语境中，计算机可用的或计算机可读的介质可以是任何含有、存储、传达、传播、或传输供指令执行系统、装置或器件使用的或与指令执行系统、装置或器件相联系的程序的介质。计算机可用的介质可包括在基带中或者作为载波一部分传播的、由其体现计算机可用的程序码的数据信号。计算机可用的程序码可以用任何适当的介质传输，包括-但不限于-无线、电线、光缆、RF等等。 

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。 

对实施例的选择和说明，是为了最好地解释本公开的原理和实际应用，使所属技术领域的普通技术人员能够明了，本公开可以有适合所要的特定用途的具有各种改变的各种实施方式。所给出的对本公开的描述其目的在于示意和描述，并非是穷尽性的，也并非是要把本公开限定到所表述的形式。对于所属技术领域的普通技术人员来说，在不偏离本公开范围和精神的情况下，显然可以作出许多修改和变型。