一种基于单元化架构的业务处理方法、装置及设备

技术领域

本说明书实施例涉及分布式技术领域，特别涉及一种基于单元化架构的业务处理方法、装置及设备。

背景技术

随着近年来的IT架构转型，越来越多的机构将传统的集中式架构转变为分布式架构。在分布式架构下，同一业务可以被拆分为多个子业务，分配至不同的设备进行并发处理，进而能够有效提升业务的处理速度以及均衡分布式中不同设备的负载。

一般情况下，在分布式中出现单机故障时，可以通过快速重启故障设备的方式解决故障问题。但是，由于分布式架构下业务的执行过程中可能会涉及多个分布式节点之间的跨站访问，相应的，某一节点的故障可能会随着业务执行流程所涉及的节点扩大影响范围。针对这种情况，往往只能通过同城切换的方式，将业务移交至异地进行重新部署，这样一来，不仅切换灵活性差，恢复时间长，异地部署模式下所产生的大量跨站访问也会延长业务处理时长，进而严重影响业务处理效果。因此，目前亟需一种应对分布式架构下的故障而有效完成业务处理的方法。

发明内容

本说明书实施例的目的是提供一种基于单元化架构的业务处理方法、装置及设备，以解决如何应对分布式架构下的故障而有效完成业务处理的问题。

为解决上述技术问题，本说明书实施例提供一种基于单元化架构的业务处理方法，所述单元化架构包括至少一个应用节点；所述应用节点包括接入单元和至少一个分区单元；所述方法应用于所述接入单元；所述方法包括：接收到业务请求的情况下，识别所述业务请求对应的目标用户；将所述业务请求转发至对应于所述目标用户的目标分区单元，以使所述目标分区单元对所述业务请求进行处理；所述目标分区单元用于执行所述业务请求对应的业务流程；在所述目标分区单元执行业务流程的过程中，向所述目标分区单元发送健康检查请求；利用目标分区单元针对所述健康检查请求的反馈结果，确定所述目标分区单元的检查结果；在所述检查结果为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

在一些实施方式中，所述目标分区单元用于闭环执行所述业务请求对应的整体业务流程，或，所述目标分区单元用于执行所述业务请求的主体业务流程，且所述业务请求涉及的分区单元和/或应用节点的数量在故障可控范围内。

在一些实施方式中，所述向所述目标分区单元发送健康检查请求，包括：每间隔特定时间向所述目标分区单元发送健康检查请求。

基于上述实施方式，所述在所述检查结果为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程，包括：在连续的特定次数的检查结果均为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

在一些实施方式中，所述基于所述目标分区单元对健康检查请求的反馈结果确定所述目标分区单元的检查结果，包括：在目标分区单元针对健康检查请求的反馈信息不符合单元健康条件的情况下，确定所述目标分区单元的检查结果为故障状态，或，在健康检查周期内未接受到目标分区单元对健康检查请求的反馈信息后，确定所述目标分区单元的检查结果为故障状态。

基于上述实施方式，所述单元健康条件包括以下至少一种：单元探活状态结果、单元实际可用容器数量不小于单元可用容器数量阈值、反馈状态码正常。

在一些实施方式中，所述备份应用节点包括针对所述目标应用节点预先设置的备份应用节点；相应的，所述将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程，包括：基于预先设置的节点切换逻辑，将所述业务请求的流量切换至备份应用节点。

基于上述实施方式，所述基于预先设置的节点切换逻辑，将所述业务请求的流量切换至备份应用节点，包括：在所述节点切换逻辑未生效的情况下，修改所述目标应用节点的可用容器数量阈值，或，修改所述目标应用节点对应的域名地址。

本说明书实施例还提出一种基于单元化架构的业务处理方法，所述单元化架构包括至少一个应用节点；所述应用节点包括接入单元和至少一个分区单元；所述方法应用于所述分区单元；所述方法包括：接收接入单元转发的业务请求；所述业务请求由接入单元在识别对应的目标用户后转发；执行所述业务请求对应的业务流程；在接收到接入单元发送的健康检查请求的情况下，发送对应于所述健康检查请求的反馈结果至所述接入单元，以使所述接入单元根据反馈结果确定对应的检查结果，并在检查结果为故障状态的情况下，将业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

