当我在看Event Driven Architecture , 想到了什么（一）

时间 2019-11-09

标签 event driven architecture 想到什么繁體版

原文原文链接

知识准备

关键词解释：html

iBPM：表明智能业务流程管理(Intelligent Business Process Management)
SOA：面向服务的架构（SOA）是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。这使得构建在各类各样的系统中的服务能够以一种统一和通用的方式进行交互。
CEP:复琐事件处理 (CEP) 处理同时发生的不一样事件，以肯定这些事件对应的操做。事件通道中的事件能够有不一样的事件类型，而且能够长期发生。能够根据内容、时间或位置来关联事件。所以，CEP 一般用于检测异常、风险，甚至业务机会，旨在利用相比传统报告解决方案更具现时性的信息的优点，最终在竞争中占据上风。
EDA：一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。若是这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔以后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。
ESP:在事件流处理 (ESP) 中，除了“相关”事件之外，“一般的”事件（如全部通常指令或 RFID 事件）也会发布到事件通道中。这对事件处理提出了更高的要求，同时也提供了更多评估选项。
SEP:在简单事件处理 (SEP) 中，只有“相关”事件才会被放入事件通道中进行处理。好比“XY 类别的汽车已售罄”或“冬季轮胎库存紧张”。这很是相似于基于消息的系统。处理逻辑评估事件类型和内容，而后相应地作出反应。
MDM:MDM 提供通用组件（或服务）以确保数据维护和分发的一致性。
FP
FRP 10.RP 11.ESB:Gartner 于 2002 年创造了术语“企业服务总线”，分析师 Roy Schulte 进一步引入这个术语来描述当时市场上的一类软件产品。10 年后，关于 EBS 究竟是什么或者它应该提供什么依然没有达成共识。根据制造商和来源的不一样，有不少不一样的定义。其中，ESB 的定义包括： “一种集成架构样式，支持提供者和服务用户之间经过由各类点对点链接构成的公共通讯总线进行通讯” “企业用来集成应用程序环境中服务的基础架构。” “一种架构模式，使用面向服务支持异构环境之间的互操做性。”
Faas
serverless

1、EDA

1.1 EDA定义

Gartner在2003年引入了一个新术语事件驱动架构（Event Driven Architecture，EDA), 主要用于描述一种基于事件的范例。EDA 是一种用于进行设计和实现应用和系统的方法—在这些应用和系统里, 事件所触发的消息能够在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。这些应用程序中的EDA极大地改进了企业或政府响应不一样的、表面上毫无关联事件的能力。经过提供瞬时过滤、聚合和关联事件的能力，EDA能够快速地检测出事件并判断它的类型，从而帮助组织机构快速、恰当地响应和处理这些事件。一般事件能够采用发布/订阅机制。node

1.2 事件驱动架构概述

一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。若是这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔以后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。react

构建一个包含事件驱动构架的应用程序和系统，会使这些应用程序和系统响应更灵敏，由于事件驱动的系统更适合应用在不可预知的和异步的环境里。linux

事件驱动架构在具体实现中是指由一系列相关组件构成的应用，而组件之间经过事件机制完成必定的业务功能。因为在一个EDA系统中各个组件都只专一于处理输入的消息与发布输出的消息，于是EDA系统可以更有加效地对管道化（pipelined）的、由多软件模块连接而成的并发事件流（concurrent processing of events）进行处理。web

1.3 EDA特色

EDA系统中各组件以异步方式响应事件，在本质上是能够并行的，于是在政府部门的电子政务应用中具备极大的优点。其具有如下特色:数据库

◆ 并发执行

◆ 事件触发/数据触发/时间规则触发

◆ 实时/增量响应

◆ 分布式事件系统处理
复制代码

上述特色能很好地知足政府部门应用需求，如跨部门的应急联动系统或联合监管协同服务等应用。编程

从目前状况来看，EDA系统还只是处理简单事件的系统，对于复琐事件的处理还有待进一步的研究。可是，EDA仍然能做为SOA系统的一个有效补充，弥补SOA系统的一些不足，如实时响应度不够。设计模式

1.4 事件驱动架构优点

事件驱动设计和开发所提供的优点以下所示:安全

◆ EDA提升了对不断变化的业务需求的响应，最大限度地减小了对现有业务应用的影响，也常消除了对新打包应用的须要。若是采用特有的粗颗粒服务模型能够基于业务目标快速肯定可控的业务变动，并直接、迅速、有效地实施变动以达到业务敏捷性和完整性。bash

