CN117793112A - 一种访问处理方法及服务平台 - Google Patents

Abstract

本发明实施例公开一种访问处理方法及服务平台，其中所述方法包括：访问服务器接收对服务平台的访问请求；访问服务器根据服务平台上多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；如果确定是，则访问服务器从服务平台上的多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。本发明实施例提供的技术方案能够有效保证系统服务正常运行。

Description

一种访问处理方法及服务平台

技术领域

本发明涉及计算机技术领域，尤其涉及一种访问处理方法及服务平台。

背景技术

在当前的企业信息系统应用环境下，保障业务的连续性是至关重要的。业务连续性要求企业能够在面对各种意外情况和灾难事件时，快速恢复业务的正常运作，以避免数据丢失和长时间停机所带来的损失。这一要求的目的是确保企业的核心业务能够持续稳定地运营，保护客户利益不受损害。为此，建立稳定可靠的信息系统基础设施成为确保业务连续性的重要措施。

然而，在实际应用中，经常会出现短时间内大量请求访问企业信息系统的现象，这种情况会给系统带来巨大压力，对业务连续性造成破坏。举例来说，当一个网站发布一条热门新闻或一个在线商店进行特价促销时，访问流量可能会暂时剧增，超过系统原本的承载能力。同样地，DDoS攻击利用大量请求流量，淹没访问企业信息系统的网络带宽或系统资源，从而使系统服务无法正常运行。

发明内容

有鉴于此，本发明实施例提供一种访问处理方法及服务平台，以有效保证系统服务正常运行。

第一方面，本发明实施例提供一种访问处理方法，所述方法包括：

访问服务器接收对服务平台的访问请求；

访问服务器根据服务平台上多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；

如果确定是，则访问服务器从服务平台上的多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

进一步的，访问服务器从服务平台上的多个应用服务器中选定一个，包括：

访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个。

进一步的，访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个，包括：

访问服务器获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

访问服务器按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

进一步的，访问服务器获取服务平台上每个应用服务器的性能评分，包括：

访问服务器获取本次接收到的所述访问请求特征；

访问服务器读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

若读取成功，则访问服务器获取读取结果。

进一步的，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还包括：

对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。

进一步的，所述方法还包括：应用服务器创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。

第二方面，本发明实施例提供一种服务平台，所述平台包括多个访问服务器和多个应用服务器；其中，访问服务器用于：

接收对服务平台的访问请求；

根据所述多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；

如果确定是，则从所述多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

进一步的，访问服务器用于从所述多个应用服务器中选定一个，包括：

根据访问请求特征和应用服务器性能情况，从所述多个应用服务器中选定一个。

进一步的，访问服务器用于根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个，包括：

获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

进一步的，访问服务器用于获取服务平台上每个应用服务器的性能评分，包括：

获取本次接收到的所述访问请求特征；

读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

若读取成功，则获取读取结果。

进一步的，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还包括：

对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。

进一步的，所述应用服务器还用于创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例一提供的一种访问处理方法的流程图；

图2为本发明实施例二提供的一种访问处理方法的流程图；

图3为本发明实施例三提供的一种服务平台的网络架构示意图。

具体实施方式

下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

以下通过各实施例详细介绍本发明的技术方案。

实施例一

本实施例提供一种访问处理方法，应用于服务平台，所述服务平台包括多个访问服务器和多个应用服务器，其中每个访问服务器连接所有应用服务器，并且各个访问服务器之间可直接或间接的相互通信。参见图1，所述访问处理方法包括如下步骤101-103。

步骤101、访问服务器接收对服务平台的访问请求。

本步骤中，访问请求可以是与服务平台所服务的客户端发送的业务处理请求，当然也有可能是攻击者伪装成客户端发送的业务处理请求，该请求的目的地址为服务平台对外开放的一个统一的IP地址。服务平台侧的所有访问服务器都位于同一个局域网或网络内部，可以通过服务器间的通信来实现访问请求的同时传递。当客户端发送访问请求时，服务平台上的任何一个访问服务器都可以将该请求广播给其他访问服务器，以使它们同时接收到该请求。或者，额外部署一个中心设备，用于：对内负责各个访问服务器之间消息的转发；对外接收对服务平台的访问请求，广播请求至各个访问服务器。亦或者，将所述中心设备的功能固定集成于其中一个访问服务器上。

作为一种优选实施方式，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还可包括：对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。可选的，认证失败时，直接丢弃所述访问请求，不再做后续响应处理。其中，所述安全认证可包括安全链接认证和身份安全认证，具体可包括数据保密性检验、数据完整性校验、用户身份验证、密码猜测攻击检验、多因素身份认证、访问控制和审计监控等，从而增强服务平台侧的安全性。

