事件驱动架构产生的背景

       国内大型企业经过十几年信息化改造后，基本上实现了全面的信息化管理。从基础设备到业务应用，大型企业企业全方位的融入了数字化时代。但数字化在带给企事业诸如提高管理效率，降低成本等便利条件的同时，也日益显现出了一些弊端和矛盾，其中信息孤岛是较为突出的一个问题。企业在信息化的过程中建立的多种面向各种业务或运维的局部应用系统互相之间不能信息共享，业务不能舒畅执行和有效控制，就形成了诸多“信息孤岛”，既影响了现有系统的继续运行，也影响了新系统的实施。信息孤岛是信息化应用推广和普及的必然结果，也是信息化进程中暴露的主要问题之一。如果没有日益扩大的信息化要求，信息孤岛仅仅是在一定范围内的出现，也容易得到解决。只要信息化、网络化进程在推进，企业之间、行业之间通过网络沟通的需求日益密切，就会产生新需求下的信息孤岛。信息化启动较早的行业，例如金融、电信、电力、交通等，由于这些行业企业由于有很好的信息化切入点，所以很容易启动信息化项目，甚至许多企业在计算机DOS时代就开始用计算机进行业务处理和办公了，随着应用的拓展并为消除信息孤岛，这些系统都经历了数次大规模的升级以适应新的环境和需求，而且随着时代和技术的进步这种升级仍会继续。

       信息孤岛可以存在于不同区域、不同行业、不同企业以及企业生产和经营的每一个环节之中。由于行业之间、行业内各职能部门之间各自为政、信息相互排斥，已经成为电子政务建设重大障碍。实现行业、政府、企业以及企业各生产环节之间的协作，就需要走出信息孤岛，才有可能向社会信息化的目标前景。按照信息化应用层次划分，信息孤岛有企业内部信息孤岛、行业内信息孤岛、行业之间信息孤岛等。企业内部信息孤岛是讨论最多的内容，也是需要首先解决的部分；行业内信息孤岛是指行业内不同职能部门之间或不同领域之间的信息孤岛，例如政府各职能机构和部门之间，各银行之间的系统；行业之间信息孤岛是行业信息系统之间相互屏蔽，例如工商与税务之间，政府与企业之间，这些信息孤岛是实现社会信息化的障碍。

       按照类型分有“数据孤岛”、“系统孤岛”、“业务孤岛”、“管控孤岛”。“数据孤岛”是最普遍的形式，存在于所有需要进行数据共享和交换的系统之间；“系统孤岛”指在一定范围内，需要集成的系统之间相互孤立的现象；“业务孤岛”是说，由于信息孤岛导致一个业务不能通过网络系统完整、顺利的执行和处理；而“管控孤岛”指智能控制设备和控制系统与管理系统之间脱离的现象，影响控制系统作用的发挥。信息孤岛需要从现有信息孤岛的解决和为了信息孤岛的防范两方面着手。

       解决企业现有系统信息化孤岛主要采用的方式有：升级替换、建立接口、集成平台方式：

