CN104915812A - 用于业务处理过程中的仓配路由的方法和装置 - Google Patents

Abstract

本申请涉及用于业务处理过程中的仓配路由的方法和装置。该方法包括：响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数；根据所述业务场景属性，确定与所述业务对应的路由方案实例；以及根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。根据本申请的技术方案，可以实现平台化的仓配路由处理方案，降低仓配路由方案的开发和维护成本并且支持复杂业务场景下的业务的快速和灵活发展，由此可以大大提高整体业务处理效率，从而更加方便用户的使用。

Description

用于业务处理过程中的仓配路由的方法和装置

技术领域

本申请涉及互联网领域，尤其涉及业务处理方法和装置。

背景技术

随着互联网技术的飞速发展，对于利用互联网技术进行多种业务的交互处理已经成为必然趋势。

在业务交互的实际应用中，为了满足不同人群和业务的物流服务层次需求，服务器往往需要针对不同的垂直业务提供物流服务。基本运作流程通常如下：（1）生成物流服务订单；（2）定位货品所在仓库；（3）选择合适的配送公司；（4）配送公司揽收并完成配送。

物流服务订单中的货品一般会放置在地理上彼此分离的多个仓库中，同时合作的快递通常也会有若干个，因此需要按照业务语义、商务约束、物流服务QOS等因素去路由最佳的仓库和快递。

仓配路由的本质是根据业务约束条件和业务规定的物流服务QOS去选择合适的仓库或者快递的过程。每种业务都有相应的业务特色或约束，比如易燃易爆类物品一般不能通过航空运输来投递，或者大家电一般需要提供送货上门服务等，这样不同的业务在选择仓库或者快递时所考虑的因素是不同的，最终选择的仓库和快递也会不同。为了提高畅销货品的配送效率，商家往往会将相同的货品存放在多个仓库，每个仓库可以辐射一定的区域，当选择某个仓库时，会考虑到诸如仓库是否有该货品、仓库是否覆盖收货区域，商务合作的优先级，货品周转周期，仓库处理效率等一系列因素；不同快递的业务范围和能力是不同的，比如有的快递擅长家装配送，有的快递擅长生鲜冷链配送等，这样在路由快递时需要匹配到符合业务要求的最佳配送公司。上述简要地说明了一些可能会影响仓配路由的因素，这些因素通过组合就会产生大量的路由方式，因此针对特定的业务需要高效地定制合适的路由方案以支持业务的发展。

在现有的解决方案中，通常是通过为每种业务独立开发一套仓配路由逻辑来支持业务的发展。每一套仓配路由逻辑中涵盖对应业务的约束条件和物流服务QOS要求，通过在若干符合约束条件的仓储和快递间按照某种业务相关的策略进行筛选后得到最佳的路由结果。这种“烟囱式”仓配路由解决方案的处理模式如图1所示，其中针对业务A、B、C分别开发独立的仓配路由逻辑A、B、C。

然而，随着垂直业务的不断拓展，业务渠道（如聚划算等）的不断增多，路由契约（如保障速递、次日必达等）的不断完善，上述现有方案的不足也暴露的淋漓尽致。现有方案的不足之处如下：

（1）为每种业务开发独立路由逻辑的方式研发周期长，维护成本高，资源浪费严重，难以支持业务快速发展。当若干业务并行发展时，这种缺陷就更加显而易见。

（2）业务演进过程中，可能不断变更业务约束条件和物流服务QOS要求，现有方案中一旦某种路由逻辑部署完毕则难以扩展，需要修改源码后重新部署。这种模式难以满足业务的进化需求，尤其是业务在活动期间和非活动期间路由模式切换的需求。

（3）现有方案中没有抽象出原子粒度的路由元素，不同路由逻辑公用了若干粒度较大的路由模块，某种业务的语义变化导致路由逻辑更新后需要回归其他业务，业务之间的路由隔离性较差，难以独立演进。

因此，需求一种改进的仓配路由方案，以克服现有技术中的上述问题。

发明内容

本申请的主要目的在于提供一种改进的仓配路由方案，以实现平台化的仓配路由解决方案，从而提高仓配路由方案的灵活性和可扩展性，提高业务处理效率和更加方便用户的使用。

根据本申请一个方面的实施例，提供一种用于业务处理过程中的仓配路由的方法，其特征在于，包括：响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数；根据所述业务场景属性，确定与所述业务对应的路由方案实例；以及根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。