步骤102、访问服务器根据服务平台上多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求。如果是，则执行步骤103；否则结束本次流程，等待下一次访问请求的到来，然后重新执行以上步骤101-102。

本步骤102中，访问分流策略用于决策在服务平台侧的多个访问服务器集群中，由哪个访问服务器来服务特定的访问请求，其可以由本领域技术人员预先设计完后统一在服务平台上的各访问服务器上配置好。每个访问服务器收到对服务平台的访问请求后，独立地评估该请求的属性(如报文头中的一个或多个字段等)，查询访问分流策略，识别该请求的属性所匹配的访问服务器标识，如果得到的访问服务器标识对应为本访问服务器，则确定由本服务器处理本次接收到的所述访问请求。需要说明的是，访问分流策略的设计应充分利用各访问服务器资源，提高访问请求处理的高效性和安全性，例如：访问请求的属性的哈希值范围在预设的第一范围时，匹配访问服务器标识1；访问请求的属性的哈希值范围在预设的第二范围时，匹配访问服务器标识2；依次类推，……。典型的，各访问服务器定期探测服务平台侧的其它访问服务器状态，在其中一个访问服务器发生故障或不可用时，同其它正常工作的访问服务器以竞争的方式接管故障或不可用的访问服务器工作。

本实施例中，每个访问服务器在物理上是独立的，它们分别运行在不同的物理服务器或虚拟主机上，有自己的资源和处理能力，负责处理特定的访问请求，并独立地执行相关的操作。而在逻辑上，又可将这些独立的访问服务器组织成一个逻辑集群或群集，视为一个整体，共同为客户端提供访问服务，客户端可以将这些访问服务器视为一个虚拟的访问服务器，从逻辑上与之交互，而无需关心其内部细节和具体的物理部署。当需要处理更多的访问请求时，可以通过增加更多的访问服务器来提供更大的容量和吞吐量。这种通过物理独立和逻辑统一的方式来处理访问请求可以提供更好的可扩展性、可用性和性能。

步骤103、访问服务器从服务平台上的多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

本步骤中，访问服务器可以通过随机的方式或者负载均衡算法选定服务平台上的一个应用服务器进行本次接收到的所述访问请求响应。其中，负载均衡算法可包括：

轮询：按照预先定义的顺序依次选择应用服务器，实现请求的均匀分配，每个请求依次发送给下一个应用服务器，直到循环完所有的应用服务器；

最少请求处理量：选择请求处理量最少的应用服务器来处理请求，以确保负载更平衡；通过实时监测每个应用服务器的请求处理量，选择请求处理量最少的应用服务器来处理请求；

最短响应时间：根据每个应用服务器的响应时间选择一个响应时间最短的应用服务器，以提供更好的性能体验；通过实时监测每个应用服务器的响应时间，选择响应时间最短的应用服务器来处理请求；

权重：为每个应用服务器分配一个权重值，根据权重的比例来选择应用服务器；可以根据应用服务器的性能情况和处理能力，给予不同的权重值，从而影响请求的分发比例；

IP哈希：根据来源IP地址将相同IP的访问请求始终分发到同一台应用服务器上，以保持会话的一致性；通过对客户端的IP地址进行哈希计算，将相同IP的请求路由到相同的应用服务器。

示例性的，访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个。其中，访问请求特征可包括请求来源，业务类型等；应用服务器性能情况可包括服务类型，应用服务器的负载，访问请求的响应时间、成本效率等。具体的，可以先选定服务类型与访问请求特征相匹配的应用服务器，若此次选定的应用服务器不唯一，则可继续按照应用服务器的负载、访问请求的响应时间、成本效率，进一步从初步选定的应用服务器中选定一个应用服务器，具体的选定规则可根据不同的应用场景和需求而定，例如选定负载最小、响应时间最短或者成本效率最小的，本实施例对此不作具体限定。

本实施例提供的技术方案，具备如下有益效果：

提高系统的可伸缩性：通过将访问服务器和应用服务器分离，可以独立扩展每个组件的能力；当系统的访问量增加时，可以增加访问服务器的数量，而无需改变应用服务器的数量；这样可以更好地应对高并发情况，提高系统的整体可伸缩性；

提高系统的可用性和可靠性：通过设置多个访问服务器，可以将请求均匀地分发到不同的访问服务器上；如果其中一个访问服务器发生故障或不可用，其他访问服务器仍然可以提供服务，保证系统的可用性和可靠性；此外，如果需要进行维护或升级，可以逐个升级访问服务器，而不会影响整个系统的正常运行；

