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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

看了这么多，那这个产品到底是如何完成的呢，其中的原理和亮点分别是什么，让小分队的成员带领我们来一窥究竟。

提高交付效率、保证交付质量，扩大交付角色，是业界追求的最高目标，也是是小彭及其小分队追求的最终目标。为保障产品功能可安全、可靠的交付给业务角色，小分队探索出了一个带可视化界面、研发和产品可共同参与开发的通用性规则平台，并在平台内设定了一系列的规范化约定，计划提供沙箱模式、录制与回放验证等机制来保证交付的质量，并提升联调与验证的效率。

而其核心原理，简而言之可以表述为：平台提供可视化设计器，业务角色在可视化界面沉浸式式编排业务规则，即可完成所有业务功能的新增、变更、修改与发布。与之相对应的，平台在功能后台自动生成规则引擎描述文件，待业务角色审核完成后自动化的同步给应用系统。应用系统通过SDK对扩展点进行拦截，并在扩展点执行生效的规则编排。

海纳低代码规则引擎工作示意图如下所示：



对于适用于业务规则类的业务场景，小分队的成员很快就发现存在共性特点：“当满足部分特定业务条件时，执行特定业务动作的一组规则集合”。

小分队成员对此特点深入研究，发现市面上常见的规则引擎提供的技术规则内容太深奥、太专业，对于普通的业务人员理解难度太高，导致市面的规则引擎产品主要在研发内部使用。为解决这一难题，小分队在平台中除了提供纯技术规则注册外，还提供了业务规则注册与组合编排。使得平台的用户不光可以覆盖至研发角色，还可以覆盖至业务角色。业务交付需求时，只需关注其业务规则与业务编排，而其背后支撑的复杂技术规则则可完全对业务角色透明。最终业务像画流程图一样在平台进行操作即可自助式完成需求交付。

伴随着需求的交付个数的增长，系统中的业务规则和业务行为不断地扩充，后续的需求交付可复用之前沉淀确定的业务规则，包括如“自营”、“厂直”、“医药”等统一的业务含义，均可统一在后续需求进行复用。可进一步提升交付速度。

下边我们以一个实际的例子展示下海纳规则引擎的主要特色功能。为了让大家有直观的感受可视化规则编排和执行过程，先展示下规则编排结果：



从规则流程图可以看到主要的元素就是菱形和矩形。菱形表示条件，类似于我们代码中的if；而矩形则是动作，就是我们具体做的一个动作，比如更新数据库、远程接口调用等任何想做的事。

那么规则流程是如何被编排出来，编排出来后又是如何运行的呢？下图描述了主要过程。



注册扩展点：

扩展点是规则要执行的切入点，在平台注册扩展点后，可围绕该扩展点进行业务规则流程编排。

业务模型注册：

业务模型是业务数据的载体，确保引擎正确识别并访问模型以进行逻辑运算；

技术规则注册：

主要面向研发人员，主要包括方法的签名信息，和系统中的代码方法对应，提供最基础的规则。

平台还内置了丰富的技术规则，如下图所示，对于一般业务而言，预制的规则可以满足80%及以上的场景。对于其余个性化场景，平台也提供了可扩展的能力。



业务规则注册：



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



业务规则编排：

对业务规则进行组合，以流程图的方式展现业务流程，最终形成规则流程描述文件。

规则引擎执行：

SDK将规则流程描述文件解析成规则引擎能执行的脚本，规则引擎通过执行脚本完成业务规则的运行。

小结：

对业务角色而言，海纳平台提供可视化规则编排能力，业务规则主要是由具有业务语义化的条件规则和动作规则组成，因此产品业务人员可以轻松地自助完成业务规则编排。随着规则丰富度持续提升，业务人员也可以对已有规则进行组合或通过自定义规则方式实现新业务规则创建，实现全面自助。

对于研发角色而言，应用系统只需引入SDK并定义要执行规则扩展点即可完成集成工作。后续需求业务实现自助化交付后，整个交付的过程从原来的10天，可缩短至最快0.5天，达成了提效的目的。

海纳规则引擎以对业务系统无侵入，只需引入规则引擎SDK，添加注解即可完成接入，对于存量系统具有友好的支持。一般而言，1天即可快速完成集成工作。

海纳平台是去中心化的设计，平台只负责流程编排，编排后的结果以流程描述文件的方式同步给业务系统，应用系统通过SDK解析并执行，采取本地化执行方式，没有性能瓶颈，并通过了京东订单履约核心系统11.11大促验证。平台提供的能力支持峰值一天处理超亿级订单平稳运行，单个规则运行的耗时在纳秒级别内完成。

海纳规则引擎将研发角色和业务角色分离，在技术领域和业务领域间建立规则适配，屏蔽技术细节，让业务角色更关注业务规则，提高业务角色的使用体验。

面向业务语义的流程编排，流程的编排可以向画流程图一样方便，实现所见即所得的业务体验。

通过在平台上注册业务规则和业务行为，可实现技术资产沉淀，随着业务规则的扩充，可支持更为丰富的业务流程。

时间又回到了当下，产品小李找到了小彭，同步了近期业务提过来的几个需求，均已经在海纳规则引擎低代码平台自助化实现了，单个需求差不多5到10分钟即可完成配置，全程在平台上沉浸式操作即可。但最终上线需要小彭帮忙审批一下。仔细检查了业务规则条件，确认业务逻辑符合预期后，小彭快速移动鼠标，轻轻点击了“发布生效”，新配置的规则就如同打一个响指一样，秒级的速度就更新至线上生产环境，并全面运行了。送走小李后，小彭看着线上平稳的监控曲线出神，这个手段确实挺有效，省去了需求评审、业务功能开发、业务功能内部测试的时间，业务角色可以快速自助化交付。那么其余60%的需求如何提效呢？是否有其他的解决方案呢？小彭又陷入了沉思。

看到了这里，您是不是对海纳规则引擎低代码平台有了更多的了解了呢？您在日常的工作中，是否遇到了类似的场景，可以复用此解决的方案么？如果有，欢迎多多交流。

在项目需求日趋增加，而人力资源逐步成为瓶颈的时候，采用多种方式来达成提效的效果，是摆在所有人面前的一个难题。希望本文章可以以一个视角和解决方案，以抛砖引玉的方式，引起大家更多的共鸣和思考。