履约核心引擎低代码化原理与实践

京东技术

发布于 2023-08-25 09:15:23

4610

发布于 2023-08-25 09:15:23

文章被收录于专栏：京东技术

Tech 导读规则引擎是一种嵌入在应用程序中的组件，主要解决易变逻辑和业务耦合的问题，行业上开源的规则引擎，在互联网场景使用存在诸多障碍，如高并发略显不足、更多面向技术人员、无法规模化的让规则从应用程序代码中实现分离。基于此，京东供应链研发部自研了一套，面向业务角色的海纳低代码规则引擎平台，产品定位是面向业务、研发多角色一体化的零低代码开发平台，其中规则引擎是其最核心的部分之一，本文以此为核心展开说明。

前言

业界，规则引擎是一个非常普遍的技术类工具，也有很多非常优秀的开源工具，例如Drools等，它是一种嵌入在应用程序中的组件，主要解决易变逻辑和业务耦合的问题，把易变的规则从应用程序代码中分离出来，进而提升交付效率，降低应用程序维护和可扩展性成本。

然而，行业上开源的规则引擎，在互联网场景使用却存在诸多障碍。从技术上来看，面对特大流量的高并发略显不足；从交付上看，操作语言是以研发视角，无法让更多的非技术人员参与来实现交付链条的最大化降低；从实施上，也没有配套的标准化架构开放规范，无法规模化的让规则从应用程序代码中实现分离。

基于此，京东供应链研发部自研了一套，面向业务角色的海纳低代码规则引擎平台，产品定位是面向业务、研发多角色一体化的零低代码开发平台，这其中规则引擎是其最核心的部分之一。

这个平台，不仅可以高效的支持互联网高并发业务，它还具有一套标准化扩展开放的能力。基于此业务系统可以快速实现业务规则的规模化开放，短短4个月内，低成本开放了近100+个扩展点，抽取沉淀了近400+个业务规则，支持了14+个京东核心链路重大项目，产品经理/ISV也首次以无代码的方式，在安全清晰的工作边界内，自助式的完成京东核心链路的业务需求，平均交付周期0.5天内。

另外，从长远来看，它把研发职能进行转移及拓宽，以安全的模式让更多的角色参与研发，进而优化了需求的交付模式，为后续生态规模化的交付奠定了基础。

JD履约的应用

2.1 现状

海纳低代码规则引擎平台在履约已大规模运用，初步达成了约20%的需求可由业务角色来直接交付，预估后续此比例可提升至40%。和其他平台的发展情况一样，海纳的发展过程也相当惊心动魄。下面就以一个独特的视角、简短的语言展开说明。

一个阳光明媚的早上，初级工程师小徐背着军绿色的双肩包，前脚刚从满满当当的电梯里面出来，还没来得及走到工位边脱下厚重的羽绒服。“铃铃铃”的电话声音就响起了，是对应业务条线的产品小李打过来的。“不会昨天晚上上线有什么问题吧”，小徐揉了下微微发胀的太阳穴，不安的接起电话，很快就放下心来，昨天上线的业务已验收没问题了，是一个新的业务诉求要去满足。

快速沟通后，小徐明白了大致想要做的事情。商城上新引入了一批高端的时尚化妆品品牌，业务侧将货物入仓并在APP上开始售卖后，客户同时或者分开购买这批化妆品后，这些货物在出库履约生产的时候，物流会建立单独的生产业务线，为不同品牌的化妆品单独包装，并放置到品牌独立的包装礼盒中。期望在配送给客户的时候，使用精美的礼盒也可以加强客户的感知，提升用户体验。

小徐工作已三年，听完这个需求后，大脑中已构思出了大致的实现方案了。这个需求简单，不就是配置一批特殊的品牌增加特殊的业务处理规则么，几行if代码就可以搞定了，前两天刚实现了个类似的需求。刚想完，小徐就打开代码编辑器，眼睛盯着那几百行多个if else分支的代码，想着加到哪个地方最合适。

想着正出神，电话再次响起，还是产品小李，这个需求的优先级提高了，业务希望今天就可以给出排期计划，小徐预估了大致的工作，认为应该可以满足预期。和小李确定了下午需求评审会时间，并顺手将该任务加到了待办列表中，看到这周工作安排：上线的需求就有4个，突破了以前每周处理2个的平均值了。看来今天晚上要加加班了，不然干不完。小徐戴上帽子，遮住了有点稀疏的脑门，抿了一口黑咖啡，全心开始工作了。

几天后，另外一个角落里，核心架构师小彭和其他几个产品、业务聚在一起，对最近排期不满足的情况进行沟通。讨论是否有合适的方式可以提升交付的速度，降低排期不满足的概率。甚至个别业务还提出来，有没有什么工作是可以分出来交给他们来做的。嗯，这是一个有意思的方向。小彭记下了这个关键的内容，开始认真琢磨有无好的办法。小彭从来就不是一个空想派，说干就干。从项目文档中拿出了近3年的项目及需求列表，从头梳理其实现方式，评估需求的共性及特点。