根据本申请另一方面的实施例，提供一种用于业务处理过程中的仓配路由的装置，其特征在于，包括：解析模块，用于响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数；确定模块，用于根据所述业务场景属性，确定与所述业务对应的路由方案实例；以及执行模块，用于根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。

与现有技术相比，根据本申请的技术方案，实现一种平台化的仓配路由解决方案，其中通过配置化的路由方案装配模式以及层次化的路由方案执行策略实现路由方案的快速组配，支持业务独立演进和个性化路由模式动态切换，从而可以降低仓配路由方案的开发和维护成本并且支持复杂业务场景下的业务的快速和灵活发展，由此可以大大提高整体业务处理效率，从而更加方便用户的使用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出根据现有技术的仓配路由方案的架构示意图；

图2示出根据本申请构思的仓配路由方案的架构示意图；

图3示出根据本申请构思的路由模型抽象结构的示意图；

图4示出根据本申请一个实施例的仓配路由方法的流程图；以及

图5示出根据本申请一个实施例的仓配路由装置的结构框图。

具体实施方式

本申请的主要思想就在于，通过平台化模式去克服传统的“烟囱式”方案的不足，即通过可插拔、动态组配、热部署等方式构建一种动态进化的仓配路由解决方案，其中通过配置化的路由方案装配模式以及层次化的路由方案执行策略实现路由方案的快速组配，支持业务独立演进和个性化路由模式动态切换，从而支持复杂业务场景下的业务快速和灵活发展，同时降低仓配路由方案开发和维护成本。更具体而言：

（1）通过抽象出不同粒度的路由组件提高了路由逻辑的重用能力。新的路由方案实例可以通过对现有路由规则的编排来实现，即使部分路由规则缺少也仅需要开发缺少部分即可，大大提高了路由方案定制进度，减少研发周期和资源投入。

（2）业务产品需要的路由模式更新后，只需组装和注册新的路由方案实例即可，系统会实时将新的路由方案实例推送到执行引擎，实现动态更新，提高系统的路由方案热部署能力。当业务产品需要频繁切换路由模式时，这种动态能力的作用是非常强大的。

（3）不同的业务产品对应不同的路由方案实例，运行时这些实例通过上下文彼此隔离。当某个路由方案实例的实现细节变化时，只需要提供变化的模块，重新组装路由方案即可，不会对其他的路由方案实例产生影响，增加业务隔离性，支持不同业务的快速发展。

（4）路由方案通过可视化方式进行管理，极大提高方案的组配效率；对路由方案实例进行监控，可及时发现关键业务的路由情况，提高关键业务的路由执行效率。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步的详细说明。

首先参照图2总体地描述本申请的思想架构。针对不同的业务例如A、B、C，业务场景不同，因此定义业务场景属性来表征不同的业务场景。换言之，不同的业务场景具有不同的业务场景属性。

如图2所示，在接收到不同业务的仓配路由请求时，通过解析引擎提取出与业务相应的业务场景属性，并根据业务场景属性选择对应的路由模型实例（路由方案实例）。该路由模型实例中包括一个或多个路由规则。

另外，通过解析引擎提取出业务路由参数，也就是与当前业务相关的特定参数，例如业务对象信息、收发地址信息等，并且将这些业务路由参数封装成业务上下文。

然后，通过执行引擎结合上述业务上下文来执行路由模型实例，从而得到与当前业务对应的仓配路由结果（仓配信息）。

需要特别说明的是，本申请的核心就在于，基于粒度较小的路由逻辑建立路由模型，下面结合图3进行详细说明。如图3所示，本申请的路由模型抽象为三层逻辑：路由元素层、路由规则层和路由方案层（包括多个路由方案实例）。具体而言，路由元素层为原子级别的路由逻辑，例如业务对象规则、库存规则等。当然应理解到的是，路由元素并不限于这些示例，而是还可以包括其它任意合适的原子级别的路由逻辑。通过路由元素间的组合可以形成路由规则，也就是，通过在路由元素之间实施特定执行策略，使得路由元素之间相互关联，形成路由规则。如图3所示，路由规则rr1可以通过路由元素rel、re2、re3以及这三个元素之间的关联关系构成。路由规则rr3可以通过路由元素re2、re3、re4以及这三个元素之间的关联关系构成。可见这些路由元素间彼此独立，重用度高。更进一步而言，通过路由规则间的组合可以形成路由方案（路由方案实例），也就是，通过在路由规则之间实施特定执行策略，使得路由规则之间相互关联，从而形成路由方案。如图3所示，路由方案rs1可以通过路由规则rrl和rr3以及这两个规则之间的关联关系构成。路由方案rs2可以通过路由规则rr1、rr2、rr3以及这三个规则之间的关联关系构成。可见这些路由规则间也是彼此独立的，重用度高。

