CN104871133B - 基于服务器健康以及客户端信息的应用智能请求管理 - Google Patents

Abstract

基于服务器健康和客户端信息按应用智能的方式来管理对服务器场的请求。请求管理(RM)模块被配置成基于将请求的性质与服务器基础设施的动态拓扑结构进行相关的路由规则作出智能路由决策。RM可以使用其对服务器应用、服务器、以及客户端的知识来拒绝可能有害的请求进入服务，将良好请求路由到合适的机器，以及维护决策及随之发生的结果的历史以用于自动和/或手动优化。

Description

基于服务器健康以及客户端信息的应用智能请求管理

技术领域

概括地说，本发明涉及数据通信，而更具体地说，本发明涉及数据通信中的请求管理。

背景技术

现代数据通信架构通常涉及“服务器场”，服务器场是出于各种目的管理数据的存储、处理和交换的服务器集合。许多服务越来越多地被作为web应用、托管应用来提供，这些应用可以被用户通过浏览器或类似的瘦客户端访问，而不会给用户带来本地安装、更新、兼容性问题等等负担。如此，服务器场可包括提供用于生产力、通信、数据分析、数据存储以及类似服务的web应用的高达数千服务器。客户端应用(瘦或胖)通过“请求”与托管应用进行交互。例如，作为web应用提供的文字处理应用程序可以接收来自客户端应用的打开文档的请求，在联网的存储中找出该文档，检索其内容，并呈现在客户端应用处。另一示例可以是“保存”请求。当用户完成时，他们可以选择客户端应用上的“保存”控件，这可以将保存请求发送到web应用，从而造成所存储的文档的更新。

由于多个服务器可能涉及该web应用，因此传入的请求需要被定向到正确的服务器，以便所请求的任务可以被完成。请求管理是管理方法中的一种，该方法通过对照请求来评估逻辑规则以便确定要采取什么动作以及场中的哪一个或多个服务器(如果有的话)要处理该请求，来帮助服务器场管理传入的请求。

传统负载平衡和路由通常基于静态规则，不能考虑服务器、请求、网络负载的动态变化。此外，随着越来越多的不同服务和服务版本通过服务器场来提供，管理不同类型的请求和不同类型的服务器(专用、良好健康、不良健康、因承租人而异的、支持不同的应用版本，等等)是复杂的工作。

发明内容

提供本发明内容是为了以精简的形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并不旨在排他地标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

各实施例涉及基于服务器健康和客户端信息的应用智能请求管理。根据一些实施例，请求管理(RM)模块可以基于将请求的性质与服务器基础设施的动态拓扑结构进行相关的路由规则作出智能路由决策。RM可以使用其对服务器应用、服务器、以及客户端的知识来拒绝可能有害的请求进入服务，将良好请求路由到合适的机器，以及维护决策及随之发生的结果的历史以用于自动和/或手动优化。应用、服务器、以及客户端信息可由管理员提供给RM或通过自动机制来收集。

通过阅读下面的“具体实施方式”并参考相关联的附图，这些及其他特点和优点将变得显而易见。应该理解，前面的一般描述和下面的详细描述只是说明性的，并且不限制所要求保护的各方面。

附图简述

图1示出了根据一些实施例的示例网络图，其中可通过服务通信头部/请求头部在请求管理实体和服务器/客户端之间交换服务器健康和客户端信息；

图2示出了根据一些实施例的系统中的客户端请求的示例管理；

图3示出了根据其他实施例的系统中的又一些客户端请求的示例管理；

图4示出了根据各实施例的请求管理器的功能分解图；

图5示出根据一些实施例的示例请求管理设置对象；

图6示出了根据一些实施例的示例请求管理规则和它们的管理；

图7是其中可以实现根据各实施例的系统的联网环境；

图8是其中可以实现各实施例的示例计算操作环境的框图；以及

图9示出了根据各实施例的基于服务器健康和客户端信息的应用智能请求管理的过程的逻辑流程图。

具体实施方式

如以上简要描述的，基于软件和/或硬件的请求管理模块可以使用在周期性或按需的服务交换通信的头部以及来自客户端的请求通信的头部中接收到的服务器健康和客户端信息，来管理请求到云服务内的服务器的转发。在知晓哪一类客户端以及生成了哪一类请求的情况下，请求管理器可被动态地编程以通过可自定义的规则或脚本来将该信息纳入考虑。

