當我在看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，同時它也是事件驅動架構的一種，從一張圖能夠看出兩者區別。