在一些实施方式中，所述业务请求基于应用节点之间的负载均衡被发送至所述接入单元对应的应用节点。本说明书实施例还提出一种基于单元化架构的业务处理装置，所述单元化架构包括至少一个应用节点；所述应用节点包括接入单元和至少一个分区单元；所述装置设置在所述接入单元上；所述装置包括：目标用户识别模块，用于在接收到业务请求的情况下，识别所述业务请求对应的目标用户；业务请求转发模块，用于将所述业务请求转发至对应于所述目标用户的目标分区单元，以使所述目标分区单元对所述业务请求进行处理；所述目标分区单元用于执行所述业务请求对应的业务流程；健康检查请求发送模块，用于在所述目标分区单元执行业务流程的过程中，向所述目标分区单元发送健康检查请求；检查结果确定模块，用于利用目标分区单元针对所述健康检查请求的反馈结果，确定所述目标分区单元的检查结果；业务请求发送模块，用于在所述检查结果为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

本说明书实施例还提出一种基于单元化架构的业务处理装置，所述单元化架构包括至少一个应用节点；所述应用节点包括接入单元和至少一个分区单元；所述装置设置于所述分区单元；所述装置包括：业务请求接收模块，用于接收接入单元转发的业务请求；所述业务请求由接入单元在识别对应的目标用户后转发；业务流程执行模块，用于执行所述业务请求对应的业务流程；反馈结果发送模块，用于在接收到接入单元发送的健康检查请求的情况下，发送对应于所述健康检查请求的反馈结果至所述接入单元，以使所述接入单元根据反馈结果确定对应的检查结果，并在检查结果为故障状态的情况下，将业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

本说明书实施例还提出一种电子设备，包括存储器和处理器；所述存储器用于存储计算机程序/指令，所述处理器用于执行所述计算机程序/指令以实现上述基于单元化架构的业务处理方法的步骤。

本说明书实施例还提出一种计算机存储介质，其上存储有计算机程序/指令，所述计算机程序/指令在被执行时用于实现上述基于单元化架构的业务处理方法的步骤。

本说明书实施例还提出一种计算机程序产品，包括计算机程序/指令，所述计算机程序/指令在被执行时用于实现上述基于单元化架构的业务处理方法的步骤。

由以上本说明书实施例提供的技术方案可见，本说明书实施例的基于单元化架构的业务处理方法，通过构建单元化架构，使得单元化架构内的应用节点包括接入单元和至少一个分区单元。针对性的，在应用节点接收到业务请求后，通过接入单元识别业务请求对应的目标用户，并根据目标用户将业务请求对应的流量转至相应的目标分区单元，是目标分区单元基于相应的业务流程完成对业务请求的处理。在目标分区单元执行业务流程的过程中，若出现故障，则可以直接将业务请求发送至备份应用节点使得备份应用节点执行业务请求对应的业务流程。通过上述方法，在分布式架构中，将不同目标用户的业务流程划分至不同的分区单元中，减少单一用户的业务所涉及的节点，进而使得在执行业务的分区单元出现故障时，直接将业务请求的流量转至备份应用节点即可实现故障状况下的业务处理，减小了分布式系统中节点故障对业务执行过程所造成的影响，保证了业务的有效处理。

附图说明

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

图1为本说明书实施例一种基于单元化架构的业务处理方法的流程图；

图2为本说明书实施例一种决策引擎调用服务的示意图；

图3为本说明书实施例一种基于单元化架构的业务处理方法的流程图；

图4为本说明书实施例一种基于单元化架构的业务处理方法的流程图；

图5为本说明书实施例一种基于单元化架构的业务处理装置的模块图；

图6为本说明书实施例一种基于单元化架构的业务处理装置的模块图。

具体实施方式

下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

为了更好地理解本申请的发明构思，首先对本申请所涉及的单元化架构进行介绍。在本说明书实施例中，单元化架构是按照业务链路的维度，将上下游应用的用户数据按照统一的规则和算法进行分片，并与所构建的应用节点一起进行逻辑上的单元划分，使业务流量按照统一的规则分配到各个单元内，并尽量确保同一用户的业务处理始终收敛在同一个单元内完成。单元化架构把单元作为部署的基本单位，单元内部署了重要对客业务所需的关键应用(或服务集群)。单元是一个能满足某一类业务按某种维度划分的业务处理环节相关操作的自包含集合，在这个集合中包含了该类业务处理环节所需的大部分关键服务，以及这个集合所需处理的数据。

