在微服务架构下对请求进行控制的方法、设备和存储介质与流程

本发明涉及微服务架构技术领域，特别涉及一种在微服务架构下对请求进行控制的方法、装置、计算设备和计算机可读存储介质。

背景技术：

微服务架构是一种用来部署应用和服务的新技术。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展。

为了处理微服务架构下的高并发业务请求，引入了熔断机制。一般地，当调用某个微服务失败达一定阈值(例如5秒内20次失败)时，就会启动熔断机制。微服务架构下的熔断策略是处理高并发业务、保证微服务正常运行的关键。为适应各种不同的需求，人们不断地调整和改进熔断策略。

技术实现要素：

本发明实施例的目的之一在于提供一种用于微服务架构的新的熔断策略。

根据本申请的第一方面，提供一种在微服务架构的应用平台中对请求进行控制的方法，其中，所述应用平台调用一个或多个微服务应用处理来自用户的业务请求，所述方法包括：

判断所述一个或多个微服务应用对调用请求的响应时间是否超过第一预定阈值；

对于所述一个或多个微服务应用中响应时间超过第一预定阈值的微服务应用，判断对该微服务应用的当前请求数是否超过第一预定数量；

针对所述当前请求数不超过第一预定数量的情况，在不熔断对该微服务应用的调用请求的情况下将所述应用平台的预定微服务应用降级。

根据一示例性实施例，所述方法还包括：

在将所述预定微服务应用降级达预定时间段的情况下，判断所述响应时间超过第一预定阈值的所述微服务应用的响应时间是否仍超过第一预定阈值；

在所述响应时间仍超过第一预定阈值的情况下，发送将该微服务应用重启的请求。

根据一示例性实施例，所述方法还包括：

在所述当前请求数超过第一预定数量的情况下，熔断对该微服务应用的调用请求。

根据一示例性实施例，所述方法还包括：

判断该微服务应用的被熔断的请求数是否超过第二预定数量；

在所述被熔断的请求数超过第二预定数量的情况下，将所述应用平台的预定微服务应用降级。

根据一示例性实施例，所述方法还包括：

响应于来自第一微服务应用的对第二微服务应用的调用请求，判断第一微服务应用在单位时间内对第二微服务应用的调用请求数是否超过第三预定数量，其中第一微服务应用和第二微服务应用是所述应用平台所包含的任意两个微服务应用；

在所述单位时间内的调用请求数超过第三预定数量的情况下，向第一微服务应用返回预定默认值，而不调用第二微服务应用处理所述调用请求。

根据一示例性实施例，所述方法还包括：

在调用被降级的所述预定微服务应用失败的次数超过第四预定数量的情况下，发送重启被降级的所述预定微服务应用的请求。

根据本申请的第二方面，提供一种在微服务架构的应用平台中对请求进行控制的装置，其中，所述应用平台调用一个或多个微服务应用处理来自用户的业务请求，所述装置包括：

第一判断模块，其被配置为：判断所述一个或多个微服务应用对调用请求的响应时间是否超过第一预定阈值；

第二判断模块，其被配置为：对于所述一个或多个微服务应用中响应时间超过第一预定阈值的微服务应用，判断对该微服务应用的当前请求数是否超过第一预定数量；

降级模块，其被配置为：针对所述当前请求数不超过第一预定数量的情况，在不熔断对该微服务应用的调用请求的情况下将所述应用平台的预定微服务应用降级。

根据一示例性实施例，所述第一判断模块还被配置为：

在将所述预定微服务应用降级达预定时间段的情况下，判断所述响应时间超过第一预定阈值的所述微服务应用的响应时间是否仍超过第一预定阈值；

其中，所述装置还包括重启请求模块，其被配置为：在所述响应时间仍超过第一预定阈值的情况下，发送将该微服务应用重启的请求。

根据一示例性实施例，所述装置还包括：

熔断模块，其被配置为：在所述当前请求数超过第一预定数量的情况下，熔断对该微服务应用的调用请求。

