CN109729131B - 一种应用请求的处理方法、装置和路由器 - Google Patents

Abstract

本申请公开了一种应用请求的处理方法、装置和路由器，涉及应用技术领域，其中方法包括：当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；根据各台服务器的实时负载状态和设备配置信息，确定各台服务器对应的请求处理能力评估信息；按照各台服务器当前的请求处理能力评估信息，将应用请求转发给请求处理能力满足预定要求的服务器进行处理。通过这种流量自动切换策略，及时切换至可用的服务器，无需修改路由配置参数，也就不会重启服务器应用系统产生宕机时间，进而保证服务器能够对客户端发来的应用请求及时处理，避免出现应用请求无法响应的情况，不会影响客户端应用的正常使用。

Description

一种应用请求的处理方法、装置和路由器

技术领域

本申请涉及应用技术领域，特别是涉及一种应用请求的处理方法、装置和路由器。

背景技术

随着市场上平板电脑、智能手机等智能终端的兴起，智能终端已经成为人们生活中不可或缺的一部分，用户可以通过智能终端上安装的客户端应用进行在线聊天、网络游戏、网上购物等操作。通常采用客户端和服务器(Client/Server，C/S)结构的应用系统来实现这些应用的功能，具体通过客户端向服务器发送应用功能对应的应用请求，然后由服务器反馈请求处理结果。

目前，为了提升应用系统的处理性能实现流量切换的目的，传统模式是需要人工根据应用系统中各台服务器的实时运行状态，修改路由配置参数，然后再重启应用系统，重启完成后就会实现将新接收到的客户端应用请求分配给适合的服务器进行处理。

然而，应用系统重启会产生宕机时间，在宕机时间内服务器无法对新接收到的应用请求进行处理，进而就会出现客户端发送的应用请求无法响应的情况，从而影响了客户端应用的正常使用。

发明内容

有鉴于此，本申请提供了一种应用请求的处理方法、装置和路由器，主要目的在于解决目前传统模式针对于流量的切换策略需要修改路由配置参数并重启应用系统会产生宕机时间，在此宕机时间内服务器无法对新接收到的应用请求进行处理，就会出现客户端发送的应用请求无法响应的问题。

依据本申请的第一方面，提供了一种应用请求的处理方法，所述方法包括：

当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

根据所述实时负载状态和所述设备配置信息，确定各台服务器当前的请求处理能力评估信息；

按照各台服务器当前的请求处理能力评估信息，将所述应用请求转发给请求处理能力满足预定要求的服务器进行处理。

依据本申请的第二方面，提供了一种应用请求的处理装置，所述装置包括：

接收单元，用于当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

确定单元，根据所述实时负载状态和所述设备配置信息，确定各台服务器当前的请求处理能力评估信息；

处理单元，用于按照各台服务器当前的请求处理能力评估信息，将所述应用请求转发给请求处理能力满足预定要求的服务器进行处理。

依据本申请的第三方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现第一方面所述的应用请求的处理方法。

依据本申请的第四方面，提供了一种路由器，所述路由器包括存储介质和处理器，

所述存储介质，用于存储计算机程序；

所述处理器，用于执行所述计算机程序以实现第一方面所述的应用请求的处理方法。

借由上述技术方案，本申请提供的一种应用请求的处理方法、装置和路由器，与目前针对于流量的切换策略的传统模式相比，本申请在接收到客户端发来的应用请求后，能够根据应用系统中各台服务器的实时负载状态以及设备配置信息，确定出各台服务器当前的请求处理能力评估信息，进而根据该请求处理能力评估信息评估出各个服务器处理应用请求的能力，并从各个服务器中筛选出最合适的服务器来处理应用请求。通过这种流量自动切换策略，及时切换至可用的服务器，无需修改路由配置参数，也就不会重启服务器应用系统产生宕机时间，进而保证服务器能够对客户端发来的应用请求及时处理，避免出现应用请求无法响应的情况，不会影响客户端应用的正常使用。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请提供的应用请求的处理方法的一个实施例的流程图；

图2为本申请提供的应用请求的处理装置的一个实施例的结构框图；