◆ 能够更容易开发和维护大规模分布式应用程序和不可预知的服务或异步服务;

◆ 能够很容易，低成本地集成、再集成、再配置新的和已存在的应用程序和服务。

◆ 促进远程组件和服务的再使用，拥有一个更灵敏、没有Bug的开发环境。

从时间维度来看EDA的优点:

◆ 短时间利益:更容易定制，由于设计对动态处理有更好的响应;

◆ 长期利益:系统和组织的状态变得更精准，对实时变化的响应接近于同步。

1.5 EDA和SOA之间的关系：

SOA和EDA是平等和互补的。因此，我不认同那些努力传播SOA的同窗们所说的“EDA只是SOA的一个子集”的论断。一个更普遍的事件驱动架构概念，不只是超越事件驱动SOA的，还应该包括实时信息流和分析，以及复琐事件处理。

当EDA认为事件是系统中最重要的组成时，你最好注意那些组件或者服务，以及组件之间的‘通道’”

与Request/Response系统不一样的是，要求请求者必须明确发送请求信息，而事件驱动架构提供一个机制去动态响应事件。在一个EDA系统里，事件产生者发布事件，事件消费者接受事件。

业务系统能够从SOA和EDA中受益不浅，由于事件发生时EDA系统能触发事件消费者，SOA服务能够快速地从相同的消费者中访问、查询。系统要求有最高的响应性，当事件被触发时这个系统必须能快速决定必须的动做。到事件结束，事件应该被发布和消费，并且事件要穿越SOA全部的边界，包括整个体系结构和物理层。

系统要有最高的响应性，当事件触发时这个系统必须能快速决定必须的动做。到事件结束，事件应该被发布和消费，并且事件要穿越SOA全部的边界，包括整个体系结构和物理层。

1.6 ESB链接EDA和SOA

企业服务总线(Enterprise Service Bus，ESB)在异类平台和环境间创建联系，充当容许不一样应用程序进程之间进行通讯的中间层。部署到企业服务总线的服务能够由使用者或事件触发。它同时支持同步方式和异步方式，可促进一个或多个参与者之间的交互。所以 ESB 可提供 SOA 和 EDA 范例的全部功能。“ESB提供了消息的传输，格式的转换等关键功能，为服务的请求者和服务提供者之间架设了沟通的桥梁，是企业应用基础架构的粘合剂。” 甲骨文公司大中华区高级技术经理黄建勇说。

企业服务总线可链接各个异类节点并做为中介传递其间的全部通讯和交互，这些节点可分散在面向服务的体系结构(同步一对一方法)和事件驱动的体系结构(异步多对多方法)中。ESB 是目前处理集成挑战的最有效方法，是可提供最大业务灵活性和不一样应用程序间的高效链接技术解决方案。

EDA应用在不少ESB（企业服务总线）产品中，好比FiornaoESB中间件产品支持同步、异步和请求响应事件，事件处理和传输实用不一样的技术例如JMS，HTTP，电子邮件和基于XML的RPC等。好比“政府网上监察系统”经过对被监察对象（系统）数据的实时采集，经过EDA技术的事件触发，事件过滤，实现对违规、违法、越权行政、超时限行政等问题进行通知和督办等。

1.7 EDA应用方向

事件驱动架构(EDA)是分布式应用程序的广泛架构形式，很是典型的是:分布式应用程序都被设计成为模块化的、封装的、可共享事件服务的组件。可以经过应用程序、适配器以及无入侵性的代理操做来建立这些服务。

因为EDA的特色，在金融贸易、能源贸易、电信以及欺诈检测这些行业中，一直都在采用事件驱动架构(EDA)技术。近期在我国政府的电子政务建设中

利用EDA分布式处理架构的优点构建共享交换平台，实现跨部门、跨平台、跨应用系统的政务信息资源的共享与交换，并对政府应急系统和跨委办局之间的业务协同办公提供支撑和保障。

EDA

Martin Fowler

2、响应式编程和响应式系统（EP&&ERP）

响应式技术目前成功的标志之一是“响应式reactive”成为了一个热词，而且跟一些不一样的事物与人联系在了一块儿——经常伴随着像“流streaming”、“轻量级lightweight”和“实时real-time”这样的词。

2.1 FRP

FRP定义

2.2 响应式编程Reactive programming，

不要把它跟函数响应式编程混淆了，它是异步编程下的一个子集，也是一种范式，在这种范式下，由新信息的有效性availability推进逻辑的前进，而不是让一条执行线程a thread-of-execution去推进控制流control flow。