根据一示例性实施例，所述装置还包括：

第三判断模块，其被配置为：判断该微服务应用的被熔断的请求数是否超过第二预定数量；

其中，所述降级模块还被配置为：在所述被熔断的请求数超过第二预定数量的情况下，将所述应用平台的预定微服务应用降级。

根据一示例性实施例，所述装置还包括限流模块，所述限流模块包括：

第四判断单元，其被配置为：响应于来自第一微服务应用的对第二微服务应用的调用请求，判断第一微服务应用在单位时间内对第二微服务应用的调用请求数是否超过第三预定数量，其中第一微服务应用和第二微服务应用是所述应用平台所包含的任意两个微服务应用；

限流单元，其被配置为：在所述单位时间内的调用请求数超过第三预定数量的情况下，向第一微服务应用返回预定默认值，而不调用第二微服务应用处理所述调用请求。

根据一示例性实施例，所述重启请求模块还被配置为：

在调用被降级的所述预定微服务应用失败的次数超过第四预定数量的情况下，发送重启被降级的所述预定微服务应用的请求。

根据本申请的第三方面，提供一种计算设备，其包括存储器和处理器，所述存储器中存储有计算机程序，所述计算机程序在被所述处理器执行时，使得所述计算设备执行如上所述的方法实施例中的任一个。

根据本申请的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被一个或多个处理器执行时实现如上所述的方法实施例中的任一个。

本申请的实施例提供的技术方案可以包括以下有益效果：

通过本申请如上所述以及如下所述的各实施例，可以提高熔断机制的效率，更好地保证在微服务架构下处理高并发业务的性能。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

图1是根据一示例性实施例示出的本申请所涉及的实施环境的示意简图。

图2是根据本申请一示例性实施例示出的在微服务架构的应用平台下对请求进行控制的方法的示意流程图。

图3是图2所示的方法实施例还可以包括的重启微服务应用的过程的一示例性具体实施方式的示意流程图。

图4是图2所示的方法实施例还可以包括的先熔断后降级过程的一示例性具体实施方式的示意流程图。

图5是图2所示的方法实施例还可以包括的限流处理过程的一示例性具体实施方式的示意流程图。

图6是根据本申请一示例性实施例示出的在微服务架构的应用平台下对请求进行控制的装置的示意组成框图。

图7是根据本申请一示例性实施例示出的计算设备的示意组成框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明的示例性实施例进行进一步详细说明。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。应当理解，此处所描述的具体实施例仅仅用于解释本发明，并不用于限定本发明。

图1是根据一示例性实施例示出的本申请所涉及的实施环境的示意简图。如图1所示，应用平台110为微服务架构，其包括一个或多个微服务应用(作为示例，在图1中示出了四个微服务应用)111、112、113、114。应用平台110还包括限流与熔断装置115，用于针对微服务应用之间的相互调用请求执行限流和/或熔断策略，以免高并发调用请求使得应用平台110由于处理能力无法承受而崩溃。对于来自用户的业务请求，应用平台110调用微服务应用111、112、113、114中的一个或多个来处理该业务请求，限流与熔断装置115采用熔断策略(包括服务降级策略)对微服务应用之间的调用请求进行控制和管理。

微服务架构的系统中经常会出现某个被调用的微服务不可用而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。在一个示例中，限流与熔断装置115所采用的熔断策略为：在应用平台110调用一个或多个微服务应用处理来自用户的业务请求时，限流与熔断装置115监控每个微服务应用对调用请求的响应时间，并判断响应时间是否超过预定阈值，如果没有超过预定阈值，则不采取行动，如果超过了预定阈值，则将该调用请求熔断，即，使得该微服务应用并不针对该调用请求进行操作或处理，而是向调用请求的发起者直接返回预定的默认值。这样可以使得不会由于该微服务应用的响应时间慢而影响对用户的业务请求的整体响应时间，避免了雪崩效应。在该示例中，限流与熔断装置115还可以在被熔断的调用请求数量超过预定数量的情况下将应用平台110的某个或某些预定微服务降级，降低整个系统的处理压力，以期响应超时的微服务应用由此尽快恢复响应时间。

