从SOA到EDA事件驱动架构(200725)

今天分享一个技术咨询类研究项目，即在集成平台规划和建设中，如何引入和应用EDA事件驱动架构。该项目研究的背景是随着集成平台建设深化，为了更好的满足业务敏捷性，实时性和高可靠性要求，集成平台提出了进一步能力提升需求；其二是在信息化集中化建设大趋势下，集成平台需要进一步提升能力以演进为支撑体系架构下的能力总线和管控平台。

经过初步分析，传统SOA集成平台需要增加如下四方面的能力。

• 在传统数据集成基础上需要进一步提升业务集成能力
• 需要提高集成平台的业务敏捷性和反应能力
• 需要进一步实现业务系统间的解耦和高可靠性
• 需要进一步提升管控平台的实时响应能力

而本技术研究项目即是研究如何通过引入业界先进的事件驱动技术框架（EDA），充分利用业务规则管理（BRM）和复杂事件处理（CEP）技术，转化为集成平台关键技术提升要求，进一步研究细化形成技术实现方案以及配套的管控方案，提升集成平台技术能力和管控能力。

对应技术研究类课题实际属于我们整体IT规划咨询中的要给子集，但是整体研究分析方法论仍然基本和IT架构规划咨询一致，里面最核心的仍然是业务目标驱动技术解决方案，同时和传统IT咨询规划不同的地方在于需要对提出的技术解决方案进行原型验证。

这篇文章可以作为大家编写技术研究类项目方案的一个重要参考，虽然里面部分内容进行了删减和脱密处理，但是整体研究内容框架基本完整。

第一部分：概念和问题提出

这部分实际相对重要，即你自己要回答清楚为何要做这个技术研究。

简单来说还是需要从业务目标和需求出发来分析，基于业务目标来看当前的技术现状，分析技术现状和目标的差距，提出关键的技术需求。而你做这个研究更多的就是提出一个整体的解决方案能够解决这些技术需求点，并间接的实现业务需求目标。即：

业务目标-》差距分析-》详细的技术需求提出

基本部分在集成平台能力提升和集中化总体目标下，对当前集成平台业务需求和问题进行了详细的分析，提出了异步，消息实时响应，发布订阅，并行处理，规则引擎，松耦合等核心技术需求。

而基于对EDA基础理解，EDA事件驱动架构基本涵盖了以上各关键的技术能力，因此后续需要进一步对EDA架构和原理进行分析，比对引入EDA架构可行性，并提出适合集成平台能力提升的融合整体解决方案并对解决方案进行验证。

第二部分：EDA基本概念和原理

当引入一个新技术的时候，肯定还是首先要对基本概念和原理进行说明。

在对基本概念说明清楚后，即着就是分析和对标业界的一些通用做法和最佳实践，再结合我们实际的业务和技术现状，进一步分析引入该技术的可行性。

比如我们在做EDA事件驱动架构研究，那么就必须要分析EDA提供的关键技术特性和能力刚好能够解决我们前面提出的技术需求和问题点，即：

技术需求和问题-》映射到具体的EDA技术能力

但是技术能力究竟如何组合来完成整体的业务目标和技术需求，并不在这个部分进行详细说明，而是到整体解决方案章节再进行详细描述。

第三部分：整体解决方案研究

大家可以看到，这部分的整体解决方案仍然是首先给出业务解决方案，然后才是技术解决方案，在提出完整的技术解决方案后，还得有管控治理方案，同时给出详细的实施落地方案。

什么意思呢？

就是一个业务问题或需求出来后，首先需要进行业务分析和建模，进行第一层次的抽象，然后才是进行技术架构设计和建模，完成第二次抽象。最后才是开发实施工作。

比如引入EDA事件驱动架构，我们看到传统的需求分析方法是业务流程驱动性质的，而EDA的引入本身就需要对传统的需求分析方法进行改进，增加事件链分析，而这个在传统的业务需求分析方法中是没有的。

因此在这个部分的整体逻辑仍然是清晰的，即：

业务解决方案-》技术解决方案-》实施方案-》管控治理方案

各层的解决方案本身就是一个逐步求解的过程，从需求分析到技术实现，从实施落地到后期的管控治理，只有这样才能够覆盖完整的生命周期并形成一个闭环流程。

第四部分：业务场景和原型验证

对应技术研究类项目，最后搭建原型对自己提出的解决方案进行验证是必须的。即你提出的解决方案必须自己先证明基本是可行的，能够验证通过。

当然原型离实际我们真实的业务场景还有很大的距离，但是通过原型验证至少说明了整体的业务和技术可行性是没有问题的。这和我们实际在解决问题中经常说的提出从问题定义，到提出假设，然后对假设方案进行验证和确认是一个道理。

其次要注意的就是原型验证一般包括两个方面内容。

• 其一是完整的实施生命周期和方法的验证
• 其二是对解决方案中关键技术能力和技术点是否解决技术需求的验证

通过原型验证，我们给出具体的验证和测试报告，确认最初的技术需求是否能够得到解决，包括给出引入新技术前后的一些关键指标特性对比。