通过对单元进行层次化的设计，对应用间流量及应用到数据库的流量进行主动控制，统一对客户交易相关主要数据的分片策略，并实现单元内的亲和性部署，大幅降低不必要的跨单元访问，有效控制故障爆炸半径，提升切换的灵活性，更好地适应未来数据中心的多地多中心部署需求。

此外，通过单元的划分和单元流量的管控，可以有效控制单元内应用节点的数量，保护数据库的连接数和服务提供方的连接数，同时还可通过单元的新增，支持系统容量进行横向的灵活扩展。

基于上述单元化架构的描述，介绍本说明书实施例一种基于单元化架构的业务处理方法，以解决前述问题。所述基于单元化架构的业务处理方法的执行主体为上述单元化架构中的一个应用节点。如图1所示，所述基于单元化架构的业务处理方法可以包括以下具体实施步骤。

S110：接入单元获取业务请求，并识别所述业务请求对应的目标用户。

业务请求即为待处理业务所对应的请求。待处理业务对应于相应的目标用户。所述目标用户可以是发起业务请求的用户，也可以直接对应至待处理业务的流程所涉及的用户。

业务请求中可以包含待处理业务的具体内容，也可以仅仅包含特定业务的相关标识，通过所述相关标识能够直接指向特定的业务，进而完成业务流程的执行过程。

在一些实施方式中，业务请求被分配至应用节点的过程可以是基于业务请求的发起端所处的区域位置而确定。例如，针对不同的应用节点预先划分对应的园区管控范围，在接收到业务请求后，直接将业务请求转发至对应园区管控范围的应用节点，从而保证应用节点与对应终端之间的交互时效。

在一些其他实施方式中，应用节点也可以基于所处理的不同业务类型进行区分。通过预先设置不同应用节点所负责的业务类型，在接收到业务请求后，识别业务请求所对应的业务类型，即可将对应的业务类型推送至相应的应用节点。这样一来，不仅有利于实现单元化架构的改造，而且能够保证不同的业务能够得到相应的推送和处理。

在一些实施方式中，发送业务请求还可以基于应用节点之间的负载均衡来实现，具体的可以综合软负载均衡来实现流量导向。软负载均衡(简称SLB)定位于开放平台的分布式技术体系的介入处理层，为应用提供七层负载均衡服务，支撑IT架构从传统单体式向分布式转型，满足业务高容量、高并发、高增长的访问场景需求。七层软负载通过负载均衡开源软件与配置管理组件相互协作，实现应用节点动态自发现与流量负载均衡。软负载均衡支撑应用做单元化改造，实现单元内和跨单元的http请求方式流量调度负载均衡，并提供容器维度健康检查接口。应用在负载均衡申请表填写节点存活预期值，软负载均衡可判断后端节点实际存活值和预期值，得出健康状态，并将状态通过header返回。

应用节点中包含有接入单元和至少一个分区单元。其中，接入单元用于业务请求的接入和转发。在业务请求被发送至应用节点后，接入单元能够从业务请求中提取相应的信息，并根据这些信息识别出业务请求所对应的目标用户。之后，接入单元根据预先设置的分类逻辑，根据所确定的目标用户将所述业务请求转发至对应的分区单元。具体的分类逻辑可以参照前述实施方式的介绍，在此不再赘述。

分区单元中集成有相应的业务处理逻辑，且由于在设置分区单元时，尽可能地保证分区单元能够闭环完成对应业务的处理，使得经由所分配的分区单元即能执行业务的整体流程，尽量减少业务处理过程中所涉及的节点数量，使得在业务处理出现故障时减小影响范围。

利用一个示意图对上述应用节点的结构进行说明，如图2所示，首先根据不同园区，例如图中的园区A和园区B，划分对应的应用节点。在园区A对应的应用节点中设置接入单元V单元1和分别对应于用户1的分区单元R单元1和对应于用户2的分区单元R单元2。接入单元通过SLB软负载均衡，以及DSF微服务架构确保分区单元可用，完成路由管控，将渠道请求分发至相应的分区单元进行处理。