• 升级替换就是对现有失去持续维护能力和没有维护意义的系统，采用升级的办法或用全新的系统替换旧系统，将旧系统中产生的数据导入到新系统中，从而消除现有信息孤岛。这种办法可以从系统运行环境、数据库系统等统一起来，在数据整合的基础上实现系统的整合和业务的集成。条件许可的情况下，可以对企业信息化重新规划，对现有运行的系统进行全面的升级和替换。这种方式带来的成本极高，并伴随着相当大的风险。尤其是对信息化改造多年的企业而言，使用整体升级替换的方式往往代表者巨额的投入和不明朗的盈利预期；
• 建立数据交换协议和数据接口，这一种不彻底但有效的方法。针对一些业务上相对独立的系统，这些系统可能由不同的供应商提供，全面升级又不可能，可以采用建立数据接口方式实现系统之间的信息共享。接口协议建立后，由供应商负责自己系统的修改，遵循接口协议在规定的数据存放地点存、取所需要的数据。目前各银行开展的代收费业务就属于这类形式，银行与需要代收费的行业系统之间通过接口协议实现数据交换。银行根据接口协议获取收费信息，收费完成后由银行按照接口协议将收费结果反馈给收费方的系统。这种方式的代价较小，但是实施难度较大，往往需要对接口所设计的各个系统进行改造，由于企业级系统种类多样，又采用各种不同的协议，操作系统和应用平台，使得在各种异构系统之间建立通讯接口的实施工作难度相当之大；
• 通过集成平台实现系统应用的集成，集成平台是可以适应于不同系统之间信息共享的通用工具，就是通过企业应用集成技术将企业的业务流程、公共数据、应用软件、硬件和各种标准联合起来，在不同企业应用系统之间实现无缝集成，使它们像一个整体一样进行业务处理和信息共享。当在多个企业系统之间进行商务交易的时候，集成平台也可以为不同企业之间实现系统集成。集成平台基于企业或机构现有的系统，但不对现有系统的使用产生影响。同时要求在实施上尽可能不修改现有的系统，通过一些“非侵入”的方式与现有系统和数据共处。研究如何将各种异构系统和繁杂多样的数据协议统一转换为可以采用模式识别的特定数据格式，并建立一个数据处理平台对这些整理后的标准格式数据进行处理并最终还原到各自系统中，是本文的研究目标。

       建立这个平台首先考虑架构，这个架构应该满足企业级系统灵活多变的要求，并可兼容企业系统中跨系统、多协议以及跨区域的种种障碍。EPN就是这样的一个基于事件驱动架构的平台。通过使用一系列的适配器和数据处理引擎来转换系统数据和协议，解决企业和机构在信息化过程中所出现的信息孤岛的问题。

事件驱动架构发展过程

        事件驱动架构(EDA)是一种更为有效的生产，监测，利用和控制各种信息事件的软件解决方案。这种架构将企业的业务理解为一系列的事件，这些事件可以源自位于不同地方、结构迥异的企业服务器、路由器或者企业资源计划(ERP)系统，客户关系管理(CRM)系统等，在对事件信息进行实时采集、分析、统计的基础上，提供业务决策支持。

       在EDA架构之上，发展出了复杂事件处理系统(CEP)和事件流处理系统(EPS)，并有效的实现了网络设备管理领域的运维智能化(OI)。同时事件可以触发面向服务架构(SOA) 中的各种服务，因此EDA和SOA之间也有着本质的互补关系。

 
