Apache EventMesh 事件驱动分布式运行时
《Apache EventMesh》系列:
01 Apache EventMesh 事件驱动分布式运行时
02 Apache EventMesh Connector 插件架构与连接生态
03 Apache EventMesh Serverless Workflow 设计与实现
04 Apache EventMesh FaaS 运行时
05 基于 Apache EventMesh 构建场景连接器
前言
Apache EventMesh (Incubating) 是一个用于解耦应用和后端中间件层的动态云原生事件驱动架构基础设施。它支持广泛的用例,包括复杂的混合云、使用了不同技术栈的分布式架构。
EventMesh 是什么
云原生时代,Service Mesh 被用作微服务的基础设施层,使通信变得更加灵活,可靠和快速。虽然服务网格可以很好地支持同步 RESTful 和一般<请求-回复>的交互,但它不支持异步、事件驱动的交互,也不适合将云原生微服务与遗留应用程序连接,也不适用于 IoT。 事件网格使企业能够支持事件驱动的体系结构,从最小的微服务部署,到以易管理、健壮、安全和架构良好的方式将应用程序扩展到混合云。 它提供了动态和全部实时地集成遗留应用程序、数据存储、现代微服务、SaaS、物联网和移动设备的能力。 事件网格为应用程序开发人员和架构师提供了构建和部署分布式事件驱动应用程序的基础,无论他们需要在何处构建和部署。
EvnentMesh定位在云原生事件基础设施,通过标准 cloudevents 事件标准 API,分离应用和中间件层,并且可以借助 workflow 引擎对事件进行编排。Runtime 运行时是一个微内核插件化架构,可以连接不同的中间件,存储,可观测性,工作流引擎等组件。
EventMesh 运行时架构
EventMesh Runtime 是一个微内核,插件化的架构,可以对接到后端的中间件或者服务,比如事件的存储 RocketMQ、Kafaka 以 及 Apache Pulsar 等;如果需要有一些状态更新维护的时候,可以对接到后端的 Redis、MySQL 以及 Mongo DB 等;如果需要有一些冷数据更新的时候,也是可以通过插件化的形式连接到 S3,ES 等存储。
在控制层面,如果需要对事件的调用链进行跟踪、元数据进行管理以及分布式协调性的时候,EventMesh Runtime 也可以对接到 ETCD、NACOS、 Prometheus、Zipkin、Skywalking、OpenTelemetry 等。我们内部最常用的是 RocketMQ 以及 Redis 两个插件,不过 EventMesh 也可以很方便地与 Kubernetes 进行集成,这是因为 EventMesh Runtime 可以作为 Sidecar 部署,也可以作为 Gateway 部署。
EventMesh 相关特性
事件总线
事件驱动架构(EDA)是一种以事件为纽带,将不同系统进行解耦的异步架构设计模型。在 EDA 中,事件驱动的运行流程天然地划分了各个系统的业务语义,用户可以根据需求对事件与针对此事件做出的响应灵活定制,这使得基于 EDA 架构可以方便地构建出高伸缩性的应用。
HTTP Source 事件源是 EventMesh 支持的事件源的一种,它以 Webhook 形式暴露了发布事件的 HTTP 请求地址,用户可以在有 URL 回调的场景配置 HTTP Source 事件源,或者直接使用最简单的 HTTP 客户端来完成事件的发布。HTTP Source 事件源提供了支持 HTTP 与 HTTPS,公有云 VPC 等不同请求方式、不同网络环境的 Webhook URL,便于用户将其集成到各类应用中。接入时无需使用客户端,仅需保证应用可以访问到对应 Webhook URL 即可,这使得接入过程变得简单而高效。
在将 HTTP 请求转换为 CloudEvent 的时候,EventMesh 会将请求的头部和消息体部分置于 CloudEvents 字段中,其余字段会依据用户 EventMesh 资源属性以及系统默认规则进行填充。用户可以在事件规则中,对所需的内容进行过滤、提取,最终按照模板拼装成所需的消息内容投递给事件目标。
EventMesh WorkFlow Engine
EventMesh-Workflow 是包含事件执行逻辑定义和流程的 EventMesh 原语。
1.定义 Task 的执行顺序,以及 Task 间数据传递(input/output)
2.编排 Task,并已正确的顺序 trigger task
3.超时或失败优雅重试,最终一致性
我们利用无服务器工作流 DSL 来描述 EventMesh 工作流。根据其规范,工作流由一系列用于描述控制流逻辑的工作流状态组成。目前我们只支持事件相关的工作流状态。请参阅Workflow DSL Design中支持的状态。
一个工作流状态可以包括 Actions 应在工作流执行期间调用的服务/功能。这些 Actions 可以引用 Function 定义如何调用这些功能/服务的可重用定义。它们还可以引用触发基于事件的服务调用的事件,以及等待表示此类基于事件的服务调用完成的事件。
在 EDA 解决方案中,我们通常使用 AsyncAPI 定义我们的事件驱动微服务。无服务器工作流 function 定义支持使用 AsyncAPI 定义调用语义。有关详细信息,请参阅为AsyncAPI 服务使用函数。
支持强大的、业界通用的控制流逻辑
CNCF Serverless Workflow 规范本身提供了非常强大的控制流逻辑,包括了大多数业界支持的核心功能,如顺序执行,以便用户可以定义流水线。在顺序执行的基础上,用户也可以定义并行的执行,如并行调用函数或微服务。另外,也支持使用不同种类的循环结构执行数据库循环调用之类的工作流。此外,重试、错误处理、工作流的手工干预,还有诸如等待和恢复之类的标准能力都被 CNCF Serverless Workflow 的规范所支持。
为解决实践中业务级的问题,CNCF Serverless Workflow 规范增强了诸多重要功能:自动重试、密钥和常量;定义可插拔的表达语言,以便用户可以插入自己选择的表达语言;不同类型的超时,如全局超时或分支超时等;短时和长时工作流的支持;工作流执行期间的补偿处理,如撤销已经成功完成的工作或状态;休眠,如等待某种事件或状态。
提供自定义拓展能力
除了上述核心的控制流逻辑,CNCF Serverless Workflow 规范也提供了自定义扩展能力。目前社区规范提供两个拓展:关键性能指标和限流。 用户可以通过关键性能指标的扩展能力(如工作流的整体指标、事件的消费与生产指标、函数使用指标、工作流状态指标等)定义工作流,使用自定义指标衡量工作流的性能,对性能和成本进行增强。此外,用户也能够通过限流的拓展能力对调用进行速率的限制,这在无服务器领域尤为重要,比如函数调用并发的限制、调用事件数量的限制、工作流状态总数的限制、工作流执行期间转换的限制等。
EventMesh Streaming
在当前的微服务下,当我们进行流量调度的时候,肯定需要解码消息头,根据消息头的特定字段,路由到对应的服务上以便增加策略。
实际上在事件驱动中,首先我们不需要解码报文,我们在它的消息主题设计上,可以解决类似的问题。比如可以设计非常多 Topic 层级,层级与层级之间有递进关系,以此来实现动态的过滤。其次,当消息到达之后,可以很方便地针对消息进行报文解析,在产生的事件上面,我们可以增加非常多的 Match 处理函数,产生的消息可以实时地经过 filter chain 的处理。事件的处理都可以由 EventMesh 来完成。
动态扩缩容
目前 Kubernetes 扩缩容是基于 HPA 机制运作的。下面举两个常见的场景。
首先是扩容场景,例如,在当前的 CPU 占用很高的时候,正常情况会触发扩容事件,但我们在消息队列中,并没有看到特别多的消息堆积,也就是说,这个时候并不需要扩容,实际上这个扩容是浪费的;其次是缩容场景,例如在消息队列里,当前没有消息堆积,理论上实例是可以缩容,甚至可以缩容到零,但是因为 CPU 的使用导致无法顺利缩容。
但是这两种场景,如果在事件驱动的服务下,我们采用 Queue 队列堆积的监控方式可以实现以下效果。首先是在资源占用很高,但队列的任务没有堆积的情况下,可以不进行扩容;其次,在占用当前的 CPU 的资源,但没有任务处理的情况下,可以进行缩容。在我看来,伸缩监控的指标应该根据当前处理的任务堆积情况来判断。
目前该特性 EventMesh 是与 OpenFunction 社区进行合作,集成 OpenFunction,整体构建 Serverless & FaaS 生态。
1. 将 OpenFunction 集成 EventMesh-Worklow,作为 OpenFunction 函数编排引擎,2. 将 EventMesh Runtime 作为 OpenFunction 异步事件运行时,替换 Dapr 异步运行时。
Summary
今天的 IT 系统正在生成、收集和处理比以往更多的数据。而且,他们正在处理高度复杂的流程(正在自动化)以及跨越典型组织边界的系统和设备之间的集成。同时,预计 IT 系统的开发速度更快、成本更低,同时还具有高可用性、可扩展性和弹性。为了实现这些目标,开发人员正在采用架构风格和编程范式,例如微服务、事件驱动架构、DevOps 等。正在构建新的工具和框架来帮助开发人员实现这些期望。开发人员正在结合事件驱动架构 (EDA) 和微服务架构风格来构建具有极强可扩展性、可用、容错、并发且易于开发和维护的系统。
EventMesh 作为事件基础设施,主要负责事件的传输、路由和序列化。它可以提供用于处理事件流的 API。事件基础设施提供对多种序列化格式的支持,并对架构质量(例如容错、弹性可伸缩性、吞吐量等)产生重大影响,也可以存储事件以创建事件存储,事件存储是恢复和弹性的关键架构模式。
打个广告:
目前 ServlessWorkflow 以及 OpenFunction 集成还有大量 Feature 在规划中,感兴趣的同学可以一起参与进来,为 EDA/Serverless 架构演进贡献一份力量。下面是 EventMesh 小助手二维码,有兴趣欢迎加入共建。
另外本周六(2022-11-19)有个 Apache EventMesh&Apache APISIX Meetup,感兴趣也可以参与下。
https://www.oschina.net/event/2327421
链接:
版权声明: 本文为 InfoQ 作者【EventMesh布道师】的原创文章。
原文链接:【http://xie.infoq.cn/article/65e4894ccc0468bd8a52499c0】。文章转载请联系作者。
评论