基于 RocketMQ 构建阿里云事件驱动引擎——EventBridge

本文涉及的产品
简介: 以Kubernetes为基础设施的云原生技术,彻底改变了我们的开发和思维模式。事件作为云原生领域的一等公民,已经无处不在,是云原生架构体系松耦合、灵活性的基础。作为Gartner定义的10大战略技术趋势之一,事件驱动架构(EDA)逐渐成为主流技术架构。根据Gartner的预估,到2022年,在新型数字化商业的解决方案中,将有6成使用EDA,在商业组织参与的技术栈中,EDA有一半的占比。本文

以Kubernetes为基础设施的云原生技术,彻底改变了我们的开发和思维模式。事件作为云原生领域的一等公民,已经无处不在,是云原生架构体系松耦合、灵活性的基础。

作为Gartner定义的10大战略技术趋势之一,事件驱动架构(EDA)逐渐成为主流技术架构。根据Gartner的预估,到2022年,在新型数字化商业的解决方案中,将有6成使用EDA,在商业组织参与的技术栈中,EDA有一半的占比。

本文将介绍事件、事件驱动架构、阿里云事件驱动引擎EventBridge及其在事件的标准化、中心化、事件驱动架构上的能力。

1 事件及事件驱动架构

1.1 事件

事件是已经发生的事实,并且是不可变的。相比而言,消息是一个服务为了另一个服务的消费或存储而生产的原始数据,消息是可以被修改的。

事件的生产者如实地产生和投递事件,它不关心这个事件将由谁、因何,以及怎样去处理。而消息的生产者是知道谁来消费的,并且知道封装哪些因素到消息中,以便消费者处理。

事件的Broker被设计为提供事实日志。事件在超时时间后被删除,这个超时时间是由组织或者业务定义的。而消息的Broker被设计为处理各类问题的,当消费者感知到消息后,消息即可被删除。

事件 消息
Data 已经发生的事实,并且不可变(Immutable) 为消费或存储而生产的原始数据
Producer/Consumer 生产者不知道消费者是谁以及如何处理 生产者知道消费者是谁以及如何处理
Broker 提供事实日志<br/>超时时间后,事件被删除 处理各类问题<br/>被消费者感知后,消息被删除
  • 离散事件:描述状态(state)的变化 可执行的
  • 连续事件:描述处于怎样的状态(condition) 可分析的

通常,事件是离散的,用于描述一个事物的状态变化,可以被执行。消费者根据离散事件所描述的状态,执行相应的动作。

事件也可以是连续数据流中的一部分,用来描述一个事物当前处于某种状态下。这些连续的事件是可分析的,消费者可以根据这些状态的变化,分析出某种趋势及背后的原因。

事件应当被设计为最小尺寸、最简类型、单一目的。这里要着重介绍下CloudEvents。CloudEvents在2018年5月进入CNCF基金会的沙箱项目,然后只用了1年多时间就成为CNCF的孵化项目,其发展速度非常快。CloudEvents将会成为云服务之间,事件通讯的标准协议。同时要强调的是,CloudEvents已经发布了多个消息中间件的绑定规范。

CloudEvents

  • 2017年12月 启动
  • 2018年05月 CNCF沙箱项目
  • 2019年10月 1.0 CNCF孵化项目
  • 2020年12月 1.0.1

1.2 事件驱动

事件驱动架构是一种围绕着事件的生产、探测、消费,及响应的软件架构范式。为云原生应用的分布式和伸缩性,提供了基础保证。事件驱动架构天然的异步特性,使云原生应用在设计上,可以根据DDD理论,清晰地划分出服务间的上下文边界,优雅地实现松耦合。

事件的传递模式

我们走近事件驱动,来看一下事件的传递模式。与请求驱动不同,事件驱动的两端不是直连的。

事件的传递模式包含如下三种。

e92db42b-8685-4394-92ce-9ba95f4c6b01.png

