规则引擎及架构设计 | 青训营笔记

llx
114 阅读7分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天

规则引擎设计与实现

目标：

  1. 理解规则引擎的组成部分及应用场景
  2. 理解核心原理-编译原理的概念
  3. 设计并实现一个规则引擎-youngEngine
  4. 实现一个web版规则引擎

组成及实现原理

在设计逻辑的时候，需要通过设计规则引擎来实现优化！

定义

一种嵌入在应用程序的组件，实现将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策，接受数据输入，解释业务规则，并根据业务规则作出业务决策。

解决：

  • 开发人员重复编码的问题
  • 业务决策与服务本身解耦，提高服务的可维护性
  • 缩短开发路径，提高效率

组成部分

  1. 支持接收使用预定义的语义编写的规则作为策略集
  2. 能够按照预定义的词法、语法、优先级、运算符等正确理解业务规则所表达的语义
  3. 根据执行时输入的参数对策略集的规则进行正确的解释和执行，同时对执行过程中的数据类型进行检查，确保执行结果准确

应用场景

  1. 风控对抗：与黑灰产业对抗过程中，策略研发和产品需要能够根据黑灰产特征进行快速识别和对抗
  2. 活动策略运营：根据用户效果反馈进行运营策略的优化和调整
  3. 数据分析和清洗：使用规则引擎便捷的实现对数据进行整理、清洗和转换

编译原理基本概念

词法分析

把源代码字符串转换为词法单元（token）这个过程

有限自动机：状态机，状态数量有限，该状态机在任何一个状态基于输入的字符都能做一个确定的状态转换

语法分析

在词法分析的基础上识别出表达式的语法结构

抽象语法树：

  • 上下无关语法：语言句子无需考虑上下文就可以判断正确性
  • 内置符号：字面量(string、bool、number)标识符、运算符
  • 递归下降算法：自顶向下构造语法树，不断的对token进行语法展开

image-20230201005330365.png

类型检查

验证执行的结果是否为合适的数据类型，在抽象语法中通常会验证某子节点的数据类型是否合法

类型综合：根据子表达式的类型构造出父表达式的类型

编译时检查和运行时检查：可以在构造语法树的阶段或者数据交互阶段

  • 编译时：提前声明参数类型，在构建语法树过程中进行类型检查
  • 执行时：根据执行时的参数输入的值类型

参数注入：在规则执行过程中使用输入的参数值来计算语法树中标识符节点值的过程

设计规则引擎

支持特定的词法、运算符、数据类型和优先级，并且支持基于以上预定义语法的规则表达式的编译和执行

词法（合法token）

  • 参数：由字母数字下划线组成
  • 布尔值
  • 字符串
  • 十进制int
  • 十进制float
  • 预定义运算符：+ -

运算符

  • 一元运算符：+ -
  • 二元运算符：+ - * / % > < >=
  • 逻辑运算符：&& || ！
  • 括号：（ ）

数据类型

  • 字符串
  • 布尔值
  • 十进制int
  • 十进制float

优先级

优先级运算符
0
1&&
2! + -
3> < >= !=
4+ -
5* /
6( )

语法树执行:

  • 先执行左子树得到左节点的值
  • 再执行右子树得到右节点的值

架构定义

架构又称软件架构

  • 用于指导软件系统各个方面的设计
  • 软件整个结构与组件的抽象描述

单机： 把所有功能都实现在一个进程里并部署在一台机器上

单体架构：分布式部署

垂直应用架构：按应用垂直切分的单体

优点：

  • 水平扩容
  • 运维不需要停服

问题：

  • 开发效率不高

SOA面向服务架构

将进程按照不同的功能单元进行抽象拆分为服务，并为服务之间的通信定义了标准

优点：

  • 各服务的职责更清晰
  • 运维粒度减小到服务

缺点：

  • 企业服务总线（ESB）需要一整套解决方案

微服务

微服务：强调的是服务的大小，关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用

微服务架构：一种新的架构形式，提倡将单一应用程序划分为一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。

1.什么是微服务？

2.微服务之间怎么进行通信的？

  • http通信协议、RPC通信

优点：

  1. 每个服务足够内聚，足够小，聚焦到一个指定的业务功能或业务需求
  2. 开发简单，开发效率提高，一个服务可能就是专一干某件事
  3. 微服务能够被小团队单独开发
  4. 微服务是松耦合的，无论在开发阶段还是部署阶段都是独立的
  5. 微服务只是业务逻辑的代码，不会和HTML、CSS或其他界面混合
  6. 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库

缺点：

  1. 开发人员要处理分布式系统的复杂性
  2. 多服务运维难度，随着服务的增加，运维的压力也增加
  3. 系统部署依赖
  4. 服务间通信 成本
  5. 数据一致性

云计算

云计算架构：

  • 云服务

    • IaaS - 云基础设施，对底层硬件资源池的抽象
    • PaaS - 基于资源池抽象，对上层提供的弹性资源平台
    • SaaS - 基于弹性资源平台构建的云服务
    • FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流

  • 云部署模式（拓展）

    • 私有云 - 企业自用
    • 公有云 - AWS/Azure/Google Cloud/Huawei
    • 混合云

云原生

云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。 它的代表技术：

  • 弹性资源

    • 虚拟化容器
    • 快速扩缩容

  • 微服务架构

    • 业务功能单元解耦
    • 统一的通信标准

  • DevOps

    • 敏捷开发
    • CI/CD

  • 服务网格

    • 业务与治理解耦
    • 异构系统的治理统一化
    • 复杂治理能力

弹性计算资源：

  • 计算资源调度

    • 在线计算 - 互联网后端服务
    • 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk

  • 消息队列

    • 在线队列 - 削峰、解耦
    • 离线队列 - 结合数据分析的一整套方案，如 ELK

弹性存储资源：

  • 经典存储

    • 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
    • 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验

  • 关系型数据库

  • 元数据

    • 服务发现

  • NoSQL

    • KV 存储 - Redis
    • 文档存储 - Mongo
服务网格

什么是服务网格？

  • 微服务之间通讯的中间层
  • 一个高性能的 4 层网络代理
  • 将流量层面的逻辑与业务进程解耦

没有什么是加一层代理解决不了的问题，服务网格相比较于 RPC/HTTP 框架：

  • 实现了异构系统治理体验的统一化
  • 服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理
avatar
文章
阅读
粉丝