我和我理解的 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 就是把函数的异步队列+异步触发器部分剥离出来了，实现起来难度真心不大，以下图架构为例：

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

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

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

{
   "specversion":"0",
   "id":"13a3f42d-7258-4ada-da6d-023a333b4662",
   "type":"cos:created:object",
   "source":"cos.cloud.tencent",
   "subjuect":"qcs::cos:ap-guangzhou:uid1250000000:bucketname",
   "time":"1615430559146",
   "region":"ap-guangzhou",
   "datacontenttype": "application/json;charset=utf-8",
   "resource":[
    "qcs::eb:ap-guangzhou:uid1250000000:eventbusid/eventruleid"
   ],
   "data":{
      $data_value
   }
}

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

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

写在最后

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