图3为本申请提供的路由器的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供了一种应用请求的处理方法，能够根据应用系统中各台服务器的实时负载状态以及设备配置信息，找出最合适的服务器来处理应用请求，这样服务器应用系统就无需进行重启的操作，也不会产生宕机时间，因而就能够及时处理客户端发来的应用请求。如图1所示，本申请实施例提供的应用请求的处理方法的步骤包括：

步骤101，当接收到客户端需要向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息。

其中，实时负载状态可以包含服务器当前的负载情况，如服务器正在处理的应用请求数量、当前负载百分比、CPU使用率、内存占用情况等；设备配置信息可以包含服务器各部分的硬件情况，如服务器的CPU型号、内存大小、存储容量等信息；客户端发送的应用请求可以与应用的功能或具体业务相关，如请求调取服务器中的数据信息、请求服务器转发客户端发来的消息、请求服务器对客户端发来的数据进行计算、请求服务器调取客户端对应账户的详细信息等等。

对于本实施例的执行主体可以为应用请求处理的装置或设备，用于将客户端需要向服务器发送的应用请求转发给适合的服务器进行快速准确的处理，以实现流量自动切换的目的，具体可理解为应用系统的网关设备，当该装置或设备接收到客户端发来的应用请求时，可以根据各台服务器的实时负载状态以及设备配置信息选择合适的服务器进行流量切换，具体执行步骤102至103所示的过程。

步骤102，根据获取到的各台服务器的实时负载状态和设备配置信息，确定各台服务器当前的请求处理能力评估信息。

其中，请求处理能力评估信息中可以包含对服务器请求处理能力的评估情况，如对其请求处理能力的打分、评定等级等；还可以包含对服务器处理请求的预测情况，如服务器还能处理的最大请求数量(若超过该最大请求数量则容易出现运行异常)、服务器新接收到应用请求后多长时间能够处理完毕等。

例如，获取各台服务器还能处理的最大请求数量，根据该最大请求数量，为各台服务器匹配请求处理能力评估信息对应的评估分数，该最大请求数量越多证明服务器的请求处理能力越强，因而评估分数越高。然后获取各台服务器的设备配置信息，根据该设备配置信息从第三方或其它网络上查询得到服务器相应的性能得分，并按照该性能得分的由高到低的顺序为各台服务器匹配对应的评估分数，服务器的硬件配置越高对应的评估分数越高。最后将各台服务器对应的上述两个评估分数进行累加，得到最终的评估分数，并按照最终的评估分数进行服务器排序，即得到各台服务器对应的请求处理能力的排序。

步骤103，按照各台服务器当前的请求处理能力评估信息，将应用请求转发给请求处理能力满足预定要求的服务器进行处理。

其中，预定要求可以根据用户的实际需求预先设定。例如，预定要求可以为选取请求处理能力最高的服务器，或选取请求处理能力中等偏上的服务器等等。

对于本实施例，预定要求还可以结合应用请求对应的类别进行设定，进而可以从各台服务器中筛选出既满足业务处理需求又能快速准确处理请求的服务器。例如，接收到的应用请求的类别为服务类，由于服务类的应用请求处理复杂度较小，因此服务类的应用请求对应的预定要求可以是请求处理能力评估信息中的评估分数在50分以上的服务器，方可处理服务类的应用请求，从评估分数超过50分的服务器中选择一台服务器作为处理该应用请求的服务器。

又例如，接收到的应用请求的类别为加密类，由于加密类的应用请求处理复杂度较大，因此加密类的应用请求对应的预定要求是请求处理能力评估信息中的评估分数在80分以上的服务器，方可处理加密类的应用请求，从评估分数超过80分的服务器中选择一台服务器作为处理该应用请求的服务器。

需要说明的是，考虑到需要转发的应用请求为多个的场景，本实施例可以根据各台服务器的请求处理能力评估信息，按照请求处理能力的比例值转发这些应用请求，例如A、B两台服务器的请求处理能力的比例值是2:1，即服务器A的请求处理能力是服务器B的2倍，此时如果有15个应用请求需要转发，按照该比例值，则有10个应用请求会进入服务器A进行处理，剩下5个应用请求会进入服务器B进行处理。通过这种方式，可以无需修改路由配置参数，也无需对服务器应用系统进行重启，就可以达到路由按需自动切换的目的。