当出现新的业务需求时，只需要通过编排引擎重新对路由元素、路由规则、路由方案进行模型定义，包括对这些路由元素、路由规则、路由方案进行删除、增加、修改、查询等操作。

上述这种层次化的路由模型支持：

（1）快速组配路由方案。这是由于路由元素和规则的重用性强导致的，当定制某种路由方案时如果缺少相应的路由规则和路由元素，则只需开发缺少部分即可，如组装图示中rs3，只需要新开发路由规则rr4和路由元素re5即可；

（2）支持动态调整路由方案。比如图示中路由方案rs1原先是由路由元素rr1和rr3组成的，为了适应活动期间业务需要将rs1更新为由rr1,rr2,rr3组成，只需要修改方案配置即可，无需重新部署应用；

（3）每一个路由方案都是互相独立的。如图示中调整rs2的编排方式，rs1和rs3均不受到影响，支持业务独立进化。路由方案的组成是配置在数据库DB中，可通过用户接口UI动态调整，并且在实际执行时为了提高响应速度，将路由方案加载到内存中。

由此可以提供平台化的路由模型，针对不同业务提供路由方案，而不必像现有技术那样需要针对每个业务独立开发路由逻辑而导致这些路由逻辑中相同逻辑开发的浪费。根据本申请的业务处理方案可以降低开发成本和提高业务处理效率。

下面参照图4进一步详细地描述基于上述这样的路由模型实现业务处理过程中的仓配路由的具体过程。

图4示出了根据本申请一个实施例的仓配路由方法400的流程图。

如图4所示，在步骤S410处，响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数。

具体而言，在典型场景中，针对业务的仓配路由请求也就是请求获取某个业务所需或与某个业务相关的仓配路由结果。例如，针对某个业务订单，其中含有诸如商品信息之类的业务对象信息以及诸如收货地址和发货地址之类的收发地址信息，则可以通过向服务器发送仓配路由请求，来获取该业务订单对应的仓储和配送的路由结果（仓储地和配送者的选择结果）。

进一步地，可以对业务进行解析处理，以获取与该业务对应的业务场景属性和业务路由参数。例如，业务场景属性可以包括诸如大家电、冷鲜产品等的垂直市场，可以包括诸如聚划算、预售活动之类的渠道，也可以包括诸如保障速递之类的路由契约，等等。应理解到，业务场景属性并不限于这些示例，而是还可以包括能够表征本领域已知或未来开发的其它任意业务场景的其它业务场景属性。同一业务场景属性下的业务对应的路由方案实例是基本相同的，也就是，同一业务场景属性下的业务对应的路由方案实例包含的路由规则以及规则遵循的执行策略大致相同。而业务路由参数则是特定业务对应的具体路由规则参数。例如，路由规则参数可以包括诸如商品信息之类的业务对象信息、诸如收货地址和/或发货地址之类的收发地址信息、诸如一日达之类的路由契约信息等。同样应理解到，业务路由参数也并不限于这些示例，而是还可以包括本领域已知或未来开发的其它任意合适种类的业务路由参数。

接下来，在步骤S420处，根据业务场景属性，确定与所述业务对应的路由方案实例。

借助于前面提及的路由模型，可以根据业务场景属性确定或选择出路由方案实例（路由方案）。如前面提及的，路由方案实例可以包括一种或多种路由规则以及路由规则之间的关联关系（即，执行策略）。

然后，在步骤S430处，根据业务路由参数，执行上述路由方案实例，以得到针对所述业务的仓配路由方案。

也就是说，将业务路由参数代入到步骤S420中选择出的路由方案实例中以执行该路由方案实例中的路由规则链，从而可以得到针对特定业务的特定仓配路由结果。