实现负载均衡：多个访问服务器可以通过负载均衡算法来分流请求，将负载均衡地分配给不同的应用服务器；这样可以避免某些应用服务器过载，提高系统的整体性能和吞吐量；

简化系统管理和维护：通过将访问服务器和应用服务器分离，可以更好地划分职责和管理任务；访问服务器主要负责请求的接收、分发和路由，应用服务器主要负责实际的业务处理；这样可以简化系统的管理和维护工作，使系统的整体结构更加清晰和可维护。

在以上方案的基础上，本实施例提供的访问处理方法还包括：应用服务器创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。

创建应用数据镜像是创建一个与原始应用数据完全相同的副本或映像，以确保数据的完整性和一致性，具体可通过流计算技术实现。镜像数据通常实时同步更新，以保持与原始数据的同步状态。数据镜像在处理访问请求时，可以直接使用，作为访问原始数据的备用选择，以提高数据的可用性和系统的容错性。

实施例二

本实施例在上述实施例一的基础上，对应用服务器的选定步骤做进一步优化。参见图2，一种访问处理方法包括步骤201-204。

步骤201、访问服务器接收对服务平台的访问请求。

步骤202、访问服务器根据服务平台上多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求。

如果是，则执行步骤203-204；否则，结束本次流程，等待下一次访问请求的到来，然后重新执行以上步骤201-202。

步骤203、访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个。

步骤204、由访问服务器所选定的应用服务器响应本次接收到的所述访问请求。

上述步骤203中，访问服务器可获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

访问服务器按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

其中，所述应用服务器的多个性能参数用来评估和衡量应用服务器的性能和效能的指标，具体可包括：

应用服务器负载：指应用服务器处理的工作量或负荷，可以通过监测应用服务器的CPU使用率、内存利用率、网络带宽等指标来衡量，反映了应用服务器当前的工作压力和资源利用情况；

成本效率：指在满足性能需求的前提下，以最低的成本获取最大的性能价值，可涉及应用服务器的购买成本、能耗成本、维护成本等方面的考量；

响应时间：指从收到访问请求至应用服务器响应完成的时间间隔，较低的响应时间意味着应用服务器能够更快地处理访问请求并返回结果，提供更快的响应速度；

服务优先级：表示了不同服务需求和任务的重要性和紧急程度，通过设定服务优先级，应用服务器可以根据该优先级来决定如何分配和处理访问请求，确保关键任务得到优先处理。

以上多个性能参数是为了评估应用服务器性能和选择合适的应用服务器而考虑的关键因素。根据对系统的重要性和影响程度，这些性能参数可以有不同的权重考量，具体可以由本领域技术人员预先设定。对于每个应用服务器，将这些性能参数加权时可以使用加权求和或加权评分的方式，但应在加权之前使用归一化或标准化等方法来处理不同性能参数之间的单位和范围差异。需要说明的是，每个应用服务器的性能评分的计算过程都是相同的。

此外，本实施例中，应用服务器的性能参数的权重还与访问请求特征关联，可以根据访问请求特征的变化而进行动态调整，从而能够实现个性化优化、动态适应性、资源分配平衡和预防性能瓶颈等优势，提升应用服务器的性能和用户体验。典型的，访问请求特征包括业务类型。例如，对于一个高流量的网站业务类访问请求，响应时间可能是最重要的因素，而对于一个成本敏感的业务类访问请求，成本效率可能更重要。具体实施时，可事先配置不同种访问请求特征下应用服务器的各个性能参数的权重。

示例性的，所述访问服务器获取服务平台上每个应用服务器的性能评分，可包括：

(1)访问服务器获取本次接收到的所述访问请求特征；

(2)访问服务器读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

(3)若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

(4)若读取成功，则访问服务器获取读取结果。

以上步骤(1)-(4)中，服务平台的各访问服务器每针对一次访问请求计算完本服务器的性能评分后，会将该访问请求特征及其评分结果缓存，并与服务平台上的其它访问服务器共享，其它访问服务器收到后也会进行缓存更新。缓存数据可以整体设置保存时长，统一定期清空，也可针对每条缓存数据(一次访问请求特征及对应的应用服务器性能评分结果)单独设置保存时长，到期后自动删除。其中，保存时长可根据缓存数据的稳定性和更新频率来设置。如果参与应用服务器性能评分计算的性能参数中有大部分是静态参数且动态参数值更新频率较慢，那么该保存时长可设置相对较长；如果参与应用服务器性能评分计算的性能参数中有大部分是动态参数且频繁更新，那么该保存时长可设置短一些，以确保评分结果能及时反映应用服务器的最新情况。