通过应用本技术方案，根据应用系统中各台服务器的实时负载状态以及设备配置信息，评估出各个服务器处理应用请求的能力，并根据处理应用请求的能力从各个服务器中筛选出最合适的服务器来处理应用请求，通过这种流量自动切换策略，及时切换至可用的服务器，无需修改服务器的配置，也就不会重启服务器产生宕机时间，进而保证服务器能够对客户端发来的应用请求进行及时的处理，避免出现应用请求无法响应的情况，不会影响客户端应用的正常使用。

进一步的，作为上述实施例的细化和扩展，为了具体说明各台服务器对应请求处理能力评估信息的确定实施方式，在本申请的一个可选实施例中，步骤102具体可以包括如下子步骤：

步骤1021，根据获取得到的各台服务器的设备配置信息，从预置存储位置中获取各台服务器在空载状态下请求处理能力的第一权重。

其中，预置存储位置中保存有按照不同设备配置信息分别预先配置的各台服务器在空载状态下请求处理能力的权重，预置存储位置具体可以为映射表或数据库等。例如，预先根据不同服务器的设备配置信息，从第三方或其它网络上查询得到服务器相应的性能评分，具体可以通过性能评分软件计算得到该设备配置信息下的服务器的性能评分；然后参照该性能评分设置各台服务器在空载状态下请求处理能力的权重并保存在预置存储位置当中，这里硬件配置越高相应的性能评分就越高，而性能评分越高相应的在空载状态下请求处理能力的权重也越大。

又例如，还可以直接根据服务器的硬件情况直接配置其在空载状态下请求处理能力的权重并保存在预置存储位置当中，服务器的CPU型号的版本越新、主频越高、内核数量越多、内存越大，其权重越高；反之，版本越旧、主频越低、内核数量越少、内存越小，其权重越低。具体可以为每种CPU型号、内核、内存，分别设置相对应的权重值，然后获取各台服务器的CPU型号对应的权重值、内核对应的权重值、内存对应的权重值，然后将三者的权重值进行累加得到其在空载状态下请求处理能力的权重。

步骤1022，根据获取到的各台服务器的实时负载状态，对各台服务器进行负载评分，得到各台服务器当前请求处理能力的第二权重。

例如，获取各台服务器能够处理请求数量的最大值a，以及各台服务器当前正在处理的数量b，利用公式(a-b)来计算每台服务器还能处理请求的数量。并根据每台服务器剩余负载的百分比进行评分，即还能处理请求的数量越多，且剩余负载百分比越高则评分越高。然后按照评分由高到低的顺序对各台服务器进行排序，并按照该排序结果为各台服务器匹配相应的权重。

步骤1023，通过第一权重和第二权重，确定各台服务器当前的请求处理能力评估信息。

例如，可以直接将每台服务器对应的两种权重进行累加，根据累加结果确定服务器对应的请求处理能力评估信息，其中，累加结果越大，证明请求处理能力越强。通过这种方案，能够更加合理的将各个服务器的负载状态和设备配置信息进行结合，进而根据结合后确定的各台服务器对应的请求处理能力评估信息更加准确，使得确定出的处理应用请求的服务器更加合理。

考虑到负载状态和设备配置信息两种不同角度对服务器请求处理能力评估影响的不同，作为一种优选方式，为了得到更加准确的请求处理能力评估信息，步骤1023具体可以包括：对各台服务器的第一权重和第二权重进行加权求和，得到各台服务器当前的请求处理能力评估值。相应的，步骤103具体可以包括：将应用请求转发给当前请求处理能力评估值最大的服务器进行处理；或将应用请求转发给当前请求处理能力评估值在预设范围内的服务器进行处理。其中，预设范围可以根据实际情况预先设置，例如，预设范围可以设置为请求处理能力评估值大于一定阈值的范围。