在下面的详细描述中，参考构成其一部分的附图，在附图中，通过例图，示出了特定实施例或示例。可组合这些方面，可利用其他方面，并且可以做出结构上的改变而不背离本发明的精神或范围。因此，下面的具体实施方式不应以限制性的意义来理解，而是本公开的范围是由所附权利要求及其等效方案来定义的。

尽管在结合在计算设备上的操作系统上运行的应用程序执行的程序模块的一般上下文中描述了各实施例，但是本领域的技术人员会认识到各方面也可以结合其他程序模块实现。

一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构和其他类型的结构。此外，本领域的技术人员可以明白，各实施例可以用其他计算机系统配置来实施，包括手持式设备、多处理器系统、基于微处理器或可编程消费电子产品、小型计算机、大型计算机以及类似计算设备。各实施例还能在任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实现。在分布式计算环境中，程序模块可位于本地和远程存储器存储设备两者中。

各实施例可被实现为计算机实现的过程(方法)、计算系统、或者诸如计算机程序产品或计算机可读介质等制品。计算机程序产品可以是计算机系统可读并且编码包括用于使计算机或计算系统执行示例过程的指令的计算机程序的计算机存储介质。计算机可读存储介质是计算机可读存储器设备。例如，计算机可读存储介质可经由易失性计算机存储器、非易失性存储器、硬盘驱动器、闪存驱动器、软盘或紧致盘和类似物理介质中的一个或多个来实现。

贯穿本说明书，术语“平台”可以是用于基于服务器健康和客户端信息的应用智能请求管理的软件和硬件组件的组合。平台的示例包括，但不仅限于，在多个服务器上执行的托管服务，在单个计算设备上执行的应用，以及类似系统。术语“服务器”一般指通常在联网环境中执行一个或多个软件程序的计算设备。下面提供了有关这些技术和示例操作的更多细节。

参考图1，图示100示出了根据一些实施例的示例网络图，其中可通过服务通信头部/请求头部在请求管理实体和服务器/客户端之间交换服务器健康和客户端信息。图示100所示出的组件和环境只是出于说明的目的。各实施例可以在使用各种计算设备和系统、硬件和软件的各种本地、联网的、基于云的和类似计算环境中实现。

在图示100中所示出的示例环境中，服务器112可以是例如，向通过在客户端设备102、103、105和107上执行的客户端应用(例如，浏览器)访问服务的用户提供一个或多个托管服务的服务器场或类似基础设施(例如，云108)的一部分。服务器104和106可以接收来自相应客户端应用的请求，并将它们转发到被配置成将请求路由到正确服务器的请求管理服务器101。

在一个示例场景中，诸如美国华盛顿州雷德蒙市的微软公司的之类的协作服务可以作为服务提供。协作服务可以允许对各种类型的文档的存储、共享以及编辑，等等。如此，用户可以通过他们的客户端设备上的浏览器访问协作服务，查看文档，编辑文档，以及将它保存在其服务器位置。这些动作可以通过由浏览器向服务器104或106提交的并由请求管理服务器101路由的请求来促进。根据各实施例的系统可包括可伸缩架构中的任何数量的请求管理服务器。云108中的不同服务器可以负责服务的不同方面。例如，一个服务器可以负责某些类型的文档的存储，而另一服务器可以负责促进编辑功能。另外，多个服务器还可以负责相同任务以提供容量、冗余等等。请求管理服务器104和106可以基于该服务器的可用性、健康状况、请求类型、客户端类型等等，通过路由器110向将请求发送到正确的服务器。在一些实施例中，路由、扼流和/或负载平衡功能性可以被集成到路由器110中，而不是请求管理服务器104或106中。

在决定要向哪一个服务器发送请求时，如上文所讨论的，请求管理服务器可以考虑服务器健康状况、客户端类型、和/或请求类型。服务器健康状况可以由各单独服务器以分数或更详细的信息(118)的形式，在服务通信116的头部114中作为请求管理服务器101和服务器112之间的正常通信交换的一部分，提供给请求管理服务器101。作为例行操作的一部分，服务器112及服务的其他组件可以周期性地或按需交换服务通信116。服务通信116可包括头部114。取决于通信类型，头部的示例可包括HTTP头部、Sharepoint头部，等等。在一个示例系统中，每一服务器都可以确定其健康状况(例如，处理器容量、存储器容量、带宽、当前负载，等等)，并将健康状况传送到请求管理服务器101。