本实施例提供的方案，利用缓存来存储先前计算过的性能评分结果。当接收到一个新的访问请求，会先检查缓存中是否存在与该请求特征相匹配的评分。如果存在匹配的评分值，可以直接使用缓存中的结果，而无需再次进行计算。通过这种方式，可以提高请求的响应速度和效率，避免重复计算。

实施例三

本实施例提供一种服务平台，参见图3，所述服务平台包括多个访问服务器(图中示例为m个)和多个应用服务器(图中示例为n个)，其中每个访问服务器连接所有应用服务器，并且各个访问服务器之间可直接或间接的相互通信。其中，访问服务器用于：

接收对服务平台的访问请求；

根据所述多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；

如果确定是，则从所述多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

示例性的，访问服务器用于从所述多个应用服务器中选定一个，包括：

根据访问请求特征和应用服务器性能情况，从所述多个应用服务器中选定一个。

具体实施时，访问服务器用于根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个，包括：

获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

其中，访问服务器用于获取服务平台上每个应用服务器的性能评分，可包括：

获取本次接收到的所述访问请求特征；

读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

若读取成功，则获取读取结果。

在以上方案的基础上，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还包括：

对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。

优选的，所述应用服务器还用于创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本发明时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种访问处理方法，其特征在于，所述方法包括：

访问服务器接收对服务平台的访问请求；

访问服务器根据服务平台上多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；

如果确定是，则访问服务器从服务平台上的多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

2.根据权利要求1所述的方法，其特征在于，访问服务器从服务平台上的多个应用服务器中选定一个，包括：

访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个。

3.根据权利要求2所述的方法，其特征在于，访问服务器根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个，包括：

访问服务器获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

访问服务器按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

4.根据权利要求3所述的方法，其特征在于，访问服务器获取服务平台上每个应用服务器的性能评分，包括：

访问服务器获取本次接收到的所述访问请求特征；

访问服务器读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

若读取成功，则访问服务器获取读取结果。

5.根据权利要求1-4中任一项所述的方法，其特征在于，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还包括：

对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。

6.根据权利要求1-4中任一项所述的方法，其特征在于，所述方法还包括：应用服务器创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。

7.一种服务平台，其特征在于，所述平台包括多个访问服务器和多个应用服务器；其中，访问服务器用于：

接收对服务平台的访问请求；

根据所述多个访问服务器间的访问分流策略，确定是否由本服务器处理本次接收到的所述访问请求；

如果确定是，则从所述多个应用服务器中选定一个，由所选定的应用服务器响应本次接收到的所述访问请求。

8.根据权利要求7所述的服务平台，其特征在于，访问服务器用于从所述多个应用服务器中选定一个，包括：

根据访问请求特征和应用服务器性能情况，从所述多个应用服务器中选定一个。

9.根据权利要求8所述的服务平台，其特征在于，访问服务器用于根据访问请求特征和应用服务器性能情况，从服务平台上的多个应用服务器中选定一个，包括：

获取服务平台上每个应用服务器的性能评分，其中所述性能评分由应用服务器的多个性能参数加权得到，且权重与访问请求特征关联；

按照性能评分的高低，从服务平台上的多个应用服务器中选定一个。

10.根据权利要求9所述的服务平台，其特征在于，访问服务器用于获取服务平台上每个应用服务器的性能评分，包括：

获取本次接收到的所述访问请求特征；

读取缓存中存储的与获取到的所述访问请求特征匹配的各个应用服务器的性能评分；

若读取失败，则访问服务器确定与获取到的所述访问请求特征对应的应用服务器的各个性能参数的权重，针对每个应用服务器：加权各个性能参数得到应用服务器的性能评分，在本地缓存本次接收到的所述访问请求特征及得到的性能评分，并共享给服务平台上其它访问服务器进行缓存更新；

若读取成功，则获取读取结果。

11.根据权利要求7-10中任一项所述的服务平台，其特征在于，在访问服务器确定是否由本服务器处理本次接收到的所述访问请求之前，还包括：

对本服务器本次接收到的所述访问请求进行安全认证，认证成功时触发确定是否由本服务器处理本次接收到的所述访问请求的操作。

12.根据权利要求7-10中任一项所述的服务平台，其特征在于，所述应用服务器还用于创建应用数据镜像，以供在处理访问请求的过程中访问原始应用数据失败时使用。