我和我理解的 EventBridge – 写在发布之前

EventBridge  内部孵化很久了,文档和产品介绍页都已经公开了。从一开始调研到推动大佬们投入,再到现在的方案落地,一直在围着这个新产品连轴转,也借机在博客简单聊聊我对这块的一些想法。

这事儿如果按照经典 lambda 的计算场景来看,在整个 lambda  Serverless 体系其实算是比较重要的一环。它其实是函数触发器更具象的产品化能力,除了典型的事件触发场景,我想让它的价值也不会仅仅局限于事件触发到函数这么简单,更愿意将它归为面向 EDA( (Event-Driven Architecture,EDA) ) 场景的,类似 Kinesis 的数据处理的中间件。

最开始的出发点

其实如果把EventBridge(下文简称EB)和生产场景画上等号,其实最关键的就是 EDA 了。事件驱动 EDA (Event-driven Architectures)最重要的场景是通过连接应用程序、云服务和无服务器功能来自动化企业生产工作流程。上图是 Gartner 2018年十大战略技术趋势的情况,EDA 赫然在列。

当然,一张图或者竞品的一些行为并不能左右一个项目是否落地。在搞这事儿之前,其实是有些核心场景驱动的,比如:

● 事件驱动收口
目前所有触发器对接直接使用 invoke function 接口,函数是较为典型的事件/时间驱动型产品。事件其实是函数拓展场景的唯一方式/渠道,也是使用函数的基石。通过 Event Bridge 一方面可以将函数接入的事件发挥更大作用,另一方面也为函数提供了统一的事件归口,后续接入的触发器事件全部通过 Event Bridge 进行事件处理/规则转发,极大减小对接产品事件的开发量。目前云上的的事件目前非常独立,无法形成规模效应,很难挖掘出有用的业务价值。其实这里EB很大的职能就是把全部新增的触发器都接起来。

● 状态变化通知
事件总线EventBridge可以作为中心接收所有应用的状态变化,然后将这些应用状态变化分别路由到需要感知这些变化的服务。大致推送流程与目标端方案如下:

● 流式数据通道
EventBridge 另一个核心能力是为流式的数据承担通道的责任,通过 CloudEvents 规范和 Schema 注册表(Coming Soon)来统一描述这些数据,并提供基础的过滤和转换的能力,在不同的数据仓库之间、数据处理程序之间、数据分析和处理系统之间进行数据路由。连接不同的系统与不同服务。
通过大量的 Source 和 Sink Connector 将用户的云数据与SaaS数据在云上流动起来。

● 构建事件驱动型架构(我认为在国内开发者环境下最不靠谱的一个场景,但是出于对AWS的尊重还是放上去吧)
借助事件总线EventBridge,无需了解事件源,就可以直接筛选并发布事件。Serverless 应用架构的最佳实践便是事件驱动,无论是传统的微服务还是函数计算,EventBridge 将极大地简化事件驱动架构的研发成本,海量的函数以及微服务将以事件的形式被有序协调。

 

一些 Event Bridge 涉及的领域前景:

● BPM (Business process management)
业务流程管理市场规模(BPM),预计将从2020年的88亿美元增长到2025年的144亿美元

● IPaaS(Integration platform as a Service)
集成平台即服务(iPaaS)市场规模,预计将从2016年的5.280亿美元增长到2021年的29.983亿美元

● RPA(Robotic process automation)
机器人流程自动化(RPA)2019年,全球RPA市场规模为14.0亿美元,预计从2020年到2027年,复合年增长率(CAGR)为40.6%

● Serverless
到2025年,市场价值211亿美元

 

千里之行

场景明确了,那我们来聊聊竞品和周边生态吧。首先,EventBridge 是个舶来品,其实我一开始很讨厌这个名字,但确实碍于减少认知障碍所以不得不进行了妥协。这里,我不认为 EventBridge 的想象力仅仅是传统的,AWS 的 “EventBridge”。所以这里我把调研范围扩大到 AWS AppFlow ,TRIGGERMESH 等周边能力。当然还有其他更多产品的调研比如 Azure 的 Event Grid,受限于篇幅就不过多介绍了。

