一种实现分布式业务规则的方法、系统和服务器与流程

本申请涉及软件
技术领域：
，特别涉及一种实现分布式业务规则的方法、系统和服务器。
背景技术：
：在软件开发过程中，频繁的需求变更是一件令人头痛的事情，比如由于工程前期对需求理解不到位，或者企业管理者的决策发生变化等情况，都会导致对软件的需求发生变化。因此，为了对应复杂多变的需求变更，出现了规则引擎技术。规则引擎主要是将软件工程中的业务逻辑抽离出来，当需求发生变化时，通过简单地修改规则文件即可，无需涉及具体业务代码。这样的框架技术越来越受到软件开发人员的关注。现有的应用规则引擎的框架技术通常是单机版，主要适用小型应用场景。随着目前大数据多业务的发展趋势，该方案则越来越难以发挥其作用。技术实现要素：本申请提供了一种实现分布式业务规则的方法，可以扩展到分布式规则引擎技术框架中实施，从而适应大数据多业务的发展趋势。本申请提出的一种实现分布式业务规则的方法具体为：在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器，所述规则服务表包含规则服务id号，所述规则服务id号与执行业务规则的分布式服务器存在关联关系；在所述分布式服务器中，根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号；在所述微服务封装的规则引擎中，根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件。进一步地，在接收业务需求数据之前，该方法进一步包括：生成对业务需求数据处理的规则引擎，并生成所述规则表；将所述规则引擎进行微服务封装生成所述微服务封装的规则引擎，并生成所述规则方案分组表；通过远程过程调用rpc方法将所述微服务封装的规则引擎部署到所述分布式服务器中，并生成所述规则服务表。进一步地，所述根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器的方法包括：查询所述规则服务表，获取所述规则服务表中所有分布式服务器，将所述业务需求数据分发到所有的分布式服务器中。进一步地，所述根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎的方法包括：查询所述规则方案分组表，获取所述规则方案分组表中所有微服务封装的规则引擎，将所述业务需求数据分发到所有的微服务封装的规则引擎中。进一步地，所述根据事先设置的规则表对接收到的业务需求数据进行处理的方法包括：根据规则引擎执行方法将接收到的业务需求数据拆解为事实对象和业务规则文件；判断所述事实对象是否属于所述可执行域，如果是，则根据业务规则文件执行对事实对象的业务逻辑，并返回执行结果；否则，返回空结果。进一步地，在接收业务需求数据之前，该方法进一步包括：设置规则分组映射表，所述规则分组映射表包含所述规则分组id号和所述规则可执行域的对应关系；设置规则服务映射表，所述规则服务映射表包含所述规则服务id号和所述规则可执行域的对应关系。进一步地，所述根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器的方法包括：从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则服务映射表，确定与所述规则可执行域对应的规则服务id号；将所述业务需求数据发送给确定出来的规则服务id号所对应的分布式服务器。进一步地，所述根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎的方法包括：从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则分组映射表，确定与所述规则可执行域对应的规则分组id号；将所述业务需求数据发送给确定出来的规则分组id号所对应的微服务封装的规则引擎。进一步地，所述根据事先设置的规则表对接收到的业务需求数据进行处理的方法包括：根据规则引擎执行方法将接收到的业务需求数据拆解为事实对象和业务规则文件；根据业务规则文件执行对事实对象的业务逻辑，并返回执行结果。进一步地，在到达映射表维护时机时，该方法进一步包括：通过监听规则数据库对所述规则分组映射表和所述规则服务映射表进行维护，所述规则数据库用于保存所述业务规则。进一步地，所述映射表维护时机包括：所述实现分布式业务规则之前，进行初始化过程中需要调用所述规则数据库以建立所述规则分组映射表和所述规则服务映射表；或者，在所述规则数据库中增加新的业务规则时；或者，所述规则表中还包括规则生效状态和规则更新时间，在所述规则数据库中废除或修改已有业务规则而导致所述规则生效状态和规则更新时间更新时。本申请还提出一种实现分布式业务规则的系统，具体为：该系统包括接口服务器和至少一台分布式服务器；所述接口服务器，在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器，所述规则服务表包含规则服务id号，所述规则服务id号与执行业务规则的分布式服务器存在关联关系；所述分布式服务器，根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号；在所述微服务封装的规则引擎中，根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件。本申请还提出一种实现分布式业务规则的服务器，具体为：该服务器用作接口服务器，包括：第一接口收发模块，在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器，所述规则服务表包含规则服务id号，所述规则服务id号与执行业务规则的分布式服务器存在关联关系；第一存储模块，用于保存所述规则服务表。进一步地，该服务器还包括：第一映射模块，用于从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则服务映射表，确定与所述规则可执行域对应的规则服务id号；将所述业务需求数据发送给确定出来的规则服务id号所对应的分布式服务器；第一列表更新模块，用于在到达映射表维护时机时，通过监听规则数据库对所述规则服务映射表进行维护，所述规则数据库用于保存所述业务规则；第一列表存储模块，用于保存规则服务映射表，所述规则服务映射表包含所述规则服务id号和所述规则可执行域的对应关系。本申请还提出一种实现分布式业务规则的服务器，具体为：该服务器用作分布式服务器，包括：第二接口收发模块，用于根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号；微服务封装的规则引擎，用于根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件；第二存储模块，用于保存所述规则方案分组表和所述规则表。进一步地，该服务器还包括：第二映射模块，用于从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则分组映射表，确定与所述规则可执行域对应的规则分组id号；将所述业务需求数据发送给确定出来的规则分组id号所对应的微服务封装的规则引擎；第二列表更新模块，用于在到达映射表维护时机时，通过监听规则数据库对所述规则分组映射表进行维护，所述规则数据库用于保存所述业务规则；第二列表存储模块，用于保存规则分组映射表，所述规则分组映射表包含所述规则分组id号和所述规则可执行域的对应关系。由上述技术方案可见，本申请实施例建立了一种新的分布式规则引擎技术框架。在本申请实施例的这种框架下，业务规则不再由单机执行，而是将业务规则分散在分布式服务器上实现。通过设置的规则服务表、规则方案分组表、规则表将业务需求数据层层下发，不再局限于单机，从而可以适应目前大数据多业务的情形。附图说明图1是本申请方法实施例一实现分布式业务规则的流程图。图2是本申请方法实施例一建立分布式业务规则引擎框架的流程图。图3是本申请方法实施例一中规则引擎技术框架工作示意图。图4是本申请方法实施例一中微服务框架工作示意图。图5是本申请方法实施例二实现分布式业务规则的流程图。图6是本申请方法实施例三实现分布式业务规则的流程图。图7是本申请方法实施例四中业务需求数据流动方向示意图。图8是本申请系统实施例一的结构示意图。图9是接口服务器801的内部结构示意图。图10是分布式服务器802的内部结构示意图。具体实施方式为使本申请的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本申请作进一步详细说明。本申请实施例将单机版的规则引擎技术框架扩展到分布式的规则引擎技术框架，用多台分布式服务器来实现，从而适应目前大数据多业务的发展趋势。图1是本申请方法实施例一的流程图。如图1所示，本实施例一实现分布式业务规则的方法包括：步骤101：在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器，所述规则服务表包含规则服务id号，所述规则服务id与执行业务规则的分布式服务器存在关联关系。本申请实施例建立分布式规则引擎技术框架，由多台服务器实现业务规则，而不是由单机实现，因而在接收到业务需求数据时，先通过规则服务表获知服务器，将业务需要数据发送给服务器。步骤102：在所述分布式服务器中，根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号。本步骤所述的微服务封装是指以单一责任和功能的小型功能区块为基础，利用模块化的方式组合成复杂的大型应用程式的一种方法。将规则引擎进行微服务封装，便于进行向外提供api调用服务，一台服务器可以包括多个微服务封装。步骤103：在所述微服务封装的规则引擎中，根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件。本领域技术人员知道，在一个规则引擎内部，可以将从外部接收到的业务需求数据拆解为事实对象和规则文件，也即是分为数据和逻辑两部分，再利用业务规则文件对事实对象进行逻辑处理。这里所述的规则文件就是一系列逻辑处理的集合，所述事实对象就是数据。而是否进行这样的逻辑处理则是由规则表中的可执行域决定的，符合可执行域的就启动执行，不符合可执行域的就不启动执行。本申请实施例一将业务规则分散在分布式服务器上实现，通过设置的规则服务表、规则方案分组表、规则表将业务需求数据层层下发，不再局限于单机，从而可以适应目前大数据多业务的情形。在实现上述分布式业务规则之前，实际应用中需要先建立分布式业务规则引擎框架。图2是本申请实施例一建立分布式业务规则引擎框架的流程图。如图2所示，该方法包括：步骤201：生成对业务需求数据处理的规则引擎，并生成规则表。如前所述，所谓规则就是逻辑处理，规则引擎就是按照该逻辑对业务数据进行的模块。图3是本步骤所述规则引擎技术框架工作的示意图。如图3所示，当规则引擎接收到业务需求数据时，将其拆解为事实对象(fact)和规则文件(rule)两部分，在内部进行匹配。当匹配成功时，对事实对象按照规则文件进行逻辑处理，生成处理结果。这里所述匹配其实就是判断事实对象是否属于可执行条件域，如果属于，则匹配成功，否则，匹配失败。而规则文件通常包括“条件”和“执行”两个部分，“条件”就是这里所述可执行域，“执行”就是具体的逻辑处理。由于本申请实施例一建立的是一种分布式业务引擎框架，为了便于将业务需求数据分发到各规则引擎上处理，可以为每一个规则引擎建立一个规则表。规则表可以采用如表一所示的方式：表头ruleidrulecontentnamespacerulegroupid解释规则id规则内容可执行域规则分组id表一其中，由于实际应用中一个规则引擎可以处理多个规则，规则id表示这些不同规则的序号，规则内容表示某个规则需要处理的逻辑内容，可执行域表示启动某个业务规则执行的条件。另外，由于一个服务器可以建立多个微服务，一个微服务在本申请实施例中也是一个规则分组，规则分组id表示这些不同规则分组的序号。步骤202：将所述规则引擎进行微服务封装生成所述微服务封装的规则引擎，并生成所述规则方案分组表。如上所示，微服务规则引擎是一种模块化的功能块，可以对外提供与语言无关的api调用。由于本实施例中一台服务器可以建立多个微服务规则引擎，为了便于将业务需求数据分发到各微服务规则引擎上处理，可以为每一个微服务规则引擎建立一个规则方案分组表。规则方案分组表可以表二所示的方式：表头rulegroupidrulegroupnameruleserviceid解释规则分组id规则分组名称规则服务id表二其中，规则分组id表示不同微服务规则引擎，规则分组名称表示不同微服务规则引擎实现功能的名称。另外，分布式服务器有多个，一个分布式服务器中可以有一个或多个规则分组集合，规则服务id区分这些不同的集合，且与分布式服务器之间存在关联关系。因此，通过规则服务id可以确定相应的分布式服务器。当然，如何确定分布式服务器由大数据框架技术决定，比如主从(master-slave)架构等。图4是本申请实施例所述微服务框架工作示意图。如图4所示，微服务框架内部工作原理和规则引擎相同，只是将其进行了微服务封装。步骤203：通过远程过程调用(rpc)方法将所述微服务封装的规则引擎部署到所述分布式服务器中，并生成所述规则服务表。本领域技术人员知道，rpc是一种计算机通信协议，该协议允许运行于一台计算机的程序调用另外一台计算机的子程序。rpc框架除了常规的点对点调用外，还支持服务治理功能，包括服务结点的自动发现、摘除，高可用和负载均衡等。通常，可以设置服务提供方(rpcserver)、服务调用方(rpcclient)和服务注册中心(registry)三个角色。其中，服务提供方是用于提供服务的，可以事先向服务注册中心注册自身的服务，并向注册中心定期发送心跳汇报状态。服务调用方需要向服务注册中心订阅rpc服务，获得返回的服务列表，并与某个服务提供方建立连接，进行rpc调用。在本实施例中，可以通过上述的rpc方法将微服务封装的规则引擎部署到各服务器中，至于具体如何实施不是本申请实施例描述的重点。另外，由于存在多个分布式服务器，可以设置一个规则服务表，如表三所示：表头ruleserviceidruleservicename解释规则服务id规则服务名称表三其中，规则服务id可关联分布式服务器，规则服务名称表示某个服务器的名称。上述分别建立了规则表、规则方案表和规则服务表，分别位于分布式业务框架的不同层次。通过表三的规则服务id可以确定最高层次服务器；通过表二的规则服务id可以找到对应的规则分组id，从而确定第二层次的微服务封装规则引擎；通过表一的规则分组id可以找到底层规则引擎对应的规则id，利用底层规则引擎执行相应的规则。本申请实施例将规则引擎技术框架、微服务技术框架、rpc技术框架结合起来建立了一种新的分布式规则引擎技术框架。在本申请实施例的这种框架下，业务规则不再由单机执行，而是在兼顾单机版优势的基础上，将规则引擎部署在多台服务器上，可以按照业务进行分组，实现多业务、多规则并发执行，从而很好地适应了目前大数据多业务的发展趋势。建立了上述分布式规则引擎技术框架之后，就可以按照本申请实施例一的方法实现分布式业务规则了。实际应用中，具体实现分布式业务规则可以有多种方案，下面用至少两种方案进行详细描述。第一种方案是通过遍历的方法实现分布式业务规则，第二种方案是通过快速定位的方法实现分布式业务规则。第一种方案：采用遍历的方法实现分布式业务规则。这种方案是将业务需求数据遍历式的层层分发，底层每一个规则引擎都利用自身的规则表判断业务需求数据中的事实对象是否属于可执行域，并以此确定是否启动业务规则的执行。图5是采用遍历方法实现分布式业务规则的实施例二的方法流程图。如图5所示，该方法包括：步骤501：在接收到业务需求数据时，查询规则服务表，获取所述规则服务表中所有分布式服务器。步骤502：将业务需求数据分发到所有的分布式服务器中。假设步骤501的规则服务表采用表三的形式，本方法实施例三中具体如下表四所示：表四那么，根据查询表四可以获得服务器列表，即serviceid-1、serviceid-2等所有的分布式服务器，并将业务需求数据发送给这些服务器。步骤503：在每一个分布式服务器中，查询所述规则方案分组表，获取所述规则方案分组表中所有微服务封装的规则引擎。步骤504：将所述业务需求数据分发到所有的微服务封装的规则引擎中。假设步骤503的规则方案分组表采用表二的形式，本方法实施例三中在serviceid-1的这个服务器中的规则方案分组表具体如下表五所示：表五那么，根据查询表五可以获得服务器serviceid-1中的规则方案分组列表，即groupid-1、groupid-2等所有的规则方案分组。这里，每一个规则方案分组就是一个微服务封装的规则引擎。步骤505：在每一个微服务封装的规则引擎中，根据规则引擎执行方法将接收到的业务需求数据拆解为事实对象和业务规则文件。步骤506：判断所述事实对象是否属于所述可执行域，如果是，则执行步骤507；否则，执行步骤508。假设规则表采用表一的形式，本方法实施例二中在groupid-1的这个微服务规则引擎中的规则表具体如下表六所示：表六对于某个规则ruleid-1来说，假设接收到业务需求数据拆解的事实对象是一些数值，拆解出来的规则文件是需要对这些数值进行相加(业务逻辑)，那么首先需要根据规则表判断接收到的数值是否为正整数，如果是正整数，说明事实对象属于可执行域，才启动规则ruleid-1的执行。对于另一个规则ruleid-2来说，假设接收到业务需求数据拆解的事实对象是一些数值，拆解出来的规则文件是将数值减去100(业务逻辑)。同样，首先需要根据规则表判断接收到的数值是否大于100，如果是，说明事实对象属于可执行域，才启动规则ruleid-2的执行。步骤507：根据业务规则文件执行对事实对象的业务逻辑，并返回执行结果。步骤508：返回空结果。上述步骤505～508是本实施例二的规则引擎内部的工作机制。可见，在本申请方法实施例三中利用规则服务表、规则方案分组表以及规则表将数据需求数据层层分发给所有的服务器、微服务规则引擎，由底层所有的规则引擎利用自身规则表中的可执行域判断是否需要执行。也就是说，本方法实施例采用的是遍历的方式将业务需求数据发送给所有的规则引擎，最后由规则引擎进行过滤。第二种方案：采用快速定位的方法实现分布式业务规则。这种方案是将业务需求数据准确分发给相关的规则引擎，只有相关的规则引擎才启动业务规则的执行。为了能够快速定位，本实施例增加两个映射表，一个是规则分组映射表，包括规则分组id号和规则可执行域的对应关系。另一个是规则服务映射表，包括规则服务id号和规则可执行域的对应关系。其中，规则分组映射表如表七所示：表七其中，规则可执行域和规则分组id表示一对对应关系。同理，规则服务映射表如表八所示：表八其中，规则可执行域和规则服务id表示一对对应关系。图6是采用快速定位方法实现分布式业务规则的实施例三的方法流程图。如图6所示，该方法包括：步骤601：在接收到业务需求数据时，从业务需求数据中获取规则可执行域。本领域技术人员知道，业务需求数据中本身包含了规则文件可执行域的内容，因此可以从中获得。步骤602：根据所述规则可执行域查询规则服务映射表，确定与规则可执行域对应的规则服务id号。假设规则服务映射表采用表八的形式，在本实施例三中具体的规则服务映射表如表九所示：表九根据查询规则服务映射表，可以获知serviceid-1和serviceid-5这两个服务器与当前需要执行的规则相关。步骤603：将业务需求数据发送给确定出来的规则服务id号所对应的分布式服务器。本步骤会将业务需求数据发送给serviceid-1和serviceid-5这两个服务器。步骤604：在服务器中，从业务需求数据中获取规则可执行域。此时，假设业务需求数据已经分发给了serviceid-1和serviceid-5这两个服务器，serviceid-1和serviceid-5这两个服务器也可以从中获得规则文件可执行域的内容。步骤605：服务器根据规则可执行域查询规则分组映射表，确定与规则可执行域对应的规则分组id号。假设规则分组映射表采用表七的形式，在本实施例三的服务器serviceid-1中具体的规则分组映射表如表十所示，服务器serviceid-5中具体的规则分组映射表如表十一所示：表十表十一步骤606：服务器将业务需求数据发送给确定出来的规则分组id号所对应的微服务封装的规则引擎。也就是说，服务器serviceid-1会将业务需求数据发送给groupid-1对应的微服务封装规则引擎，而服务器serviceid-5会将业务需求数据发送给groupid-3对应的微服务封装规则引擎。步骤607：根据规则引擎执行方法将接收到的业务需求数据拆解为事实对象和业务规则文件。步骤608：根据业务规则文件执行对事实对象的业务逻辑，并返回执行结果。这里所述步骤607是服务器serviceid-1中groupid-1规则引擎对业务需求数据进行处理的过程，步骤608是服务器serviceid-5中groupid-3规则引擎对业务需求数据进行处理的过程。由于之前已经通过规则可执行域筛选过，业务需求数据只发给了相关的规则引擎，因此可以省略再次验证的步骤，直接进行逻辑处理即可。本申请实施例三，由于利用设置的规则服务映射表和规则分组映射表对业务需求数据进行了拦截，只发送给符合条件的规则引擎，无需遍历所有的服务器和规则引擎，因此可以快速定位。另外，由于无需其他服务器和规则引擎接收、处理业务需求数据，因而可以大大节约资源。当然，实际应用中还可以对规则可执行域的条件进行细化，进行更为精准的定位。至于具体如何实施可以由应用本申请方案的用户自行确定。实际应用中，与规则相关的信息都可以事先保存在规则数据库中，从数据库中获取信息构成上述的规则分组映射表和规则服务映射表。在整个系统运行过程中，所述规则分组映射表和规则服务映射表可以调到内存中供使用。在到达映射表维护时机时，通过监听规则数据库的方法对所述规则分组映射表和所述规则服务映射表进行维护。其中，映射表维护时机可以选择在以下环节：1、在本申请实施例实现分布式业务规则之前，系统进行初始化过程中需要调用规则数据库以建立规则分组映射表和所述规则服务映射表的时候。此时，对映射表的维护相当于是从无到有的构建。2、在本申请实施例实现分布式业务规则过程中，如果需要在规则数据库中增加新的业务规则的时候。此时，为了匹配新的业务规则，需要对映射表及时进行更新。3、事先为规则设置规则生效状态(rulestatus)和规则更新时间(updatetime)，并将其添加在规则表中。在本申请实施例实现分布式业务规则过程中，如果需要在数据库中修改或删除某个已有的业务规则的时候。为了匹配该情况，需要对映射表及时进行更新。比如，规则数据库中某个业务规则被废除，在规则表中将规则生效状态(rulestatus)设置为“废止”，在规则更新时间(updatetime)中填写废除时的系统时间。此时，需要对映射表进行更新。上述仅列举出几种映射表维护时机，时机应用中也可能还存在其他时机，只要能够及时适应对数据库更新情况即可。本申请上述实施例方案可以应用于各种场景，只要软件工程中可以将作为业务数据的事实对象和作为业务逻辑的规则文件拆解出来即可。比如：数据挖掘、机器学习的数据清洗、深度学习的特征变换等等各种应用场景。下面用实施例四简单举例说明。假设需要进行数据清洗的数据集为某个社交软件的登录数据，而清洗的最终步骤分别进入两种模型，循环神经网络(rnn，recurrentneuralnetworks)模型和深度神经网络(dnn，deepneuralnetworks)模型。图7是本实施例四的业务需求数据流动方向示意图。如图7所示，假设按照上述方法实施例三对业务需求数据进行处理，其中，分布式业务规则系统包括三台服务器，分别为服务器a、服务器b和服务器c。服务器a中建立了微服务封装的规则引擎分别执行login-rnn方案a、login-rnn方案b、订单数据方案a；服务器b中建立了微服务封装的规则引擎分别执行login-dnn方案a、订单数据方案b、订单数据方案c、服务器c中建立了微服务封装的规则引擎分别执行浏览数据方案a和订单数据方案d。方法实施例四以处理login-rnn和login-dnn数据为例。假设系统接收到业务需求数据，其中既包含login-rnn业务输入的相关数据和login-dnn业务输入的相关数据，还可能包含与浏览或订单相关的业务数据。因此，在接收到业务需求数据时，可以利用规则服务映射表和规则分组映射表进行拦截，使与login-rnn业务的相关数据准确进入服务器a的执行login-rnn方案a和login-rnn方案b的规则引擎中，使login-dnn业务的相关数据准确进入服务器b的执行login-dnn方案a的规则引擎中。因此，本实施例四在实现数据清洗的业务规则时，采用了分布式规则引擎技术框架而可以适应大数据多业务的需求，还由于采用了规则服务映射表和规则分组映射表仅将业务数据准确快速分发给了相关的规则引擎，不必调用所有的规则引擎，大大节约了资源。本申请还提出一种实现分布式业务规则的系统。图8是本申请系统实施例一的结构示意图。如图8所示，该系统包括至少一台分布式服务器802和接口服务器801。其中，接口服务器801，在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器802，所述规则服务表包含规则服务id号，所述规则服务id号与执行业务规则的分布式服务器存在关联关系。分布式服务器802，根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号；在所述微服务封装的规则引擎中，根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件。图9是所述接口服务器801的内部结构示意图。如图8所示，该服务器包括：第一接口收发模块901和第一存储模块902。其中，第一接口收发模块901，在接收到业务需求数据时，根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器，所述规则服务表包含规则服务id号，所述规则服务id号与执行业务规则的分布式服务器存在关联关系。第一存储模块902，用于保存所述规则服务表。该接口服务器还可以进一步包括第一映射模块903、第一列表更新模块904、第一列表存储模块905。其中，第一映射模块903，用于从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则服务映射表，确定与所述规则可执行域对应的规则服务id号；将所述业务需求数据通过所述第一接口收发模块901发送给确定出来的规则服务id号所对应的分布式服务器；第一列表更新模块904，用于在到达映射表维护时机时，通过监听规则数据库对所述规则服务映射表进行维护，所述规则数据库用于保存所述业务规则；第一列表存储模块905，用于保存规则服务映射表，所述规则服务映射表包含所述规则服务id号和所述规则可执行域的对应关系。图10是所述分布式服务器802的内部结构示意图。如图10所示，该服务器包括：第二接口收发模块1001、微服务封装的规则引擎1002、第二存储模块1003。其中，第二接口收发模块1001，用于根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎，所述规则方案分组表包含规则分组id号，所述规则分组id号表示执行业务规则的微服务封装的规则引擎序号；微服务封装的规则引擎1002，用于根据事先设置的规则表对接收到的业务需求数据进行处理，所述规则表包含规则可执行域，所述规则可执行域表示启动业务规则执行的条件；第二存储模块1003，用于保存所述规则方案分组表和所述规则表。该服务器还可以进一步包括：第二映射模块1004、第二列表更新模块1005、第二列表存储模块，其中，第二映射模块1004，用于从所述业务需求数据中获取所述规则可执行域；根据所述规则可执行域查询所述规则分组映射表，确定与所述规则可执行域对应的规则分组id号；将所述业务需求数据发送给确定出来的规则分组id号所对应的微服务封装的规则引擎；第二列表更新模块1005，用于在到达映射表维护时机时，通过监听规则数据库对所述规则分组映射表进行维护，所述规则数据库用于保存所述业务规则；第二列表存储模块1006，用于保存规则分组映射表，所述规则分组映射表包含所述规则分组id号和所述规则可执行域的对应关系。也就是说，接口服务器801在接收到业务需求数据时，第一接口收发模块901根据事先设置的规则服务表将所述业务需求数据分发给分布式服务器802；分布式服务器802的第二接口收发模块1001根据事先设置的规则方案分组表将所述业务需求数据分发给微服务封装的规则引擎1002；微服务封装的规则引擎1002根据事先设置的规则表对接收到的业务需求数据进行处理。同时，在到达映射表维护时机时，第一列表更新模块904和第二列表更新模块1005还会通过监听的方式对规则服务映射表和规则分组映射表进行维护。利用本申请提供的方法、系统和装置实施例方案，可以将规则引擎技术框架、微服务技术框架、rpc技术框架结合起来建立一种新的分布式规则引擎技术框架。在分布式规则引擎技术框架基础上，可以按照业务进行分组，实现多业务、多规则并发执行，从而很好地适应了目前大数据多业务的发展趋势。以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。当前第1页12