作者：京东科技 刘红申
一、事件总线介绍
事件总线，或称其为数据管道，作为整个危险洞察数据流转的重要一环，它承当着危险实时数据对立标准化的重要职责。
在面对简单多样的上游数据，事件总线能够将简单数据进行解析、转换, 富化、散发等操作。底层外围算子形象为 source、transform、sink 三层架构, 反对各层算子插件式扩大, 并反对 groovy、python 等脚本语言自定义配置，以及自定义 jar 包的上传，领有将上游数据单向接入多向输入的能力，在数仓与下层利用的发展中，起着承前启后的作用。
二、事件总线 - 遇到的技术挑战与解决方案
技术难点与挑战
危险洞察平台运行初期，业务数据接入齐全采纳定制化代码解决，通过代码配置生产 MQ 音讯，而后依据业务需要，实现其所需字段的解析，最终数据落入 Clickhouse。这种业务接入形式在晚期是能够满足业务所需，然而随着危险洞察平台在风控畛域的一直推动，业务的倒退与数据一直收缩，面对风控数据的简单多样性、音讯平台的差异性，数据接入定制化老本也越来越高，同时数据转化与计算逻辑的强耦合，大促期间吞吐量未然达到瓶颈，呈现出越来越多的痛点：
1. 数据结构差异性: 随着危险洞察平台应用业务方的的一直减少，业务数据音讯体的复杂性也不尽相同，如简单场景以天盾反欺诈场景为例，音讯体构造蕴含对象、对象字符串而且还有数组；简略场景以内容平安为例，音讯体构造就是简略平铺的一层；面对风控数据的简单多样性，定制数据的对立标准化未然火烧眉毛；
2. 代码逻辑重复性: 对音讯体的解决绝大多数逃离不了序列化与反序列化操作，然而随着业务量的增多以及开发人员的不尽相同，业务代码是每日剧增且带有错落性的，逻辑反复，保护老本高；
3. 解析写入低效性: 同一个 MQ 音讯可能会对应很多的业务方，不同的业务方所需业务数据又千差万别，如以天策 MQ 为例，实时数据中蕴含着金白条数据，金条与白条数据又辨别着各自的业务线，如果单次订阅 MQ 音讯，会导致逻辑解决极其简单，不可保护；然而采纳屡次订阅，又无奈复用已有逻辑，且导致数据成倍增长，造成资源节约，同时吞吐能力成为瓶颈；
4. 输入输出多样性: 随着危险洞察平台被应用的越来越广，来自于上游数据的生产方式也呈现了多样性，如 JMQ2、FMQ、Kafka 以及 JMQ4 等等，同时又为了给用户更好的平台应用体验，不同业务数据又会被落入不同存储中，如 Clickhouse、R2m、Jes 以及音讯队列，如何疾速反对这些组件成为了挑战；
5. 业务需要易变性: 上游业务频繁的策略调整与变更，对应到事件总线就意味着解析字段以及底层表字段频繁的增删改，正如字段解析齐全依赖于硬编码且不同业务数据耦合着各自的业务逻辑，导致开发人员保护老本极高，开发周期长、上线影响广；
技术解决方案
研发一套数据流转服务，用其贯通数据接入到数仓存储的整个流程，再联合危险洞察平台个性，以数据源组件为根底，作为数据流转的入口与进口，具体计划如下：
• 数据对立标准化能力 ：对立标准化入口与进口。上游数据接入时，无论音讯体构造如何，通过事件总线解决后，都输入为平铺单层 key-value 构造；
• 代码逻辑规范化能力 ：针对风控策略自身易变的个性，采纳灵便度更高的音讯体解析组件 Jsonpath，任何音讯体解决第一步就是生成音讯体上下文对象，后续字段的提取，都从这个上下文中获取；
• 高吞吐解析写入能力 ：一次解析，多路复用。MQ 主题实现单次接入，依据不同的业务需要通过过滤下沉不同的业务表，如以天策金白条为例，提取金白条各自的 INTERFACE_NAME 作为条件，下沉到不同的业务表中；又如以高 TPS 营销反欺诈场景为例，在下沉表的同时，下沉音讯队列给 Flink 计算应用；缩小反复解析，同时形象各种算子，针对不同的数仓写入可做对应的频次、批次、大小设置，晋升吞吐量；
• 输入输出插件化能力 ：输入输出插件化，新的业务需要来时，能够疾速扩大相应组件，以应答新需要；
• 低代码化热加载能力 ：针对业务需要的频繁变更，解决硬编码问题，缩小上线频次，那就须要开发一套可配置化零碎，反对脚本开发与热加载，同时内置函数插件化，疾速扩大共性函数；
三、事件总线 - 整体架构图
事件总线 - 架构介绍
事件总线整体架构形象为三层，source、transform 和 sink。通过连接器扩大机制实现数据引擎扩大, 并采纳责任链模式解决数据链路, 插件化治理函数、脚本，实现实时音讯接入、过滤、富化、转换、散发标准化解决，并通过分组生产、降级机制保障架构高可用。
• 实时数据 : 危险外围场景，目前事件总线业务数据的次要起源；
• 事件总线 :
◦Source：数据输出层，危险业务数据的次要起源形式，目前大多数来源于 JMQ2、JMQ4、FMQ 等；
◦ Transform: 事件总线的外围解决层，同时也是自定义函数与自定义脚本的解析层，该层形象了大量的算子，如，数据解析算子、过滤算子、富化算子、转换算子等等当简单音讯体数据通过一系列算子之后，最终会转化为单层 key-value 规范构造；
◦ Sink: 数据输入层，经 Transform 组件转换后，此时的数据能够发实时音讯给各个音讯队列，也能够存储到 Clickhouse、Es、R2m 等数据库；
• 数据服务 : 基于事件总线标准化后积淀的数据所撑持的平台利用；
事件总线 - 外围类图介绍
事件总线定义了一个顶层父接口 IEventHubExecutor，并定义了一个 execute 办法，其三个次要子接口，IEventHubParse、IEventHubTransform 与 IEventHubSink 别离对应于事件总线的三个组成部分，source、transform 和 sink。通过实现这三个子接口，便能够实现对不同中间件的适配问题。比方，目前事件总线仅反对解析的数据写入到 Clickhouse，但业务需要须要做检索，那么很显然数据存储在 Es 要优于存储在 Clickhouse，所以此时须要扩大一个 JesEventHubSink 来实现 IEventHubSink 即可。
其中 Context 作为上下文，贯通了整个事件总线的执行过程，上下文中蕴含了解析过程中所须要的一起信息，比方，从哪里来的数据、要解析哪些字段、解析好的数据送到那里去等等。
事件总线 - 自定义函数介绍
自定义函数的实现，其实借助了开源框架 Avaitor 表达式，Aviator 是一个轻量级、高性能的 Java 表达式执行引擎, 它动静地将表达式编译成字节码并运行，次要用于各种表达式的动静求值。相比 Groovy 这样的重量级脚本语言，Aviator 是十分轻量级的表达式执行引擎。
• 函数解析器：自定义函数反对脚本编写（脚本采纳 groovy，同时为了更加“亲民”，采纳 Java 语法）与 Jar 包上传两种形式；
• 函数编译器：编译脚本与解析 jar 包，生成对应的 AvaitorFunction 实例；
• 函数注册器：将生成的 AvaitorFunction 实例注册到 Avaitor 的上下文中；
• 函数执行器：通过实现 FunctionExecutor，便能够对函数不便的调用；
事件总线 - 动静分组、一键降级与流量监控介绍
分组生产
事件总线解析能力的晋升，也很大一部分归纳于分组生产的设计，对流量做到灵便分流，对机器做到物尽其用。动静分组，又分为物理分组与逻辑分组，如下图：
• 物理分组：单纯依附机器划分，规定好哪些机器生产哪些主题，如，天盾分组就生产天盾主题，营销分组就生产营销主题。
• 逻辑分组：逻辑分组与物理分组的区别在于，逻辑分组在物理分组之上，又形象出一个生产组的概念，用机器与生产组绑定，而非间接与主题绑定，这样带来的益处就是，能够更加不便的调配流量，如，营销流量十分大，那么能够间接动静调配，使天盾分组也去生产营销主题，既能充分利用天盾分组机器，又能进步营销主题生产能力。
一键降级
一键降级更多的用于大促期间，然而为了降的更加“人性化”，一键降级咱们也做了分类：抛弃降级与积压降级，如下图：
• 抛弃降级：所降级主题处于生产状态，顾名思义，事件总线拿到了数据，就间接将数据抛弃，降级期间数据是不可找回的；抛弃降级可用于业务方并不在意一时数据的失落或者压测场景。
• 积压降级：所降级主题处于非生产状态，降级期间数据积压在音讯平台，降级过后，再开启生产；积压降级可用于业务方容许降级期间内没有新数据，然而降级过后数据又可查场景。
流量监控
事件总线的流量监控现依赖于 ump，对单个主题以及所有主题的入口都设有埋点，数据在每个要害流转地位解析性能以及流量都能被监控，代码片段如下：
Profiler.registerInfo(this.getClass().getSimpleName(), UmpUtil.UMP_APP_NAME, false, true);
四、将来瞻望
自事件总线上线以来，曾经经验了屡次大促考验，大促解析量已达 5000w/min, 日常解析量也已 2000w/min，随同着危险洞察平台被越来越多的部门所应用，事件总线未然成为其重要组成部分，为了更好的进步解析性能，就须要去做更多的摸索。同时，目前事件总线做的更多的是对实时数据的解决，将来咱们也将推动 flink-cdc 等技术在事件总线中的利用。