在一个具体示例中，例如江苏南京某用户通过天猫网购一台浙江杭州某品牌厂商电视机，要求三日内送达，并且送货上门。则本例中的业务场景属性包括：垂直市场（大家电）和路由契约（时效为三日达）；业务路由参数包括：收发货地址（收货地江苏南京，发货地浙江杭州）、商品属性（彩色电视机，电视机尺寸等）等。根据业务场景属性：大家电+三日达，可以获取对应的路由方案实例（即路由规则链）：A（商品规则）—>B（时效规则）—>C（商务规则）。通过基于上述业务路由参数中的商品属性执行A，发现仓库S1和S2有用户订购的电视机。之后，通过基于上述业务路由参数中的收发货地址执行B，发现快递D1和D2可以在3日内送货上门。然后执行C，例如C为大家电垂直市场规定：S1和S2的发货比率是2:1，D1和D2的配送比率是3:1。若目前S1和S2的已发货数量为19件和10件，D1和D2的已配送数量为30件和10件，则通过执行C可以确定仓库选为S1（因为仓库S1的目前发货占比19/10<2/1），由于D1和D2的配送比率30/10=3:1，则此时随机选择D1和D2，如随机选择了D2。则最终的仓配路由结果为仓库S1和配送D2。

至此描述了根据本申请实施例的业务处理过程中的仓配路由方法。其中：

（1）通过可插拔的仓配路由解决方案，克服了传统“烟囱”式路由模式的不足，实现了仓配路由解决方案的平台化。

（2）层次化的路由模型设计策略和可视化的路由模型管理模式，简化路由方案编排和更新，支持业务快速发展；实时推送能力实现路由方案的热部署，提升路由方案进化效率，支持业务路由模式的快速切换需求。

（3）抽象业务场景和路由模型的映射，不同的业务场景实例注册对应的路由方案实例，达到业务间的彼此隔离，实现了不同业务独立发展的目标。

（4）物流动态、实时监控成为可能，大幅提高了关键业务的路由执行效率。

与以上描述的仓配路由方法类似，本申请实施例还提供了相应的仓配路由装置。

图5示出了根据本申请一个实施例的仓配路由装置500的结构框图。

如图5所示，装置500可以包括解析模块510、确定模块520和执行模块530。

具体而言，解析模块510可以响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数。确定模块520可以根据所述业务场景属性，确定与所述业务对应的路由方案实例。执行模块530可以根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。

根据本申请的实施例，所述路由方案实例可以包括一个或多个路由规则和所述路由规则之间的关联关系，所述路由规则可以包括一个或多个路由元素和所述路由元素之间的关联关系，所述路由元素可以包括原子级别的路由逻辑。

根据本申请的更具体实施例，所述路由元素可以包括以下中的至少一种：业务对象校验逻辑、库存校验逻辑。

根据本申请的更具体实施例，所述业务场景属性可以包括以下中的至少一种：垂直市场、渠道、路由契约。

根据本申请的更具体实施例，所述业务路由参数可以包括以下中的至少一种：收发地址信息、业务对象信息、路由契约信息。

根据本申请的实施例，所述执行模块530可以进一步包括：组装子模块，用于根据所述业务路由参数，组装路由上下文；获取子模块，用于获取所述路由方案实例中的路由规则链；以及得到子模块，用于根据所述路由上下文，执行所述路由规则链，以得到针对所述业务的仓配路由结果。

根据本申请的实施例，装置500还可以包括（图中未示出）：更新模块，用于根据业务需求，更新所述业务场景属性以及与所述业务场景属性对应的路由方案实例。

根据本申请的更具体实施例，所述更新模块可以进一步包括：更新子模块，用于更新所述路由方案实例中的路由规则和路由规则之间的关联关系。

在更具体实施例中，所述更新子模块可以进一步包括：元素更新子模块，用于更新所述路由规则中的路由元素和路由元素之间的关联关系。

至此描述了根据本申请实施例的用于业务处理过程中的仓配路由的方法和装置。总体而言，本申请实现一种平台化的仓配路由解决方案，克服了传统的”烟囱”式的解决方案的不足。具体表现为：

（1）通过抽象出不同粒度的路由组件提高了路由逻辑的重用能力。新的路由方案实例可以通过对现有路由规则的编排来实现，即使部分路由规则缺少也仅需要开发缺少部分即可，大大提高了路由方案定制进度，减少研发周期和资源投入。

（2）业务需要的路由模式更新后，只需组装和注册新的路由方案实例即可，系统会实时将新的路由方案实例推送到执行引擎，实现动态更新，提高系统的路由方案热部署能力。当业务需要频繁切换路由模式时，这种动态能力的作用是非常强大的。