S120：接入单元将所述业务请求转发至对应于所述目标用户的目标分区单元。

接入单元根据从业务请求中所识别出的对应的目标用户，可以将业务请求转发至对应的目标分区单元。目标分区单元与所述目标用户之间可以预先设置相应的逻辑对应关系，例如将全体用户依次分配给相应的分区单元，并利用分区单元记录相应的用户的标识，根据目标用户的标识与相应的分区单元之间的对应关系，即可确定目标分区单元。

此外，在确定目标分区单元时，也可以考虑分区单元之间的负载均衡，基于负载均衡状况完成分区单元的确定。例如，在应用节点中可以存在多个负责所述目标用户的分区单元，基于负载均衡的考量，可以从这些分区单元中选取最适合的分区单元，例如当前进程数最少的分区单元，作为目标分区单元。

S130：目标分区单元对所述业务请求进行处理。

所述目标分区单元中集成有处理相应业务的整体业务执行逻辑，用于保证目标分区单元能够闭环执行所述业务请求对应的整体业务流程。在业务执行需要涉及其他分区单元和/或应用节点时，也保证执行对应业务的流程所涉及的分区单元和/或应用节点的数量在故障可控范围内。通过这一操作，保证了在执行业务的任意节点出现故障时将影响降至最小。

S140：在所述目标分区单元执行业务流程的过程中，向所述目标分区单元发送健康检查请求。

由于本申请的重点在于分布式系统中任意节点在执行业务时出现故障的解决方案，因此，在目标分区单元执行业务流程的过程中，可以向目标分区单元发送健康检查请求。

健康检查请求即为确定分区单元当前状态是否正常的检测请求，通过将健康检查请求发送至目标分区单元，使得目标分区单元能够基于健康检查请求进行自检并反馈相应的参数，进而通过分析目标分区单元所反馈的参数确定目标分区单元当前状态是否正常。

一般情况下，在接入单元将业务流量路由至对应的分区单元后，即由接入单元负责发送健康检查请求，实际应用中，也可以由应用节点中的控制模块或其他的总控单元负责健康检查请求的发送，对此不做限制。

健康检查请求可以设计TCP检查、HTTP检查和应用节点探活。对于TCP健康检查，可以支持端口探测或者深度探测，其中深度探测由软负载均衡在探测包DATA字段中插入指定字符串，默认为heathcheck ，后端服务器识别此字符串后，需在响应报DATA字段中插入字符串@the@health@is@good@，当该字符串与软负载均衡上所配置预期返回值一致则判断健康检查通过。对于HTTP健康检查，将对指定健康检查路径发起HTTP GET请求，根据预期返回值进行模糊匹配，当HTTP响应包体包含软负载均衡上配置返回值则判断健康检查通过。

对应用节点接口地址发起路径为健康检查路径的探测，软负载均衡在响应头中返回字段为unit-health的值，据此和健康检查返回情况综合判断是否实施应用节点切换。

在一些实施方式中，健康检查请求可以是每间隔特定时间向所述目标分区单元发送健康检查请求来实现。特定时间可以根据具体需求进行设置，例如可以是4秒/次，在保证实时获取分区单元监控结果的同时，避免过于频繁发送健康检查请求对分区单元正常工作和响应造成干扰。

S150：目标分区单元针对健康检查请求发送反馈结果至接入单元。

目标分区单元根据健康检查请求中的检查需求可以反馈对应的信息，即为反馈结果。反馈结果可以是目标分区单元自身的执行状态，也可以是业务请求执行过程中所产生的参数。具体的反馈结果的内容可以根据检查内容以及目标分区单元自身的状态进行设置，对此不做限制。

S160：接入单元根据所述反馈结果确定所述目标分区单元的检查结果。

反馈结果中可以包含目标分区单元的相关参数，基于相应标准对参数进行分析后即可获知对于分区单元的检查结果。

具体的，可以预先设置单元健康条件，将目标分区单元的反馈信息与单元健康条件进行比对，即可根据比对结果判断目标分区单元的检查结果是故障状态或正常状态。

单元健康条件可以根据分区单元处理业务的具体状况进行设置，例如可以包括健康检查路径状况、单元实际可用容器数量不小于单元可用容器数量阈值、反馈状态码正常。

健康检查路径状况用于反映通信链路的状况，进而确定分区单元能够正常完成通信。