但是，有时上述熔断策略并不能及时避免雪崩效应，因为微服务应用的响应超时并不总是由于对其的调用请求过多使得其处理压力过大而导致，可能是由于别的原因引起其响应超时，例如由于系统整体处理压力过大。在这样的情况下，熔断对其的调用请求并不能从根本上解决问题，反而可能拖延解决问题的时间。本申请的发明人意识到，在这样的情况下通过将预定微服务降级来缓解系统的整体处理压力，可以有效地使响应超时的微服务应用恢复正常。

因此，在一个示例中，限流与熔断装置115可以采用如下熔断策略：当发现某微服务应用对调用请求的响应时间超过预定阈值时，并不像上面所述的示例中那样直接将该调用请求熔断，而是进一步判断针对该微服务应用的当前调用请求数，如果当前对该微服务应用的调用请求数并没有过多(例如没有超过某预定数量)，则并不熔断对该微服务应用的调用请求，而是将预定微服务降级，以缓解系统整体压力，由此使得响应时间超时的该微服务应用尽快恢复正常。

图1及以上描述只是本申请所涉及的实施环境的示例性实施例，可以理解的是，适用于本申请的实施环境存在多种变形。

下面将参考图2-5通过对本申请的各方法实施例的描述来具体说明上面提到的熔断策略。

图2是根据本申请一示例性实施例示出的在微服务架构的应用平台下对请求进行控制的方法的示意流程图。该示例方法的执行者可以是如图1中所示的限流与熔断装置115。如图2的示例性实施例所示，该方法可以包括步骤：

s210，判断一个或多个微服务应用对调用请求的响应时间是否超过第一预定阈值。

可以监控和计算应用平台所包含的每个微服务应用对调用请求的响应时间，以判断其响应是否超时。在一示例中，可以设置第一预定阈值(例如200ms)，将监控和计算得到的响应时间与第一预定阈值进行比较，以判断是否响应超时。

s220，对于响应时间超过第一预定阈值的微服务应用，判断对该微服务应用的当前请求数是否超过第一预定数量。

在图2所示的实施例中，当在步骤s210中判断某个微服务应用响应超时时，并不是直接将对该微服务应用的调用请求熔断，而是进一步判断对该微服务应用的当前请求数。这是因为，如果该微服务应用响应超时的原因不是由于对其请求数过多而导致，那么即使熔断对其的调用请求，也无法从根本上解决该微服务应用的响应超时问题。因此，在步骤s220中进一步判断该微服务应用的当前请求数。

在一个示例中，可以设置第一预定数量作为判断的基准，例如可以将第一预定数量设置为60个，如果微服务应用的当前请求数不超过该第一预定数量，则表明其响应超时的原因并不是请求数过多。如果当前请求数超过该第一预定数量，则表明该微服务应用响应超时的原因很有可能是因为请求数过多。

可以理解的是，第一预定数量可以被设置为60以外的数值，无论其被设置为什么值，该值都应当能尽量准确地表明当前请求数是否超过该值代表响应超时的原因是否是请求数过多。

s230，针对所述当前请求数不超过第一预定数量的情况，在不熔断对该微服务应用的调用请求的情况下将所述应用平台的预定微服务应用降级。

如前所述，如果当前请求数不超过第一预定数量，则表明该微服务应用响应超时的原因并不是请求数过多，这时熔断对该微服务应用的调用请求并不能从根本上解决该微服务应用响应超时的问题。由于造成该微服务应用响应超时的另一个有很大可能的原因是应用平台的整体处理压力过大，因此，通过使某些微服务降级来减轻整体压力，有可能会使得响应延迟的微服务恢复。因此，在图2所示的实施例中，在步骤s230中，针对当前请求数不超过第一预定数量的情况，采取服务降级的措施，而并不熔断对该微服务应用的调用请求。