响应式编程通常是事件驱动event-driven，相比之下，响应式系统则是消息驱动message-driven的

响应式编程的基本好处是：提升多核和多 CPU 硬件的计算资源利用率；根据阿姆达尔定律以及引伸的 Günther 的通用可伸缩性定律Günther’s Universal Scalability Law 脚注3 ，经过减小序列化点serialization points来提升性能。

另外一个好处是开发者生产效率，传统的编程范式都尽力想提供一个简单直接的可持续的方法来处理异步非阻塞式计算和 I/O。在响应式编程中，因活动(active)组件之间一般不须要明确的协做，从而也就解决了其中大部分的挑战。

响应式编程真正的发光点在于组件的建立跟工做流的组合。为了在异步执行上取得最大的优点，把反压back-pressure加进来是很重要，这样能避免过分使用，或者确切地说，避免无限度的消耗资源。

2.4 事件驱动 && 消息驱动

响应式编程——专一于短期的数据流链条上的计算——所以倾向于事件驱动，而响应式系统——关注于经过分布式系统的通讯和协做所获得的弹性和韧性——则是消息驱动的脚注4 （或者称之为消息式messaging 的）。

一个拥有长期存活的可寻址long-lived addressable组件的消息驱动系统跟一个事件驱动的数据流驱动模型的不一样在于，消息具备固定的导向，而事件则没有。消息会有明确的（一个）去向，而事件则只是一段等着被观察observe的信息。另外，消息式messaging更适用于异步，由于消息的发送与接收和发送者和接收者是分离的。

一条消息就是一则被送往一个明确目的地的数据。一个事件则是达到某个给定状态的组件发出的一个信号。在一个消息驱动系统中，可寻址到的接收者等待消息的到来而后响应它，不然保持休眠状态。在一个事件驱动系统中，通知的监听者被绑定到消息源上，这样当消息被发出时它就会被调用。这意味着一个事件驱动系统专一于可寻址的事件源而消息驱动系统专一于可寻址的接收者。

2.5 响应式系统

响应式系统的基石是消息传递message-passing，消息传递为两个组件之间建立一条暂时的边界，使得它们可以在时间上分离——实现并发性——和空间space ——实现分布式distribution与移动性mobility。这种分离是两个组件彻底隔离isolation以及实现弹性resilience和韧性elasticity基础的必需条件。

2.6 响应式系统&&响应式编程

响应式编程是一种管理内部逻辑internal logic和数据流转换dataflow transformation的好技术，在本地的组件中，作为一种优化代码清晰度、性能以及资源利用率的方法。响应式系统，是一组架构上的原则，旨在强调分布式信息交流并为咱们提供一种处理分布式系统弹性与韧性的工具。

响应式编程是一个很是有用的实现技术，能够用在响应式架构当中。可是记住这只能帮助管理一部分：异步且非阻塞执行下的数据流管理——一般只在单个结点或服务中。当有多个结点时，就须要开始认真地考虑像数据一致性data consistency、跨结点沟通cross-node communication、协调coordination、版本控制versioning、编制orchestration、错误管理failure management、关注与责任concerns and responsibilities分离等等的东西——也便是：系统架构。

3、CEP

3.1 关键概念

事件指在业务里发生的事情，包括业务活动、流程状态、网络或IT条件，或者其余任何东西。不少事件只要可以识别出来就能够进行处理，一般会伴随着发送警报。当没法可靠处理单个事件而必须在上下文里分析时，就会使用CEP。几乎全部场景里，CEP分析都要求事件可以实时关联，而且要求带有准确时间戳的必定格式。

CEP应用大体分为两大类：事件关联和根本缘由分析。一般来讲，事件关联用来识别不是单个事件，而是多个事件组合起来触发的条件.

好比“若是你打喷嚏而且发烧了，那么你感冒了。”根本缘由分析用来解释一系列事件—一般是错误—的底层缘由，确保补救措施并不只仅针对症状，而是可以真正解决问题。

全部CEP都应该是实时的，或者和事件同时发生，可是，固然这里的同时发生意味着不少种状况。CEP处理的关系越复杂，就越难保证明时性。

3.2 从事件驱动编程（Event-driven Programming)开始

若是你写过GUI程序，对事件处理必定不陌生。事实上，事件驱动编程已经成为一种设计模式。大多数的GUI库都会采用这一模式。

