今天谈下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接口发布。这样可以更加方便上层微服务应用的访问和调用，实现微服务和底层消息事件架构的融合。
如上图，实际Order订单微服务仍然是在消费调用Rest API接口，但是这个数据EventMesh在获取后通过代理适配和路由转发将其写入消息中间件，然后CustomerService通过订阅端标准的能力实现对消息的获取。
简单来说消费端仍然调用Rest API Service服务，但是底层已经是异步的消息中间件和事件引擎，并且通过这个引擎实现微服务间的彻底解耦。
注：如果要实现彻底和消息中间件的解耦，那么在订阅端也不是通过消息中间件的API进行消息监听和订阅，而是订阅端本身提供一个Http Rest API接口来实现消息事件的导入。这个时候Mesh组件可以在获取消息后，去调用这个API接口能力将数据推送到目标端。当采用这种模式时候，消息中间件彻底演变为一个EventStore作用。
关键组件和分层架构
通过上图可以看出 EventMesh 横向分为 Control Panel、Data Panel、Store Panel 三层。
整体来说实际的业务系统和Data PanelApp这层进行交互，来失效消息事件的发布，订阅等，这个时候无须关注底层适配的消息中间件和底层事件存储逻辑。
在数据层实际是需要实现一个简单的代理，还是通过边车的模式将代理包下发到业务系统或微服务层，也就是说最终消息事件的发布，订阅，整个数据流不应该走到控制层，而是在业务系统和EventStore间之间交互完成，以避免引入一个新的中心点。
但是整个Mesh架构在去中心化的同时需要引入对于消息事件的管控治理能力，其中包括了注册，路由，安全，监控，度量分析等，这些能力在当前的Control Panel层来实现。Control PanelControl Panel 分为治理模块、注册模块、安全模块、指标模块、追踪定位模块， 这些模块都将采用业界通用、优秀的解决方案与 EventMesh 进行对接，进而丰富内容。EventMesh 的生态环境。例如：注册模块可对接 Nacos、指标模块可对接 Prometheus、追踪定位模块可对接 SkyWalking 等。
对EventMesh的简单总结
最后再简单做下总结。
当采用ServiceMesh的时候，我在谈可以通过ServiceMesh来实现一种去中心化的服务治理能力。同样道理，当采用EventMesh的时候，我们更加希望的是通过这个事件架构来实现去中心化的事件管控治理能力。
对于ServiceMesh的时候，如果一个大应用本身不对外，那么完全可以取消使用API网关，而对于EventMesh可以看到本身无法完全取代消息中间件，更多的是对消息中间件进行适配，将消息中间件能力变成一个EventStore的能力。基于这个思路你可以看到，你也可以完全不用当前消息中间件，而是基于Redis+自研来实现一个去中心化的消息事件管理架构。在这种情况下消息事件管理能力，本身也下移到了各个业务系统代理端来完成，而不是在中心化的消息中间件中完成。
事件驱动架构下，对于多语言，多环境，私有云和公有云的混合云管理和协同，物联网硬件设备的接口协同等提供了更好的支持和适配能力。这个本身是事件驱动架构的优势。
最后，EventMesh引擎本身是依托在云原生架构下的，其底层直接托管或部署到容器云上面，其上层又和微服务管理，微服务治理中心进行集成。如果做得好的话，EventMesh引擎本身也是一个对用户透明的底层引擎能力。