所谓“服务降级”是指，使这个服务实际上是挂掉的，即返回的内容是空的或是旧的或是预先设置的默认值。被执行服务降级的微服务应用是预先设定好的，可以是一个比较外围的、不那么重要的微服务应用，也可以是多个较不重要的微服务应用。在一个示例中，这多个微服务应用具有各自的降级优先级，在执行服务降级时先对优先级较高的执行。

通过图2所示的实施例，在判断引起响应延迟的原因并非请求数过多的情况下，直接执行服务降级，而无需等到被熔断的请求超过一定数量才执行服务降级，因此，更快速地有效解决了微服务应用响应延迟的问题，提高了系统效率和性能。

图3是图2所示的方法实施例还可以包括的重启微服务应用的过程的一示例性具体实施方式的示意流程图。如图3所示，该实施例方法在图2的步骤s230之后还可以包括步骤：

s310，在将所述预定微服务应用降级达预定时间段的情况下，判断所述响应时间超过第一预定阈值的所述微服务应用的响应时间是否仍超过第一预定阈值。

在将预定微服务应用的服务降级后，如果微服务应用响应延迟的原因在于系统整体压力过大，则在服务降级后一定时间，当系统整体压力由于服务降级而逐渐减轻时，该微服务应用的响应时间应该会恢复。如果没有恢复，则表示原因判断可能错误，需要采取其他措施。因此，在步骤s310中，在服务降级达预定时间段(例如80ms)后，检查原来响应延迟的微服务应用，看其响应时间是否恢复。

s320，在所述响应时间仍超过第一预定阈值的情况下，发送将该微服务应用重启的请求。

如果响应时间没有恢复，则可以采取其他措施来尝试恢复该微服务应用。例如，在步骤s320中，可以发送将该微服务应用重启的请求。在一个示例中，发送重启请求可以包括：在发送该请求预定时间(例如10s)后将该微服务应用直接重启。在另一示例中，发送重启请求可以包括：将重启请求发送到运维消息队列中，在得到管理员的确认后重启该微服务应用。

如果步骤s310的判断结果为该微服务应用的响应时间已恢复，则表明响应延迟的原因判断正确，在微服务应用的响应时间恢复后(例如在恢复预定时间段后)，可以将被降级的微服务应用重启，即开始提供服务。

图4是图2所示的方法实施例还可以包括的先熔断后降级过程的一示例性具体实施方式的示意流程图。在图2所示的实施例中，如果在步骤s220中判断为对该微服务应用的当前请求数超过第一预定数量，则在步骤s220之后执行先熔断后降级的策略，如图4所示，先熔断后降级的过程可以包括步骤：

s410，在所述当前请求数超过第一预定数量的情况下，熔断对该微服务应用的调用请求。

如果一微服务应用响应超时，并且判断为对其的当前请求数超过第一预定数量，则表明造成其响应超时的原因很有可能是请求数过多导致它处理不过来。因此，在步骤s410中，可以熔断对该微服务应用的调用请求，以减轻它的处理压力，使其响应时间尽快恢复。

s420，判断该微服务应用的被熔断的请求数是否超过第二预定数量。

s430，在所述被熔断的请求数超过第二预定数量的情况下，将所述应用平台的预定微服务应用降级。

如果该微服务应用被熔断的请求数已达一定数量(例如超过第二预定数量)，但是该微服务应用仍然没有恢复响应时间，则表明熔断请求这一措施还不足够，可能需要采取其他措施。因此，在步骤s430中，在判断为该微服务应用的被熔断的请求数超过第二预定数量的情况下，可以采取服务降级措施，即，将预定的一个或多个微服务应用降级，以减轻系统整体处理压力，使得响应延迟的微服务应用尽快恢复正常。

之后，如果响应延迟的微服务应用恢复正常，则可以发送重启被降级的微服务应用的请求(例如在该微服务应用恢复正常预定时间后)。或者，虽然响应延迟的微服务应用未恢复正常，但在调用被降级的微服务应用失败的次数超过一预定数量的情况下，发送重启被降级的所述预定微服务应用的请求。

