基于事件驱动的邀约自动化机制

原创
08/30 14:26
阅读数 3.1K

本文详细介绍了58同城邀约业务系统的架构设计和实践经验。文章涵盖了系统的业务背景、整体架构、核心组件设计、技术实现细节等。通过平台化设计和标准化实践,该系统显著提升了产研效率、交付质量和业务复用性,为大规模招聘匹配提供了强有力的技术支撑。


背景介绍

系统邀约是招聘业务模式中一种高效的人岗撮合机制,它通过推荐匹配技术,将合适的职位推荐给需要的求职者,借助AI对话等能力引导双方更高效完成沟通最终实现意向达成。

从技术层面而言,一次邀约的过程,可以分如下重要步骤:邀约触发、双端匹配、效果调控、以及消息触达、AI对话等环节,本文重点介绍从触发到消息发出这些环节中的设计和实现方案。

一、技术挑战

为了支持上述这些功能,我们设计并实现了一个基于事件驱动的自动化邀约平台。这套系统高效地支撑了邀约业务的快速增长和功能迭代。然而,在系统的落地和演进过程中,我们也面临了许多技术挑战,这些挑战可以归纳为三大类。


1.1、架构设计

我们的系统设计面临着一个挑战:需要适应多样化的业务场景,这些场景在复杂性和规模上各不相同,特别是在触发时机和业务流程的处理上。因此如何设计出「扩展性高并且流程可定义的系统架构」,成为重点考虑的方向。其中系统设计的关键指标包括,不同业务场景中的统一的管理控制能力,如触发时机的定义、业务流程的配置化、流量的分发调控、系统的监控等等;如何支持业务流量错峰,提升资源利用率;如何提升并发性能等等。


1.2、触发时机

这里的触发时机主要分为以下两大类:

  • 实时触发:即基于用户的行为,实时触发,对实时性要求较高,经验证5s内触发用户得到的转化最高

  • 定时触发:即基于目前用户群,在某个时刻触发,这类一般转化效率较低且对时效性要求低。

1.3、业务流程的抽象和复用

无论是定时触发还是实时触发,都会涉及到一些相同的业务流程。例如,需要进行前置条件判断、用户筛选、AB实验、效果调控(如频控和岗位校验等)、双端匹配、消息样式等(如下图)。然而,每个流程节点又存在差异。因此,如何将这些功能抽象为具备通用性的原子能力,并通过统一的接口和框架实现编排以及组合,成为了业务流程抽象和复用的关键。

下面针对上述三方面的技术挑战,我们逐一进行深入探讨。

二、整体设计

2.1 整体思想

基于前述业务背景,我们设计了一个高度模块化和标准化的系统架构。这个架构的核心思想是从整体流程定义出发,逐步细化到具体的原子能力抽象,即系统能力的精细划分。

我们的系统设计遵循标准化的抽象流程,形成了一套完整的产品研发(产研)和质量保证(QA)协作的标准化流程。这种方法不仅确保了系统的模块化和可扩展性,还显著提高了交付效率和质量。系统架构图如下:

这种模块化和标准化的设计使我们能够更好地应对复杂的业务需求,同时保持系统的灵活性和可维护性。每个功能模块都可以独立开发、测试和优化,从而提高整体系统的稳定性和性能。


2.2 触发时机与流程编排

邀约系统的触发机制主要分为实时触发和定时触发两大类,分别适用于不同的业务场景。这种分类为系统提供了灵活应对各种复杂业务需求的能力。

流程编排是我们系统的另一个关键特性。它的主要目的是解决不同业务场景下执行流程的差异化问题。通过抽象和模块化的设计,我们实现了高度可配置的流程管理。这使得系统能够根据不同的业务需求,快速组装和调整处理流程,而无需大幅度修改底层代码。

如系统架构图所示,流程编排模块允许我们灵活定义和组合各个处理步骤。这种设计不仅提高了系统的适应性,也大大增强了其可维护性和可扩展性。

关于触发机制和流程编排的详细技术实现,将在第三部分的技术框架设计中进行深入探讨。

三、技术框架设计

3.1.触发时机

上文说到我们的触发时机分为两大类,即实时触发(用户行为)和离线调度(定时触发)两大类,这里重点说下实时触发的系统设计。

3.1.1 事件驱动服务

在这块的设计中,我们将用户的行为抽象成一个事件,采用异步消息的方式来进行解耦。这就很容易让我们联想到这种基于事件和消息的响应式系统架构设计。这里引入几个核心概念。

  • 事件源:即事件的来源,负责产生事件。这里一般是用户活跃、浏览职位、投递等

  • 事件处理器:接收事件并进行处理的组件,这里主要负责事件的中间存储,规则以及该事件关联的一系列投递目标。

  • 事件目标:即获取该事件后最终的动作,这里是指触发后链路的流程

上图介绍了一个事件驱动服务的核心流程。我们可以基于接入方来定义识别一个标准事件,也即事件源。而事件处理器接收到事件后,查询该时间的关联数据和规则,对事件进行过滤、协议转换、目标投递。当然也可按照需求选择是否延迟执行。这里以用户活跃为例来介绍下这几个核心流程。

1)、过滤规则