基于队列的生产者-消费者模式。这是一种单一接收者的模式,用于两个服务之间的事件传递。生产者服务并不关心消费者服务如何处理事件。

0db88609-faa9-45b3-bf1f-4911832a263c.png

基于队列的异步请求-回调模式。这种模式和请求驱动的request-response类似,是异步的request-reply或者叫request-callback,同样用于两个服务之间的事件传递。生成者服务会关心消费者服务随后生产的响应事件。

cea816a5-e6e5-4c74-ba50-adb33cb50071.png
基于主题的发布者-订阅者模式。这是一种多对多的模式。发布者服务可能生产不同类型的事件,并将其传输给不同的主题,订阅者服务可能订阅一个或者多个主题,以实现对不同类型事件的处理。

事件的服务定义模式

我们再来了解下事件的服务定义模式。

73b9cabb-3eca-4e72-8475-e599e6254ae3.png

我们已经知道,事件的生产者并不知道消费者是谁,因此不能像消息那样预先定义消息的格式。因此,在事件驱动架构中,需要一个Schema Registry为生产者提供序列化依据,为消费者提供反序列化依据。

Schema类似gRPC中的proto定义。在请求驱动模式下,gRPC的服务端和客户端会分别根据proto定义,生成stub模板代码。然后将模板代码提供给自己的上层代码调用,从而实现序列化和反序列化。

与之类似,在事件驱动模式下,消费者在获取事件后,可以根据CloudEvents标准协议,解析出Schema和Content(通常是二进制),然后通过消费者调用Schema Registry服务,将Content反序列化为事件体。

可以看到,事件的服务定义模式,可以将事件的生产者和消费者充分地解耦。

1.3 EventBridge

通过上面的介绍,相信你已经对事件和事件驱动的概念有了较清晰的认识。接下来我介绍下EventBridge。

EventBridge是为用户提供构建松耦合、分布式的事件驱动架构的Serverless事件总线服务。EventBridge的事件传输和存储遵循CloudEvents协议。

在EventBridge中,事件的生产者称为事件源,传输和存储事件的介质称为事件总线,事件的消费者称为事件目标。事件由事件规则转换、匹配、聚合,并路由到事件目标。

7abeea1f-551d-4b2f-827b-5a05e5b501c0.png

EventBridge连接了事件生产和消费的两端,利用云原生基础设施的能力及Serverless按需消费的特点,为用户提供了低代码、松耦合、高可用的事件处理能力。用户可以以极简的投入,实现强响应能力的EDA云原生应用。

同时,EventBridge基于标准的事件协议,有利于促进各类事件源的事件标准统一,使事件孤岛逐步融合进完整的事件生态体系之中。因此,EventBridge正成为云原生事件驱动架构的标准范式。

那么,EventBridge是如何结合Serverless实现极简的EDA应用的呢?在接下来的事件总线范式及应用场景中,我将会详细介绍。

2 事件总线

EventBridge的一大特点是标准事件协议的管道。那么,我们一起来看一下,阿里云事件总线EventBridge实现这个管道能力的各个组成部分。

2.1 EventBridge的组成

事件源

阿里云EventBridge的事件源包罗万象。可以是阿里云的各类云产品、阿里云第三方SaaS服务,也可以是阿里云用户自己的服务,甚至可以是其他云厂商、边缘服务、私有机房内的服务。用户使用CloudEvents的SDK,即可将事件推送到阿里云事件总线,从而实现事件上云。

事件总线

为了提供开箱即用的云产品事件处理能力,阿里云EventBridge为每个用户提供了租户隔离的默认事件总线。用户所使用的云产品产生的事件,会由这条事件总线传输和存储。

用户可以通过自定义事件总线对接各类事件源,将不同的数据源产生的事件统一采集、存储和响应。

事件规则

EventBridge的事件规则的两端分别是事件总线事件目标。用户通过配置匹配规则、转换规则等,以低代码甚至无代码的方式,实现从事件总线到事件目标的事件过滤、转换和路由。