健康信息118或分数可以是可由管理员自定义的。例如，健康状况可以是单个分数、多个分数(对于健康量度的多个组或健康量度中的每一个)，或更详细的信息(健康量度值)。该信息可以在头部中发送到请求管理服务器101。在决定阻塞还是转发请求、向哪一个服务器路由请求、以及如何执行负载平衡时，请求管理服务器101(或路由器110)可以考虑健康信息。

与经由头部交换服务器健康状态信息相似，请求管理服务器101可以经由请求通信120的头部124来从客户端设备102、103、105和107接收客户端信息122。客户端信息可以标识客户端类型，如机器人、真实用户、与服务器场的特定承租人相关联的客户端、与提交请求的客户端应用相关联的服务版本、以及类似信息。客户端信息还可标识请求类型，这可引导请求管理服务器101确定处理该请求时涉及什么类型的资源以及资源量。因而，请求管理服务器101可以使用客户端信息来决定将请求发送到哪些服务器、是否要对该请求进行扼流、以及是否及如何对该请求进行负载平衡。

请求管理服务器(在这些服务器处执行的一个或多个请求管理应用或模块)可以基于将请求的性质与服务器场的动态拓扑结构进行相关的路由规则来作出智能路由决策。请求管理服务器可以维护并分析决策和随之发生的结果以用于自动和/或手动优化。被解释的一个或多个规则和/或可自定义脚本可被用来作出路由、扼流、负载平衡决策。根据一些实施例，请求管理服务器101和/或路由器110可以被实现为软件、硬件或软件和硬件的组合。

图2示出了根据一些实施例的系统中的客户端请求的示例管理。图示200在概念上显示请求管理的若干示例场景。例如，来自用户236(例如与机器人形成对比)的请求可以是正常情况且被请求管理器230指派高优先级，从而被指派给良好健康的服务器234。来自机器人客户端238的请求可被指派较低优先级且被发送给低健康(或专用)服务器232或被拒绝以进行重试，因为机器人可容易地重试请求而没有数据损失或性能降级。在另一示例中，具有交互式会话的客户端(例如，浏览器)可被指派高优先级且被发送给具有良好健康的服务器234，因为任何延迟可被用户容易地检测并使用户体验降级。在又一示例中，来自超过它们的资源限额的客户端242的请求可被拒绝。类似地，有问题的请求244(例如，与资源的过度使用相关联的请求、不安全的请求、或未知来源的请求)可不被允许或被拒绝以稍后重试。

以下是示例场景：系统上可能具有许多最终用户浏览器请求的沉重负担。笔记本同步请求可能开始来自笔记web应用。管理员可以意识到这些请求可能不利地影响浏览器请求，并且添加扼流规则以拒绝笔记web应用请求。在下一传入的笔记web应用请求时，请求管理器可以评估：

拒绝具有UserAgent regex＝“Note Taking App 2010*”(用户代理正则表达式＝“笔记应用2010*”)的请求。

基于这一规则，请求管理器可以拒绝该请求。在系统负载减轻时，管理员可以移除该扼流规则并再次允许笔记请求。或者，管理员可以在规则的期满字段中输入时间以使其自动停用。拒绝某些请求来为其他请求预留资源的能力可以允许更大的可靠性。高优先级请求(如来自最终用户的交互式请求)可通过降低它们与低优先级请求竞争资源的需求来被确保增强型服务。在一些实施例中，规则可由系统自动应用且被应用了健康阈值。在这种情况下，随着服务器负载增加以及服务器健康分数达到接近或大于该阈值的值，规则可被自动应用且笔记请求被阻塞。

在另一示例场景中，针对服务的一个版本的新浏览器请求可以到达，跟随有针对同一服务的较新版本的请求(多个版本可被同时部署以用于不同客户端/承租人)。路由规则可存在于该系统中以将针对较旧版本的请求路由到一个场中的所选服务器且将针对较新版本的请求路由到另一个场(或同一个场)中的其他所选服务器。请求管理器可以评估：

将具有URL regex＝”service_version1*”(URL正则表达式＝“服务版本1*”)的请求路由到场1，WFE1–WFE3

将具有URL regex＝”service_version2*”(URL正则表达式＝“服务版本2*”)的请求路由到场2，WFE2–WFE4

基于这些规则，请求管理器可以将第一请求在场1中的WFE1–WFE3服务器之间随机路由，且可以将第二请求在场2中的WFE2–WFE4服务器之间随机路由。以此方式使请求分开的能力可以允许更容易的可管理性和容量规划。场之一可被供应所需的资源/配置以服务较旧版本请求，而其他场可被类似地供应以用于服务较新版本请求。在一些实施例中，用健康状况加权的路由可被采用来代替随机路由。

