近年来,随着微服务、云原生和 Serverless 概念的普及以及容器化技术的发展,事件驱动也再次成为热点,引起 IT 界广泛的关注。事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言,事件的捕获、通信、处理和持久保留是解决方案的核心结构。事件驱动架构可以最大程度减少耦合度,很好地扩展与适配不同类型的服务组件,因此是现代化分布式应用架构的理想之选。
本文会从以下几个方面来剖析 Apache EventMesh 云原生分布式事件驱动架构:
Apache EventMesh 是⼀个⽤于解耦
应⽤和后端中间件层的动态云原⽣事件驱动
架构基础设施。它⽀持⼴泛的⽤例,包括复杂的混合云、使⽤了不同技术栈的分布式架构。
上面这张图我们可以看到 EventMesh 所处的位置就是连接云应用和基础设施的一个中间层, Event Mesh 与 Service Mesh 具有同等的定位,而且它本身支持云原生的部署方式并且可以在 Kubernetes 上运行。
Service Mesh 更多的是集成 RPC 的服务,是同步调用的,可能存在一定的耦合度。而对于 Event Mesh 来说,更多的是集成的事件驱动的微服务,这种微服务的特性就是松耦合和异步的。
从上面这张图可以看出,EventMesh 可以接入的应用有很多:分布式应用、云原生应用和服务、IoT 设备、数据流、云合作伙伴以及其它的云厂商。通过标准的 CloudEvents 协议接入到 EventMesh,通过这种事件驱动的架构,可以提高应用的弹性伸缩能力,因为它们借助 EventMesh 实现了通信的解耦。
EventMesh 内部具有 Orchestrator 的能力,可以自定义数据源触发器以及实时处理函数,对于其它接收到的事件,Orchestrator 可以路由到上面这些服务,包括无服务的计算(像容器、函数、IoT 应用)、监控或通知类服务、数据分析类服务。
举个例子,比如我在 Github 上提了一个 PR,其实都是可以配置这种 WebHook 的,其实就是类似这种旁路消息的通知机制,有任何的变动,都会推送过来。对于通知服务来讲,它并不关注推送的目标是谁,并且也不关注我产生的事件你是如何使用的或者被谁使用,它只关注产生事件就好。
那基于这样的场景接入到 EventMesh 的话,那 EventMesh 其实具备事件路由、事件转换、事件过滤的能力,你可以基于这样的事件去配置相应的规则,比如正向过滤、排除过滤。
EventMesh 本身对外提供了轻量级客户端,标准化接口和协议。上面我们有讲到 EventMesh 的定位是基于应用与基础设施的中间层。应用通过轻量级客户端可以接入 EventMesh,进而实现与基础设施强绑定的解耦。
上图的左边部分也就是我们 EventMesh 内部的一个架构,EventMesh 对外提供了不同类型的 API,包括 Java、Go、C、Python 等。左边最中间这部分其实是 EventMesh 的运行时状态,它本身支持集群化 Gateway 的方式部署,同时也可以支持容器化 Sidecar 的方式部署。
EventMesh 内部主要分成以下几个部分:协议、可观测性、处理器、编排以及存储。不同的部分都做了插件化处理,像协议的部分支持 HTTP、TCP、gRPC、MQTT,内部通信的话都会转成 CloudEvents,相当于适配器的功能。
SPI(Service Provider Interface)机制
设计思想:
借助 EventMesh 可以将事件源与事件目标进行打通,比如左边的 RDMS 关系型数据库的数据发生了更新,EventMesh 将以通知的形式通知到事件目标比如 MQ,这样就可以跨消息中间件、跨存储的一个同步。这里其实借助 EventMesh brige 的能力,看起来只是像跨组件,但实际上两边的 EventMesh 可能不是一个集群的,它其实可以跨网络,往大的说还可以跨企业之间的联通,以及公有云与私有云的数据交换。
EventMesh 在整个事件驱动的这套系统中,起到的是事件编排的能力,EventMesh 会有无服务计算的工作流引擎,同时配合 AsyncAPI,AsyncAPI 可以定义这些服务节点的描述,Workflow 的工作引擎是符合 Serverless Workflow 规范标准的,通过这种方式可以完成一套工作流的定制与运作。
EventMesh Workflow Engine 主要分为三大块:EventMesh Catalog、EventMesh Workflow Engine、EventMesh Runtime。
对于 EventMesh Catalog 而言,其实就是对哪些服务定义了,定义了之后,通过 Catalog 内部的 AsyncAPI 解析器,解析出来 Publisher Module、Channel Module、Subscriber Module,这些节点在下面的工作流 DSL 定义,EventMesh Workflow Engine 解析到 Workflow 节点后,会跟 EventMesh Catalog 有个交互,会查询服务有哪些 Publisher 以及 Subscriber,Engine 这边触发了事件后,会发给 EventMesh Runtime,最后才会推给下游的应用,整个一套 EventMesh Workflow Engine 是可以实现工作流的流转。