单元探活状态结果用于直接反映分区单元的探活状态。例如，单元探活状态的值可以为ture和false，用于直接反映分区单元是否正常。单元探活状态可以根据单元实际可用容器数量和单元可用容器数量阈值而确定，进而反映分区单元当前是否具备正常处理业务的能力，单元实际可用容器数量为分区单元当前实际能够用于处理业务的能力；单元可用容器数量阈值可以是为了实现业务处理所需要的最小容器数量。通过比对单元实际可用容器数量和单元可用容器数量阈值，若单元实际可用容器数量不小于单元可用容器数量阈值，则表示可以正常利用分区单元完成对于业务的处理。状态码可以是对通信状态进行描述，例如当网络不通，返回4xx、5xx状态码时，分区单元可能在通信上出现一定的问题。

利用一个具体的示例进行说明，设定单元实际可用容器数量为active-pods，单元可用容器数量阈值为min-pods，单元探活状态为unit-health，则若min-pods的值≤active-pods的值，unit-health＝true；min-pods的值>active-pods的值，unit-health＝false；min-pods的值与active-pods的值无法比较时，例如某个为空，unit-health＝-1。

综合单元探活状态，存在以下情况：1)、访问健康检查路径通过且unit-health值为true，则探活通过，说明单元节点正常；2)、访问健康检查路径通过而unit-health值为false，说明单元异常，需要实施切流；3)、访问健康检查路径通过而unit-health值为-1，说明SLB进程处于重启状态，需要重新发起健康检查获取探活结果；4)、访问健康检查路径出现网络不通、返回4xx、5xx状态码、健康检查返回超时或返回值不匹配等异常情况，软负载均衡可能无法返回unit-health值，此时说明单元故障，需要实施切流。

具体的单元健康条件可以基于实际应用的情况进行设置，并不限于上述示例，在此不再赘述。

此外，在健康检查周期内未接受到目标分区单元对健康检查请求的反馈信息，也可以认定目标分区单元的检查结果为故障状态。若目标分区单元未在限定时间内反馈相应信息，则可能通信链路出现问题或是分区单元自身无法做出正常响应，均会影响业务的有效执行，因此可以判定分区单元为故障状态。

S170：在所述检查结果为故障状态的情况下，接入单元将所述业务请求发送至备份应用节点。

若基于步骤S140，确定检查结果为故障状态，则可以将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程，即完成对于业务执行的切流过程。

所述备份应用节点包括针对所述目标应用节点预先设置的备份应用节点，可以预先确定，也可以基于当前的负载均衡状况临时确定。

相应的，在预先设置备份应用根节点的情况下，在切换业务流程时，可以基于预先设置的节点切换逻辑，自动将所述业务请求的流量切换至备份应用节点。例如应用节点A和C互为备份节点，如果A发生故障，流量进来时，如需访问A节点的接口http://应用节点A地址:端口，但A节点的探活结果不可用，自动触发单元接管，流量自动访问C节点的接口http://应用节点C地址:端口。

在一些实施方式中，可能出现节点切换逻辑未生效的情况，则可以通过修改所述目标应用节点的可用容器数量阈值，或，修改所述目标应用节点对应的域名地址的方式，完成手动切换过程。

例如，若节点A故障，且上述基于节点切换逻辑的自动切换过程失效，则可以通过修改预设单元最低可用容器数量阈值min-pods，改为无限大，此时min-pods的值>active-pods的值，unit-health＝false，强制探活检查失败。A节点的探活结果不可用，流量自动访问C节点的接口http://应用节点C地址:端口。或是，2)将应用节点A地址对应DNS域名下IP修改成应用节点C地址对应DNS域名下IP，A节点的探活结果变成可用，进而恢复流量正常。

基于步骤S130中的实施方式，在每间隔特定时间发送健康检查请求的情况下，若在连续的特定次数的检查结果均为故障状态的情况下，可以认定为分区单元出现故障无法执行业务，进而将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。例如在连续三次健康检查请求的检查结果均对应于故障状态时实现应用节点切换。通过连续特定次数的检查结果排查能够避免因为网络波动等情况导致判断失误，保证判断结果的准确性。

若检查结果为正常状态，则目标分区单元正常，可以依据正常流程使得备份应用节点完成对于业务的处理直至业务处理完毕。