首先的话还是来看看 EB 的产品形态该怎么定,这里简单列了一些不是详细的功能调研,只是让大家清楚业内的情况:

Amazon EventBridge

Amazon EventBridge 是一项独立的 Serverless 服务,让用户可以无需编写代码即可实时了解 AWS 服务、自己的应用程序以及软件即服务 (SaaS) 应用程序中的数据的变化。

看过无数 Youtube 上 AWS 的宣讲,给人的直观感觉:

  1. AWS EventBridge 主要还是做控制类或者是管理类的事件,状态变更或者监控资源等场景。
  2. AWS EventBridge 将重点全部放到了 SaaS,但其实发布这么多年了,接入的厂商很少。主要原因想了下有几点,a. AWS的事件总线只能被动接收,其实整个架构都是 PUSH模型,SaaS 第三方接入费时费力。b. 整体接入成本很高,调用链路过长,对第三方研发素质要求较高。
  3. 重点推的是微服务解耦或EDA场景,这里其实想象力很大,但是EDA架构其实目前看不算是比较核心的。
  4.  收费比较贵,这种付费模式基本告别了数据流客户。
  5. 主流 Target:函数/消息队列

Amazon AppFlow

Amazon AppFlow 是一种全部托管的整合服务,主要功能是在软件即服务(SaaS) 应用程序与AWS 服务之间安全地传输资料。使用Amazon AppFlow 在几分钟内即可自动化完成资料传输,无需进行编码。(这里的功能点和 EventBirdge 合作伙伴事件源很类似)

 

整体看下来,AppFlow的大部分能力其实可以由EventBridge承载,更像是EventBridge + Lambda的方式。通过抓取,映射,筛选等方式将数据端从A到B进行全托管式的对接。
不过 AppFlow 的整合SaaS连接部分可以借鉴,相对于较重的合作伙伴那种方式的对接,AppFlow的对接方案全部落在AWS侧,可对事件完全自定义采集,合作方几乎不用做任何工作即可完成事件对接。相对与 eventbridge 让合作方 Push 的形式,AppFlow 获取合作方 SaaS 事件的形式是 Pull。

 

TRIGGERMESH

Triggermesh 是多云场景下的事件桥工具,提供更为拓展和强大的事件源,通过Broker各个云Bridge的方式实现全云端触发,它更加关注源头采集。整体使用较为流畅。它的架构如下:

 

搞完这些后,脑海里其实已经大致知道 EventBridge 到底长啥样了,主体还是延续经典EB的能力,然后在小的方向作些突破。总结下来就是取长补短:

  1. 解决PUSH模式下,第三方比较难接入的问题。终极解法其实就是增加PULL
  2. 增加数据流时间也就是 Batch 计算的处理方案,能想到的点比如 在Batch批量投递的场景下去掉原本的 EventPattern 逻辑,减小服务压力。
  3. 对端到端的数据链接提供更优的体验。

 

一叶知秋

其实 EB 就是把函数的异步队列+异步触发器部分剥离出来了,实现起来难度真心不大,以下图架构为例:

中间需要解耦一些类似事件集和事件规则的概念。经过简单梳理:
控制流产品设想的架构大概就出来了:

数据流逻辑设计的架构如下:

整体产品大概就是这些,比较重要的还有事件体部分,大概定义是这样的:

这样,EB 其实整体形态就完成90%,还有Target端消费速率这块的设计大概这样:

当异步触发执行无法满足处理请求时,会触发异步投递扩容策略,该扩容策略不会产生额外计费。
异步触发执行扩容速度,首次产生调用即扩容 500 个 异步触发执行数,如扩容完成后,队列内仍然有消息并且未达到投递上限,则会以 5s 为步长每次扩容 500个。下面图例展示了异步触发执行扩容的具体扩缩容情况。

 

写在最后

感觉产品上线后自己脾气变好了。太神奇了。总也算是自己留在诺大互联网的一点足迹。