简单的说，事件驱动模式包括三个参与者：事件产生者，事件分发器和事件处理器。

事件产生者（Events Generator）决定是否须要产生事件。好比，GUI上的每一个组件都是一个事件产生者，能够根据用户操做产生鼠标事件或者键盘事件。
事件分发器（Events Dispatcher）收集全部事件产生者发出的事件放入事件队列(Events Queue)，并根据事件的类型将事件分发给已经注册的事件处理器。事件分发器一般由GUI框架实现。
事件处理器（Events Handler)根据接收到的事件进行处理，须要GUI框架的使用者自行编写。

事件驱动编程的核心价值在于：程序的执行流程不是预先定义好的，而是由程序的使用者决定的。这将极大加强程序的交互性。

就好像DVD与RPG游戏的区别：前者的剧情是设定好的，你只能进行开始、暂停、快进、回退等有限的交互；后者能够决定主角的行为从而影响故事的结局。

3.3 事件驱动业务（Event-driven Business)

代码的世界不多是现实世界的完整镜像，但必定是对现实世界的某种抽象，这种抽象可以简化代码世界中对问题的分析和处理。同时，这种抽象还能够反向映射到现实世界，为咱们解决现实问题提供思路。

现代企业生存的外部环境处于剧烈的变化之中，“敏捷企业”已经成为生存之道，而事件驱动业务是敏捷企业的一个基本要求。

事件驱动业务（Event-driven Business)，是在连续的业务过程当中进行决策的一种业务管理方式，即根据不一样时点上出现的一系列事件触发相关的任务，并调度可用的资源执行任务。若是说事件驱动编程可以为软件带来更灵活的交互性和强大的功能，那么企业中的事件驱动业务可以大幅度提升业务的效率和灵活性。

事件驱动业务依托于比较成熟的信息化建设。各个业务应用系统在产生连续不断的数据流的同时，根据定义好的条件产生一些业务事件，按照策略对这些业务事件进行分析处理，触发新的业务事件或者业务流程，即实现了业务的事件驱动。

从上面的描述能够看出，事件驱动业务要求可以快速（毫秒级）、不间断的处理连续、海量的数据，具有灵活的规则或策略设置，从而具有迅速识别、捕获、响应实时业务数据的能力。而传统的企业IT架构一般采用：

在业务应用系统中处理业务操做遵循固定的业务流程（Business Process）处理跨系统事务，而且这些流程不多变化基于数据仓库进行海量数据的存储及过后分析这种IT架构远远达不到事件驱动业务的要求。

事件驱动业务可以应用的业务领域不少，凡是须要快速处理连续性数据、须要可以灵活制定策略的业务，均可以采用事件驱动的业务模式。如证券行业常见的风险分析预警（事前及事中风控）、投资决策（程序化交易）、经纪人绩效计算等。

3.2.1 业务事件处理的几个层次

其实在传统的IT架构中，咱们已经实现了业务事件的处理。好比在传统的业务应用系统中，咱们一般将业务数据存储在数据库中，经过应用系统的操做界面由人工发现和处理业务事件。

这样的处理方式存在两个不足，一是速度慢，二是对于复杂的状况只靠人脑难以处理。因而有了两个技术方向：

消息队列（MQ）对于速度慢的解决办法是用机器代替人工，为了在多个系统之间传递消息，发展出了消息队列（MQ）的技术商业智能（BI）为了应对复杂性，经过数据仓库将数据整合到一块儿，并用专门的工具在数据模型的基础上进行分析可是上述两个方向是正交的：MQ不适合处理复杂性，而BI主要适应于对结构化的历史数据的分析，没法处理“如今”的状况。

3.4 CEP：鱼与熊掌能够兼得

CEP（Complex Event Processing）的出现解决了上述两个方面的问题，在实时性和复杂性方面都获得了很好的解决。

3.4.1 处理数据流

无论是单独的应用系统，仍是数据仓库，都是先将数据存储到数据库/数据仓库，而后再处理或查询。而CEP与MQ相似的将数据看做是数据流 。在连续数据的快速移动过程当中进行分析处理。这样的方式不须要很大的数据加载，彻底能够在内存中进行，从而可以快速产生结果。

3.4.2 处理复杂性

业务事件可能很复杂，在各类不一样的数据流中源源不断产生各类类型的事件。须要对这些业务事件进行复杂的计算，如过滤、关联、聚合等，同时还须要考虑这些也是事件出现的时间序列。最终才能产生有意义的事件，或触发业务流程。同时，这些计算的规则可能还会常常变化。