在本优选方式中，可以根据实际业务需求预先为两种权重分别设置相应的比例系数，以便进行加权求和时，将两种分别乘以各自相应的比例系数之后，再进行累加，作为服务器对应的请求处理能力评估值。例如，比例系数可以根据应用请求的种类进行设置，若获取到应用请求种类是服务类，则服务器1在空载状态下请求处理能力的权重A的比例系数是0.3，及根据服务器1实时的负载状态确定得到的权重B的比例系数是0.5，则服务器1当前的请求处理能力评估值为：A×0.3+B×0.5。

按照上述方案中得出的请求处理能力评估值由大到小的顺序进行排列，可以选择排在最靠前的一台服务器来处理应用请求，或者选择排在前N台服务器中任意选择一台服务器来处理应用请求。

有时服务器可能因为一些异常原因导致中途宕机或无法服务，为了解决该问题，进一步的，在步骤103之后，本方法还可以包括：若请求处理能力符合预定要求的服务器没有响应，则根据各台服务器当前的请求处理能力评估信息，按照请求处理能力从高到低的顺序，将应用请求依次转发给各台服务器，直至找到可正常处理应用请求的服务器时停止转发；或将应用请求直接转发给应用系统中可正常处理应用请求的服务器进行处理。

在上述技术方案中，将应用请求转发给请求处理能力符合预定要求的服务器之后，如果该服务器没有响应，证明该服务器运行出现异常，需要换一台服务器来处理应用请求，这时可以按照各台服务器请求处理能力的顺序进行筛选，帅选出请求处理能力最强的服务器，然后改向该服务器转发应用请求，以保证应用请求能够及时被服务器处理，并且不会给请求处理能力较弱的服务器增加负担。

除了上述方式以外，还可以向各台服务器同时发出测试请求，若服务器接收到该测试请求后能够反馈响应信息，证明该服务器运行正常，能够正常处理应用请求。否则，证明该服务器运行异常，不能正常处理应用请求。然后将所有能正常处理应用请求的服务器进行汇总，并根据请求处理能力评估信息，按照请求处理能力由高到低的顺序进行排列，并从中选择请求处理能力最高的一台服务器或任意选择一台服务器，来对应用请求进行处理。

上述方案中，一旦发现服务器运行异常，就会将该服务器进行异常标记。该服务器被异常标记期间，不再处理客户端发来的应用请求，并且后续会定期向该服务器发送重试请求(该重试请求并非真正的应用请求)，测试该服务器是否恢复正常运行，当发现服务器对该重试请求能够响应时，则将该服务器的异常标记删除，恢复该服务器的正常使用。

通过应用本技术方案，即使服务器出现运行异常的情况，也能保证应用请求能够及时被处理，避免流量进入到不再提供服务的机器当中，减少出现应用请求无响应的情况。

如果各台服务器中出现运行异常的服务器，为了提高对再接收到的应用请求的处理效率，相应的，本方法还可以包括：当再接收到客户端向服务器发送的新的应用请求时，对应用系统中除去没有响应服务器后剩余的各台服务器进行请求处理能力评估信息的确定操作，以便将新的应用请求转发给在剩余的各台服务器中请求处理能力满足预定要求的服务器进行处理。

通过应用上述方案，应用系统再接收到新的应用请求后，能够将上一个应用请求确定出的没有响应的服务器，进行剔除，然后从剩余运行正常的服务器中筛选出合适的服务器来处理新的应用请求(具体为新的应用请求筛选合适服务器的过程，可以参照上述技术方案中对应用服务器筛选的过程)。这样，可以避免将新接收到的应用请求转发给运行异常服务器的情况，可以提高新接收到的应用请求的处理效率。

通常同一用户一次访问的不同应用请求会随机分配给不同的服务器进行处理，这样就可能会导致出现用户流量丢失的问题，为了解决该问题，进一步的，在本申请的另一可选实施例中，步骤101具体可以包括：首先调取客户端的请求记录，并从请求记录中查询上一次处理客户端应用请求的服务器的标识信息，以及上一次接收到应用请求的时间信息，若该时间信息与当前时间信息之间的时长小于预定时长阈值，则将本次接收到的应用请求转发给与该标识信息对应的服务器进行处理，若时间信息与当前时间信息之间的时长大于或等于预定时长阈值，则获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息。

