如何在端外投放的场景下实现前端实时 CEP 框架？

背景

复杂事件处理（Complex Event Processing，以下简称 CEP）在闲鱼内得到了广泛应用，基于用户使用闲鱼的实时行为，为用户提供更加丰富的优质信息与服务。闲鱼技术公众号有介绍过 CEP 在服务端和客户端上的设计与实现。然而之前的设计方案都只适用于闲鱼 App 端内场景，针对端外投放拉新场景（例如用户访问了多个商品详情页之后给用户发放优惠引导用户下单）需要设计在纯前端环境执行的实时 CEP 框架。本文主要介绍了在前端实现 CEP 的相关设计与实现。

设计目标

整个流程可以抽象为用户实时行为按照一系列规则匹配之后，以前台 UI 的方式对用户进行触达干预。对外投业务场景进行抽象，除了 CEP 基础能力之外，还有这三点关键设计目标：

1. 触达实时：从用户相关行为操作到对用户进行触达干预要尽量快，如果整个流程不够快，在触达干预的时候用户可能已经流失了。

2. 策略动态：业务需要经常对线上策略进行调整，期望业务开发只需要做一次接入，后续策略都可以服务端动态下发。

3. 多容器：外投场景包括小程序/Web/Weex 这几种容器场景，都需要支持。

架构设计

将业务流程拆解为三部分，分别是用户实时行为采集、对实时行为按照规则复杂计算、以前端 UI 组件进行用户触达，对应三个核心模块：事件采集、复杂计算和用户触达。针对上述设计目标，为了实现触达实时，将对行为的复杂计算放到前端去执行；为了实现策略动态，设计了一个服务端运营平台管理所有策略，采集行为信息、复杂计算规则、触达组件信息都从服务端获取；为了实现多容器，将实时行为采集和 UI 组件触达进行标准设计，分不同容器环境实现。此外由于策略会存在跨页面的场景，底层会有数据同步模块同步行为数据和计算状态。下面分别对重要模块进行详细介绍。

事件采集

事件采集模块将用户行为转化为标准事件。首先是用户行为无侵入采集，无侵入采集是为了解决两个问题，第一个是为了让业务开发接入更加简单，不需要手动调用采集代码；第二个是为了覆盖更多可能的采集点，利于后续策略动态下发。这里我们选用静态扫描代码的方式，在具有特定行为标示（例如 onClick）的元素节点上注入采集参数，采集参数通过元素样式名称、组件名称、文件路径等信息生成，具有比较好的语义；并且和运行时无关，更利于扩展不同容器实现。

初期先定义了用户基础操作行为（enter、leave、scroll、appear、click），用户行为多样并且形态复杂，因此首先需要将用户行为做标准化处理。此外随着业务使用后续有一些业务模块也要事件形式进入计算，例如 http 请求返回的结果也会作为一个事件，因为这里设计了一个插件机制，能够让业务模块快速转化成标准行为。

复杂计算

目前社区前端复杂计算相关方案都比较简单，不适用于业务场景。自研上选择参考业界 CEP 标准实现，业界 CEP 设计主要源于这篇论文 Efficient Pattern Matching over Event Streams，在这篇文章里介绍了 CEP 的核心是 NFA（不确定的有限状态机），CEP 的匹配过程就是 NFA 状态变化的过程。因此首先在前端实现了一个 NFA 类，实现这样一个状态机。

但是我们无法直接创建一个 NFA 去描述匹配规则，更习惯按照事件间关系与每个事件的匹配规则去定义，因此需要在上层封装一套 API 来创建 NFA。这里参考了 Flink CEP Pattern API 的设计。通过 next/followedBy/followedByAny/notNext/notFollowedBy 等 API 来定义事件间关系，通过 where/and/or 等 API 来定义每个事件的匹配规则。通过 Pattern 定义会生成一个中间链表，生成 NFA 的过程就是反向解析这个链表。

前端做复杂计算我们总会担心性能是否有问题。以下面这个性能压测为例，有 20 个策略在做匹配的情况下，一次灌入 200 条行为数据，整体耗时在 3.73s。虽然时间并不是特别长，但是由于浏览器运行机制，JS 引擎线程在执行的情况下，UI 渲染线程也会被挂起，在这 3.73s 内用户所有在页面上的操作都得不到响应，感觉就是“卡住了”。因此前端复杂计算性能优化更多需要考虑计算过程中不能影响用户体验。

对比目前业内的解法，Worker 和 Webassembly 存在容器限制以及优化效果可能不明显。这里选用了一种时间切片的解法，整体思路和 React Fiber 机制比较类似。将复杂计算的大任务拆解为小任务执行，在小任务执行完之后，会适当让出 JS 主执行线程的控制权，让浏览器能够响应用户操作，保证用户操作不受影响。下面这张图是优化后的效果，可以看到每个任务执行之后有一段空闲。并且这个优化方式是纯 JS 层面的优化，不受单一容器的限制。

用户触达

用户触达模块管理用户前台展示组件，出于对 bundle 大小的考虑，组件代码都通过动态加载的方式。由于需要针对不同容器实现，在上层统一标准组件的设计，包括统一组件 API、输入数据源以及埋点信息等。组件相关设计最终会影响各容器实现成本和业务效果统计。

数据同步

由于跨页面场景（例如访问了详情页又访问了这个卖家的闲鱼号）存在，而前端多个页面之间不具备通信能力，也不存在一个线程在后台一直处理业务逻辑，因此在行为数据以及计算状态的同步上需要依赖本地存储能力。前端本地存储都只支持 Key/Value 存储，能力相对较弱，频繁读写数据容易出错。因此在本地存储上层实现一层内存缓存，扩展了一些存储能力，每隔一段时间或者在一些时间节点上（例如离开页面）和本地存储同步，这样既保证了存储的灵活性，又实现了跨页面数据同步。

未来展望

目前该前端 CEP 框架已投入线上业务使用，在阿里小程序、Weex、Web 下都能良好运行，并且提供了一定的运营配置能力，在目前线上单一策略下整个流程可以在毫秒级内完成，后续在业务上会有更广泛的使用。

在技术细节以及业务易用性上，我们依然有很多可以完善的地方，后续的一些演进方向如下：

1. 端内外全链路触达：与服务端、客户端在行为定义、规则计算、触达干预上统一一套标准协议，在闲鱼端内外全链路上此类问题通过统一一个系统承接。

2. 运营体系完善：让业务更加便捷构建策略投放，在数据挖掘上能够更好辅助业务做决策。

3. 智能化：将目前依据业务经验的规则匹配向算法根据用户行为智能决策转化，同时探索前端智能化的可能性。

本文转载自公众号闲鱼技术（ID：XYtech_Alibaba）。

原文链接：

https://mp.weixin.qq.com/s/gMUG7D66-zzzSXknMpVPcw