蛮荆

业务规则引擎演变过程简述

2023-08-07

概述

技术实现的角度,规则引擎的功能就是布尔表达式的解析和求值过程,外加建立在求值结果之上的工作流。 业务使用的角度,规则引擎就是运营人员可以独立快速操作业务逻辑规则并且影响到最终的用户。

# 规则引擎的典型语法

rule  <rule_name> <rule_description>
   <attribute> <value> {
   when
      <conditions>
   then
      <actions>
}

常见场景

  • 网页中的保险广告: 根据各种条件最后计算出你的投保金额
  • 网约车: 根据车型、天气、目的地、拥堵情况等计算出价格
  • 网上购物: 会员、优惠券、店铺活动等计算订单价格
  • 网站内容反爬虫: IP、访问频率、浏览行为模式等判定客户端是否为正常用户

演变过程

下面简单概括下常规的规则引擎的演变过程,以及过程中开发人员和运营人员的不同分工。

代码

在这个阶段,业务规则全部由开发人员完成,运营有任何变更,都需要找到开发经历开发 -> 测试 -> 生产的过程,沟通加具体的工作量要花掉可观的时间, 而且系统的业务规则没有任何灵活性,今天应该没有公司这么干了,不过作为上古的工作模式,这里简单提一下。

代码更改业务规则阶段

服务

根据不同的业务规则进行分类,所有请求统一由业务引擎代理转发到不同的服务,代理同时也需要处理认证和鉴权,例如根据用户的会员等级转发到不同的服务。 在这个阶段,业务规则全部由开发人员完成,但是和上一阶段不同的地方在于: 业务引擎代理将代码中公共逻辑和具体业务逻辑进行了分离,如果运营策略有变化, 开发人员只需要修改规则引擎代理即可,不会污染到其他服务模块代码。

自动配置

将业务规则抽离出来保存到配置中,这里的配置可以是文本配置文件、代码配置文件,也可以是通过管理后台操作并最终保存到数据库的配置信息。

在这个阶段,开发人员需要和运营人员提前写好所有的业务规则,虽然已经有了自动化的基本雏形,但是灵活度还远远不够 (例如 10 点刚写完业务规则,11 点又想到几个新的规则…)。

图片来源: https://g.alicdn.com/aic/aep-docs/1.6.1/ze9s2o.html

表达式解析

使用定义好的布尔表达式替换掉代码中的 if else 语句,业务逻辑代码只需要对具体的布尔表达式求值,然后根据求值结果来执行不同的操作。

这里以 Go 语言生态的 govaluate 组件来做演示,其 Github 的主页上面的简介: 可以对任意的 Go 表达式语句求值。

例如在一个视频网站中,我们可以根据用户是否 VIP 来决定播放视频广告。

// 获取用户信息
user := getUserInfo()

expression, err := govaluate.NewEvaluableExpression("user.level > 0")
isVip, err := expression.Evaluate(nil)

if err != nil {
	panic(err)
}

if isVip {
	// 不播放广告
} else {
	// 播放 60s 广告
}

在这个阶段,业务规则可以随时更新,但是必须要由懂系统/服务实现编程语言的人员来编写规则,大部分情况下,业务规则依然全部由开发人员完成。

对于 govaluate 组件内部将表达式编译为 AST 的过程感兴趣的读者可以看看 这篇文章

DSL

针对特定领域的语言,也就是专门解决某个特定领域的问题,分为内部 DSL 和外部 DSL,规则引擎中用到的都是外部 DSL,主要是给开发人员和经过培训的其他岗位人员。

图片来源: https://g.alicdn.com/aic/aep-docs/1.6.1/ze9s2o.html

这方面的例子太多了,我们日常使用的编程语言和数据库 SQL 语句本质上都是高度抽象的 DSL :-)

ElasticSearch 全文搜索

# 全文搜索 hello world

GET /xxx/yyy/_search
{
    "query" : {
        "match" : {
            "about" : "hello world"
        }
    }
}

Prometheus 聚合操作

# 计算 HTTP 请求总量

sum(http_requests_total)

在这个阶段,开发人员和运营人员大部分情况下分工完全独立,开发人员专注于 DSL 的丰富和完善,运营人员专注于编写各种 DSL, 但是当发布新的 DSL 语法时或者现有的 DSL 存在问题时, 开发人员和运营人员需要沟通协调。

规则引擎中台

可视化操作界面,通过点击、拖拽等操作自动生成规则并保存,运营人员只需要关注操作界面即可。

图片来源: https://g.alicdn.com/aic/aep-docs/1.6.1/ze9s2o.html

在这个阶段,开发人员和运营人员分工完全独立。开发人员专注于中台的功能建设,运营人员专注于业务策略的调整,但是系统的业务能力依然会受到以下几个因素的影响:

  • 运营人员设置的业务规则有效性
  • 业务规则设置完成到生效的实时性
  • 无法实现自动化处理 (例如紧急事件的处理周期非常短,是否能在有效时间内指定出有效的规则)

AI 构建

目前来看,最后阶段是使用 AI 模型来构建完全自动化的业务规则,完全解决规则引擎中台存在的问题。

软件定义一切,软件吞噬一切。

扩展阅读

转载申请

本作品采用 知识共享署名 4.0 国际许可协议 进行许可,转载时请注明原文链接,图片在使用时请保留全部内容,商业转载请联系作者获得授权。