EDA 和 SOA

　　SOA 简介

　　事件驱动架构 (Event-Driven Architecture，EDA) 简介

　　可以从两个方面来理解 EDA：

　　EDA 是一种侧重于以生成/消费为基础的异步通信的架构模式。这主要对照于传统的基于线程的同步系统。

　　EDA 是一种以事件 (event)为核心，提供事件产生，路由，消费已经结果回调等机制的架构模式。

　　简单地说， 面向服务架构 (Service-Oriented Architecture, SOA) 是一种 IT 架构策略，其基于面向服务的概念之上。自从 2002 开始为大家熟知以来，SOA 已经逐渐地成为业界的标准，也得到了广泛的应用。

　　SOA != Web Service

　　因为 SOA 经常和 Web Service 相提并论，所以导致大家一直有一个误区，认为这两者是等同的，其实不然。虽然两者有很多的关联，但它们是截然不同的两个概念，或者说考虑问题的角度不同。虽然 SOA 最初的流行离不开 Web Service 的贡献，但如今 SOA 早已超越了 Web Service 的范畴，变成一个独立的设计理念。

　　SOA 的局限性

　　SOA 主要从系统解构的角度入手，它侧重于将整个应用分解为一系列独立的服务，并指定各种标准和基础设施来使得这些服务易于重用，能够很容易地被各种平台上的应用来使用。但是在服务实际业务时出现了一些问题，因为 SOA 更多地是关注静态的信息，所以不能很好地与动态业务匹配。比如 SOA 不能很好地回答类似下面的一些问题：

　　比如在一个证券公司，有很完善的交易系统、后台系统、账务系统和头寸管理系统等，当一个客户的下单在交易所执行后，所有的这些系统都应该得到通知，并做出相应的处理。这里面其实包含了几个问题：谁来负责触发这样一个事件，各个系统如何得到通知？如何保证各个系统行动的一致性？ SOA 架构由于其关注点的限制，并不能很好地解决上述问题，而这些问题往往又是实际系统非常需要的特性。因此，EDA 与 SOA 的集成引起了人们的注意。

　　通过引入面向事件的机制，使得系统具备了感知和快速响应业务事件的能力。其实不管是 SOA 还是 EDA 都不是什么新技术，无非是在一些旧的概念上添加了一些新元素。

　　什么是事件（Event）？

　　事件就是状态的显着变化，比如说前面提到的客户下单被执行。从来源来分，事件可以分为系统内部事件和外部事件。从类型来分，可以分为业务事件和系统事件。

　　其实你可以从 SOA 或 EDA 的身上很容易看到以前的技术 ( 比如 CORBA 或者 DCOM) 的影子。任何系统都可以简化为组件 / 服务加上通道 (channel，解决通讯的问题 )，如果说 SOA 关注于组件和服务的话，那么 EDA 更多地关注通道。

　　Event-Driven SOA

　　我们一般将 SOA 和 EDA 的集成体称之为事件驱动的面向服务架构 (Event-Driven SOA)，可以将其理解为 SOA 的一种衍生。SOA 和 EDA 的交互主要体现在以下几个方面：

　　将事件处理的能力引入到 SOA

　　一个事件的产生可以触发一个或多个服务被调用，这样就把这些静态的功能动态地串联起来。

　　服务本身也可以产生事件

　　服务除了完成特定的功能外，也可以根据自身需要产生某个事件。

　　有人将 EDA 和 SOA 的关系与人体做了一个形象的比喻，如果把 SOA 比作手和脚的话，那 EDA 就像人的眼睛和耳朵。当眼睛发现一只狮子正朝你奔来时，一个消息被发送到大脑，然后大脑向你的手脚发出指令：赶快跑。

　　Event-Driven SOA 架构的特点

　　当然，任何一种架构模式都有其适用的场景，Event-Driven SOA 自然也不例外。

　　首先，它适用于异步的环境。如果你的系统对实时性要求比较高，请不要使用该架构。

　　第二，如果你的系统需要面对复杂的异构环境——跨平台 / 跨语言，那么面向服务的架构能够很好地应对。

　　第三，将系统功能分解为适当粒度并且重用性高的一个个服务，可以显着地提高 IT 系统的适应性和效率，进而提高投资回报率 (ROI)。

　　第四，引入事件处理的能力以后，每个服务都是由不同的事件驱动，这样当某个事件发生后，系统的不同服务就能够自动地进行触发。这对那些有更高自动化要求的系统来说非常适合。

　　第五，与面向过程的系统中客户端必须轮询更改请求 ( 通过 API 调用 ) 不同，事件驱动架构允许系统和组件在事件发生时实时动态地做出响应。事件驱动架构通过引入长时间运行的处理功能来弥补 SOA 的不足。这一点对于金融系统来说尤其重要，比如说一次股票买卖从客户下单到最终交割会经历几天的生命周期。

　　最后，Event-Driven SOA 使得增加事件的 consumer 和 producer 非常容易，这样就使得增加系统吞吐量也变得很简单，系统的弹性非常好，非常适合那些业务量持续增加的系统。在这方面，有一个 EDA 的变体 SEDA（Staged Event-Driven Architecture）将这方面的设计发挥到了极致，详细的介绍请参考正文后的参考资料。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。