解决复杂事件采集、计算、实时触发的模型

核心内容设计

核心设计这一步很考验基本功和技术视野的，需要综合判断、权衡取舍，依据设计目标选出一个当前的最优解。在系统的设计目标中，其中一条，就是要标准化，标准化最大的好处是可以统一不变的接入。互联网是个发展只有不到30年的行业，但工业已经发展了几百年，很多互联网行业里的问题，在工业里已经有了标准化的定义。在搜集技术方案资料中，对RFID（射频识别）进行复杂事件的流处理的方案进入我们视野[参考1]。

RFID系统信息体系结构

而这个工业场景下的问题定义，具有标准化和通用性，其核心内容包含3个模块：数据采集模块、复杂事件处理模块、结果触发相应的时间模块。 这个设计正好符合我们的业务场景所需要解决的问题。结合我们自己的业务，我们将其定义为“日志采集模块、复杂事件的实时处理(EPL)模块、结果触达模块”，其核心的架构图设计如下：

核心架构图 这3大核心模块，都是通过异步消息进行通信，目的是每个模块可以解耦，即可以进行独立使用，又可以作为整体的能力提供。 通过日志采集模块，进行日志的采集和归一，得到输入的数据；而后进入EPL模块，进行规则定义和计算；最终的结果进入触达模块，进行用户的结果触达。下面分别介绍这3个模块的详细设计。

各子系统模块的详细设计

1：日志采集模块 闲鱼的系统架构，入口应用多，而且还有是异构的（有java应用，dart应用，Fass应用）。我们做了一个拦截器，屏蔽这些应用的细节，作统一的拦截处理。 经过统一请求拦截层，将所有的请求日志写入到SLS中。如图

但这些日志的格式千变万化，对下游的业务处理非常的不便，因此需要对原始的日志数据进行清洗，清洗为统一的格式，同时这个清洗任务随着原始数据的多变，需要支持可配置化。 我们使用blink实时的对原始数据进行清洗，同时在blink任务里，嵌入一个UDTF，这个UDTF接入动态化配置平台，支持对清洗任务的可配置化。经过blink清洗后的数据，格式归一化为：

归一化格式后的数据，通过rocketMQ和SLS往下游输出。这里提一下为何要通过两种数据通道输出：rocketMQ对于在线业务的接入非常方便； SLS对下游接blink任务实时计算并发度要快。

2：EPL引擎模块 EPL模块， 这里提一下我们设计此DSL的目的和目标。

1. 简化该业务领域下的写法。
2. 云/端表达的统一。
3. 该写法要作为blink的一层通用抽象表达。
4. 该DSL要尽量的符合行业内的规范。