🏢复杂业务模型抽象架构
type
status
date
slug
summary
tags
category
icon
password
Status
- “做什么决策？” —— 策略引擎负责回答这个问题。
- “呈现什么顺序？” —— 排序架构负责回答这个问题。
- “按什么步骤做？” —— 流程引擎/任务系统负责回答这个问题。
几乎所有复杂的业务逻辑，都可以被拆解或组合成这三种模型的应用。
1. 策略引擎 (Policy/Strategy Engine)
这是“满足了哪些条件，就可以命中哪些结果”的模式。它的核心是将易变的业务规则（策略）与相对稳定的系统代码分离开来。
核心思想
定义一系列规则（条件），当输入的数据（事实）满足这些规则时，系统执行相应的动作或返回特定的结果。A/B测试、风控引擎的原理。
典型应用场景
- 风控系统：用户注册、登录、交易、发帖等行为，命中不同风险等级的规则，从而触发拦截、验证码、人工审核等不同操作。
- 营销活动：用户满足地域、会员等级、历史消费行为等条件，即可命中优惠券、折扣、弹窗提醒等营销策略。
- A/B测试与灰度发布：根据用户ID、设备信息、地理位置等，将用户分流到不同的实验组，下发不同的产品策略（UI、算法、业务逻辑等）。
- 访问控制（Authorization）：用户拥有什么角色、属于哪个部门，决定了他能访问哪些资源、执行哪些操作。
- 内容分发：根据用户画像和内容标签，决定向用户推荐哪一类内容。
涉及的关键技术和知识点
- 规则定义与管理
- 领域特定语言 (DSL - Domain-Specific Language)：为业务人员（如风控、运营）设计一套简单易懂的语言来描述规则，例如
user.level == 'VIP' AND order.amount > 1000。 - 可视化规则编辑器：提供拖拽式的界面，让非技术人员也能配置复杂的规则逻辑。
- 规则版本控制与生命周期管理：规则的上线、下线、回滚、版本对比等。
- 规则引擎核心 (Rule Engine)
- 匹配算法：最经典的是 Rete 算法，它能高效地对大量规则和事实进行匹配，避免重复计算。需要理解其工作原理（Alpha 网络、Beta 网络）。
- 规则的编译与执行：DSL或可视化配置如何被解析成可执行的代码（例如动态生成Java/Groovy/Python代码，或解析成字节码）。
- 无状态 vs 有状态：风控场景通常是无状态的（一次请求，一次决策），而一些流式处理场景可能需要有状态的引擎（持续跟踪事件流）。
- 事实 (Facts) 的管理
- 数据集成：如何实时或准实时地获取决策所需的各种数据（用户画像、行为日志、订单信息等）。
- 特征工程：将原始数据加工成规则引擎可以理解和使用的“事实”或“特征”。
- 与A/B测试的结合
- 流量分割：如何设计稳定、正交的流量分割算法，保证实验组之间互不干扰。
- 实验层/域：管理不同业务线上的实验，避免冲突。
- 指标系统：配套的数据上报和分析系统，用于评估实验效果。
高度抽象的模型:
+-------------------+
输入数据 -> | 特征/事实提取 | -> [事实集合]
+-------------------+
|
v
+----------------+ +-----------------------+ +-------------------+
| 规则/策略仓库 | -> | 规 则 引 擎 | -> | 决策结果/动作 |
| (DB, Config) | | (Rete算法, DSL解析) | | (通过, 拒绝, 发券) |
+----------------+ +-----------------------+ +-------------------+
^
|
+-------------------+
| A/B实验分流模块 |
+-------------------+2. 排序架构 (Ranking Architecture)
理解得非常准确：“算法模型给出来的结果，它不一定精确，他需要 的是后端工程再去手动的（干预）”。这完美描述了“搜广推”中的重排（Re-ranking）阶段。
核心思想
对一个候选结果集合（召回集），通过多阶段的过滤和排序模型，结合业务规则的强行干预，最终生成一个最优的、满足业务多样性需求的有序列表。
典型应用场景
- 搜索引擎：搜索结果页的排序。
- 推荐系统：淘宝的“猜 喜欢”、抖音的视频流、B站的首页推荐。
- 广告系统：广告的排序，不仅要考虑预估点击率（eCPM），还要考虑出价和预算。
- 电商列表页：商品列表的默认排序、按销量/价格排序。
涉及的关键技术和知识点
- 召回 (Recall)
- 多路召回：通过多种方式拉取可能相关的物品。例如：协同过滤、基于内容的召含、向量相似度搜索（ANN）、热门召回等。
- 这是排序的输入源，目标是“全”，保证相关内容不被漏掉。
- 粗排 (Pre-ranking / Coarse Ranking)
- 使用简单、计算快的模型，从数万或数十万的召回集中，快速筛选出几百到几千个高质量的候选集。
- 目标：在保证一定精度的前提下，大幅减少后续精排的计算压力。
- 精排 (Fine-ranking)
- 核心算法阶段。使用复杂的机器学习/深度学习模型（如
Wide & Deep,DeepFM,Transformer等）对粗排结果进行精准打分。 - 会用到大量精细化的特征（用户侧、物品侧、上下文、交叉特征）。
- 目标：追求排序的“准”，即预估点击率、转化率、播放时长等指标的准确性。
- 重排/混排 (Re-ranking / Blending)
- 提到的“后端手动干预”主要发生在此层。
- 在精排结果的基础上，应用一系列业务规则，进行最终的调序。
- 常见策略：
- 打散 (Diversity)：避免同类型或同店铺的商品/内容扎堆出现。
- 去重 (Deduplication)：过滤掉用户近期已经看过或消费过的内容。
- 强插/置顶 (Forced Insertion / Pining)：将运营指定的内容（如活动banner、必推新闻）插入到特定位置。
- 提权/降权 (Boosting / Deboosting)：提升新品、高利润商品的权重；降低差评多、库存少的商品权重。
- 规则保护：确保结果符合法规和平台政策。
高度抽象的模型:
+----------+ +----------+ +----------+
| 召回层 |-->| 粗排层 |-->| 精排层 |--> [算法排序列表]
| (多路召回) | | (轻量模型) | | (复杂模型) |
+----------+ +----------+ +----------+
|
v
+-----------------+
| 重排层 |
| (打散, 去重, 强插) | --> 最终呈现给用户的列表
+-----------------+3. 流程引擎 / 任务系统 (Workflow Engine / Task System)
对这个模型的描述也非常到位：“执行完A，再执行B...延迟20分钟再执行C...各种任务的编排调度”。它解决了业务流程的自动化和可靠性问题。
核心思想
将一个复杂的端到端业务流程，拆解为一系列独立的、可编排的、可观测的任务节点（Node），并根据预设的逻辑（串行、并行、分支、延迟、事件触发）来调度和驱动整个流程的执行。
典型应用场景
- 电商订单系统：下单 -> 锁库存 -> 支付 -> 通知仓库 -> 发货 -> 确认收货，这是一个经典的线性流程，但其中支付、发货等环节可能包含复杂的子流程和异常处理。
- 商品发布流程：上传图片 -> 图片处理（加水印、压缩）-> 内容审核（机审+人审） -> 同步到搜索引擎 -> 上架。
- 数据处理 (ETL Pipeline)：从不同数据源抽取数据 -> 清洗转换 -> 加载到数据仓库，这是一个典型的数据任务流。
- 用户增长任务：用户完成任务A（签到）-> 发放奖励 -> 触发任务B（去浏览商品）的引导。
- SRE/运维自动化：监控到告警 -> 自动执行诊断脚本 -> 尝试自动恢复 -> 失败则创建工单并通知负责人。
涉及的关键技术和知识点
- 流程定义 (Process Definition)
- 标准化语言：如 BPMN (Business Process Model and Notation) 是行业标准。
- 配置文件：使用
YAML,JSON或XML来定义任务依赖关系和执行逻辑。 - 可视化编排：提供Web界面，通过拖拽方式定义流程。
- 任务调度与分发 (Scheduling & Dispatching)
- 分布式调度器：需要一个中心调度节点（Scheduler）来管理整个集群的任务状态和依赖关系。
- 任务队列 (Job Queue)：使用
RabbitMQ,Kafka,Redis List等作为任务的缓冲池，实现调度器与执行器的解耦。 - 触发机制：时间触发（Cron）、事件触发（Event-driven）、手动触发。
- 任务执行器 (Worker / Executor)
- 负责实际执行单个任务逻辑的进程或线程。通常是无状态的，可以水平扩展。
- 状态管理与持久化
- 流程引擎必须可靠地记录每个流程实例、每个任务节点的当前状态（等待、运行、成功、失败、重试中）。这通常需要一个关系型数据库（如MySQL, PostgreSQL）来保证事务性。
- 高级特性
- 依赖关系：支持复杂的依赖，如
A, B都完成后才能执行C(DAG - 有向无环图)。 - 重试与超时：任务失败后自动重试，或长时间未完成则超时。
- 分支与条件判断：
If/Else逻辑。 - 并行与聚合：
Fork/Join模式。 - 分布式事务：在需要跨多个服务保证数据一致性的场景下，可能会用到 Saga、TCC 等模式来处理补偿逻辑。
开源框架示例：
Airflow, Azkaban (偏数据处理)，Temporal, Cadence, Camunda (偏业务流程)。高度抽象的模型:
+-------------------+
触发器 ----> | 流程引擎 |
(时间/事件) | (调度器, 状态机) |
+-------------------+
| ^
(分发任务) | | (更新状态)
v |
+-------------------------------------------------+
| 任务队列 (MQ) |
+-------------------------------------------------+
| ^
(获取任务) | | (上报心跳/结果)
v |
+----------+ +----------+ +----------+
| Worker 1 | | Worker 2 | | Worker 3 | ...
+----------+ +----------+ +----------+结论
这三大模型：
- 策略引擎 解决 “判断” 的问题。
- 排序架构 解决 “择优” 的问题。
- 流程引擎 解决 “执行” 的问题。
在真实的重型后端业务中，这三者往往是融合在一起的。比如：一个营销活动（策略引擎决策），可能会触发一个用户任务流（流程引擎执行），任务流的最终奖励可能是个性化的优惠券列表（排序架构生成）。