信息管理技术的进化历程

        传统的信息化管理是将各种信息汇总成文件，打印出来后保存在文件柜中，或者直接保存在文件服务器中，包括各种设备信息，业务汇报，财务状况等等。各个部门往往拥有各自独立的文件服务器和打印服务器，这些信息仅通过手工方式或简单的网络传输在部门间流转，效率低且容易出错。目前国内大多数传统行业仍停留在这一阶段，如服装纺织、食品、物流、钢铁、电力等。随着企业规模的扩大和现代化管理方式的引入，企业组织面向扁平化、网络化和虚拟化，企业内的数据信息开始大幅增长，传统的以文件服务器为核心的信息管理方式成为企业成长过程中的一个瓶颈，混乱的目录结构，被动的信息传递，以及大量低效率的手工重复操作。为解决这些问题，信息管理的方式提升到了第二阶段，以数据库为核心，采用浏览器/服务器(B/S)或客户端/服务器(C/S)，以及邮件辅助进行交互操作的管理模式。

       从上世纪八十年代末开始，客户端/服务器(C/S)结构的信息管理模式开始得到大量应用，而随后产生的浏览器/服务器(B/S)架构更是将这种结构推向了一个新的阶段。企业的信息在数据库中完整、有效的存储起来，其业务逻辑则由可分布部署的应用服务器承担。应用服务器和数据库服务器通过企业局域网或Internet连接。在这种结构中，企业业务中繁复的人工操作被剥离出来，由计算机进行统一的高效处理，企业员工则直接或者间接接入网络信息系统并成为其中的一个节点，从而构成一个高效复杂的信息管理系统。数据库服务器在其中不仅扮演了存储、传递企业信息的角色，更通过商务智能(BI)对数据分析后反作用于业务系统，促进其进一步完善和发展。目前，这一架构普遍的应用于国内外企事业单位中。基于这一架构，衍生出各种各样适用于不同行业，不同领域的繁杂的信息管理系统。比如面向企业战略层面的企业资源计划(ERP)，面向电信运营管理的业务支撑和运维支撑系统(BSS/OSS)，面向常规企业办公室内部流转业务的办公自动化系统(OA)，客户关系管理系统(CRM)等众多的信息管理解决方案。作为辅助沟通、触发用户操作的工具，邮件子系统被嵌入在所有的上述系统中。

       在这个过程中，企业自身的信息也在快速的变化中。以面向电信的网管系统(NMS) 为例，设备从最初的几十台PC到现在的涵盖基站设备、数据库服务器、应用服务器、路由、防火墙、工作站等大批量各种软硬件设备。这些设备每秒钟都在产生或者分发、处理数以万计的事件信息。这些信息大都瞬间即逝，且变化复杂。按照现有的处理方式，这些信息将通过被动或主动的方式存入数据库，然后由应用程序进行分析处理。随着业务的创新和市场竞争的压力，新的需求出现了，如何将这些信息实时的呈现出来，进而与企业的相关业务动态关联起来，业务人员和公司决策层可以在第一时间了解庞杂的市场数据？跨区域跨平台的信息如何由一个中央节点统一管理？在上述数据库模型中，所有的数据交换和分析都通过数据服务器进行管理，采集的信息经由数据库存储再由业务系统进行分析，这个延迟无法避免，上述需求中的实时化要求就无法实现。数据库的跨域同步也是一个很难完美实现的问题。目前国内大型企业通过每天定时同步（数据维护），实现延迟一天的数据同步，中央节点的数据管理工作也相应的有至少一天的延迟。这个问题已经越来越多的成为企业高速成长中的一个亟待解决的瓶颈。

       事件驱动架构的出现正是为了解决上述的问题。在这个架构中，事件服务器取代了数据库服务器的地位，成为数据交换核心，同时应用服务器的数据分析工作也由事件服务器的分析引擎取代，数据进入事件服务器后被封装成一系列的事件，再由事件分析引擎进行实时分析，再将分析结果分发给系统订阅者。

EPN的由来

       事件处理机制最早应用于监控核心设备的运行状态，在1980年前后，网络管理员为了能够随时监控核心设备的运行状，通过ping等方式捕获设备的基本运行信息，并将这些信息即时反馈到网管监视器上。这类应用中，事件仅对应一组基本的正常或异常的信号，接收端捕获到事件后直接将其显示在客户端屏幕上或者记录在日志中。

EPN的发展历史

       到了1998年后，监控的内容从最基本的设备状态升级到针对某一局部应用的信息概况。例如安全信息和事件管理(SIEM)，法规审计等。这类应用通常是通过分析应用程序和系统日志，将日志信息解析为面向管理人员的可视化图表。日志的状态改变如新增的一行记录将触发一组事件产生，事件处理端针对特定日志进行解析处理。
       再到2004年后，复杂事件处理 (Complex Event Processing) 开始蓬勃发展起来。复杂事件处理中涉及的事件范围从硬件或日志信息扩大到特定领域的软件系统各个应用层上交互产生的大量离散的信息。例如在金融软件系统中，针对电子交易的欺诈分析系统就是一种典型的CEP应用。这类应用中，事件对应电子交易系统产生的数据包和相应的环境数据，CEP引擎针对特定数据包进行特殊封装处理，采用行业规则进行分析，并最终将结果展示到客户端。

       2007年后，事件处理网络 (Event Processing Network) 的概念形成。在CEP的基础之上，如何淡化事件处理引擎对特定领域的依赖？通过一系列标准查询语言，开发脚本和规则引擎将业务相关的内容“虚拟化”，对千变万化的信息数据进行统一的封装，由一套事件引擎处理泛化的所有事件，这就是事件处理网络。