事件目标

事件目标是事件被最终处理的地方。阿里云EventBridge目前已经支持了多种事件目标,为用户带来开箱即用的体验。我们可以为一个告警事件指定钉钉机器人,可以将一个订单事件通过HTTP网关传输给用户服务,也可以将事件投递给消息服务实现事件上云。

当然,云原生的经典事件目标是由Serverless服务,因为Serverless服务充分展现了云原生的优势。

  • Serverless的资源是按需消费的,将弹性发挥到极致
  • 轻量级的函数具有低延迟、高可用的能力,且无运维成本
  • 用户编写事件处理函数的学习门槛低、开发代码量小

举个例子

我这里给大家展示个小例子,一起感受下EventBridge+Serverless实现EDA的轻量化。

c4d40380-7d66-47bc-9f06-8f5dd35b6781.png

首先我们自定义一个事件总线,将Kubernenets容器服务作为事件源,将Serverless服务(函数计算)作为事件目标。

然后我们为容器内的资源状态变化事件定义一个事件规则,当这类事件进入事件总线后,将被路由到函数计算服务。

最后,我们编写并部署一个处理这类事件的函数到函数计算服务,在函数内,首先接收到CloudEvents标准协议的事件,通过Schema Registry解析事件,最后由函数自身完成事件处理——比如调用容器服务的API,对资源进行相关操作。

从这个小例子中,我们可以看到,EventBridge+Serverless可以让用户以很低的成本快速实现一个事件驱动的业务。四两拨千斤。

接下来,我将介绍两种事件驱动架构的编排模式,并给出相应的例子,抛砖引玉,希望能激发你的脑洞,结合自身业务,得到因地制宜的事件总线最佳实践。

2.2 事件驱动架构的编排模式

c6e9bcec-82f4-492f-a0cd-03d51df848c1.png

调停者模式

对于处理较复杂的事件驱动场景,调停者模式能帮助我们有条不紊地对事件进行拆解和分析,并最终执行指定的动作。调停者模式由三个角色组成:外部服务、调停者、执行者。

首先,外部服务作为一个事件总线的事件源,将事件传输给事件总线。作为调停者的微服务或者函数是这个事件总线的事件目标,接收并处理来自某个事件源的事件。

调停者函数在执行过程中,会将事件处理的多个中间状态作为新的事件,传输到对应的事件总线。此时,调停者是作为这些事件总线的事件源。作为执行者的函数是这些事件总线的事件目标。这些函数从事件总线中接收并处理事件,然后产生一个回调事件并传输到相应的事件总线中。可以看出,这里调停者和执行者之间,是前面讲到的异步请求-回调模式。

调停者接收到回调事件后,执行调停逻辑,并将结果作为回调事件,经过事件总线,传输给外部服务。

示例:智能家居

接下来,我来展示一个使用调停者模式实现智能家居的例子。

c1dcb15b-79a0-4da3-939e-4f6bb7599484.png

在这个例子中,我们将IoT设备/传感器作为外部服务,将用户的全屋系统作为调停者,将用户在函数计算中创建的函数作为执行者

首先,传感器产生一条"空气质量超标"事件,并将其传输到用户自定义的"空气质量"事件总线。

用户的全屋系统接收到这个事件后,分别计算室内外空气质量,得出室外空气超标,然后将窗内外空气质量事件发送到用户自定义的"窗内外空气"事件总线,窗户控制函数作为执行者,向IoT服务发出关窗指令,然后传输窗户状态事件。

全屋系统得知窗户都已关闭后,继续根据用户定义的全屋逻辑,向新风控制、灯控等对应的事件总线发送相应的事件,以完成全屋控制。

调停者模式的示例就介绍到这儿。接下来,我来介绍管道和过滤器模式。

管道和过滤器模式

1e9acac7-1502-4434-87a1-4eb764094b4b.png