在上述技术方案中，应用系统会将客户端发送的每个应用请求，和接收到应用请求的时间信息，以及处理该应用请求的服务器的标识信息，进行映射后并列表记录在应用系统中。这样，当应用系统再次接收到相同的应用请求后，首先判断两次应用请求的间隔时间是否小于预定时长阈值(例如，10分钟)，若是，则根据记录的服务器的标识信息查找上一次应用请求对应的服务器，将本次应用请求，转发至该服务器进行处理；否则，按照上述方案内容为本次应用请求筛选合适的服务器进行处理。

例如，应用系统会将接收到的每个应用请求都进行HASH(哈希算法)处理成唯一的钥匙串，并将该钥匙串与对应的处理服务器的标识号进行对应存储在该客户端的访问记录中。当应用系统接收到客户端发来的应用请求后，会对该应用请求进行HASH处理成唯一的钥匙串，从应用系统中调取发送应用请求的客户端的访问记录，查询所述访问记录中是否存在该钥匙串，若存在，则提取访问记录中最后一次处理应用请求的服务器，将应用请求发送到该服务器进行处理；若不存在，则根据各台服务器的实时负载状态以及设备配置信息，为该应用请求筛选出合适的服务器进行处理。

通过上述技术方案，如果两次相同的应用请求的接收间隔时间小于预定时长阈值，就可以使用相同的服务器进行处理，既能减少筛选合适服务器的时间，又可以保证在应用服务器正常可用的情况下，使得用户一次访问相关联的一系列的应用请求都可以由同一应用服务器进行处理，不用担心一个人在访问过程中流量丢失的问题。

目前为了应用新版本能够逐渐过渡发布以保证整体系统的稳定，通常会采用灰度发布方式，而本申请为了满足用户不同的业务需求，方便用户选择灰度发布或正式线上生产，作为又一种可选实施例，步骤101具体还可以包括：通过对应用请求进行对应的HTTP请求(HTTP Request)进行解析，得到客户端访问域名时附带的Cookie标记；检测Cookie标记是否包含预先配置的灰度标记，若Cookie标记包含预先配置的灰度标记，则获取在灰度发布环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息，若Cookie标记不包含预先配置的灰度标记，则获取在线上生产环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息。

其中，灰度发布环境与线上生产环境的域名相同，灰度发布环境为预先根据实时的线上生产环境创建得到的环境。例如，根据线上生产环境当前的实际情况(包括服务器当前正常运行的个数，每个服务器处理请求的能力(如请求响应时间、处理请求数量等)，线上生产环境已发布的应用版本等)，创建与线上生产环境相同的灰度发布环境，其中该灰度发布环境可以理解为线上生产环境的备份环境，包含多台应用服务器。而线上生产环境可以理解为直接面对用户的环境，而灰度是介于在内网环境和线上环境中间的一层服务层，灰度发布环境属于线上生产环境中的测试环境，可以为应用更新代码所提供的服务进行更加有安全性保证的测试；灰度发布环境除代码外，与线上生产环境完全一致，在极大的可能性下，排除对线上用户服务造成影响。

在本可选实施例中，当用户想要先将应用请求在灰度发布环境中进行测试处理时，在发送应用请求时，可以在对应的HTTP请求附带的Cookie标记中加入灰度标记。这样应用系统接收到该应用请求后，就会根据灰度标记将该应用系统发送至灰度发布环境中，按照上述各个实施例筛选服务器处理应用请求的方案进行测试处理。当在灰度发布环境中处理正常后，再将该应用请求发送到线上生产环境中，按照其在灰度发布环境中处理步骤在线上生产环境中处理。当用户想将直接将应用请求发送至线上生产环境中进行处理时，就不在对应的HTTP请求附带的Cookie标记中加入灰度标记，这样该应用请求就会直接被发送至线上生产环境中，按照上述各个实施例筛选服务器处理应用请求的方案进行处理。