（3）不同的业务对应不同的路由方案实例，运行时这些实例通过上下文彼此隔离。当某个路由方案实例的实现细节变化时，只需要提供变化的模块，重新组装路由方案即可，不会对其他的路由方案实例产生影响，增加业务隔离性，支持不同业务的快速发展。

（4）路由方案通过可视化方式进行管理，极大提高方案的组配效率；对路由方案实例进行监控，可及时发现关键业务的路由情况，提高关键业务的路由执行效率。

以上描述的仓配路由装置与之前描述的仓配路由方法的处理是对应的，因此，关于其具体细节，可以参见之前描述的仓配路由方法，这里不再赘述。

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

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

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

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (18)

1.一种用于业务处理过程中的仓配路由的方法，其特征在于，包括：

响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数；

根据所述业务场景属性，确定与所述业务对应的路由方案实例；以及

根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。

2.根据权利要求1所述的方法，其特征在于，所述路由方案实例包括一个或多个路由规则和所述路由规则之间的关联关系，所述路由规则包括一个或多个路由元素和所述路由元素之间的关联关系，所述路由元素包括原子级别的路由逻辑。

3.根据权利要求2所述的方法，其特征在于，所述路由元素包括以下中的至少一种：业务对象校验逻辑、库存校验逻辑。

4.根据权利要求1所述的方法，其特征在于，所述业务场景属性包括以下中的至少一种：垂直市场、渠道、路由契约。

5.根据权利要求1所述的方法，其特征在于，所述业务路由参数包括以下中的至少一种：收发地址信息、业务对象信息、路由契约信息。

6.根据权利要求1所述的方法，其特征在于，所述根据所述业务路由参数执行所述路由方案实例以得到针对所述业务的仓配路由结果的步骤，进一步包括：

根据所述业务路由参数，组装路由上下文；

获取所述路由方案实例中的路由规则链；以及

根据所述路由上下文，执行所述路由规则链，以得到针对所述业务的仓配路由结果。

7.根据权利要求1-6中任一项所述的方法，其特征在于，还包括：

根据业务需求，更新所述业务场景属性以及与所述业务场景属性对应的路由方案实例。

8.根据权利要求7所述的方法，其特征在于，更新所述路由方案实例的步骤，进一步包括：

更新所述路由方案实例中的路由规则和路由规则之间的关联关系。

9.根据权利要求8所述的方法，其特征在于，更新所述路由规则的步骤，进一步包括：

更新所述路由规则中的路由元素和路由元素之间的关联关系。

10.一种用于业务处理过程中的仓配路由的装置，其特征在于，包括：

解析模块，用于响应于针对业务的仓配路由请求，对所述业务进行解析处理，以获得业务场景属性和业务路由参数；

确定模块，用于根据所述业务场景属性，确定与所述业务对应的路由方案实例；以及

执行模块，用于根据所述业务路由参数，执行所述路由方案实例，以得到针对所述业务的仓配路由结果。

11.根据权利要求10所述的装置，其特征在于，所述路由方案实例包括一个或多个路由规则和所述路由规则之间的关联关系，所述路由规则包括一个或多个路由元素和所述路由元素之间的关联关系，所述路由元素包括原子级别的路由逻辑。

12.根据权利要求11所述的装置，其特征在于，所述路由元素包括以下中的至少一种：业务对象校验逻辑、库存校验逻辑。

13.根据权利要求10所述的装置，其特征在于，所述业务场景属性包括以下中的至少一种：垂直市场、渠道、路由契约。

14.根据权利要求10所述的装置，其特征在于，所述业务路由参数包括以下中的至少一种：收发地址信息、业务对象信息、路由契约信息。

15.根据权利要求10所述的装置，其特征在于，所述执行模块进一步包括：

组装子模块，用于根据所述业务路由参数，组装路由上下文；

获取子模块，用于获取所述路由方案实例中的路由规则链；以及

得到子模块，用于根据所述路由上下文，执行所述路由规则链，以得到针对所述业务的仓配路由结果。

16.根据权利要求10-15中任一项所述的装置，其特征在于，还包括：

更新模块，用于根据业务需求，更新所述业务场景属性以及与所述业务场景属性对应的路由方案实例。

17.根据权利要求16所述的装置，其特征在于，所述更新模块进一步包括：

更新子模块，用于更新所述路由方案实例中的路由规则和路由规则之间的关联关系。

18.根据权利要求17所述的装置，其特征在于，所述更新子模块进一步包括：

元素更新子模块，用于更新所述路由规则中的路由元素和路由元素之间的关联关系。