这一类的问题一般经过基于规则的推理机（即规则引擎）来实现。

综上所述，CEP在逻辑上应该包括：

事件发生器经过应用系统、文件系统、数据库、互联网、人工、以及传感器产生事件
事件处理器模式的匹配、验证和改进，路由，转换以及编排
事件消费者与事件发生器相似，也能够是应用系统、文件系统、数据库、互联网、人工界面等

3.5 CEP的三个基本模型及其特性，以及CEP的限制

CEP的最简单方案是触发或者阈值激活处理。该模型里，事件要么直接致使一些操做的发生，要么是当事件达到某个阈值时会执行某个操做。CEP可以在从源到目的地的事件流里引入事件处理，好比在线事务处理，由于生成的延时很小。虽然触发或阈值CEP可以经过单个类型事件实现，可是也可使用多个不一样权重的不一样事件来提供对条件更为深刻的理解。

第二种模型是上下文模型，该模型假定一个事件或者事件集在某个特定的上下文里才有意义，所以须要维护这个上下文。能够经过模式匹配来完成，意味着查找知足某个模式的特定事件集，或者当事件改变某个显式上下文或状态时经过状态事件处理，随后在上下文理解事件。后一种方案很普遍地用于网络管理，这里上下文示例可能包括初始化，激活或者错误。

对于更为复杂的CEP，可使用级联分析模型，这里的事件流包括使用某个CEP模型处理的一种或者多种类型的事件。它们并非直接采起操做加以处理，而是生成其余事件或者事件上下文，随后注入CEP的其余阶段，直到可以最终决定采起什么操做。

综上所述,须要关注的点是：

触发或者阈值激活处理
上下文模型
级联分析模型

4、iBPM

iBPM 表明智能业务流程管理(Intelligent Business Process Management)。Gartner 认为iBPM在 BPM 的基础上加强了复琐事件处理(CEP)、智能机器人和云服务的能力，并在案例管理以及流程协调能力上更为卓越。

Gartner的Jim Sinur最先提出了“iBPM”的概念。实际上，当业务流程管理系统（BPMS）与其余智能工具融合, iBPM便应运而生。这些智能工具包括机器学习、云服务、移动社交、复琐事件处理(CEP)、物联网集成、业务活动监控（BAM)。

把事件技术跟操做联系在一块儿，让分析结果跟应用集成及有用的商业活动关联，这些对于业务流程管理（BPM）的实践者来讲是重要的。

4.1 特色

iBPM有如下一些特色：

更智能的自动化

更智能的路由，由流程机器人自动完成流程工做；

更智能的移动工做

云服务，支持任何地方的流程工做；

更智能实时的分析能力

复琐事件处理（CEP）能力；

4.2 iBPM与BPM的区别

BPM是以规范标准的方式对业务流程进行建模以及执行的一组工具，而iBPM 是BPM的智能提高。从流程发现、设计、建模、执行、监控以及分析优化的流程全生命周期的各个阶段，融合了人工智能、复琐事件处理、云服务和移动技术。

4.3 iBPM 特色

根据Pega System，iBPM中的智能（i）体如今如下几个方面：

动态案例管理：

iBPM支持传统的预设计划和结构化的BPM流程，也支持建立关联知识工做者的动态流程案例。这些动态流程案例反映出融合社交、协做、响应式的新型工做模式，包括异常处理。动态案例能够由多层级的任务组成，也能够响应或触发事务。

社交iBPM：

iBPM在流程生命周期的各阶段融入社交工具。最重要的是，iBPM提供了社交网络在规则协做下的应用场景。

移动iBPM：iBPM容许组织经过移动设备无缝启动和完成端到端的自动化流程工做。流程状态、流程工做和经过移动流程合做的即时性使得全新的移动工做成为可能。
云iBPM：

经过云端的iBPM平台，能够安全创建企业应用程序，也就是iBPM平台即服务（PaaS）；而最终BPM解决方案构建和部署后，iBPM成为能够在云上执行或运行的服务:iBPM软件即服务（SaaS）；

iBPM中的业务规则：

业务规则实现业务决策逻辑和业务策略，这些规则驱动iBPM的解决方案。业务规则有许多类别和类型，如决策树、决策表、约束和表达式。业务规则的重点是使业务逻辑尽量接近业务，而没必要担忧执行时间、执行方法或执行顺序。业务规则是声明式的，可使用预测建模技术来检测业务模式，而后在iBPM的场景中调用或操做已发现的规则；