例如，以Nginx反向代理服务器为例，对于m.ph.com.cn这个域名的访问过程，根据相关条件对HTTP请求进行转发，这里可以预先准备两份代码，一份对应线上生产环境，另一份对应灰度发布环境；检测Cookie标记，如果有预先做的灰度标记，就可以认为是需要将应用请求放入到灰度发布环境中进行测试处理，反之，如果没有预先做的灰度标记，就可以认为是需要将应用请求直接进入线上生产环境进行处理。

示例性的，上述灰度发布环境的预先创建过程，具体包括如下步骤：

步骤A，安装Lua(可嵌入其它脚本语言中使用的脚本语言)解释器。其中，该解释器是即时编辑的脚本解释器(Just-In-Time Compiler of Lua programming language，LuaJIT)，该脚本解释器实质是采用C语言编写的Lua解释器的代码；

步骤B，配置负载均衡服务器安装时所需的环境变量。为后续编译安装负载均衡服务器(如Nginx服务器，为高性能的HTTP和反向代理服务器)做准备；

步骤C，获取负载均衡服务器的测试安装包，并根据环境变量编译安装负载均衡服务器；

步骤D，获取并安装Lua脚本使用数据库和Lua脚本本地终端数据库；

步骤E，参照当前的线上生产环境的配置信息，在负载均衡服务器中解析并执行脚本解释器的脚本逻辑，利用脚本逻辑将脚本使用数据库与脚本本地终端数据库进行关联，完成灰度发布环境的创建。

例如，利用Nginx服务器做负载均衡和反向代理，Nginx服务器内嵌Lua脚本解释器，能够解析并执行Lua语言编写的脚本逻辑，由于Lua脚本使用数据库中存放有一些通过用户访问域名时附带的Cookie值关联的灰度分流的策略，因此可以通过Lua脚本解释器解析该Cookie值得到储存在用户本地终端上的数据以及访问Lua脚本本地终端数据库，来实现灰度发布环境的构建过程。这样，创建出一个跟线上生产环境相同的灰度发布环境，能够在该灰度发布环境中对应用请求进行测试处理，避免了直接将应用请求放入线上生产环境进行处理，出现处理错误，影响用户的正常使用的问题。

对于本技术方案，通过流量自动切换策略，及时切换至可用的应用服务器，不需要修改配置并重启应用系统，就可以达到服务器按需自动切换的目的，减少出现应用请求无法响应的情况；且通过按需分配哪个环境可以满足不同的业务需求；通过在服务器正常运转的条件下，使得同一用户在一次访问只会进入同一台服务器进行处理，使得用户一次访问相关联的一系列的应用请求都可以由同一服务器进行处理，不用担心用户在访问过程中流量丢失的问题；本技术方案通过这些优点可以提高应用系统动态分流策略的完整性。

进一步的，作为图1方法的具体实现，本申请实施例提供了一种应用请求的处理装置，如图2所示，装置包括：接收单元21、确定单元22和处理单元23。

接收单元21，用于当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

确定单元22，用于根据实时负载状态和设备配置信息，确定各台服务器当前的请求处理能力评估信息；

处理单元23，用于按照各台服务器当前的请求处理能力评估信息，将应用请求转发给请求处理能力满足预定要求的服务器进行处理。

在具体实施例中，确定单元22具体包括：权重获取模块、评分模块、确定模块；

权重获取模块，用于根据设备配置信息，从预置存储位置中获取各台服务器在空载状态下请求处理能力的第一权重，其中预置存储位置信息中保存有按照不同设备配置信息分别预先配置的各台服务器在空载状态下请求处理能力的权重；

评分模块，用于根据实时负载状态，对各台服务器进行负载评分，得到各台服务器当前请求处理能力的第二权重；

确定模块，用于通过第一权重和第二权重，确定各台服务器当前的请求处理能力的评估信息。

在具体实施例中，确定模块具体包括：加权子模块，用于对各台服务器的第一权重和第二权重进行加权求和，得到各台服务器当前的请求处理能力的评估值；