在另一示例场景中，一系列新请求可到达。场中的一个服务器可能是不良健康，而其他两个服务器可能是良好健康。请求管理器可以评估：

健康信息：{[WFE1,有病],[WFE2,健康],[WFE3,健康]}

基于这一信息，请求管理器可以路由请求，将它们在WFE2和WFE3之间拆分，而非加重有病的WFE1的负担。或者，管理员可以从路由池中移除WFE1，从而允许它完成其当前请求的处理并返回健康状态。基于健康来作出路由决策的能力可以允许更大的可靠性。

在一些实施例中，加权的路由可被实现。健康方面可按照设置权重的方式进入。策略引擎机制可以分析服务器健康数据并相应地且动态地更新权重。因而，系统可以采用规则或脚本来作出优化的路由决策；扼流或排定优先次序以防止有害请求进入服务并排定不同请求类型的优先次序；以及维护作出路由决策的原因以及决策的结果(成功/响应时间、失败/原因)的记录以用于优化并允许自动和手动自定义。

图3示出了根据其他实施例的系统中的又一些客户端请求的示例管理。图示300示出了三个附加示例场景。根据第一场景，承租人1的客户端358可以向托管多个承租人的服务器场的请求管理器330提交请求。因而，该请求可被转发给该场中的与承租人1(352)相关联的服务器。另外，请求管理器可以与两个不同的场相关联，其中一个场(354)支持服务的旧版本而另一个场(356)支持服务的旧版本和新版本两者。来自客户端360的针对旧版本的请求可被发送给场354或场356，而来自客户端362的针对新版本的请求只可被发送给场356。

下表包括进一步的说明性示例场景。这些和上面所讨论的场景旨在用于说明，且不构成对各实施例的限制。

表1.示例请求管理场景

根据各实施例，通过规则或脚本基于服务器健康信息和客户端信息对请求进行路由、扼流以及负载平衡可以是应用智能的。例如，不同的请求类型或客户端类型可被指派不同的优先级，且请求根据应用类型被路由/扼流/负载平衡。例如，与数据存储服务或数据分析服务中的类似请求相比，生产力服务中的请求可被不同地处理。

图4示出了根据各实施例的请求管理器的功能分解图。图示400显示请求管理器(RM)470，其任务是决定请求是否可以被允许进入服务，如果是，则请求可以被发送到哪一个WFE服务器。这两个决策可以由RM 470的三个主要功能部件(请求路由(RR)472、请求扼流和优先(RTP)474以及请求负载平衡(RLB)476)作出。在某些实施例中，RM 470可以在每个web应用的基础上执行请求管理。

如果系统中没有规则或没有执行脚本，则RR 472可以随机选择该请求要被发送到的服务器。如果存在规则或脚本被执行，则RR 472可以应用该规则，例如如表1所示。该系统中可以存在许多路由规则，但它们可能未必全部应用于每一请求。因而，RR 472可以通过请求-规则匹配来确定哪些规则匹配给定请求。每一规则可具有一个或多个匹配准则，这可包括：匹配属性、匹配类型、以及匹配值。匹配属性可包括主机名、统一资源定位符(URL)、IP地址、用户代理、端口、超文本传输协议(HTTP)方法、其他头部，等等。匹配类型可包括准则，诸如“相等”、“包含”、“始自”，等等。匹配逻辑可看起来像：

如果[匹配属性][匹配类型][匹配值]，则路由到[服务器]

示例匹配语句可看起来像：

如果([用户代理][包含][“Note_Taking_App_2010(笔记应用2010)”])则路由到

除了请求_规则匹配之外，RR 472还可执行服务器选择。服务器选择可以使用所有路由规则，不管它们匹配还是不匹配给定请求。匹配的规则使请求必需可被发送到它们的机器集中的服务器之一。不匹配的规则使请求必需可不被发送到它们的机器集中的服务器中的任一个。

RTP 474可以将路由池过滤到足够健康以处理请求的服务器。如果RR472被启用，则路由池可以是RR 472选择的服务器。如果RR 472被禁用，则路由池可以是当前服务器。在后一种情况下，RTP 474可以决定其自己的服务器是否足够健康以处理请求。类似于RR472，RTP 474可被分成两部分：请求-规则匹配和服务器过滤。请求_规则匹配可以与RR 472类似地执行。