iBPM用于实时决策的分析和自适应：

行业中最重要的趋势之一是数据科学的出现，特别是大数据分析。预测分析能够经过解开隐藏在大量数字信息中的规律，为组织带来实实在在的好处。 iBPM经过预测和自适应（自学习）分析，使得探寻某些决策具备可操做性。在iBPM中，可执行模型中用以挖掘的数据来源和类型多种多样，涵盖社交网络、事务数据和数据仓库。iBPM运用预测和自适应数据分析模型，在各类动态案例交互中提供更智能化的执行方案。

BPM解决方案是动态的、社会化的、移动的、规则驱动和适应性的。这些解决方案能够不断地分析、学习和适应外部事件，以及三方成员和参与者的行为。 iBPM为适应性企业提供了平台、解决方案、最佳实践、方法和管理方式。

iBPM的研究和技术使得“适应性企业”在商业环境中脱颖而出。经过智能业务流程管理，自适应的企业不断将其经营目标的政策和业务流程彻底透明，使得业务流程管理的能见度更高、控制力更强。在将来的商业环境中，适应性企业在应对变化时变得更灵活和主动。毕竟，商业中惟一不变的就是改变！

5、MDM

5.1 MDM 的做用

MDM 的做用是组织如何处理公司实施其业务流程所需的主数据。

主数据管理 — 主数据管理 (MDM) 是旨在确保主数据质量的管理活动。其目的是保证主数据对象适用于公司全部增值流程。MDM 包括全部必要的操做和控制流程，这些流程包含质量保证定义，并保证对主数据对象实施维护和管理。此外，MDM 还提供 IT 组件来映射这个过程。所以，MDM 起着支撑做用，并以隐含的方式从两个方向帮助提升附加值。首先是数据质量管理不断提升主数据的数据质量，从而提高信息的价值；其次是主数据对象对全部核心流程的适用性，从而经过优化的核心流程提升附加值。

主数据对象 — 主数据对象是正式的基本业务对象，在公司内的增值流程中使用。主数据对象描述结构（蓝图）和质量要求（如结构中的验证、容许值）。它们与用户交互，一般将参考数据（值列表）理解为公司的实际主数据。一个典型的例子是标准化的值列表，如 ISO 国家/地区代码和 ISO 货币代码。主数据使用这些列表做为分组、分层和分类的基础。在本文中，主数据不是惟一的参考列表，但都是正式的基本业务对象。

5.2 MDM 系统架构

做为业务转型，MDM 追求的目标是在公司范围内实施主数据管理。要在合理的运营成本下实现这个目标，IT 必须支持这个过程。一方面，这适用于 MDM 自己的手动支持流程，另外一方面适用于数据处理和分发的自动化流程。

为此，有必要创建一个清晰的、包括系统相互依赖关系的系统架构。MDM 的系统架构描述目前的形势和计划的目标架构。如下结果对 MDM 发展规划很是有意义：

针对 MDM 发展规划的 IT 整体规划，以基础架构为重点

包含数据模型和数据存储的主数据规划
跨公司信息流（价值和商品的流动）概述
运营流程（影响 MDM 发展规划和支持 MDM 所需的 IT 应用程序系统）的流程规划
设计领域包括包含必要的 MDM 特定系统的应用程序架构、对 IT 组件的支持、主数据物流的集成架构和基础系统架构。检查应用程序系统和候选 MDM 以确保它们提供相应的功能，同时用相应的标准对其进行评估。应用程序和集成组件基于与基础设施架构相互独立的基础架构平台。信息架构对 MDM 有着特殊意义。除了跨公司信息流（价值和商品的流动）之外，信息架构还描述了主数据对象、关联及其属性。
复制代码

6、ESB

6.1 定义

ESB 是一个中间件解决方案，使用面向服务的模型来促进和支持异构环境之间的互操做性。没有规范准肯定义了什么是 ESB 或者它应该提供什么功能。虽然 ESB 主要与“调节”和“集成”这类概念相关，但它还适合做为一个平台以相似于应用服务器的方式提供服务。ESB 表明被称做“集成”和“应用服务器”的产品类别的整合。

6.2 关键特性

ESB 的一个关键特性是服务虚拟化。本文提出的 ESB 蓝图提供了各类功能的有序排列，构成了评估 ESB 产品的基础。

6.3 要点