相应的，处理单元23，还用于将应用请求转发给请求处理能力评估值最大的服务器进行处理；或将应用请求转发给请求处理能力评估值在预设范围内的服务器进行处理。

在具体实施例中，装置还包括：请求转发单元，用于若请求处理能力符合预定要求的服务器没有响应，则根据各台服务器当前的请求处理能力的评估信息，按照请求处理能力从高到低的顺序，将应用请求依次转发给各台服务器，直至找到可正常处理应用请求的服务器时停止转发；或将应用请求直接转发给应用系统中可正常处理应用请求的服务器进行处理。

在具体实施例中，装置还包括：请求再处理单元，用于当再接收到客户端向服务器发送的新的应用请求时，对应用系统中除去没有响应服务器后剩余的各台服务器进行请求处理能力评估信息的确定操作，以便将新的应用请求转发给在剩余的各台服务器中请求处理能力满足预定要求的服务器进行处理。

在具体实施例中，接收单元21具体包括：调取模块和查询模块；

调取模块，用于调取客户端的请求记录；

查询模块，用于从请求记录中查询上一次处理客户端应用请求的服务器的标识信息，以及上一次接收到应用请求的时间信息；若时间信息与当前时间信息之间的时长小于预定时长阈值，则将本次接收到的应用请求转发给与标识信息对应的服务器进行处理；若时间信息与当前时间信息之间的时长大于或等于预定时长阈值，则获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息。

在具体实施例中，接收单元21具体还包括：解析模块和检测模块；

解析模块，用于通过对应用请求进行对应的HTTP请求进行解析，获取得到客户端访问域名时附带的Cookie标记；

检测模块，用于检测Cookie标记是否包含预先配置的灰度标记；若Cookie标记包含预先配置的灰度标记，则获取在灰度发布环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；若Cookie标记不包含预先配置的灰度标记，则获取在线上生产环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息，其中，灰度发布环境与线上生产环境的域名相同，灰度发布环境为预先根据实时的线上生产环境创建得到的环境。

需要说明的是，本申请实施例提供的一种应用请求的处理装置所涉及各功能单元的其他相应描述，可以参考图1中的对应描述，在此不再赘述。

基于上述如图1所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1所示的应用请求的处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述图1所示方法和图2所示装置的实施例，为了实现上述目的，本申请实施例还提供了一种路由器，如图3所示，包括存储介质32和处理器31，其中存储介质32和处理器31均设置在总线33上。存储介质32，用于存储计算机程序；处理器31，用于执行该计算机程序以实现上述如图1所示的应用请求的处理方法。

可选地，该路由器还可以连接用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种路由器结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理和路由器硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与路由器中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过流量自动切换策略，及时切换至可用的应用服务器，不需要修改配置并重启应用系统，就可以达到服务器按需自动切换的目的，减少出现应用请求无法响应的情况；且通过按需分配哪个环境可以满足不同的业务需求；通过在服务器正常运转的条件下，使得同一用户在一次访问只会进入同一台服务器进行处理，使得用户一次访问相关联的一系列的应用请求都可以由同一服务器进行处理，不用担心用户在访问过程中流量丢失的问题。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (9)

1.一种应用请求的处理方法，其特征在于，所述方法包括：

当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

根据所述实时负载状态和所述设备配置信息，确定各台服务器当前的请求处理能力评估信息；

根据所述应用请求对应的类别或/和所述应用请求中用户的实际需求设定预定要求，其中所述预定要求包括选取满足处理能力要求的服务器；

按照各台服务器当前的请求处理能力评估信息，将所述应用请求转发给请求处理能力满足所述预定要求的服务器进行处理；

所述根据所述实时负载状态和所述设备配置信息，确定各台服务器当前的请求处理能力评估信息，具体包括：

根据所述设备配置信息，从预置存储位置中获取各台服务器在空载状态下请求处理能力的第一权重，其中所述预置存储位置中保存有按照不同设备配置信息分别预先配置的各台服务器在空载状态下请求处理能力的权重；及，

根据所述实时负载状态，对各台服务器进行负载评分，得到各台服务器当前请求处理能力的第二权重；