2.2 挑战

小彭带领团队，重新审视了最近收到的项目及需求，发现约有40%的需求相似性比较高，需求抽象后基本可以描述为“基于一定组合的业务条件下”、“执行特定领域的业务动作”。看起来和规则引擎的匹配度相当高。但是综合分析后，发现实施难度存在2类挑战，均需要有对应的解决方案。

性能挑战：小彭负责的业务领域有点特殊，所有商城的每一个订单都会流向他负责的系统，峰值时一天处理超亿级订单。传统意义上的规则引擎，应用的都是低流量的业务场景。在这种大数据量，高并发的场景下，怎么保障性能是个问题，需要有对应的解决方案。

价值挑战：引入成熟的规则引擎，假定可以解决目前的应用场景。但是一般规则引擎都会有其独立的领域描述语言（DSL Domain Specific Language），这类语言的使用门槛一般都比较高，交给研发人员维护还处于勉强可以接收的程度，交给产品或者业务人员去维护，初步看可能性较低。那么引入规则引擎后，如何实现一种方案，可以让产品、业务、研发均可以快速参与进来，均可以使用此产品功能进行快速交付，就是此产品要解决的核心问题了。

2.3 方案

经过几天连夜的奋战，小彭总算敲定了具体的可行性方向，与上级主管沛公约好了汇报讨论的时间。与前几天心惊肉跳的讨论不同，在大的讨论开始之前，小彭的心反而没有那么紧张了。小彭就是这样，越是难的事情，越觉得有挑战。即使再难的事情，在心里过一过，总可以想得明白。他是使万物回归其本源，而种子总能突破土地的束缚，慢慢长成谁也无法阻挡的参天大树。

落地层面，小彭从来不担心。虽然可以预判到实施的过程中会有这样或那样的难题。但小彭和其合作团队的战斗力，是小彭信心高昂的一切来源。这是一支不同寻常的团队，支撑的也是不同寻常的业务。业务上，小彭负责了商城所有订单的履约生产过程，为每一个订单实时高效的制定好最优的生产计划，在过程中发出多个如拆单、转仓、补货等多个快速指令，为在商城中消费的每一个客户提供最优服务，并最大可能性的降低履约生产过程中的生产成本。过去多次并肩作战与冲锋，早就锻造了这支团队独特的战斗力。

和沛公的交谈如预期中顺利，但沛公说他还是要再认真考虑一下。是的，是要认真考虑一下，成熟的人总是要三思而后行，而一但确定好后就毫不犹豫的坚决执行。这个事情，风险和收益同样巨大。干得好则后面研发交付的工作可以发生变革式的变化，产品、业务来完成需求交付不再是个可望而不可及的事情；干得不好，比如过程中遇到了无法突破的难题，或者交付后出现业务使用不佳的情况，辛辛苦苦投入的精力可能就会存在白费的情况，特别是面对如此高的交付压力，一旦失败，对上对下，都不好交代。

变革的过程总是很痛苦，而有先见之明的人在经历痛苦后才能有机会涅槃重生。做，还是不做，这是一个摆在沛公面前的难题。在经过一个晚上的深思熟虑后，沛公心中就有了预判和决断。这个事情是一个长期的事、有价值的事、正确的事，现在不做，将来也会要做。等将来项目及需求的压力变得不可阻挡，不得不做的时候，重重压力下执行的动作反而会变形。最好的时机就是当下，沛公已暗暗下定了决心。至于困难，总会有的，但是只要信心在，办法总比困难多。敢于冲锋，直面失败，这也是这个团队难以磨灭的特质。

沛公找到了供应链负责整体效能同时身为首架的林老师沟通。林老师最近也一直在思考，如何将供应链高频共性的研发动作进一步抽象、打造出合适的Y工具产品，并将工具提供开放给业务角色，来降低研发的需求数，提升交付效率，部门也一直在做这样的探索，正好最近零（低）代码解决方案也初步有了成果，与沛公提到的想法不谋而合。两个部门立刻决定，共同推进落地。

一个小的分队很快就成立了，两个团队都挑选了一些精兵强将，共同负责功能的设计、开发及运维，具体带队的分别是小丽、小徐、小彭，总体架构师是林老师，部门中一些架构师和研发也自愿踊跃参加，例如小孙、小马、小丁、小梦、小张、小喜等。大家除了日常需要支持的本职工作外，其余的时间都扑在了这个新产品能力的打造上了。和一般伟大的事业开启必然附加有华美的篇章不同，研发的工作总是这样，朴实而无华。没有激情澎湃的赞歌，也没有千里不留行的豪迈，只是一个接一个的不眠之夜。看似枯燥的工作，和冷冰冰的代码，但总难浇灭大家心中火热的激情。每每深夜里有一些灵光乍现的新思路，每个人总会赶紧拿手机记下来，再倒头躺下。想到新的一天可以和团队一起，讨论新的思路和落地方式，大家按捺不住激动的内心，久久不能入睡。