在处理事件时,我们采用了前置过滤机制,主要针对消息体中的字段进行筛选。这种场景下,规则引擎成为了显而易见的技术选择。在众多规则引擎中,我们选用了Aviator。Aviator作为一个轻量级但功能强大的规则引擎,具备以下几个突出特点:

  • 多样化的数据类型支持

    • 基本类型:数字、字符串、正则表达式、布尔值等

    • 高精度类型:bigint和decimal,适用于超大整数和高精度数值运算

  • 全面的语法功能

    • 多行数据处理、条件语句和循环语句

    • 异常处理机制 这些特性使得复杂逻辑的编写变得简洁明了。

  • 函数式编程支持:提供Sequence抽象工具、简化集合操作、提高数据处理和转换效率

  • 扩展性:支持自定义函数,可实现更复杂的业务逻辑

Aviator的这些特性使其成为处理通用规则的理想选择,尤其适合我们的前置过滤需求。通过使用Aviator,我们可以灵活地定义和管理各种复杂的过滤规则,从而有效地处理不同类型的事件。

2)、 协议转换(指令集)

在处理不同事件源和多个投递目标时,我们面临着消息体格式不一致的问题。为了避免大量硬编码开发,我们抽象出了一套灵活的协议转换流程。这个流程能够将源消息体(source)高效地转换为目标格式(target)。以下图为示例,我们想要把source消息体转化为target消息体

这中间要做的字段变化如下:

source

操作

target

business_line

变更字段

businesType

userid

变更字段

uid

extra.resumeId

移动字段

resumeId

city

删除字段


为了实现这一目标,我们设计了一套自定义指令集:

  • CHANGE指令:用于字段变更,如将源事件中的A字段更名为目标协议中的B字段。

  • MOVE指令:用于字段转移,特别适用于多层协议。例如,可以将源中A字段(JSON格式)内的x字段移动到目标协议B中的y字段。

  • DELETE指令:用于删除不需要的字段。

  • ADD指令:用于添加固定字段,主要用作业务标识。

通过这套指令集,我们可以灵活地定义各种转换规则。下面是一个具体的转换示例:

source

command

target

源字段 源值 转换指令 目标字段 目标值
business_line 58 CHANGE businesType 58
city beijing DELETE - -
new_job_id 80xxxx91 DELETE - -
new_market_id 10xxxx74 DELETE - -
stime 17xxxx73 CHANGE reportTime 17xxxx73
top_userid 20xxxxxxxx02 DELETE - -
userid 10xxxxxxxx16 CHANGE uid 10xxxxxxxx16
extra.resumeId 9x2 MOVE resumeId 9x2

通过这种方式,我们实现了一套标准的、可配置的协议转换机制。每个事件类型可以定义自己的指令集,从而实现灵活的协议转换,无需编写额外的代码。

这个协议转换机制是事件驱动服务的核心组成部分之一,它极大地提高了系统的灵活性和可维护性。通过这种设计,我们成功地实现了事件驱动服务的核心功能,为整个邀约业务系统奠定了坚实的基础。


3.2. 业务流程的抽象和复用

在这里我们定义了一个流程引擎的服务。流程引擎作为整个执行链路中的决策中心,承担着极其重要的作用。将各种类型的基础原子能力进行组装编排。这里采用了DAG有向图来描述流程。将不同类型的原子能力定义为一个图中的一个路径节点。考虑到业务场景的复杂度,这里将图进行树化,变成一颗多节点的树。如下图所示。

3.2.1 原子能力的抽象

整个树由多个节点构成。我们将具有相同功能的节点抽象为一种节点类型(Node)。节点间存在关联性,当前节点完成后是否触发下一个节点取决于一套规则。为实现节点间的串联,我们将节点关系的抽象如下图所示:

每个节点包含两部分内容,即执行该节点的条件condition,以及执行该节点需要的数据value。我们会将每个节点的执行结果带入到上下文,作为下一个节点能否执行的条件。以一个简单业务场景为例,可实现如下配置的策略树。

3.2.2 流程引擎的调度机制

流程引擎的调度是由前面的事件驱动服务来发起,这里针对于每个邀约规则抽象了一个邀约计划,即该邀约流程的有效期。

3.3 业务组件层沉淀

基于流程引擎中用的原子能力,这里抽象出了人群、频控、AB实验、效果调控、推荐匹配、内容展示等。流程引擎可基于以上原子组件完成常见业务流程的定义。

该架构设计支持快速接入新的业务场景。通过配置化方式,可以快速完成新业务的接入,无需大规模代码改动。

四、效果展现

  • 系统能力沉淀

    • 相关业务已经全部完成平台化架构升级,并在此架构上持续运行和迭代

    • 业务基础能力积累,包括人群、频控、AB实验、效果调控、推荐匹配、内容展示等公共组件,每个组件内承接不同业务的不同规则。实现千人千面能力。


  • 交付能力&质量

    • 通过平台化架构和公共组件的应用,交付质量显著提升,减少了代码冗余和潜在的错误,提高了系统的稳定性和可靠性。

    • 对比其他业务架构,邀约整体架构并行承接业务能力较强。大部分功能业务无需开发,包括效果调控、推荐匹配、事件触发等业务基本都是配置化。

    • 在新业务接入中,Action复用80%以上。

五、总结与展望

本文介绍了针对邀约业务,通过平台化设计在建设和实践中的思考与落地,为未来的业务拓展和创新奠定了坚实的基础。另一方面,我们也在逐步引入更多AI能力,通过大模型等技术解决招聘双方撮合过程中意向匹配、对话体验、招聘反馈等各个环节的问题,不断提升全流程的招聘体验,为更多的求职者找到合适的工作和帮助更多商家招到合适的人。


本文分享自微信公众号 - 58技术(architects_58)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击加入讨论🔥(2) 发布并加入讨论🔥
2 评论
10 收藏
0
分享
返回顶部
顶部