在服务器过滤中，RTP 474可以使用来自扼流规则的健康阈值参数结合环境服务器健康数据来确定所选路由池中的服务器是否可处理给定请求。RTP474首先可确定路由池是当前服务器还是包括RR 472选择的一个或多个服务器。RTP 474随后可检查匹配规则以找出最小健康阈值。在过滤过程的结束处，路由池中可存在零个、一个或多个服务器。如果没有服务器，则服务器的健康与管理员的扼流规则集相组合可能已经确定当前没有服务器可以处理该请求，且适当的出错页可被返回给客户端。

在RR 472和RTP 474被执行时，多个路由目标仍然可供用于使该请求被发送到它们。RLB 476可以选择将该请求发送到的单个目标。该目标可以使用先前描述的路由加权方案或类似方法来选择。在一示例实施例中，路由目标可以始自权重1。如果静态加权被打开，则权重可以使用每一路由目标的静态权重集来调整。如果健康加权被打开，则权重可以使用健康信息来被进一步调整，以向较健康的目标添加权重且从较不健康的目标移除权重。如果客户端(客户端类型、请求类型)也被用在决策过程中，则可以应用基于该信息的进一步加权。一旦使用所启用的路由加权方案调整了路由目标权重，它们就可被用来按加权随机来选择单个目标。

在被启用时，扼流组件可以对照指定开始扼流的阈值的扼流规则的集合来匹配请求。该阈值可以是服务器健康的形式。对于所有匹配的扼流规则，如果服务器健康值高于规则的阈值，则服务器可被从列表中移除。在路由没有被启用但扼流被启用的情况下，当前服务器可被用作服务器的列表。在扼流组件的结束处，如果服务器列表是空的，则扼流页可被发送给客户端。

图5示出根据一些实施例的示例请求管理设置对象。

在根据各实施例的系统中，路由和扼流组件可以在其创建期间按照web应用来配置。各组件可以在其他应用代码之前执行。请求管理的配置信息可包括服务器列表(默认或自定义)、路由状态(启用/禁用)、扼流状态(启用/禁用)、路由规则、以及扼流规则。以下是示例多步骤技术。

步骤0：确定是否要执行路由

路由组件的起始点可以是确定是否要执行路由。这可通过查看配置以检查路由是否被启用来检查。如果没有，则可不采取进一步的步骤。接着，路由组件可以检查标识先前路由评估的自定义头部。这一头部可由路由组件在最后步骤中插入，且标识评估路由的场。

步骤1：启动服务器集

可以使用路由的配置设置来检索服务器的列表(其可被用于路由)。请求管理器可以跟踪两个服务器集。第一服务器集可以是场的服务器，它可被自动填充。管理员可以使用管理组件来设置这些服务器的可用性。请求管理组件所维护的第二服务器集可以是管理员所指定的自定义服务器。服务器的工作集合可以是来自这两个列表的可用服务器，如根据服务器的可用性设置所定义的。

步骤2：评估路由规则

这一步骤可以查看请求头部并评估路由规则。路由规则可被高速缓存在启用了路由的每一web应用本地。在一些实施例中，在评估请求时，该逻辑可以使用高速缓存在本地的规则。每一规则可对照请求来被评估。对于每一规则，路由规则Criteria(准则)中的每一MatchProperty(匹配属性)可以确定对照哪一头部值来进行匹配。MatchValue(匹配值)(以及MatchType(匹配类型))可被用来通过对照属性值来运行正则表达式或匹配类型比较，来确定特定规则是否匹配该请求。每一匹配可以对照该请求评估为真以应用规则。如果规则匹配，则该规则中的每一服务器可被从步骤1中找出的服务器集中选择出。如果规则不匹配，则该规则中的每一服务器可以从步骤1中找出的服务器集中移除，只要没有匹配规则包含该服务器。如果存在匹配的规则，则路由目标的列表可以是这些规则所选择的服务器。如果没有匹配的规则，则路由目标的列表可以是没有被这些规则移除的服务器。如果在步骤2之后没有留下服务器，则出错页可被返回给客户端。

步骤3：评估扼流

在步骤2确定的路由目标可被用作扼流组件的输入。返回值可以是移除了被扼流的服务器的新列表。

步骤4：路由请求

路由的最后步骤可以是将请求传递给新服务器以处理它。为了通知最后目标路由已经执行，自定义头部可被添加到该请求，指定哪一个场评估了该路由。以此方式，场中的单个服务器可以处理该路由。路由目标列表中的每一服务器的健康状况可以被用来执行加权的负载平衡。为了将请求路由到最终目标，一旦被确定，就可以创建新请求。可以将传入的请求复制到该新请求，该新请求包括诸如以下值：头部、cookie、请求正文，等等。来自服务器的响应可被复制到传出流。同样，这可包括值，诸如头部、cookie、响应正文，等等。