通过所述第一权重和所述第二权重，确定各台服务器当前的请求处理能力的评估信息。

2.根据权利要求1所述的方法，其特征在于，通过所述第一权重和所述第二权重，确定各台服务器当前的请求处理能力的评估信息，具体包括：

对各台服务器的所述第一权重和所述第二权重进行加权求和，得到各台服务器当前的请求处理能力评估值；

按照各台服务器当前的请求处理能力评估信息，将所述应用请求转发给请求处理能力满足所述预定要求的服务器进行处理，具体包括：

将所述应用请求转发给当前请求处理能力评估值最大的服务器进行处理；或，

将所述应用请求转发给当前请求处理能力评估值在预设范围内的服务器进行处理。

3.根据权利要求1所述的方法，其特征在于，将所述应用请求转发给请求处理能力满足所述预定要求的服务器之后，所述方法还包括：

若所述请求处理能力满足所述预定要求的服务器没有响应，则根据各台服务器当前的请求处理能力评估信息，按照请求处理能力从高到低的顺序，将所述应用请求依次转发给各台服务器，直至找到可正常处理所述应用请求的服务器时停止转发；或，

将所述应用请求直接转发给所述应用系统中可正常处理应用请求的服务器进行处理。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

当再接收到客户端向服务器发送的新的应用请求时，对所述应用系统中除去没有响应服务器后剩余的各台服务器进行请求处理能力评估信息的确定操作，以便将所述新的应用请求转发给在所述剩余的各台服务器中请求处理能力满足所述预定要求的服务器进行处理。

5.根据权利要求1所述的方法，其特征在于，所述获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息，具体包括：

调取所述客户端的请求记录；

从所述请求记录中查询上一次处理所述客户端应用请求的服务器的标识信息，以及上一次接收到所述应用请求的时间信息；

若所述时间信息与当前时间信息之间的时长小于预定时长阈值，则将本次接收到的所述应用请求转发给与所述标识信息对应的服务器进行处理；

若所述时间信息与当前时间信息之间的时长大于或等于所述预定时长阈值，则获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息。

6.根据权利要求1所述的方法，其特征在于，所述获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息，具体包括：

通过对所述应用请求进行对应的HTTP请求进行解析，得到所述客户端访问域名时附带的Cookie标记；

检测所述Cookie标记是否包含预先配置的灰度标记；

若所述Cookie标记包含所述灰度标记，则获取在灰度发布环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

若所述Cookie标记不包含所述灰度标记，则获取在线上生产环境的应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息，其中，所述灰度发布环境与所述线上生产环境的域名相同，所述灰度发布环境为预先根据实时的线上生产环境创建得到的环境。

7.一种应用请求的处理装置，其特征在于，所述装置包括：

接收单元，用于当接收到客户端向服务器发送的应用请求时，获取应用系统中各台服务器的实时负载状态以及各台服务器的设备配置信息；

确定单元，根据所述实时负载状态和所述设备配置信息，确定各台服务器当前的请求处理能力评估信息；根据所述应用请求对应的类别或/和所述应用请求中用户的实际需求设定预定要求，其中所述预定要求包括选取满足处理能力要求的服务器

处理单元，用于按照各台服务器当前的请求处理能力评估信息，将所述应用请求转发给请求处理能力满足所述预定要求的服务器进行处理；

所述确定单元，还用于根据所述设备配置信息，从预置存储位置中获取各台服务器在空载状态下请求处理能力的第一权重，其中所述预置存储位置中保存有按照不同设备配置信息分别预先配置的各台服务器在空载状态下请求处理能力的权重；及，根据所述实时负载状态，对各台服务器进行负载评分，得到各台服务器当前请求处理能力的第二权重；通过所述第一权重和所述第二权重，确定各台服务器当前的请求处理能力的评估信息。

8.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至6任一项所述的应用请求的处理方法。

9.一种路由器，其特征在于，所述路由器包括存储介质和处理器，

所述存储介质，用于存储计算机程序；

所述处理器，用于执行所述计算机程序以实现权利要求1至6任一项所述的应用请求的处理方法。

Images