“新一代”系统采用7+1层12应用平台的架构，它是基于业界SOA(面向服务的架构)参考架构的实例化。面向服务的架构（SOA）是一种帮助系统在增长的同时保持可扩展性和灵活性的方法，它也有助于填平“业务/IT”鸿沟。随着下一代SOA技术的发展，事件驱动架构（EDA）被引入，并和原SOA参考架构一起，成为下一代SOA的重要组成(即SOA2.0)。
事件驱动架构（EDA）是一种用于设计与实现应用和系统的方法，在这些应用和系统里, 事件所触发的消息可以在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。通常事件可以采用发布/订阅机制。
在“新一代”二期项目中，总行基于AMQP的标准实现Apache Qpid构建了消息中心等基础应用一满足这种需求。又在消息中心基础上构建事件管理接口，进一步优化了跨系统的消息传递和解决系统各组件间或组件内的消息传递的机制，简化了部署实施的过程。
本文通过介绍消息中心的基础设施，分析事件管理接口的设计和在项目中的部署实施，分析EDA架构具体实现方式、实际应用配置上做了分析，希望能进一步减少配置的复杂度，并尽可能的优化设计，完善异常处理机制，提高效率
本文通过介绍学员徐冬冬在EDA部署实施项目中的参与情况，结合事件驱动结构介绍和企业现金、客户服务组件中的部署，介绍了EDA的技术架构和部署实施策略。
关键词：EDA 事件驱动架构
目 录
1 绪论 2
1.1 研究背景 2
1.2 研究意义 2
1.3 研究内容 3
1.4 论文结构 3
2 事件驱动架构简介 5
2.1 事件驱动架构的特点 5
2.2 事件驱动架构的组成 6
2.3 事件驱动架构的典型处理模式 7
2.4 “新一代”中业务事件的基本设计基础 9
2.4.1 AMQP 和 Qpid介绍 9
2.4.2 消息中心msgCenter概述 10
2.4.3 Ems-client事件管理功能概述 10
2.4.4 App-eda封装包 11
3 “新一代“系统的实施 12
3.1 EDA在“新一代”二期中的实施 12
3.2 事件消息报文结构 13
3.2.1 报文框架设计原则 13
3.2.2 事件消息报文的结构 13
3.2.3 事件消息物理报文格式框架 15
3.3 事件发布/订阅注册流程 17
3.4 业务事件设计 19
3.5 业务事件管理接口定义 20
3.5.1 事件发送 20
3.5.2 接收事件 21
4 EDA应用示例 22
4.1 EDA典型应用场景 22
4.2 企业现金中实施部署 23
4.2.1 基础代码环境配置 23
4.2.2 业务事件订阅申请 26
4.2.3 消息报文配置 27
4.2.4 EDA事件管理接口使用 29
5 总结与展望 33
5.1 总结 33
5.2 展望及改进建议 34
1绪论
1.1研究背景
“新一代”系统采用7+1层12应用平台的架构，它是基于业界SOA(面向服务的架构)参考架构的实例化。面向服务的架构（SOA）是一种帮助系统在增长的同时保持可扩展性和灵活性的方法，它也有助于填平“业务/IT”鸿沟。该方法由服务（Services）、企业服务总线（ESB）、决策和过程（Decisions & Processes）这三个主要元素构成。随着下一代SOA技术的发展，事件驱动架构（EDA）被引入，并和原SOA参考架构一起，成为下一代SOA的重要组成(即SOA2.0)。
为适应新技术的发展，为了有效解决组件的异步消息传递需求，“新一代”系统中也开展了事件驱动架构的建设，建立了消息中心等基础应用。
1.2研究意义
事件驱动架构（EDA）是一种用于设计与实现应用和系统的方法，在这些应用和系统里, 事件所触发的消息可以在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。通常事件可以采用发布/订阅机制。
目前，为了有效解决组件的异步消息传递需求，总行已经基于AMQP的标准实现Apache Qpid构建了消息中心等基础应用一满足这种需求。
在“新一代”二期项目中，又在消息中心基础上构建事件管理接口，进一步优化了跨系统的消息传递和解决系统各组件间或组件内的消息传递的机制，简化了部署实施的过程。
本文通过介绍消息中心的基础设施，分析事件管理接口的设计和在项目中的部署实施，分析EDA架构具体实现方式、实际应用配置上做了分析，希望能进一步减少配置的复杂度，并尽可能的优化设计，完善异常处理机制，提高效率 。
1.3研究内容
首先，本论文回顾了在入职一年来学员所承担的主要现金管理相关项目的功能实施和项目开发工作，以及在导师责任制要求下，对我行规章制度、开发平台和框架技术、现金管理项目开发和实施等多方面的学习情况，并简要介绍个人所认知的银行系统开发的主要工作内容。
其次，论文以EDA基础组件为研究对象，结合现金管理和客户服务组件中实际的开发测试实践，从技术角度和项目管理角度阐述学员对EDA组件实施的研究心得。在EDA现金管理中开发部署过程中，学员独立承担EDA管理和测试支持的开发任务，全程参与将开发二处公共组多年的实施经验融入整个组件的设计和研发，使之统一管理与维护全部测试任务和测试资源，极大地提升了实施过程的标准化、自动化和规范化。同时在组件的各个环节参与实施流程，积极进行技术方法的研究和主动探索，并进行了总结沉淀。
最后，结合对银行系统开发的学习成果及对流程的理解，提出对EDA开发测试工作的个人改进意见和建议。
本论文首先对事件驱动架构做了讲解，介绍了EDA与SOA之间关系和差别，其次介绍了EDA的主要组成，然后介绍了EDA典型的处理模式，包括简单事件处理模式 (SEP)、事件流处理模式 (ESP)、复杂事件处理模式 (CEP)。
再次，结合“新一代”二期的EDA中消息传送实例，简单介绍了“新一代”二期中EDA实现的按架构模式
然后，结合企业现金的中EDA的实际部署，展示了在鲜见项目中使用EDA作为消息传递机制需要做的一些工作。
最后，结合开发环境的学习成果，对一年来的工作进行总结。
1.4论文结构
本论文共分为五章。
第一章，绪论（即本章）。介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。
第二章，对事件驱动架构做了一般性介绍，并同SOA做了比较性分析。同事简单介绍了“新一代”二期中消息传递机制的基础实施构造。
第三章，介绍了“新一代”二期项目中基于EDA的消息传递机制的部署实施策略。
第四章，介绍了在企业现金项目组中EDA的实际开发部署工作。
第五章，总结与展望。对一年开发工作做了简单的回顾和总结，并对未来的工作学习作了展望。
2事件驱动架构简介
2.1事件驱动架构的特点
事件驱动架构（EDA）属于下一代的SOA技术。
EDA的先进性主要体现在如下几点：
•弥补SOA仅能处理静态业务的不足，通过动态增减事件的产生者和消费者，快速感知并响应业务需求
•松耦合的架构具备更好的弹性，可以更容易开发和维护大规模分布式服务
•通过包含业务上下文的事件，确定与该事件相关联的事件处理机制，有助于建立一个完整业务总体状态的实时视图
EDA 并不会替代 SOA，而只是对 SOA 形成补充。通常SOA更适合交易请求/响应交换环境，而EDA更适合业务事件发布/订阅环境，并不依赖于所发布的服务的可用性，真正地实现了节点间的松耦合。
传统SOA架构的主要特征如下：
功能 描述
松散耦合的交互 服务的调用独立于其技术和位置。
一对一通信 一个特定服务一次由一个用户调用。通信是双向的。
基于用户进行触发 控制流由客户机（服务使用者）发起。
同步 应答将以同步方式发回给使用者。
EDA的主要特征如下表所示：
功能 描述
分离的交互 事件发布者并不会意识到事件订阅者的存在。
多对多通信 采用发布/订阅消息传递，一个特定事件可以影响多个订阅者。
基于事件的触发器 控制流由接收者确定（基于发布的事件）。
异步 通过事件消息传递支持异步操作。
事件驱动架构（EDA）具有非常松耦合与高分布的特性。事件流总是只往一个方向流动。事件的创建者只知道发布该事件，不知道事件后续的处理，对于在动态多路径的网络中追踪事件非常困难，因此事件驱动架构多使用异步的方式传递工作与信息。
2.2事件驱动架构的组成
EDA架构的事件处理链中，一个事件的处理环节通常具备以下四个部分：事件创建者（Event Generator），事件通道（Event Channel），事件处理引擎（Event Processing Engine），下游事件应用（Downstream Event-Driven Activity）。
事件创建者（Event Generator）
每个事件都有一个产生的源头，源头可能是一个应用，数据仓库，服务，业务流程，传送者，传感器或协作工具。一个普通的事件可能需要经过事件预处理器评估其显著性，或将生成一个新的显著事件。
由于事件创建者的多样性，不是所有的事件都会被直接生成事件处理所要求的格式，在这种情况下，事件首先由创建者按标准格式创建，才能进入事件通道。
事件通道（Event Channel）
事件通道在事件创建者，事件处理引擎和下游事件订阅者之间传递标准格式的事件。
事件处理引擎（Event Processing Engine）
在事件处理层，依据事件处理规则与活动初始化事件。规则与活动由感兴趣方制定而不是由事件创建者制定。
活动包括调用一个服务，初始化一个业务流程，发布事件到订阅中心，直接通知人或系统，产生一个新的事件，并且/或因为历史原因捕获事件。
事件由引擎进行处理。一个简单的引擎单独地处理每个事件，一个复杂的引擎可以按照先后顺序处理一组事件。
下游事件应用（Downstream Event-Driven Activity）
一个单独的事件或事件集，可能引发许多下游的活动。活动的执行可能由事件处理引擎推送或由订阅者获取。这些订阅者可能是人、应用、业务流程、数据仓库、展示板、与/或自动化的代理。事件应该以标准事件格式进行发布。
2.3事件驱动架构的典型处理模式
典型的事件驱动架构（EDA）处理通常有三种处理模式：
简单事件处理模式 (SEP)：
事件或者以单个事件的形式，或者以事件流的形式发生。单个的事件被认为是一个消息源状态的重要改变，特别是一个业务事件状态的重要改变。这类事件通常会触发接收消息的系统的处理。一个典型的SEP的例子就是Java消息服务(JMS）。
事件流处理模式 (ESP)
事件流处理模式涉及对进入的消息或事件的流的处理。典型的ESP系统有传感器，能传送大量的事件，并且运用过滤器或其他处理方式来影响消息或事件的处理。ESP系统中，单个的事件重要性较低，焦点在于事件的流。众所周知的例子是追踪股市价格的系统：单纯的价格波动通常不那么重要，只有从一系列事件中才能得出一个更具情报性的总体的趋势来。
复杂事件处理模式 (CEP)
事件处理的第三种类型是复杂事件处理模式，这是ESP的一个组成部分。在CEP中，更看重的是从大量事件中识别其模式与内容，这些模式和内容有可能经由不同的数据流进行发布。
下图是一个典型的事件处理漏斗模型：
2.4“新一代”中业务事件的基本设计基础
新一代中消息中心的设计是基于开发的AMQP协议的标准实现Apache Qpid项目进行实施的，从下到上一次封装形成消息中心msgcenter结构和业务事件管理接口ems-client接口，和北开封装的app-eda接口。
2.4.1AMQP 和 Qpid介绍
AMQP 是 Advanced Message Queuing Protocol，即高级消息队列协议。和前面罗列的技术不同，AMQP 是一个标准化的消息中间件协议。她的理想是让不同语言，不同系统的应用互相通信，并提供一个简单统一的模型和编程接口。这样，人们就可以采用各种语言和平台来实现自己的应用，当需要和其他系统通信时，只要承认 AMQP 协议即可。
AMQP 来自 JPMorgon，最初只是这个财大气粗的投行内部使用的消息中间件。发起人 John O'Hara 很有气魄，他说“从 1996 年开始到 2003 我一直在等这样一个标准，但始终没有等到，我已经等不下去了”，并且“投行对这类标准的需求最迫切，而银行又从来不缺乏技术专家” ，所以他自己开发了一个。因为他的努力，AMQP 从金融界迅速推广到整个计算机行业，参与者包括了很多 IT 巨头。AMQP 的基本构架如下：
图 1. AMQP 系统构架
在 AMQP 模型中，消息的 producer 将 Message 发送给 Exchange，Exchange 负责交换 / 路由，将消息正确地转发给相应的 Queue。消息的 Consumer 从 Queue 中读取消息。
这个过程是异步的，Producer 和 Consumer 没有直接联系甚至可以不知道彼此的存在。
QPID 是 Apache Foundation 的一个开源项目，是一个 AMQP 实现。它提供了 C++ 和 Java 两个版本的 broker，并支持多种语言的客户端，它还包括一个配置工具集。
除了完全实现了 AMQP 的基本功能之外，Qpid 还提供了一些额外的特性：
采用 Corosync 来保证了集群环境下的 Fault-tolerant 特性
支持 XML 类型的 Exchange，当消息格式为 XML 时，可以利用 Xquery 进行过滤
支持 plugin，用户可以方便地增加新的功能，比如新的 exchange 类型
提供了安全认证特性，任何 producer/consumer 需要和 broker 通信时，都需要提供身份认证，以便防止恶意的不相干的程序进入消息体系。QPID 的安全认证使用 SSL 协议。
2.4.2消息中心msgCenter概述
建行上开对消息qpid进行了一定的封装，以适应建行的企业级应用，简化应用开发设计流程，使其易用，提高了开发效率。
目前新一代2.2项目针对msgCenter进行了更高一层次的封装，msgCenter应用中不再直接使用。
2.4.3Ems-client事件管理功能概述
事件管理分为事件注册、注册信息同步、监控统计和事件管理接口等四部分，其主要功能如下：