上面所描述的示例是用于说明的目的，且不旨在构成对各实施例的限制。根据各实施例在系统中对请求进行路由/扼流可以用更多或更少步骤以及按其他操作次序来实现。

图示500示出了具有在字段582、属性584以及方法586下编组的特定示例配置元素的示例请求管理设置对象。取决于系统配置、应用类型、服务器类型、以及其他方面，设置对象可包括更多或更少元素。

图6示出了根据一些实施例的示例请求管理规则和它们的管理。

每一扼流规则可包括确认该规则、对照传入的请求进行匹配、以及指定用于扼流的阈值所需的信息。如上所述，路由和扼流可以作为web应用执行的一部分来执行。web应用的扼流可以在web应用的路由之后执行。以下是示例多步骤扼流技术。

步骤0：确定是否要执行扼流

扼流组件的起始点可以是确定是否要执行扼流。这可通过查看配置以检查扼流是否被启用来检查。如果没有，则可不采取进一步的步骤。

步骤1：确定扼流目标

扼流目标可以由路由组件来确定。如果这未被启用，则当前服务器可被用作目标。

步骤2：评估扼流规则

下一步骤可以检查请求头部并评估每一扼流规则。扼流规则可被高速缓存在启用了扼流的每一web应用本地。在评估请求时，该逻辑可以使用高速缓存在本地的规则。每一规则可对照请求来被评估。路由规则中的每一MatchProperty(匹配属性)可以确定对照哪一头部值来进行匹配。MatchValue(匹配值)(以及MatchType(匹配类型))可被用来通过对照属性值来运行正则表达式或匹配类型比较，来确定特定规则是否匹配该请求。

每一匹配可以对照该请求评估为真以应用规则。如果规则匹配，则扼流目标中的具有高于规则的阈值的健康分数的任何服务器可被移除。如果在步骤2之后没有留下服务器，则扼流页可被返回给客户端。所得的服务器列表可被返回给路由组件。

图示600示出了馈送到具有上述元素(如扼流阈值、路由目标、扼流规则、路由规则、准则、期满，等等)的示例请求管理规则对象694的示例扼流规则对象692和示例路由规则对象696。

图1到5中的示例场景和模式被示为带有特定的组件、通信协议、数据类型以及配置。各实施例不仅限于根据这些示例配置的系统。在使用此处所描述的原理来实现基于服务器健康和客户端信息的应用智能请求管理时，可以使用其他协议、配置、头部等等。

图7是其中可以实现根据实施例的系统的联网环境。本地以及远程资源可以通过一个或多个服务器714或诸如托管服务之类的单个服务器(例如，web服务器)716来提供。应用智能请求管理应用可以在管理服务器(例如，服务器714中的一者或多者)上执行，应用智能请求管理应用接受/拒绝/通过网络710将来自诸如智能电话713、平板设备712或膝上型计算机712之类的各单独计算设备(“客户端设备”)上的客户端应用的请求定向到正确的服务器(例如，数据库服务器718)。

如上文所讨论的，可以通过头部交换服务器健康和客户端信息以用于请求管理。可以使用应用知晓决策过程基于规则或脚本来作出路由/扼流决策。客户端设备711-713可以允许对在如前面所讨论的远程服务器(例如，服务器714中的一个)上执行的应用的访问。服务器可以直接或通过数据库服务器718从数据存储719检索或向其存储相关数据。

网络710可包括服务器、客户机、因特网服务供应商以及通信介质的任何拓扑结构。根据各实施例的系统可以具有静态或动态拓扑结构。网络710可包括诸如企业网络等安全网络、诸如无线开放网络等非安全网络、或因特网。网络710还可通过诸如公共交换电话网络(PSTN)或蜂窝网络等其他网络来协调通信。此外，网络710可包括诸如蓝牙或类似网络等短程无线网络。网络710提供此处描述的节点之间的通信。作为示例而非限制，网络710可以包括例如声学、射频、红外线和其他无线介质等无线介质。

可以采用计算设备、应用、数据源和数据分发系统的许多其他配置来实现基于服务器健康和客户端信息的应用智能请求管理。此外，图7中所讨论的联网环境只是为了说明的目的。各实施例不仅限于示例应用、模块，或过程。

