再谈EDA事件驱动架构

标签: 随笔文章 | 发表时间:2012-10-20 18:36 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
EDA事件驱动架构首先不是对于传统的面向业务流程,数据等各种架构模式的完全否定,而是解决传统架构下无法很好解决的一些问题。传统模式里面更加关注业务流程和业务对象,而EDA模式下将更加关注在整个业务流程中的关键状态点,已经由关键状态点触发的有明确业务含义的业务事件。

EDA架构的核心仍然是基于消息的发布订阅模式,消息的特定就是准实时,异步和彻底解耦。同时通过发布订阅模式实现事件的一对多灵活分发。不论是哪种消息中间件基本需要实现上面所谈到的核心能力。消息中间件有消息存储和持久化功能,有消息消费方的配置功能,正是由于有这些功能才谈得上消息发布方和消息接收方的彻底解耦,消息消费方对发送方而言完全透明,消息发送方只管把消息发送到消息中间件,其它事情全部不用关心,由于消息中间件中的MQ等技术,即使发送消息时候消息接收方不可用仍然可以正常发送,这才叫彻底解耦。其次一对多的发布订阅模式是另外一个核心重点,对于消息的订阅方和订阅机制可以在消息中间件灵活的进行配置和管理,而对于消息发送方和发送逻辑基本没有任何影响。

既然EDA做为一个架构模式和架构方法,那么就不是简单的一个技术层面的问题,而是以事件为核心的一套需求分析,设计,和实施的方法论。可以看到传统的方法到事件分析方法有一个完整映射,即传统的业务流程会映射到具体的事件消息链,而业务活动会映射到具体的业务事件。并不是说传统的业务流程分析方法不再适用,而是在传统的分析方法中增加了对关键状态点和业务事件的识别。大家可以看下EPC事件流程链,其中即在原有的业务流程,岗位角色基础上将业务事件融入了进来。EDA要求我们的是通过业务流程首先要识别出有价值的业务事件,这些事件符合异步实时,发布订阅等基本的事件特征;其次是对事件进行详细的分析和定义,对事件对应的消息格式进行定义,对事件的发布订阅机制进行定义等。最后才是基于消息事件模式的开发和测试等工作。

再EDA朝CEP过渡的时候,我们看到一个核心就是由单一的事件发展到了有多个事件形成的一个复杂事件链。而复杂事件链正是可以驱动企业内部的复杂端到端业务流程。单一事件有其自身价值,但是仍然是解决点到点的事件发送和消费问题,而复杂事件才能给真正完成端到端业务流程的实时驱动和信息传递。当谈到复杂事件的时候,必然需要引入的一个内容就是规则引擎,其原因我们要意识到往往一个消费方会接受多个事件,而当同时收到多个事件的时候往往在符合某个业务规则的时候通过处理需要进一步产生新的业务事件并进行事件的发布,只有这样才能形成事件消息链,只有引入规则引擎才可以更好的实现规则的灵活配置。

EDA架构将传统的轮询模式转化为了事件驱动的实时推动模式,加快了业务响应的敏捷性,减少了由于跨业务部门或业务系统消息传递而带来的时间延长,真正实现业务系统间的彻底解耦。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [eda 事件驱动 架构] 推荐:

再谈EDA事件驱动架构

- - 人月神话的BLOG
EDA事件驱动架构首先不是对于传统的面向业务流程,数据等各种架构模式的完全否定,而是解决传统架构下无法很好解决的一些问题. 传统模式里面更加关注业务流程和业务对象,而EDA模式下将更加关注在整个业务流程中的关键状态点,已经由关键状态点触发的有明确业务含义的业务事件. EDA架构的核心仍然是基于消息的发布订阅模式,消息的特定就是准实时,异步和彻底解耦.

事件驱动架构避坑指南

- - DockOne.io
事件驱动架构非常强大,非常适合分布式微服务环境. 通过引入代理中介,事件驱动架构提供了更好的解耦架构、更容易的可扩展性和更高程度的弹性. 请求应答模式 (client-server) vs. 事件流模式 (pub-sub). 但与请求应答客户端-服务器类型架构相比,事件流模式的搭建更复杂. 在Wix过去的几年里,我们逐渐的将我们不断增长的微服务集(目前为 2300 个)从请求-应答模式迁移到事件驱动架构模式.