在一些具体示例中，健康检查请求的发送可以基于DSF微服务框架进行实现。如图2所示，DSF服务提供方在实施服务注册，同时要实施接入SLB应用实现服务节点容器注册及发现功能，用于跨单元服务调用场景，单元内服务注册发现及调用机制不变。DSF服务间调用流量优先在单元内通过RPC调用方式闭环，如涉及到跨单元访问通过SLB提供的HTTP模式进行。DSF中增加单元自动接管功能，根据节点健康检查，在判断目标单元内的服务不可用时，自动将请求路由到其备份单元。

DSF服务提供方预设一个服务最低可用容器数阀值，并在接入SLB时同步配置到参数配置中心。SLB集群定时获取服务节点最低可用容器数阀值，同时对服务提供方节点进行探活，获取后端健康检查结果和实际健康节点数值。

DSF消费方定期发起SLB健康检查请求，SLB将健康检查透传到容器获取并返回健康检查结果，同时根据可用性阈值和实际健康节点数值判断得出可用状态，通过HTTPHeader字段返回，连续3次健康检查失败判断是节点故障。

S180：备份应用节点执行所述业务请求对应的业务流程。

备份应用节点在接收到业务请求后，即可执行所述业务请求对应的业务流程。由于备份应用节点中也包含相应的接入单元和分区单元，可以通过这些接入单元和分区单元完成业务请求的处理。具体的处理过程可以参照目标分区单元对业务请求的处理过程的介绍，在此不再赘述。

基于上述实施例和场景示例的介绍，可以看出，上述方法通过构建单元化架构，使得单元化架构内的应用节点包括接入单元和至少一个分区单元。针对性的，在应用节点接收到业务请求后，通过接入单元识别业务请求对应的目标用户，并根据目标用户将业务请求对应的流量转至相应的目标分区单元，是目标分区单元基于相应的业务流程完成对业务请求的处理。在目标分区单元执行业务流程的过程中，若出现故障，则可以直接将业务请求发送至备份应用节点使得备份应用节点执行业务请求对应的业务流程。通过上述方法，在分布式架构中，将不同目标用户的业务流程划分至不同的分区单元中，减少单一用户的业务所涉及的节点，进而使得在执行业务的分区单元出现故障时，直接将业务请求的流量转至备份应用节点即可实现故障状况下的业务处理，减小了分布式系统中节点故障对业务执行过程所造成的影响，保证了业务的有效处理。

基于图1所对应的基于单元化架构的业务处理方法，介绍本说明书实施例另一种基于单元化架构的业务处理方法。所述基于单元化架构的业务处理方法的执行主体为应用节点中的接入单元。如图3所示，所述基于单元化架构的业务处理方法包括以下具体实施步骤。

S310：接收到业务请求的情况下，识别所述业务请求对应的目标用户。

对于该步骤的具体描述可以参照步骤S110中的介绍，在此不再赘述。

S320：将所述业务请求转发至对应于所述目标用户的目标分区单元，以使所述目标分区单元对所述业务请求进行处理；所述目标分区单元用于执行所述业务请求对应的业务流程。

对于该步骤的具体描述可以参照步骤S120、S1130中的介绍，在此不再赘述。

S330：在所述目标分区单元执行业务流程的过程中，向所述目标分区单元发送健康检查请求。

对于该步骤的具体描述可以参照步骤S140中的介绍，在此不再赘述。

S340：利用目标分区单元针对所述健康检查请求的反馈结果，确定所述目标分区单元的检查结果。

对于该步骤的具体描述可以参照步骤S150、S160中的介绍，在此不再赘述。

S350：在所述检查结果为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

对于该步骤的具体描述可以参照步骤S170、S180中的介绍，在此不再赘述。

基于图1所对应的基于单元化架构的业务处理方法，介绍本说明书实施例另一种基于单元化架构的业务处理方法。所述基于单元化架构的业务处理方法的执行主体为应用节点中的接入单元。如图4所示，所述基于单元化架构的业务处理方法包括以下具体实施步骤。

S410：接收接入单元转发的业务请求；所述业务请求由接入单元在识别对应的目标用户后转发。

对于该步骤的具体描述可以参照步骤S110、S120中的介绍，在此不再赘述。