图8及相关联讨论旨在提供对其中可实现各实施例的合适计算环境的简要概括描述。参考图8，该图示出了诸如计算设备800之类的根据各实施例的应用的示例计算操作环境的框图。在基本配置中，计算设备800可包括至少一个处理单元802和系统存储器804。计算设备800还可包括在执行程序时协作的多个处理单元。取决于计算设备的确切配置和类型，系统存储器804可以是易失性的(诸如RAM)、非易失性的(诸如ROM、闪存等)或是两者的某种组合。系统存储器804通常包括适于控制平台的操作的操作系统805，例如来自华盛顿州雷蒙德市的微软公司的和WINDOWS 操作系统。系统存储器804还可以包括一个或多个软件应用，诸如程序模块806、请求管理应用822、路由模块824、扼流模块826、以及负载平衡模块828。

根据各实施例，请求管理应用822可以管理传入的请求，包括将请求定向到准确的服务器、服务器状态信息的维护、路由/扼流/负载平衡规则和脚本的管理。不同的子任务(如路由、扼流以及负载平衡)可由不同或集成模块来执行，如路由模块824、扼流模块826、以及负载平衡模块828。该基本配置在图8中通过虚线808内的那些组件示出。

计算设备800可以具有附加特征或功能。例如，计算设备800还可包括附加数据存储设备(可移动和/或不可移动)，诸如，例如磁盘、光盘或磁带。在图8中通过可移动存储809和不可移动存储810示出这样的附加存储。计算机可读存储介质可以包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机可读存储介质是计算机可读存储器设备。系统存储器804、可移动存储809和不可移动存储810都是计算机可读存储介质的示例。计算机可读存储介质包括但不限于，RAM、ROM、EEPROM、闪存或其他存储器技术，CD-ROM、数字多功能盘(DVD)或其他光学存储，磁带盒、磁带、磁盘存储或其他磁存储设备，或能用于存储所需信息且能够由计算设备800访问的任何其他介质。任何这样的计算机可读存储介质都可以是计算设备800的一部分。计算设备800也可具有输入设备812，诸如键盘、鼠标、笔、语音输入设备、触摸输入设备和类似输入设备。还可以包括输出设备814，诸如显示器、扬声器、打印机和其他类型的输出设备。这些设备在本领域中公知且无需在此处详细讨论。

计算设备800还可以包含允许该设备与其他设备818通信的通信连接816，诸如通过分布式计算环境中的无线网络、卫星链路、蜂窝链路和类似机制。其他设备818可包括执行通信应用的计算机设备、存储服务器和类似设备。通信连接816是通信介质的一个示例。通信介质可以包括计算机可读指令、数据结构、程序模块、或者诸如载波或其他传输机制等的已调制数据信号中的其他数据，并且包括任何信息传递介质。术语“已调制数据信号”指其一个或多个特征以这样的方式设置或改变以便在信号中对信息进行编码的信号。作为示例而非限制，通信介质包括诸如有线网络或直接线连接之类的有线介质，以及诸如声学、射频、红外及其他无线介质之类的无线介质。

各示例实施例还包括各种方法。这些方法可以用任何数量的方式来实现，包括本文中所描述的结构。一种此类方式是通过本文中描述的类型的设备的机器操作。

另一可任选方式是该方法的各个操作中的一个或多个操作在结合一个或多个人类操作者执行该方法的各个操作中的某一些的情况下被执行。这些人类操作者无需彼此同在一处，而是其每一个可以仅与执行程序的一部分的机器同在一处。

图9示出了根据各实施例的基于服务器健康和客户端信息的应用智能请求管理的过程的逻辑流程图。在一些示例中，过程900可以通过诸如在服务器场管理中的路由器或扼流器之类的请求管理应用来实现。

过程900可始自可任选操作910，在此，作为正常系统交换的一部分，可以在来自服务基础设施中的服务器的服务通信的头部中接收服务器健康信息。在可任选操作920，可以从客户端接收请求连同客户端信息(例如，客户端类型和/或请求类型)。

在操作930，可以由请求路由模块作出是否要执行路由的判定，此后跟随有操作940处的起始服务器集的确定。在操作950，请求扼流和优先模块可以评估路由规则(或执行脚本)，从而执行请求匹配和服务器选择。在操作960，扼流规则可被评估且作出是否应当对接收到的请求进行扼流的判定。在操作970，路由和扼流规则评估的结果可被使用来执行路由、扼流、以及负载平衡中的一者或多者。

