EDA和SOA的融合以及实践

将事件处理的能力引入到 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）将这方面的设计发挥到了极致，详细的介绍请参考正文后的参考资料。

Event-Driven SOA 在金融系统的应用

金融系统的实际需求

在当今社会，市场变化莫测，商机稍纵即逝，企业需要有极强的灵活性和应变能力，金融行业尤其如此，特别是在中国这样一个金融行业处于快速发展的市场里。企业要求 IT 系统能够快速地对业务需求做出应对，否则就会丧失先发优势。这有点类似于现代战争条件下，各国都要求部队具备快速反应能力，这种能力主要体现在 IT 部门能够通过快速开发或者重用 / 整合现有资源来达到快速响应业务需求。还有，金融行业业务越来越庞大复杂，所涉及的第三方系统或者遗留系统非常多，这就要求 IT 系统有很强的整合能力及对异构环境的适应能力。最后，由于金融行业的发展日新月异，特定金融业务都会在其初期发展后迎来一个快速膨胀期，业务量和业务类型会急剧增加，这也要求 IT 系统有很好的可扩展性。

对照前面提到的 Event-Driven SOA 的特点，我们可以很直观地发现该架构可以很好地满足金融系统的实际需求。当然，金融系统也是包罗万象，特点各不一样，这里可能更偏重于金融行业的交易系统。

为什么选择 Event-Driven SOA ——适用性讨论

除了上面提到的这些大的因素之外，我们还可以深入到具体系统的内部，从一些微观层面来考虑 Event-Driven SOA 是否仍然能够符合我们的要求。

从上图我们可以看出，整个应用被分为很多子系统，各个子系统之间存在着大量的信息交互。而且大部分应用输入都需要经历一个比较长的生命周期，比如说一个客户订单输入到系统后，会先后经历前台系统 （Front Office），中台系统 （Middle Office） 以及后台系统 （Back Office），而且每个系统内部又包括很多服务组件。除了系统层面的跨度外， 这个生命周期也体现在时间长度上。而且，如今所有的金融系统都追求 STP （Straight Through Processing） 的能力，主张尽可能少的人工干预，这样所有的服务组件都需要具备自触发的能力。

Event-Driven SOA 架构设计

架构师在着手每次的架构设计时，其实都是在提出并回答一系列的问题，把这些问题都回答了，架构设计也就出来了。比如我们每次肯定都会问：系统的最终用户是谁，他们会如何来使用该系统，他们的核心诉求是什么。当然，不是所有的问题都能有一个圆满的答案，更多的时候其实是一个取舍的过程。比如说系统的关键指标我们很难一下子全部满足，就需要结合具体的业务需求和人力物力以及时间的具体情况来做取舍。下表就列出了一些我在做 Event-Driven SOA 架构设计时认为比较关键的问题（在遵循一般架构设计的原则的基础之上），看看你是否也有同感。

表一：Event-Driven SOA 架构设计时的几个关键考虑

下面我就其中的几点具体展开讨论一下：

业务为先

任何的技术或者架构思想都是由具体的业务需求驱动的，比如 SOA 的出现是由于人们打破竖井应用 （application silos） 并追求功能重用的强烈需求，而 EDA 的出现也迎合了业务流程化、自动化的趋势。所以，任何的架构设计都要服从于自身业务的具体需求，没有最好的架构设计，只有最合适的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友