企业服务总线应被视为一个架构样式或模式，而不是一款产品。 ESB 没有定义或规范，所以也没有标准。 ESB 可帮助实现系统间的松散耦合。 ESB 上的服务是无状态的。长期运行的流程不属于 ESB，可是在使用 BPEL 和 BPMN 之类语言的 BPM 系统中受支持。 “误用”ESB 来执行批处理时应当心谨慎，由于可能会对性能产生负面影响

更多详情

7. 关系说明

7.1. ESP && CSP && CEP

ESP 与 CSP 之间的区别究竟是什么？ESP 是流的处理，其中事件流是按时间顺序排列的事件序列，如股票行情自动收录器。而 CEP 工做在称为“事件云”的“云”上。事件云是来自 IT 系统不一样部分的多个事件生成活动的结果。事件云可能包含多个流。所以，流是云的一个特殊实例。

在流内使用时间顺序有本身的优势：处理速度快，由于只有少数几个事件须要保存在缓冲区中。可是，依赖关系在云中很是重要：发生了哪些依赖事件？或者一般更精彩的是：或许没有发生哪些事件？

很明显，事件流处理侧重于高速处理，而 CEP 的重点是从事件云提取信息。在实践中，因为 ESP 和 CEP 之间的差异变得模糊，因此更强大的 CEP 占据了主导地位。

7.2. SOA && EDA

SOA 标识符是服务的松散耦合、客户端在提供者与使用者之间发起的 1:1 通讯以及同步响应行为。EDA 的标识符是分离的交互、n:m 通讯、事件驱动的操做和异步操做。咱们认为没有必要肯定一端或另外一端。SOA 为 EDA 提供了很是坚实的基础，应用程序能够同时采用这两种风格。在如下状况下，组件应使用 SOA 调用服务：

确切知道要调用哪一个服务
服务将只调用一次
期待获得关于服务完成的应答
期待应答
在如下状况下，组件应使用 EDA 发布事件：
复制代码

在某些状况下，通知全部相关接收方
不知道事件的相关接收方
不知道接收方如何对该事件作出反应
不一样接收方对同一事件有不一样反应
涉及从发送方到接收方的单向通讯
复制代码

从这方面来讲，“2 + 2 > 4”，由于这两种架构风格的组合大于各部分之和。SOA 在执行预约义的流程和逻辑时使用“请求-应答”通讯模式（多是异步方式，请求与响应之间的时间间隔比较长）。相比之下，ED 应用程序使用典型的“发布者/订阅者”模式，在某些状况下可处理大量事件，旨在建立更少的新“可操做”事件。SOA 与 EDA 是相辅相成的：结合使用能够建立按需提供的高商业价值应用程序

7.2.1 多事件航班

常常乘飞机旅行的人都很是熟悉一个使人不快的问题“个人行李在哪里?”在值机柜台，旅客与行李分离。飞行结束时，旅客须要通过一系列流程才能取回行李，包括：

办票柜台
安检
行李处理
舱门操做
航班操做
机场运做控制 (BAM) 仪表盘
客户服务
复制代码

最好的临时结果是飞机按时起飞，乘客和行李都在飞机上。然而，咱们不少人都知道，可能会发生许多致使事情变得复杂的事件。行李可能在会在办理登记手续与登机之间丢失。乘客可能因安检处排队致使误机。行李可能包含禁带物品，须要搜查。航班可能取消，乘客可能改飞其余地方。乘客办理登记手续后可能决定改签航班。也可能发生其余复杂状况。

在这种状况下，SOA、EDA 或二者的组合

在作决定以前，须要考虑的是：所描述的场景并非单个“登机服务”或流程。而是一系列相互影响的服务/流程。交互很是复杂，取决于多个边界条件，所以这是一个典型的“感知与响应”场景，或者说是在必要时启动 SOA 服务的 EDA 技术。试图将这种场景统一在一个可执行的流程中势必会陷入一片混乱。

1. 办票:乘客办理登记手续、检查行李
2. 安检:乘客进入/离开安检区
3. 行李处理:在安检站扫描行李、行李装入集装箱
4. 舱门操做:舱门打开、登机、最后登机、关闭
5. 航班操做:登机口、装载集装箱、出发、起飞
6. 客户服务:新航班复查行李
复制代码

7.3. SOA 和 MDM

SOA 的一个重要优势是 IT 组件的松散耦合。这有利于组件重用，而且组件能够更轻松、更灵活地支持新功能或新流程 。