一些实施例可以在包括通信模块、存储器以及处理器的计算设备中实现，其中处理器结合存储在存储器中的指令执行如上文所描述的方法或类似方法。其他实施例可以实现为在其上存储了用于执行如上文所描述的方法或类似方法的指令的计算机可读存储介质。

过程900中所包括的操作只是为了说明的目的。根据各实施例基于服务器健康和客户端信息的应用智能请求管理可以使用本文所述的各原理通过具有更少或更多步骤的相似过程、以及按不同的操作次序来实现。

以上说明书、示例和数据提供了对各实施例的组成的制造和使用的完整描述。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求和各实施方式的示例形式而公开的。

Claims (10)

1.一种在计算设备上执行的用于基于服务器健康和客户端信息的应用智能请求管理的方法，所述方法包括：

在服务通信的头部中从服务基础设施中的一个或多个服务器接收服务器健康信息；

从客户端接收请求，其中所述请求包括在所述请求的头部中的客户端信息；

确定是否要执行路由；

如果要执行路由，则确定起始服务器集；

对照接收到的请求和所述起始服务器集来评估路由规则；

确定是否要执行扼流；

确定一个或多个扼流目标服务器；以及

评估扼流规则，其中，检查匹配规则以找出最小健康阈值，如果服务器健康值高于所述最小健康阈值，则从扼流目标服务器中移除所述服务器；以及

基于所述评估的结果来将所述请求路由到所选服务器。

2.如权利要求1所述的方法，其特征在于，评估所述路由规则包括：

确定与接收到的请求相匹配的一个或多个规则；以及

基于从服务器接收到的健康信息来将路由池过滤到满足健康状况阈值的服务器。

3.如权利要求2所述的方法，其特征在于，进一步包括：

通过采用所有路由规则而不管是否匹配所述请求来过滤所述路由池，其中匹配的规则使所述请求必需被发送给路由池中的服务器之一，且不匹配的规则使所述请求必需不被发送给所述路由池中的服务器中的任一个。

4.如权利要求1所述的方法，其特征在于，进一步包括：

每一规则具有一个或多个匹配准则，所述匹配准则包括：匹配属性、匹配类型、以及匹配值。

5.如权利要求4所述的方法，其特征在于，进一步包括：

如果在扼流之后多个路由目标服务器可供用于所述请求被发送到它们，则采用加权路由权重方案来选择单个目标服务器。

6.如权利要求5所述的方法，其特征在于，进一步包括：

如果健康加权被启用，则基于来自所述服务器的健康信息来调整权重，使得权重被添加到较健康的目标服务器且权重从较不健康的目标服务器移除。

7.如权利要求5所述的方法，其特征在于，进一步包括：

如果客户端加权被启用，则基于来自所述客户端的客户端信息来调整权重，其中所述客户端信息与客户端类型、服务版本、请求类型、以及请求重复中的一者或多者相关联。

8.一种用于基于服务器健康和客户端信息来采用应用智能请求管理的计算设备，所述计算设备包括：

被配置成与服务基础设施中的一个或多个服务器和一个或多个客户端进行通信的通信模块；

被配置为存储指令的存储器；以及

耦合到所述存储器的处理器，所述处理器被配置成结合存储在所述存储器中的所述指令来执行请求管理应用，其中所述请求管理应用被配置成：

在服务通信的头部中从服务基础设施中的一个或多个服务器接收服务器健康信息；

从客户端接收请求，其中所述请求包括在所述请求的头部中的客户端信息；

确定是否要执行路由；

如果要执行路由，则确定起始服务器集；

对照接收到的请求和所述起始服务器集来评估路由规则；

确定是否要执行扼流；

确定一个或多个扼流目标服务器；

评估扼流规则；以及

如果所述请求不被扼流，则采用加权路由将所述请求路由到所选服务器。

9.如权利要求8所述的计算设备，其特征在于，所述请求管理应用进一步被配置成执行脚本以执行路由和扼流。

10.一种用于基于服务器健康和客户端信息的应用智能请求管理的方法，所述方法包括：

在服务通信的头部中从服务基础设施中的一个或多个服务器接收服务器健康信息；

从客户端接收请求，其中所述请求在所述请求的头部中包括客户端信息；

确定是否要执行路由；

如果要执行路由，则确定起始服务器集；

对照接收到的请求和所述起始服务器集来评估路由规则；

确定是否要执行扼流；

确定一个或多个扼流目标服务器；

评估扼流规则；以及

如果所述请求不被扼流，则采用加权路由将所述请求路由到所选服务器。