S420：执行所述业务请求对应的业务流程。

对于该步骤的具体描述可以参照步骤S130中的介绍，在此不再赘述。

S430：在接收到接入单元发送的健康检查请求的情况下，发送对应于所述健康检查请求的反馈结果至所述接入单元，以使所述接入单元根据反馈结果确定对应的检查结果，并在检查结果为故障状态的情况下，将业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

对于该步骤的具体描述可以参照步骤S140、S150、S160、S170、S180中的介绍，在此不再赘述。

基于图3所对应的基于单元化架构的业务处理方法，介绍本说明书实施例一种基于单元化架构的业务处理装置。所述基于单元化架构的业务处理装置可以设置于对应的电子设备上。如图5所示，所述基于单元化架构的业务处理装置包括以下模块。

目标用户识别模块510，用于在接收到业务请求的情况下，识别所述业务请求对应的目标用户。

业务请求转发模块520，用于将所述业务请求转发至对应于所述目标用户的目标分区单元，以使所述目标分区单元对所述业务请求进行处理；所述目标分区单元用于执行所述业务请求对应的业务流程。

健康检查请求发送模块530，用于在所述目标分区单元执行业务流程的过程中，向所述目标分区单元发送健康检查请求。

检查结果确定模块540，用于利用目标分区单元针对所述健康检查请求的反馈结果，确定所述目标分区单元的检查结果。

业务请求发送模块550，用于在所述检查结果为故障状态的情况下，将所述业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

基于图4所对应的基于单元化架构的业务处理方法，介绍本说明书实施例一种基于单元化架构的业务处理装置。所述基于单元化架构的业务处理装置可以设置于对应的电子设备上。如图6所示，所述基于单元化架构的业务处理装置包括以下模块。

业务请求接收模块610，用于接收接入单元转发的业务请求；所述业务请求由接入单元在识别对应的目标用户后转发。

业务流程执行模块620，用于执行所述业务请求对应的业务流程。

反馈结果发送模块630，用于在接收到接入单元发送的健康检查请求的情况下，发送对应于所述健康检查请求的反馈结果至所述接入单元，以使所述接入单元根据反馈结果确定对应的检查结果，并在检查结果为故障状态的情况下，将业务请求发送至备份应用节点以使备份应用节点执行所述业务请求对应的业务流程。

基于图1所对应的基于单元化架构的业务处理方法，本说明书实施例提供一种电子设备。所述电子设备可以包括存储器和处理器。

在本实施例中，所述存储器可以按任何适当的方式实现。例如，所述存储器可以为只读存储器、机械硬盘、固态硬盘、或U盘等。所述存储器可以用于存储计算机程序指令。

在本实施例中，所述处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。所述处理器可以执行所述计算机程序指令实现图3或图4所对应的实施例中的基于单元化架构的业务处理方法。

本说明书实施例提供一种计算机可读存储介质，其上存储有计算机程序/指令。所述计算机可读存储介质可以基于设备的内部总线被处理器所读取，进而通过处理器实现所述计算机可读存储介质中的程序指令。

在本实施例中，所述计算机可读存储介质可以按任何适当的方式实现。所述计算机可读存储介质包括但不限于随机存取存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard Disk Drive,HDD)、存储卡(MemoryCard)等等。所述计算机存储介质存储有计算机程序指令。在所述计算机程序指令被执行时实现本说明书图3或图4所对应的实施例的基于单元化架构的业务处理方法的程序指令或模块。

本说明书实施例还提供一种计算机程序产品，包括计算机程序/指令。所述计算机程序产品可以是通过相应的计算机程序语言所编写的程序，以程序方式存储在相应的存储设备中，并可以通过计算机网络进行传输。所述计算机程序产品可以被处理器所执行。在本说明书实施例中，所述计算机程序产品在被执行时实现如图3或图4所对应实施例的基于单元化架构的业务处理方法的程序指令或模块。

需要说明的是，上述基于单元化架构的业务处理方法、装置及设备可以应用于分布式技术领域，也可以应用至除分布式技术领域外的其他技术领域，对此不做限制。

此外，上述实施例的执行过程涉及对于数据的获取、处理、使用、存储等操作，均符合国家相关法律法规的要求。

虽然上文描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

本申请是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁带存储、磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。