一个月后，产品雏形已初步完成，小彭拉上业务线对口的产品和业务来试用，算是毁誉参半，小彭没有泄气，收集了大家的问题和反馈，并开始快速迭代。又半个月过去，产品总算达到了可用、可交付的状态。经过一段时间的试点使用后，一些业务、产品开始主动来寻求合作和反馈。总算形成了正向反馈。

03 核心原理介绍

以上阐述了很多，那这个产品到底是如何完成的呢，其中的原理和亮点分别是什么？提高交付效率、保证交付质量、扩大交付角色，是业界追求的最高目标，也是小彭及其小分队追求的最终目标。为保障产品功能可安全、可靠的交付给业务角色，小分队探索出了一个带可视化界面、研发和产品可共同参与开发的通用性规则平台，并在平台内设定了一系列的规范化约定，计划提供沙箱模式、录制与回放验证等机制来保证交付的质量，并提升联调与验证的效率。而其核心原理，简而言之可以表述为：平台提供可视化设计器，业务角色在可视化界面沉浸式式编排业务规则，即可完成所有业务功能的新增、变更、修改与发布。与之相对应的，平台在功能后台自动生成规则引擎描述文件，待业务角色审核完成后自动化的同步给应用系统。应用系统通过SDK对扩展点进行拦截，并在扩展点执行生效的规则编排。

图1.海纳低代码规则引擎工作示意图对于适用于业务规则类的业务场景，小分队的成员很快就发现存在共性特点：“当满足部分特定业务条件时，执行特定业务动作的一组规则集合”。小分队成员对此特点深入研究，发现市面上常见的规则引擎提供的技术规则内容太深奥、太专业，对于普通的业务人员理解难度太高，导致市面的规则引擎产品主要在研发内部使用。为解决这一难题，小分队在平台中除了提供纯技术规则注册外，还提供了业务规则注册与组合编排。使得平台的用户不光可以覆盖至研发角色，还可以覆盖至业务角色。业务交付需求时，只需关注其业务规则与业务编排，而其背后支撑的复杂技术规则可完全对业务角色透明。最终业务像画流程图一样在平台进行操作即可自助式完成需求交付。伴随着需求交付个数的增长，系统中的业务规则和业务行为不断地扩充，后续的需求交付可复用之前沉淀确定的业务规则，包括如“自营”、“厂直”、“医药”等统一的业务含义，均可统一在后续需求进行复用，可进一步提升交付速度。下面以一个实际的例子展示海纳规则引擎的主要特色功能。为了让读者有直观的感受可视化规则编排和执行过程，先展示规则编排结果：

图2.可视化规则编排结果从规则流程图可以看到主要的元素就是菱形和矩形。菱形表示条件，类似于代码中的if；而矩形则是动作，就是具体做的一个动作，比如更新数据库、远程接口调用等任何想做的事。那么规则流程是如何被编排出来，编排出来后又是如何运行的呢？

图3.可视化规则编排主要过程 注册扩展点： 扩展点是规则要执行的切入点，在平台注册扩展点后，可围绕该扩展点进行业务规则流程编排。 业务模型注册： 业务模型是业务数据的载体，确保引擎正确识别并访问模型以进行逻辑运算。 技术规则注册：

图4.注册页面展示主要面向研发人员，主要包括方法的签名信息，和系统中的代码方法对应，提供最基础的规则。平台还内置了丰富的技术规则，如下图所示，对于一般业务而言，预制的规则可以满足80%及以上的场景。对于其余个性化场景，平台也提供了可扩展的能力。

图5. 预制规则展示 业务规则注册：

图6.业务规则注册业务规则是对技术规则或业务规则的组合，形成具有业务语义的规则，最终用于业务规则流程编排。为了实现复杂业务条件，提供了and/or/not/group等多种组合形式，方便业务灵活配置。

图7.组合形式展示 业务规则编排：

图8.业务规则编排对业务规则进行组合，以流程图的方式展现业务流程，最终形成规则流程描述文件。 规则引擎执行： SDK将规则流程描述文件解析成规则引擎能执行的脚本，规则引擎通过执行脚本完成业务规则的运行。 小结： 对业务角色而言，海纳平台提供可视化规则编排能力，业务规则主要是由具有业务语义化的条件规则和动作规则组成，因此产品业务人员可以轻松地自助完成业务规则编排。随着规则丰富度持续提升，业务人员也可以对已有规则进行组合或通过自定义规则方式实现新业务规则创建，实现全面自助。对于研发角色而言，应用系统只需引入SDK并定义要执行规则扩展点即可完成集成工作。后续需求业务实现自助化交付后，整个交付的过程从原来的10天，可缩短至最快0.5天，达成了提效的目的。