除了上述熔断(包括降级)策略，还可以采取限流策略，即对微服务应用之间的相互调用请求数进行限制。图5是图2所示的方法实施例还可以包括的限流处理过程的一示例性具体实施方式的示意流程图。如图5所示，限流处理过程可以包括步骤：

s510，响应于来自第一微服务应用的对第二微服务应用的请求，判断第一微服务应用在单位时间内对第二微服务应用的调用请求数是否超过第三预定数量。

其中，第一微服务应用和第二微服务应用是应用平台所包含的任意两个微服务应用。在一个示例中，第三预定数量被设置为每秒内2000个。

s520，在所述业务请求数超过第三预定数量的情况下，向第一微服务应用返回预定默认值，而不调用第二微服务应用处理所述调用请求。

通过限流措施，可以有效阻止来自某个微服务应用的突发大量调用，保证微服务应用的正常运行。

根据本申请的另一方面，还公开了在微服务架构的应用平台中对请求进行控制的装置。图6是根据本申请一示例性实施例示出的在微服务架构的应用平台下对请求进行控制的装置的示意组成框图，该装置601可以上如图1中所示的限流与熔断装置115。该装置601用于执行如上所述的各方法实施例。如图6所示，示例装置601可以包括：

第一判断模块610，其被配置为：判断所述一个或多个微服务应用对调用请求的响应时间是否超过第一预定阈值；

第二判断模块620，其被配置为：对于所述一个或多个微服务应用中响应时间超过第一预定阈值的微服务应用，判断对该微服务应用的当前请求数是否超过第一预定数量；

降级模块630，其被配置为：针对所述当前请求数不超过第一预定数量的情况，在不熔断对该微服务应用的调用请求的情况下将所述应用平台的预定微服务应用降级。

根据图6所示的实施例，所述第一判断模块610还可以被配置为：

在将所述预定微服务应用降级达预定时间段的情况下，判断所述响应时间超过第一预定阈值的所述微服务应用的响应时间是否仍超过第一预定阈值；

其中，所述装置601还可以包括重启请求模块640，其被配置为：在所述响应时间仍超过第一预定阈值的情况下，发送将该微服务应用重启的请求。

根据图6所示的实施例，装置601还可以包括：

熔断模块650，其被配置为：在所述当前请求数超过第一预定数量的情况下，熔断对该微服务应用的调用请求。

根据图6所示的实施例，装置601还可以包括：

第三判断模块660，其被配置为：判断该微服务应用的被熔断的请求数是否超过第二预定数量；

其中，所述降级模块630还被配置为：在所述被熔断的请求数超过第二预定数量的情况下，将所述应用平台的预定微服务应用降级。

根据图6所示的实施例，装置601还可以包括限流模块670，所述限流模块670可以包括：

第四判断单元671，其被配置为：响应于来自第一微服务应用的对第二微服务应用的调用请求，判断第一微服务应用在单位时间内对第二微服务应用的调用请求数是否超过第三预定数量，其中第一微服务应用和第二微服务应用是所述应用平台所包含的任意两个微服务应用；

限流单元672，其被配置为：在所述单位时间内的调用请求数超过第三预定数量的情况下，向第一微服务应用返回预定默认值，而不调用第二微服务应用处理所述调用请求。

根据图6所示的实施例，所述重启请求模块640还被配置为：

在调用被降级的所述预定微服务应用失败的次数超过第四预定数量的情况下，发送重启被降级的所述预定微服务应用的请求。

上述装置中各个单元/模块的功能和作用的实现过程以及相关细节具体详见上述方法实施例中对应步骤的实现过程，在此不再赘述。

以上各实施例中的装置实施例可以通过硬件、软件、固件或其组合的方式来实现，并且其可以被实现为一个单独的装置，也可以被实现为各组成单元/模块分散在一个或多个计算设备中并分别执行相应功能的逻辑集成系统。