MDM 应基于面向服务的概念，并提供通用组件（或服务）以实现数据维护和主数据检索的一致性。在这里，SOA 架构理念再次与 MDM 不谋而合。这一论断支持了两个不一样的观点：

MDM 业务服务 — 用于维护和验证主数据的可重用业务逻辑
MDM 信息服务 — 业务流程中使用的可重用信息
复制代码

7.4. ESB && EDA && SOA

ESB链接EDA和SOA

7.5.iBPM && BPM && CEP

把事件技术跟操做联系在一块儿，让分析结果跟应用集成及有用的商业活动关联，这些对于业务流程管理（BPM）的实践者来讲是重要的。

8.Serverless

Serverless（无服务器架构）指的是由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发，彻底被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。

8.1 Serverless架构的优势

下降运营成本：

Serverless是很是简单的外包解决方案。它可让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑，不然您就不得不本身来维护。因为这个服务使用者的数量会很是庞大，因而就会产生规模经济效应。在下降成本上包含了两个方面，即基础设施的成本和人员（运营/开发）的成本。

下降开发成本：

IaaS和PaaS存在的前提是，服务器和操做系统管理能够商品化。Serverless做为另外一种服务的结果是整个应用程序组件被商品化。

扩展能力：

Serverless架构一个显而易见的优势即“横向扩展是彻底自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是，您只需支付您所须要的计算能力。

更简单的管理：

Serverless架构明显比其余架构更简单。更少的组件，就意味着您的管理开销会更少。

“绿色”的计算：

按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着Serverless架构的出现，让服务提供商提供咱们的计算能力最大限度知足实时需求。这将使咱们更有效地利用计算资源。

9. FAAS

FaaS（Functions as a Service）函数即服务，FaaS是无服务器计算的额一种形式，当前使用最普遍的是AWS的Lambada。

如今当你们讨论Serverless的时候首先想到的就是FaaS，有点甚嚣尘上了。FaaS本质上是一种事件驱动的由消息触发的服务，FaaS供应商通常会集成各类同步和异步的事件源，经过订阅这些事件源，能够突发或者按期的触发函数运行。

传统的服务器端软件不一样是经应用程序部署到拥有操做系统的虚拟机或者容器中，通常须要长时间驻留在操做系统中运行，而FaaS是直接将程序部署上到平台上便可，当有事件到来时触发执行，执行完了就能够卸载掉。

9.1 Serverless && FaaS

Function 能够理解为一个代码功能块，这个功能块具体包含多少功能，没法明确给出定义，但有一个明确的指标：冷启动时间须要在毫秒数量级。由于 FaaS 的本质上是以程序的快速启动来实现正真的按需运行，按需伸缩，以及高可用。Function 配合调度系统，就能够彻底作到开发者对服务运行的实例无感，真 Serverless。

Serverless 比 FaaS 的外延要广，FaaS 主要解决的是用户自定义的代码逻辑如何作到 Serverless，能够叫作 Serverless Compute，同时它也是事件驱动架构的一种，从一张图能够看出两者区别。

9.2 从云的发展来看 FaaS

第一阶段的云主要解决硬件资源（网络，计算，存储）的运维和供给问题，也就是 IaaS 云，能够理解成基于硬件资源的共享经济。IaaS 云的交付的主要是资源，接口以及控制台也是面向资源的，尽可能以模拟物理机房环境来下降应用的迁移成本。而云发展到当前阶段来看，出现了两种需求：

正真的按需计算

原来云的按需计算只是虚拟机维度的，按时间计费以及弹性伸缩，并不能正真作到按需计算，计算和内存资源都是预申请规划的，和服务的请求并发数并无明确的关系，哪怕一段时间一个请求没有，资源仍是依然占用。而 FaaS 能够作到按请求计费，不须要为等待付费，能够作到更高效的资源利用率。

面向应用

本质上用户对云的指望是应用的运行环境，而且最好是只让用户关心业务逻辑，而不须要关心，或者尽可能少关心技术逻辑（好比监控，性能，弹性，高可用，日志追踪等）。这也是云原生应用（Cloud Native Application）这个概念提出的背景。

云原生应用就是让渡一部分功能给云，以实现弹性，高可用，故障恢复，下降研发运维成本的应用

但 FaaS 给出来一个方案。就是应用只须要把包含本身业务逻辑的 Function 提交给云，其余的事情由云来完成。这样，云至关于直接接管了业务逻辑模块，而后其余的技术功能直接由云来提供，不依赖开发者在本身应用中引入标准化框架来实现。