谈云原生基础设施-EventMesh事件驱动网格
发布时间：2022-07-06 09:50:23 所属栏目：云计算 来源：互联网
导读：今天谈下EventMesh事件驱动网格，实际在我前面谈云原生技术类的文章中对于ServiceMesh服务网关，EDA事件驱动架构都做过详细介绍。在去年腾讯微众银行开源了自己的EventMesh事件驱动网格和金融消息中间件。 因此今天就EventMesh相关架构资料谈下自己对EventMe
|
今天谈下EventMesh事件驱动网格，实际在我前面谈云原生技术类的文章中对于ServiceMesh服务网关，EDA事件驱动架构都做过详细介绍。在去年腾讯微众银行开源了自己的EventMesh事件驱动网格和金融消息中间件。 因此今天就EventMesh相关架构资料谈下自己对EventMesh的理解。 EventMesh概述 EventMesh 是以事件驱动为核心的基础服务，EventMesh 之于微服务与Service Mesh 具有同等的定位。EventMesh 作为动态的插件式云原生基础服务层，将应用程序和中间件层分离，并提供了灵活，可靠和快速的事件分发能力，同时可以对事件进行管理，可以作为应用进程的连接层，提供企业实现其数字化转型目标所需的全套应用进程间通信模式。 参考网上另外一个解释如下： 事件网格对于事件驱动的应用程序，就好比是服务网格对于 RESTful 应用程序：一个架构层，无论在哪里部署这些应用程序(非云，公有云或者私有云)，都可以动态路由某个应用程序的事件并使其被其他应用程序所接收。事件网格由内部连通的 Event broker(事件代理)网络来创建和启用。 可能看了这个还是不好理解EventMesh。 在这里我想强调几点。 其一EventMesh的底层仍然是事件驱动架构，仍然是消息中间件，其核心是基于消息的异步机制，消息发布订阅机制。而传统的Rest API接口更多的是一种同步调用模式。通过消息事件机制的引入，可以更好地实现解耦。 其二就是这类强调了Mesh网格化的概念，即引入EventMesh不应该是再增加一个中心化的节点，而应该是一种类似ServiceMesh中的Sidecar代理模式的方式引入。要做到这点，参考Mesh架构的标准思路，其控制平面和数据平面应该是分离的，这个是Mesh架构的基础。因此对于EventMesh实现也需要遵循这个原则。 为什么需要使用EventMesh? 这个仍然需要从两个方面来回答，第一个内容实际本身是为何需要采用EDA事件驱动架构或者CQRS模式要回答的问题。这个问题本身核心还是通过消息机制对于业务的彻底解耦，其次是类似消息1对多发布订阅，大并发下的削峰处理等。 当事件驱动架构变为云原生下的EventMesh后，带来哪些变化? 实际上这里需要谈两点。 其一是EventMesh是融入到整个云原生整体技术架构体系框架的，即底层和Kurbernetes和Docker容器云的基础，上层和当前主流的微服务融合集成。而对于我们传统谈到的消息中间件，变成了一个EventStore。 其二我个人认为引入EventMesh实际是在传统的容器云底层，消息中间件上层引入了一层抽象和统一适配，让微服务下对事件机制的使用，包括事件的发布，事件的订阅更加简单，同时也统一标准化。其次是在适配层引入对事件本身的治理能力，类似安全，路由等各种事件管控治理能力。 微众开源EventMesh架构 EventMesh 目前整体的架构如上图所示，通过以事件驱动为核心的体系结构,实现了应用程序与中间件层的解耦分离。对于这个架构简单做了理解。 首先整体EventMesh是可以运行在云原生的容器云平台上的，底层直接和容器云平台对接。 其次是Connector连接器部分。当前EventMesh通过连接器的方式对接和适配了多个消息中间件，类似Kafka，RocketMQ，微众自己的金融消息中间件，还有Redis分布式缓存等，这些都作为EventMesh的EventStore。 在原来我们使用消息中间件的时候都知道，对于不同的消息中间件，其发送消息事件，对消息事件订阅和监听，具体的API接口和实现方式本身都有差异，而通过EventMesh，我们可以在代理层来屏蔽这些差异，实现底层消息中间件能力的透明化。 对于EventMesh最核心的还是Runtime运行时。 客户端所发出的事件交予 Runtime 调度的 Connector，将事件存储到对应的地方。Event Store 进而再由订阅对应事件的 EventMesh 将事件接收并转发给所代理的下游客户端。也就是说在核心引擎部分，可以实现协议转换，事件路由，消息中间适配，负载均衡，事件链路监控，安全等各种治理能力。 而这些能力并不需要消息事件的消费端和订阅端去提供，而是通过Mesh架构在代理中通过各种插件来实现，这个思路实际和ServiceMesh边车模式思路一致。 所以EventMesh实现机制中核心并不是将已有的消息中间件能力重新实现一遍，而是在当前主流消息中间件上增加了一个适配层，并在该层完成消息事件的统一管控治理，如果再朝上抽象，还可以进一步做消息事件的组装编排等。 事件能力对外发布 eventmesh-sdk-java：当前支持 HTTP 和 TCP 协议，未来会支持 gRPC 等。对于这点，再展开说明下。 当我们在采用某种消息中间件的时候，比如RocketMQ消息中间件，你会看到该中间件本身有自己的Java API接口，来实现事件的发布，消息的监听和订阅等。如果是在一个微服务架构体系下，那么在业务系统或微服务端，实际是需要安装和部署一个代理包来实现本地代理。那么当代理包本身有升级的时候，所有的消费端和订阅端都必须做出配套的修改。 在我们早期实施SOA的业务场景中，就存在使用JMS消息中间件来实现消息一对多分发的场景。在整个实现过程中，我们对JMS消息进行了一层代理和适配。 将JMS消息发布能力封装为一个标准的Rest API接口服务，这样消费端就不再需要安装任何代理组件，直接调用Rest API接口来实现消息发布。 但是对于订阅端，很难做这种适配，仍然是需要安装一个代理Jar包，通过传统的方式来实现消息事件的监听和订阅。在这种场景下可以看到，如果需要替换消息中间件，或消息中间件本身代理包版本升级的时候会很麻烦，基本所有的订阅端都需要配套升级。 在引入EventMesh+微服务+容器云后可以更好地解决这个问题。 对于EventMesh运行引擎组件，我们可以在进行镜像制作的时候动态下发到镜像里面，并完成动态部署。这个不再需要人工去操作了。 其次我们在Mesh中做一层适配，形成一套标准的API接口和订阅机制，这样在消息中间件本身出现变更或替换的时候，对业务系统影响最小。 同时对于消息发布的能力，我们在消息层上面封装为Http Rest API接口发布。这样可以更加方便上层微服务应用的访问和调用，实现微服务和底层消息事件架构的融合。 （编辑：鞍山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
