技术领域
[0001] 本
发明涉及特别是在基于
云的无状态（stateless）
服务器架构的上下文中处理请求。
背景技术
[0002] 在这样的架构中，多个服务器被提供用于处理来自多个客户端的请求。服务器能够位于相同的物理
位置中，或者位于不同的物理位置中，但是就任何特定客户端而言它们不知道服务器的位置。服务器位于负载均衡机制后面，所述负载均衡机制依照各种各样的负载均衡技术来管理从客户端终端到服务器的请求。客户端经由可以为有线的或无线的任何适合的网络与负载均衡机制通信，并因此与服务器通信。
[0003] 图1图示了示例性架构，其中云被一般地表示成被示出为包括位于负载均衡机制6后面的多个服务器4。客户端终端8经由网络10与云2通信。客户端终端能够被实施为任何形式的计算机终端。例如，它们可以是膝上型电脑、平板、
移动电话、个人计算机等。在每种情况下，客户端终端8执行允许终端的用户
访问云2的应用（例如，安装的客户端）。云2形成可被应用访问的因特网的一部分。当服务是需要的时，访问特定因特网位置的请求被从客户端终端8发送到网络10以用于例如使用形式为统一资源
定位符URL的因特网地址来访问该位置。当云2被访问时，负载均衡机制6接收请求并且将它导向服务器4中的一个。所选服务器处理请求并且将响应返回给发出了请求的客户端终端8。
[0004] 应当了解，在任何特定时间，非常大量的请求能够由客户端全球性地发出以便将在云2处被接收并且由负载均衡机制6管理。服务器4在它们不知道关于可能已从相同的客户端终端被接收到并且发出到云2中的其它服务器的较早请求的任何事情的意义上而言是不可知论的。每个特定服务器基于由负载均衡机制6所管理的到该服务器的传入请求的队列而管理对它服务的请求的处理。
[0005] 这样的架构的例子是在
搜索引擎中，其中搜索请求被从客户端终端接收并且导向服务器。服务器通过实施搜索并且将搜索结果返回给发出了请求的客户端终端的用户来处理请求。
发明内容
[0006] 本发明内容被提供来以简化形式引入下面在具体实施方式中被进一步描述的构思的选择。本发明内容不旨在识别所要求保护的主题的关键特征或必要特征，它也不旨在被用来限制所要求保护的主题的范围。
[0007] 从用户终端发出请求的方法在本文中被描述。针对服务的第一请求被发出到服务器。对第一请求的响应被监测以便确定它是否在预定时间内在用户终端处被接收到。如果响应在预定时间内尚未被接收到，则第二类似的请求被发出，其包括表示处理第一请求的失败的程度的遇困（distress）信息，遇困信息基于监测步骤被评估。
[0008] 用户终端被描述，其用于访问来自它经由通信网络被连接到的服务器的服务。用户终端具有可操作来将针对服务的第一请求发出到服务器的传送功能。用户终端还具有监测对第一请求的响应是否在预定时间内在终端处被接收到的监测功能。如果响应在预定时间内尚未被接收到，则传送功能发出针对相同服务的第二类似的请求。在用户终端处的插入功能在第二请求中插入表示处理第一请求的失败的程度的遇困信息，其中遇困信息通过监测功能被评估。
[0009] 具有在计算机可读介质上的计算机可读指令的
计算机程序产品被描述，所述计算机可读指令当被计算机执行时提供用于建立通信事件的通信客户端。所述产品还向服务器发出针对通信客户端需要的服务的第一请求，监测对第一请求的响应是否在预定时间内在用户终端处被接收到，并且如果响应在预定时间内尚未被接收到，则发出第二类似的请求并且将表示处理第一请求的失败的程度的遇困信息包括在第二请求中，遇困信息基于监测步骤被评估。
[0010] 各种
实施例能够被应用在各式各样的上下文中。它能够被用于浏览器应用、web客户端以及其它客户端。根据一个例子，可操作来建立基于分组的通信的通信客户端能够受益于本发明构思。
[0011] 为了更好地理解各种实施例并且为了示出这些实施例可以如何被付诸实施，现在将作为例子对
附图进行参考。
附图说明
[0012] 图1是无状态服务器基于云的架构的示意图；
[0013] 图2是依照一个或多个实施例的客户端终端的架构的构件的示意
框图；
[0014] 图3是依照一个或多个实施例的浏览器应用的功能框图；以及
[0015] 图4是依照一个或多个实施例的服务器的功能框图。
具体实施方式
[0016] 各种实施例能够改进特别地但不排他地在基于无状态服务器的云架构中处理请求的效率。
[0017] 各种实施例使得客户端侧应用能够根据连续请求向服务器侧发
信号通知接收服务的遇困或失败。这使得服务器侧能够优先考虑请求和/或能够后退以便提供较低的复杂性或服务
质量。这允许对近实时应用来说是重要的可配置质量/服务时间（time-to-serve）权衡。本原理能够被应用于使得web服务API（应用编程
接口）调用能够被建立的通信系统。无状态服务器可以保持针对Web服务API调用的备选
进程的列表。在一个实施例中，备选进程可以基于计算要求而被优先考虑。在一个实施例中，如果服务器负载是高的，则较低计算要求进程可以响应于客户端调用而被执行。
[0018] 服务器配置可以是调用到供替换的调用的映射。
[0019] 配置能够由app开发者设置。配置被同步到组中的所有其它无状态服务器。替换地，开发者可以在每个服务器处设置不同的配置。
[0020] 当客户端应用向云做出服务请求时，它附加关于最后失败的请求的信息。在负载均衡后面的无状态云服务器通常将不知道先前的请求的失败，但是由于在该请求中提供的“遇困”信息，它能够优先考虑队列中的该请求，并且还考虑采用不同的（例如，计算上更便宜的）
算法来服务该请求。
[0021] 参考图2，每个客户端终端8包括被连接到
存储器22和显示器24的处理器20。处理器20能够执行存储在存储器22中的代码。特别地，它能够执行用于经由因特网来访问服务的客户端。以下描述描述了其中客户端是浏览器应用或web客户端的情况。然而，各种实施例不仅是预定给这样的上下文。根据另一例子，可操作来通过因特网建立基于分组的通信的通信客户端能够受益于本发明构思。这样的通信客户端的例子是由Skype提供的通信客户端。处理器20被连接到端口26，从所述端口26，到云2的请求能够被发出并且对那些请求的响应能够被接收到。如在本领域中众所周知的，浏览器应用能够使
用户界面在显示器24上被呈现给用户，借助于这个，用户能够键入因特网地址以便访问用户需要的服务。例如，它可能正从
数据库中搜寻内容。
[0022] 由客户端发出的到云的请求能够响应于用户请求或在不用用户具体地知道请求已被发出的情况下被发出。所有用户知道他已要求了特定服务。
[0023] 依照本发明的实施例，浏览器应用（web客户端）被
修改以便当客户端向云做出服务请求时附加关于最后的先前失败请求的遇困信息。这可能是先前已被提交的失败请求的数目或自第一请求以来以秒为单位的时间，从而提供对于服务质量的
感知恶化的梯度。
[0024] 在负载均衡机制6后面的无状态云服务器（如在图1中一样）通常不知道先前的请求的失败，但是采用本文中所描述的经修改的客户端应用，在请求中提供的遇困信息能够允许请求在服务器处被优先考虑。附加地或替换地，当遇困信息指示已存在恶化的服务质量时服务器能够考虑采用不同的（例如，计算上更便宜的）算法来服务请求。这个机制能够被用来当系统处于压
力之下时通过减少服务器上的负载并且通过降低服务质量来减少到客户端终端的服务中断。
[0025] 出于说明的目的，依照一个或多个实施例的经修改的客户端的示意功能图在图3中被示出。传送功能30将请求32传送到云2。接收功能34接收对该请求的响应35。例如，这可能是在服务来自数据库的用户内容的web页面的上下文中，其中客户端使用AJAX来请求内容。如众所周知的，AJAX（异步Java Script和XML（扩展
标记语言））提供能够被用来从服务器中检索数据的请求对象。AJAX允许数据在用户终端与服务器之间被异步地交换，而不干扰当前被呈现给用户的web页面。接收功能34监测用于接收响应的时间。如果响应在
指定的时间内未出现，则类似的后续请求被生成（有效地，请求被重复），连同生成修改以包括关于在接收服务时的延迟的遇困信息。遇困信息在遇困功能36中被处理并且通过插入功能38插入到请求中。遇困信息由请求32中的附图标记42来指定，并且能够采取遇困梯度的形式。
[0026] 在客户端侧做按指数规律地增加的等待以帮助减少过载服务器上的负载是可能的，这将增加在接收到后续响应并且判定遇困信息将被包括在下一个请求中之前的时间周期。这能够给忙碌的服务器基于第一遇困信息做出响应留出时间。
[0027] 响应与请求的关联能够使用已知机制以各种各样的方式来完成。在一个实施例中，请求与请求标识符44一起被传送，所述请求标识符44能够被包括在被返回的响应35中，这样客户端终端能够识别响应是否已被提供给特定请求。
[0028] 在客户端是通信客户端的情况下，遇困信息能够被用于对例如客户端的用户不知道的媒体中继请求进行响应。如果中继请求失败则在该上下文中对用户唯一可见的梯度仅仅是长呼叫建立时间。这能够通过客户端发送具有遇困信息的多个请求而被改进。
[0029] 现在将对在服务器处的功能性进行描述。每个服务器能够被实施为单独的服务器或服务器实例。服务器实例中的一个从服务器队列中拾取不比特定超时周期旧的请求，在所述特定超时周期之后请求被放弃。指示较高的遇困梯度（由请求中的遇困信息42的值来表示）的请求在其余请求之前被拾取，并且请求基于遇困梯度被对待。也就是说，特定算法或后端进程或数据库访问能够基于遇困梯度被选择。
[0030] 例如，用户通常能够被呈现有具有源于运行大量的查询的高质量结果的网页，其一起呈现关于用户的预期和如何最好地服务他或她的非常有知识的图片。在示出高遇困梯度（例如高于特定
门限）的请求的情况下，这能够被用显示最新结果的简单查询代替，而不用修改搜索项来使个性化最大化。
[0031] 在其中客户端是通信客户端并且请求与遇困信息一起被发送的上下文中，服务器可以通过为中继来建立通信路径的媒体提供候选的较少优化的选择来做出响应。这允许通信事件（诸如，例如，IP语音电话呼叫）被更迅速地建立，即使可能具有稍微较低的呼叫质量。
[0032] 图4示出了在服务器侧的功能性，其图示依照一个或多个实施例的一个特定服务器实例4a。服务器实例4a具有接收功能50，所述接收功能50评估队列46中的请求32的遇困梯度42并且拾取最遇困的请求以用于处理。选择功能52读取请求中的遇困梯度并且选择许多功能54a、54b、54c中的一个，所述功能54a、54b、54c中的每一个能够以不同程度的复杂性或质量服务请求。所选功能被传递给处理构件56并且请求然后通过处理构件56使用所选功能而被服务，并且结果得到的响应通过传送功能58被生成以用于传送到请求客户端终端。
[0033] 遇困信息能够取决于传输协议被以任何适当的方式提供，并且在应用层处被读取。
[0034] 所描述的本发明的实施例使得客户端侧应用能够针对连续请求发信号通知从服务器侧接收服务的遇困或失败，从而使得服务器侧能够优先考虑请求和/或能够后退以便提供较低的复杂性或较低的服务质量。这允
许可配置质量对服务时间的权衡被实施，这对近实时应用来说是重要的。
[0035] 根据本发明的一个实施例，提供了在计算机服务器处处理请求的方法，包括：从用户终端接收针对服务的请求，请求包括遇困信息，其表示处理来自用户终端的针对服务的至少一个之前类似的请求的失败的程度；从请求接收遇困信息；以及依照遇困信息处理请求。
[0036] 在一个或多个实施例中，处理请求的步骤包括基于遇困信息按顺序对待在服务器处接收到的多个请求当中的请求。
[0037] 在一个或多个实施例中，处理请求的步骤包括从一组备选功能中选择用于基于遇困信息来处置请求的功能。
[0038] 在一个或多个实施例中，在遇困信息高于指示处理先前类似的请求的失败的高程度的门限
水平时，所选功能与该组备选功能中的其它功能相比具有降低的复杂性或成本。
[0039] 在一个实施例中，要被服务器处理的多个请求被放入队列，并且其中服务器基于请求中的遇困信息从队列中检索请求以用于处理。
[0040] 在一个或多个实施例中，已在队列中持续达超过超时周期的周期的请求被丢弃。
[0041] 根据本发明的另一实施例，提供了可操作来处理在其输入端处接收到的请求的服务器，该服务器包括：接收构件，其可操作来接收识别用户终端的请求，请求包括表示处理来自用户终端的至少一个其它请求的失败的程度的遇困信息，以及可操作来从请求中读取遇困信息；以及处理构件，其可操作来依照遇困信息处理请求。
[0042] 在一个实施例中，服务器包括用于处置请求的一组供替换的功能，服务器包括选择功能，其用于基于请求中的遇困信息选择一组功能中的一个以用于处置请求。
[0043] 在另一实施例中，服务器的接收构件可操作来从请求的队列中检索请求以及基于队列的请求中的遇困信息来针对检索选择请求。
[0044] 根据本发明的另一实施例，提供了从用户终端发出请求的方法，包括：向服务器发出针对服务的第一请求；监测对第一请求的响应是否在预定时间内在用户终端处被接收到；如果响应在预定时间内尚未被接收到，则发出第二类似的请求并且将表示处理第一请求的失败的程度的遇困信息包括在第二请求中，遇困信息基于监测步骤被评估。
[0045] 在一个实施例中，所述方法包括：监测对第二或任何后续请求的响应是否在预定时间内被接收到，并且如果响应在预定时间内尚未被接收到，则发出后续或另外的后续请求，其包括表示处理第一请求和第二请求以及任何先前的后续请求的失败的程度的遇困信息。
[0046] 在另一实施例中，遇困信息包括针对相同服务从对于其的响应尚未被接收到的用户终端发出的之前请求的数目。
[0047] 在另外的实施例中，遇困信息包括自发出第一请求以来经过的时间。
[0048] 根据本发明的另一实施例，提供了一种用户终端以用于访问来自它经由通信网络被连接到的服务器的服务，该用户终端包括：传送功能，其可操作来向服务器发出针对服务的第一请求；监测功能，其可操作来监测对第一请求的响应是否在预定时间内在终端处被接收到，其中传送功能被配置成如果响应在预定时间内尚未被接收到则发出针对相同服务的第二类似的请求；以及插入功能，其可操作来将表示处理第一请求的失败的程度的遇困信息包括在第二请求中，其中遇困信息通过监测功能被评估。
[0049] 根据本发明的另一实施例，提供了包括在计算机可读介质上的计算机可读指令的计算机程序产品，所述计算机可读指令当被计算机执行时：将第一请求发出到服务的服务器，监测对第一请求的响应是否在预定时间内在用户终端处被接收到；并且如果响应在预定时间内尚未被接收到，则发出第二类似的请求并且将表示处理第一请求的失败的程度的遇困信息包括在第二请求中，遇困信息基于监测步骤被评估。
[0050] 根据本发明的另一实施例，提供了包括在计算机可读介质上的计算机可读指令的计算机程序产品，所述计算机可读指令当被计算机执行时：从用户终端接收针对服务的请求，请求包括表示处理来自用户终端的针对服务的至少一个之前类似的请求的失败的程度的遇困信息；从请求接收遇困信息；并且依照遇困信息处理请求。
[0051] 一般地，本文中所描述的功能中的任一个能够使用
软件、
固件、
硬件（例如，固定逻辑
电路）或这些实施方案的组合被实施。如本文中所使用的术语“模
块”、“功能性”、“构件”以及“逻辑”一般地表示软件、固件、硬件或其组合。在软件实施方案的情况下，模块、功能性或逻辑表示程序代码，所述程序代码当在处理器（例如，一个或多个CPU）上被执行时执行规定的任务。程序代码能够被存储在一个或多个计算机可读存储器设备中。在下面所描述的技术的特征是平台无关的，意味着技术可以被实施在具有各种各样处理器的各种各样的商业计算平台上。
[0052] 例如，用户终端还可以包括使用户终端的硬件执行操作（例如，处理器功能块等等）的实体（例如软件）。例如，用户终端可以包括可以被配置成保持指令的计算机可读介质，所述指令使用户终端并且更特别地使用户终端的
操作系统和相关联的硬件执行操作。因此，指令运作来配置操作系统和相关联的硬件以执行操作，并且以这种方式导致操作系统和相关联的硬件的转换来执行功能。指令可以由计算机可读介质通过各种各样不同的配置提供给用户终端。
[0053] 计算机可读介质的一个这样的配置是信号承载介质，并且因此被配置成诸如经由网络将指令（例如作为载波）传送到计算设备。计算机可读介质还可以被配置为计算机可读存储介质并且因此不是信号承载介质。计算机可读存储介质的例子包括
随机存取存储器（RAM）、
只读存储器（ROM）、光盘、闪速存储器、
硬盘存储器，以及可以使用磁、光学和其它技术来存储指令和其它数据的其它存储器设备。
[0054] 尽管已经用特定于结构特征和/或方法学动作的语言对本主题进行了描述，但是应当理解，在所附
权利要求中定义的本主题未必限于上面所描述的特定特征或动作。相反，上面所描述的特定特征和动作作为实施权利要求的示例性形式被公开。
