EventMesh 1.3.0 发布!支持 CloudEvents 协议、Standalone、可观测性等
CloudEvents
每一个发生(Occurrence)都会产生事件(Event),包含了相关的上下文和数据。每一个事件都具有数据唯一标识。事件代表事实,因此不包括目的地,而消息则传达意图,将数据从源头传送到特定的目的地。
缺乏通用的描述事件的方式意味着开发人员必须不断地重新学习如何消费事件。这也限制了类库、工具和基础设施在跨环境时发送事件数据的潜力,如SDK、事件路由器或跟踪系统等。我们从事件数据中实现的可移植性和生产力总体上受到了阻碍。CloudEvents是一个用通用格式描述事件数据的规范,以提供跨服务、跨平台和跨系统的互操作性。CloudEvents得到了大量的行业关注,从主要的云提供商到流行的SaaS公司都有。CloudEvents由云原生计算基金会(CNCF)主办,于2018年5月15日获批为云原生沙盒级项目。
Eventing
在服务器端代码中,事件通常用于连接不同的系统,其中一个系统的状态变化会导致另一个系统的代码执行。例如,当源接收到外部信号(如 HTTP 或 RPC)或观察到一个变化的值(如 IoT 传感器)时,可能会产生一个事件。
为了说明系统如何使用 CloudEvents,下面的图显示了来自源的事件如何触发一个动作。
源(Source)生成消息(Message),其中事件(Event)被封装在协议中。事件到达目的地,触发一个由事件数据提供的动作(Action)。源是源类型的一个特定实例,它允许staging和测试实例。一个特定源类型的开放源软件可以由多个公司或供应商部署。事件可以通过各种行业标准协议(如HTTP、AMQP、MQTT、SMTP)、开源协议(如Kafka、NATS、RocketMQ、RabbitMQ)或平台/供应商特定的协议(AWS Kinesis、Azure Event Grid)来递送。动作处理定义了由特定源的特定事件触发的行为或效果的事件。虽然不在本规范的范围内,但生成事件的目的通常是为了让其他系统能够轻松地对它们无法控制的源中的变化做出反应。源和动作通常是由不同的开发人员建立的。通常情况下,源是一个托管服务,而动作是无服务器函数(如AWS Lambda或Google Cloud Functions)中的自定义代码。EventMesh支持扩展多种协议,内部协议流转示意图如下:
Standalone
EventMesh支持了Standalone Connector功能,在Standalone模式下EventMesh不依赖于任何外部存储组件,方便用户快速体验EventMesh收发事件能力以及相关特性,极大地降低了用户初次体验EventMesh的门槛,我们不建议在生产环境使用该模式,仅在本地体验即可。
OpenTelemetry
EventMesh支持了OpenTelemetry的集成,该功能极大的提升了EventMesh的可观测性,集成OpenTelemetry标准化了EventMesh的Metrics与Tracing数据,方便后续对接不同的采集器,目前分别支持将Metrics数据导出到Prometheus,以及将Tracing数据导出到Zipkin。后续还会根据社区内部的需求支持更多的采集器。
插件化优化
1.3.0版本极大的提升了EventMesh的可插拔能力,相较于1.2.0版本基于JDK SPI的插件化加载架构,1.3.0版本采用了注解的方式完善了各个类型插件的加载,提供了多种插件在运行时共存的能力,同时相较于1.2.0版本除了支持存储插件Rocketmq-connector以外,我们还提供了Standalone-connector插件,可以通过简单配置实现插件之间的切换与加载;同时协议部分我们也完善了插件化的扩展与支持,在原有的EventMesh原生协议基础上,扩展支持了CloudEvents协议,以此为例,可以很方便用户后续在协议层面进行其他的扩展,后续版本还将丰富更多类型的插件。
致谢
EventMesh 1.3.0 的发布离不开 EventMesh社区的贡献者,在这里感谢为社区做出贡献的小伙伴们:
Committers:
qqeasonchen、xwm1992、ruanwenjun、lrhkobe、iNanos、vongosling、wqliang、keranbingaa、yiliuchen、jonyangx
Contributors:
tydhot、jzhou59、yuzhao244、wangshaojie4039、xiaoyang-sde、dongzl、hagsyn、msdhinesh-geek、sarihuangshanrong、Alonexc、AhahaGe、horoc、zhannicholas、dengqunhua、Roc-00、yuzhoumao、sunxi92、liangyuanpeng、SteveYurongSu
非常感谢各位的积极参与和贡献,同时EventMesh社区非常期待有更多的用户、开发者、厂商参与到EventMesh生态的建设中来。
预告
在后续的版本中,如下特性将会与大家见面:
- 支持Grpc协议,提升EventMesh传输的性能与效率
- 支持WasmEdge,增加EventMesh的边缘计算的能力,支持更广泛的应用场景
- 支持Serverless Workflow工作流编排
- 支持Event Sourcing与分布式事务
- ......
EventMesh社区欢迎更多的用户、开发者参与讨论共建。
项目地址

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Bootstrap Blazor 更新版本 6.2.0
Bootstrap Blazor 是一款基于 Bootstrap 的 企业级 Blazor UI 组件库,目前内置近100 个组件,欢迎大家尝试使用。 破坏性更新 refactor(#I4P0MT): 表单内组件前置标签由原来的默认四个汉字宽度更改为六个汉字宽度#I4P0MT refactor(#I4OZ32): 组件Tab与Layout移除TabItemTextDictionary参数#I4OZ32 改用页面级标签TabItemOptionAttribute feat(#I4OTDY): 移除NavigateTo扩展方法#I4OTDY 由于用此扩展方法生成的TabItem无法保持标签页状态(丢失Text)等属性,改用页面内使用TabItemOptionAttribute属性替换 feat(#I4NAQ4): 组件BootstrapDynamicComponent参数集合更改为IDictionary<string, object?>#I4NAN8 方便使用者赋值避免触发不可为空检查绿色波浪线 feat(#I4NAN8): 组件ModalDialog内置一个保存按钮默认不显示...
- 下一篇
源码解读:揭秘Nacos服务发现全过程
作为一个开发者,解读开源代码是一项非常重要的技能,在上篇文章《源码解读:读多写少的Nacos是如何实现高性能设计的?》中介绍了“盲猜”法的方式解读开源代码,并且使用这种方法成功的将Nacos服务端的源码梳理了一遍,介绍了其后端的一些机制、技巧。上篇文章中仅仅介绍了Nacos后端的代码逻辑,没有涉及应用方服务作为Nacos客户端是如何将自身的节点配置注册给Nacos后端的。上篇文章结尾处说明了“盲猜”法是建立在有丰富经验的基础上的,但是,如果盲猜不到,又或者没有什么经验的情况下就不适用了,因此,本文将延续上篇文章使用调试法暴力解读开源代码,从入口到到结束将Nacos服务发现的全过程理一遍。 本文涉及知识点:JDK SPI和Spring SPI、Spring-boot启动过程等。 架构原理简介 首先,我们需要找到服务发现的起点,也就是最一开始是从哪里发起的请求。可以想像,肯定是在我们的应用服务中了,那么,我们是如何使用Nacos的呢?使用的时候是很简单的,只需要以下几个步骤就可以了: 1. 引入Nacos的包 <dependency> <groupId>com...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS6,7,8上安装Nginx,支持https2.0的开启