管道和过滤器模式由三个角色组成:源服务、管道函数、目标服务。

源服务产生的事件,经历多个事件总线,被相应的管道函数执行转换、过滤、聚合等操作,最终将新的事件,经事件总线传输给目标服务。

示例:在线学习

87248b6d-06d2-4c76-a13b-3d2cfa3932ef.png
接下来,我来展示一个使用管道和过滤器模式实现人工智能服务在线学习的例子。

我们都知道,AI的兴起源自大数据。我们今天所使用的各类人工智能服务,背后都有一个或多个业务算法模型。这些模型通常是由算法架构+离线的、批量的大数据反复训练而成的。由于这些服务具有天然的数据相关性,因此实时发生的在线数据会对模型的改进有一定的帮助。

这里,我们假定出行推荐系统源服务出行模型训练服务目标服务,中间的各个函数为管道函数

出行推荐系统将实时的路况事件传输到实时交通事件总线。

实时交通事件总线的事件目标是两个功能不同的函数。

  • 第一个函数负责完成数据清洗和特征提取,然后生成特征事件,传输到特征事件总线。
  • 第二个函数负责数据标注,将原始数据打标后,生成标注数据事件,传输到标注数据事件总线。

特征数据事件总线的事件目标同样是两个功能不同的函数。这里不再冗述。

最终出行模型训练服务会根据实时数据,训练出一个新的模型。这里省去了模型回归等工业化流程细节。

3 事件中心

到这里,我们对EventBridge作为事件传输、存储和路由的管道能力有了一定认识。接下来,我将介绍EventBridge的另一大特点,事件的中心化查询、展示、分析能力。

75df1fab-194c-44c8-ba58-d8a6389fa220.png

如前所述,EventBridge基于标准的事件协议CloudEvents,正逐步将事件孤岛统一、融合到一起,形成完整的事件生态体系。

在这个生态体系下,事件中心将用户使用的云产品、第三方SaaS服务、用户服务、云下服务所产生的事件统一到一起,为用户提供全方位的事件查询、可视化和分析能力。

7c9324c0-3a67-4cf4-876c-593ebc6e7e31.png

  • 事件中心以租户维度,为用户提供一个或者多个事件总线的查询和分析。
  • 针对事件特征鲜明的服务或者云产品,事件中心提供了大盘和图表,方便用户实时观测。
  • 同时,事件中心提供了事件告警和事件卡片,实现用户以0代码的方式处理特定的事件。

事件中心让事件的价值最大化,从事件角度为用户的云原生服务提供可追踪、可度量、可观测性。

4 展望

阿里云事件总线EventBridge作为云上的事件枢纽,最核心的能力是连接。无论是在线业务场景、IoT场景、还是大数据场景,无论是阿里云、其他云厂商,还是私有IDC机房,我们都将提供安全可靠的集成方式。

未来,EventBridge会重点发展生态网络。云时代下这么庞大的神经中枢系统,不是一日可以建成的,我们需要并期待与你一起共建云原生事件驱动架构生态。

中间件消息团队现开放转岗HC,欢迎你的加入!

同时欢迎你扫码进群,一起聊RocketMQ和EventBridge。