微服务架构之事件驱动架构 - 简书

- -
为了解决传统的单体应用(Monolithic Application)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(Microservice Architecture)构建自己的应用. 微服务(Microservices) 是一种软件架构风格 (Software Architecture Style),它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯.

事件驱动架构在 vivo 内容平台的实践

- - 掘金 架构
当下,随着微服务的兴起,容器化技术的发展,以及云原生、serverless 概念的普及,事件驱动再次引起业界的广泛关注. 所谓事件驱动的架构,也就是使用事件来实现跨多个服务的业务逻辑. 事件驱动架构是一种设计应用的软件架构和模型,可以最大程度减少耦合度,很好地扩展与适配不同类型的服务组件. 在这一架构里,当有重要事件发生时,比如更新业务数据,某个服务会发布事件,其它服务则订阅这些事件;当某一服务接收到事件就可以执行自己的业务流程,更新业务数据,同时发布新的事件触发下一步.

Redis事件驱动库结构

- zffl - NoSQLFan
本文翻译自Redis官方对事件驱动库的结构描述,英文原文点这里,由Day Day Up博客原创,文章写的时间已经比较长了,今天才被NoSQLFan挖出来,实属难得. 文章地址:blog.ddup.us. 这是一篇翻译文章,原文见这里. Redis实现了它自己的事件库. 要弄明白Redis事件库是如何工作的最好的方法就是弄明白Redis是如何使用它的.

反向Ajax,第5部分:事件驱动的Web开发

- Taozi - 译言-电脑/网络/数码科技
到目前为止你已经了解了创建通过事件来通信的组件,在本系列的最后一部分内容中,我们把事件驱动开发的原则应用到实践中,构建一个示例性的事件驱动web应用. 你可以下载本文中使用的源代码. 理想情况下,要充分体会本文的话,你应该对JavaScrpit和Java有一定的了解,并且要有一些web开发经验. 若要运行本文中的例子,你还需要最新版本的Maven和JDK(参见参考资料).

[译] 当提到 “事件驱动” 时,我们在说什么?

- - IT瘾-dev
文/Martin Fowler. 去年年底(译者注:2016年底),我和ThoughtWorks同事一起参加了一个研讨会,讨论“事件驱动”的本质. 在过去的几年里,我们构建的很多系统都大量使用了事件. 对于这些系统,人们常常赞誉有加,但批评的声音也不绝于耳. 我们的北美办公室组织了一次峰会,来自世界各地的ThoughtWorks资深开发者出席会议并分享了他们的想法.

从事件驱动到observable的异步编程——PubSub+Promise+Rx的JS事件库

- Kejun - YY in Limbo 混沌海狂想
你上当叻,虽然从外面看标题很有气势,传达出一种宏大叙事的赶脚,其实我只是刚刚把一个阿尔法城的JS模块提交到github,想顺便介绍一下,但我连API文档都懒得写,就别指望能深入浅出的讲一遍来龙去脉了⋯⋯. 所以就直接帖几个前置阅读的链接罢. 这些潮流的外部起源:(技术也有外源论/exogenesis⋯⋯).

架构

- - IT瘾-dev
网关:Nginx、Kong、Zuul. 缓存:Redis、MemCached、OsCache、EhCache. 搜索:ElasticSearch、Solr. 熔断:Hystrix、resilience4j. 负载均衡:DNS、F5、LVS、Nginx、OpenResty、HAproxy. 注册中心:Eureka、Zookeeper、Redis、Etcd、Consul.

信息架构

- Michael - Tony-懒得设计
写几篇关于信息架构的文章,系统地输出我理解的信息架构. 发了一篇关于招信息架构实习生的博客,收到不少简历. 但谈起信息架构,多数不了解,稍微了解的扯了很多很偏的东西. 随手搜索了一下,我发现了原因:. 1 《web信息架构》这本书太概念,太学术. 2 有人绑架了“信息架构”这个词,拿出去唬人,内容都是皮毛或者是根本和信息架构不沾边的东西.