简介：我们认为EventBridge是云原生时代的新计算驱动力。这些数据可以驱动云计算能力，创造更多的商业价值。作者：周新宇本文内容整理自中国开源年会。演讲首先做自我介绍。我是RocketMQ的PMC成员周新宇。目前负责阿里云RocketMQ和EventBridge的产品开发。我今天的分享主要包括以下几个部分：消息与事件、微服务与事件驱动架构阿里云EventBridge：基于RocketMQ内核构建阿里云统一事件中心的事件驱动架构实践云原生时代新趋势：Serverless+Event-Driven事件驱动架构的未来展望消息与事件、微服务与事件驱动架构首先说一下消息和事件的区别：大家都知道RocketMQ中的消息是一个很笼统的概念，也是比事件更抽象的概念.因为消息的内容体是一个没有任何定义的Byte数组，是一个弱Data，所以是一个很笼统的抽象。相比之下，事件可能更具体。一般来说，它有一个Schema来准确描述事件的字段。例如，CloudEvents对事件有明确的Schema定义。事件也往往代表着某一事物的发生或某种状态的变化，因此非常具体。在使用上，消息常用于微服务的异步解耦架构中。但是在这种情况下，事件驱动有点类似于消息。消息的应用场景往往发生在组织内部，消息的生产者知道消息将如何处理。比如在一个团队中，消息的生产者和发送者可能是同一个团队，同一个业务，对消息的内容有很强的共识。相比之下，事件的耦合更为松散。例如，事件的发送者不知道事件会被传递到哪里，谁会消费它，谁会对它感兴趣。不期望事件将如何处理。因此，基于事件的架构更加解耦。消息的应用往往还是离不开同一个业务部门，即使一些大公司顶多涉及跨部门合作。消息的使用受文档约束，事件受模式约束，所以我们认为事件比消息解耦更彻底。接下来，微服务架构和EDA架构有什么区别？首先是微服务架构。微服务是从单个应用程序发展而来的架构。例如，将单个应用拆分成多个微服务，微服务之间通过RPC进行组织和连接。以前一个业务可能会在本地安排一堆功能，现在通过一堆RPC连接起来。比如用户做前端点餐操作，后台可能有几个微服务做订单操作，一个微服务创建订单，一个微服务处理订单，再调整另一个微服务处理订单。通知完成的消息，是典型的RPC架构。但是纯RPC架构有很多问题，比如所有业务逻辑耦合在一起，只是用远程调用代替本地方法调用。当业务增长速度达到一定阶段后，会发现各个微服务的容量可能并不相等。例如，短信通知可以异步完成，但它是同步完成的。这样导致前端的流量很大，短信通知也需要准备同样的流量。当准备资源不足，上下游流量不对等时，可能会导致一个微服务挂掉，影响上游，造成雪崩效应。这种情况下，大家一般都会引入消息队列来进行异步解耦。这种架构非常接近于事件驱动架构。让我们以在用户前端创建订单为例。订单创建的事件会被发送到事件总线、事件代理、事件总线，下游的各个订阅者都会监听这个事件。处理。不同的是，消息订阅者是基于消息中间件厂商提供的SDK来进行消息处理的。业务往往需要转型，也会受到厂商提供的技术栈的束缚；订阅者需要开发什么样的技术栈，可以是一个HTTP网关，一个函数，甚至是一个历史遗留的遗留系统。只要事件代理兼容业务协议，就可以将事件推送给不同的订阅者。可以看出，广义订阅使用更广泛，解耦性更强，改造成本最低。阿里云EventBridge：事件驱动架构实践Gartner曾预测EDA架构将成为未来微服务的主流。到2022年，将有60%的新数字业务解决方案和50%的业务组织参与其中。同时，CNCF基金会还提出了CloudEvents规范，旨在使用统一的规范格式来声明事件通信。EventBridge也遵循这个标准。CloudEvents作为社区标准，解除了大家对供应商锁定的担忧，提高了各个系统之间的互操作性。相当于为各个系统约定了统一的语言。这是非常关键的一步。事件在开源社区有统一的规范，但在云端，很多用户从云厂商那里购买了很多云产品。这些云产品每天可能产生数以亿计的事件，这些事件存储在不同云服务的日志中。,内部实现。用户看不到也不知道云上的云产品实例发生了什么。每个厂商对事件的定义不同，整体上没有同类型的标准。各种云服务之间的事件是孤立的，即没有联系，不利于挖掘事件的价值。使用开源产品时也有类似的问题。用户往往没有统一的数据交换标准。当他们想要开放这些生态时，他们需要支付二次开发费用。最后，事件驱动应用在很多场景下的现状是线下的，现在线上场景使用EDA架构的人相对较少。一方面，由于没有基于事件的中间件基础设施，很难实时获取和推送一个事件，同时业务方可以全程跟踪。所以，以上也是阿里云做这个产品的背景。因此，我们定义了EventBridge，它有几个核心价值：1.统一事件中心：统一事件接口，定义事件标准，打破云产品事件孤岛。2、事件驱动引擎：海量事件源，毫秒级触发能力，加速EDA/Serverless架构升级。3、开放融合：提供丰富的跨产品、跨平台连接能力，促进云产品、应用、SaaS服务的相互融合。首先EventBridge的基本模型，EventBridge有四个部分。第一部分是事件源，包括云服务事件、自定义应用、SaaS应用、自建??数据平台。第二部分是事件总线，也就是存储实体。当事件来临时，它必须存储在某个地方以进行异步解耦。类似于RocketMQ中topic的概念，在具备一定存储的同时提供异步能力。事件总线有两种，一种是默认的事件总线，用于收集所有云产品的事件，另一种是自定义的事件总线，用户可以自己管理、定义和收发事件，以及用于实践EDA架构的概念。第三部分是规则。规则类似于RocketMQ的消费者和订阅，但是我们赋予了规则更多的计算能力，包括过滤和转换。第四部分是事件目标，即订阅者。如果你对一个事件感兴趣，创建一个规则来关联这个事件，包括函数计算、消息服务、HTTP网关等等。下面就详细说说这个事件规则吧。虽然类似于订阅，但事件规则具有轻量级的事件处理能力。例如，在使用消息时，可能需要先在本地获取消息，然后再决定是否消费。但是根据规则，这个消息可以在服务器端处理。事件规则支持非常复杂的事件模式过滤，包括匹配指定值，如前缀匹配、后缀匹配、数字匹配、数组匹配，甚至可以将这些规则组合起来形成复杂的逻辑匹配能力。另一个是转换器能力，事件目标的通用定义，可以接受多种事件格式，但不一定是下游服务。比如你想给钉钉推送事件，钉钉的API已经写好了，只接受固定的格式。然后，要将事件推送过来，您需要转换事件。我们提供以下内容：CompleteEvents：直接交付原生CloudEvents，无需转换。部分事件：通过JsonPath语法从CloudEvents中提取部分内容，传递给事件目标。常量：事件只作为触发器，传递的内容是常量。模板转换器：通过定义模板，您可以灵活地渲染自定义内容并将其交付给事件模板。功能：通过指定一个处理函数，通过自定义函数对事件进行处理，并将返回值传递给事件目标。目前EventBridge集成了80多个云产品，约800类事件，并首次打通了消息生态。比如RocketMQ就是一个微服务生态。如果实践消息事件的理念，我们可以直接将RocketMQ的事件传递到EventBridge中，通过事件驱动的架构来处理这些消息，甚至可以集成MQTT、KafKa等消息生态。除了开放阿里云消息产品，下一步还将开放一些开源和自建的消息系统。另一个生态是ISV生态。为什么ISV需要EventBridge？以钉钉6.0为例，最近发布了连接器能力。钉钉需要安装很多软件。这些软件可能由政府提供，也可能由ISV和第三方开发商提供，这导致数据互操作性很差。所以我们提供这个能力，让ISV的数据流通。最后是事件驱动生态。我们目前能够达成的事件目标有10种左右，目前还在不断丰富中。事件比消息更加解耦和离散，因此事件治理更加困难。所以我们做了事件中心，提供了三个能力：事件追踪：我们可以对每一个事件进行完整的追踪，从哪里产生的，什么时候发出的，什么时候过滤掉的，什么时候传递到某个目标的，当它被成功处理时。使整个生命周期完全可追溯。事件洞察&分析：让用户从EDA编程视角转变为用户视角，让用户更快速的了解EventBridge中有哪些事件，并进行可视化分析。通过EB可以实现就近计算分析，将业务信息直接导入事件总线，及时分析信息。事件市场：针对云产品，引导云产品定义业务事件，使云产品更加开放，提供市场能力。基于RocketMQ内核构建阿里云统一事件中心，EventBridge从一开始就构建在云原生容器服务之上。最重要的是RocketMQ核心。核心在该产品中扮演两个角色。一种是事件存储，用作存储；另一种是使用订阅功能将订阅转换为广义订阅。RocketMQ内核之上是连接集群。EventBridge更重要的能力是连接，所以EventBridge首先要有Source的能力，然后才能保存事件的来源；它的核心是Connect集群，每个Connect集群都有很多Worker。每个Worker负责很多事情，包括事件的摄入、事件的过滤、事件的转换、事件的回放、事件的跟踪等。同时在Connect集群之上有一个Connect控制平面，完成集群治理和Worker调度.上层是APIServer，一个事件入口网关。在EventBridge的世界中，有两种方式来摄取事件。一种是通过Connect的SourceConnector主动获取事件源，另一种是从用户或云端获取事件源。产品可以通过API服务器和我们的SDK传递事件。有多种交付方式，包括OpenAPI和多语言的官方SDK。同时，考虑到CloudEvents有社区标准，EventBridge也完全兼容社区开源SDK，用户也可以通过Webhooks来传递事件。这种架构的优势非常明显：(1)降低用户开发成本用户不需要额外开发事件处理和编写规则来过滤和转换事件(2)NativeCloudEvents支持拥抱CNCF社区，与社区SDK标准无缝对接协议，统一阿里云事件规范（3）EventSchema支持Source和TargetSchema绑定的事件schema自动检测和校验（4）全局事件任意互通建立了跨地域、跨账号的事件网络，支持跨云以及云原生时代跨数据中心的事件路由新趋势：Serverless+事件驱动我们认为Serverless+事件驱动是一种新的研发方式。每个厂商对serverless的理解都有自己的侧重，但是实现的方式都是一样的。首先，Serverless基础设施屏蔽了底层的IaaS，上层的Serverless运行时是计算托管，不仅托管微服务应用、K8s容器，还托管函数。EventBridge首先连接这些驱动程序的事件源，并可以触发这些运行时。因为Serverless最需要的就是驱动，而事件驱动给他带来了这样一个能力，就是计算入口。EventBridge驱动Serverless运行，然后连接后端服务。目前EventBridge和Serverless结合的场景主要是松耦合场景，比如前端应用、SaaS服务商小程序、音视频编解码等落地场景。那么，ServerlessEDA架构开发模式究竟是怎样的呢？以函数计算为例，首先，开发者需要从应用视角切换到函数视角，在每个函数中实现每一个业务逻辑；一个function代表一个代码片段和一个具体的业务，当这段代码上传后就变成了一个function资源，然后EventBridge可以通过事件来驱动function，通过事件组织function，形成一个具体的应用。函数在这里还需要做很多事情，而且大家都知道函数有很多缺点，最受诟病的就是冷启动。因为Serverless要求scale到0pay-as-you-go，当没有请求或事件触发时，应该直接接收0。从0到1是冷启动。有时这个冷启动可能需要等待一秒钟，因为它可能涉及下载代码、下载图像、构建命名空间、存储挂载和根挂载。片。Serverless的价格优势很明显。它的资源利用率特别高。因为是按量付费，可以做到接近100%的资源利用率，不需要做容量规划。举一个简单的例子，它是基于Serverless加EDA的极简编程范式，再举一个具体的例子，新零售场景下的EDA架构改造这个业务。首先，业务中有几个关键资源，可能包括API网关和函数计算。首先，可以打通一些数据，打通rds并同步rds数据，兼容一些历史结构，同时触发计算资源、函数、网关。整个架构的优势非常明显，因此具有极大的灵活性，不需要预留资源。事件驱动的未来前景我们认为事件驱动的未来有两个部分。一是做好云内云间的连接集成工作，让用户的多架构更加高效。二是开源生态的融合。我们可以看到开源生态越来越繁荣，所以也需要整合这些开源生??态中的数据。此外，还有传统的IDC计算能力、边缘计算能力等生态系统，都需要连接软件来连接它们。EventBridge是云原生时代的新计算驱动。这些数据可以驱动云计算能力，创造更多的商业价值。原文链接本文为阿里云原创内容，未经许可不得转载。