以上各实施例中组成该装置的各单元/模块是根据逻辑功能而划分的，它们可以根据逻辑功能被重新划分，例如可以通过更多或更少的单元/模块来实现该装置。这些组成单元/模块分别可以通过硬件、软件、固件或其组合的方式来实现，它们可以是分别的独立部件，也可以是多个组件组合起来执行相应的逻辑功能的集成单元/模块。所述硬件、软件、固件或其组合的方式可以包括：分离的硬件组件，通过编程方式实现的功能模块、通过可编程逻辑器件实现的功能模块，等等，或者以上方式的组合。

根据一个示例性实施例，该装置可被实现为一种计算设备，其包括存储器和处理器，所述存储器中存储有计算机程序，所述计算机程序在被所述处理器执行时，使得所述计算设备执行如上所述的各方法实施例中的任一个，或者，所述计算机程序在被所述处理器执行时使得该计算设备实现如上所述的各装置实施例的组成单元/模块所实现的功能。

上面的实施例中所述的处理器可以指单个的处理单元，如中央处理单元cpu，也可以是包括多个分散的处理单元/处理器的分布式处理器系统。

上面的实施例中所述的存储器可以包括一个或多个存储器，其可以是计算设备的内部存储器，例如暂态或非暂态的各种存储器，也可以是通过存储器接口连接到计算设备的外部存储装置。

图7示出了这样的计算设备701的一个示例性实施例的示意组成框图。如图7所示，计算设备701可以包括：处理器710、通信接口720、存储器730和总线740。存储器730内存储有可被处理器710执行的计算机程序。处理器710执行所述计算机程序时实现上述实施例中的方法及装置的功能。存储器730和处理器710的数量分别可以为一个或多个。通信接口720用于处理器710与外部设备之间的通信。

其中，处理器710可以是中央处理单元、通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明公开内容所描述的各种示例性的流程步骤、功能单元/模块和/或电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合、数字信号处理器等等。

存储器730可以包括易失性存储器和/或非易失性存储器，例如非易失性动态随机存取存储器、相变随机存取存储器、磁阻式随机存取存储器、磁盘存储器、电子可擦除可编程只读存储器、闪存器件、半导体器件(例如固态硬盘)等。存储器730可选地还可以是外部远程存储装置。

总线740可以是工业标准体系结构(isa，industrystandardarchitecture)总线、外部设备互连(pci，peripheralcomponent)总线或扩展工业标准体系结构(eisa，extendedindustrystandardcomponent)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。可选地，如果存储器730、处理器710及通信接口720集成在一块芯片上，则存储器730、处理器710及通信接口720可以通过内部接口完成相互间的通信。

以上各方法和装置实施例还可以被实现为计算机程序的形式，被存储在存储介质上，并且可被分发。因此，根据本公开的另一方面，还提供一种计算机程序产品，该计算机程序产品被存储在计算机可读存储介质上，并且在被处理器执行时实现如上所述的各方法和装置实施例中的任一个。根据本公开的又一方面，还提供一种计算机可读存储介质，其上存储有可供处理器执行的计算机程序，所述计算机程序在被处理器执行时实现如上所述的各方法和装置实施例中的任一个。

该计算机可读存储介质可以是任何可以保持和存储可由指令执行设备使用的指令的有形设备。例如，其可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、静态随机存取存储器(sram)、便携式压缩盘只读存储器(cd-rom)、数字多功能盘(dvd)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。

这里所描述的计算机程序/计算机指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

本公开中所述的计算机程序指令可以是汇编指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如smalltalk、c++等，以及常规的过程式编程语言—诸如“c”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(fpga)或可编程逻辑阵列(pla)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。但本领域技术人员应当清楚的是，上述各实施例可以根据需要单独使用或者相互结合使用。另外，对于装置实施例而言，由于其是与方法实施例相对应，所以描述得比较简单，相关之处参见方法实施例的对应部分的说明即可。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。