c20f03f2-5d65-4b61-be10-1cad84a9fe38.png

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
相关文章
|
9天前
|
域名解析 弹性计算 运维
基于云效流水线高效构建企业门户网站体验评测
阿里云云效流水线作为一款企业级持续集成和持续交付工具,在助力高效构建企业门户网站方面表现出色。
861 7
基于云效流水线高效构建企业门户网站体验评测
|
10天前
|
弹性计算 运维 持续交付
构建与部署企业门户网站:阿里云云效解决方案评测
在数字化时代,企业门户网站作为企业形象的线上窗口,其建设和运维效率直接影响着企业的在线品牌形象与用户体验。阿里云提供的“构建企业门户网站”解决方案,借助云效平台实现从代码到云端的无缝部署,为开发者和企业带来了前所未有的便捷性与效率。
124 5
构建与部署企业门户网站:阿里云云效解决方案评测
|
3天前
|
存储 弹性计算 安全
构建高效企业应用架构:阿里云产品组合实践深度解析
该方案展现了阿里云产品组合的强大能力和灵活性,不仅满足了当前业务需求,也为未来的扩展打下了坚实的基础。希望本文的分享能为读者在设计自己的IT解决方案时提供一定的参考和启发。
20 1
|
8天前
|
域名解析 弹性计算 开发者
期待已久,重磅回归,阿里云推出全新《高效构建企业门户网站方案》,你想了解的,这一篇就足够了。
期待已久,重磅回归,《高效构建企业门户网站方案》,你想了解的,这一篇就足够了。
48 1
|
10天前
|
弹性计算 安全 持续交付
深度评测:阿里云“高效构建企业门户网站”解决方案
阿里云的“高效构建企业门户网站”解决方案在操作便捷性、系统稳定性、扩展性以及成本控制等方面都表现出色,为企业用户提供了一站式的网站建设和托管服务。
28 3
|
12天前
|
消息中间件 监控 调度
构建Python中的分布式系统结合Celery与RabbitMQ
在当今的软件开发中,构建高效的分布式系统是至关重要的。Python作为一种流行的编程语言,提供了许多工具和库来帮助开发人员构建分布式系统。其中,Celery和RabbitMQ是两个强大的工具,它们结合在一起可以为你的Python应用程序提供可靠的异步任务队列和消息传递机制。
|
28天前
|
弹性计算 运维 负载均衡
【阿里云弹性计算】阿里云ECS在金融科技中的应用案例:高性能交易系统的构建
【5月更文挑战第27天】阿里云ECS助力某证券公司构建高性能交易系统,满足高并发、高可用和弹性扩展需求。ECS凭借最新处理器技术、高速内存实现高性能计算;支持多地域、多可用区部署保证高可用性;弹性伸缩特性适应业务波动,降低运维成本。通过分布式架构和负载均衡技术,实现交易请求高效处理,确保系统稳定运行。案例证明,阿里云ECS是金融科技领域构建高性能交易系统的理想选择。
143 1
|
7天前
|
消息中间件 Java 双11
RocketMQ:揭秘电商巨头背后的消息队列秘密
**RocketMQ概览:**高性能分布式消息队列,适用于有序消息、事务处理、流计算、消息推送、日志处理及Binlog分发。在双11等高流量场景下证明了其性能、稳定性和低延迟。Java开发,利于扩展,性能超RabbitMQ,支持死信队列,但可能有集成兼容性问题。适合Java开发者,为电商等场景优化,每秒处理大量消息。
27 3
RocketMQ:揭秘电商巨头背后的消息队列秘密
|
14天前
|
消息中间件 监控 应用服务中间件
消息队列 MQ操作报错合集之重启Broker后,积压数出现为负数是什么导致的
在使用消息队列MQ时,可能会遇到各种报错情况。以下是一些常见的错误场景、可能的原因以及解决建议的汇总:1.连接错误、2.消息发送失败、3.消息消费报错、4.消息重试与死信处理、5.资源与权限问题、6.配置错误、7.系统资源限制、8.版本兼容性问题。
消息队列 MQ操作报错合集之重启Broker后,积压数出现为负数是什么导致的
|
14天前
|
消息中间件 Java 测试技术
消息队列 MQ操作报错合集之设置了setKeepAliveInterval(1)但仍然出现客户端未连接,该怎么解决
在使用消息队列MQ时,可能会遇到各种报错情况。以下是一些常见的错误场景、可能的原因以及解决建议的汇总:1.连接错误、2.消息发送失败、3.消息消费报错、4.消息重试与死信处理、5.资源与权限问题、6.配置错误、7.系统资源限制、8.版本兼容性问题。

热门文章

最新文章