이벤트 지향 아키텍처

Event-driven architecture

이벤트 기반 아키텍처(EDA)는 이벤트의 생산, 검출, 소비 및 반응을 촉진하는 소프트웨어 아키텍처 패러다임입니다.

개요

이벤트는 "상태의 중요한 변화"[1]로 정의할 수 있습니다.예를 들어, 소비자가 자동차를 구입할 때 자동차 상태는 "판매용"에서 "판매용"으로 바뀝니다.자동차 딜러의 시스템 아키텍처는 이러한 상태 변화를 아키텍처 내의 다른 응용 프로그램에 알릴 수 있는 이벤트로 간주할 수 있습니다.형식적인 관점에서 보면 생성, 공개, 전파, 검출 또는 소비되는 것은 이벤트 알림이라고 불리는 (일반적으로 비동기) 메시지이며 이벤트 자체가 아닙니다.이 메시지는 메시지 방출을 트리거한 상태 변화입니다.사건은 여행하지 않고 그냥 일어난다.그러나 이벤트라는 용어는 종종 통지 메시지 자체를 나타내기 위해 메타니메이션으로 사용되며, 이로 인해 혼란이 발생할 수 있습니다.이것은 이벤트 드리븐 아키텍처가 종종 메시지 드리븐 아키텍처 위에 설계되기 때문에, 이러한 통신 패턴은 각 통신이 어떻게 처리되어야 하는지를 구별하기 위해 입력 중 하나인 메시지만을 필요로 합니다.

이 아키텍처 패턴은 느슨하게 결합된 소프트웨어 컴포넌트와 서비스 간에 이벤트를 전송하는 애플리케이션 및 시스템의 설계 및 구현에 의해 적용될 수 있습니다.이벤트 구동 시스템은 일반적으로 이벤트 이미터(또는 에이전트), 이벤트컨슈머(또는 싱크) 및 이벤트채널로 구성됩니다.이미터는 이벤트를 검출, 수집 및 전송할 책임이 있습니다.이벤트 이미터는 이벤트의 소비자를 알 수 없습니다.소비자가 존재하는지 여부도 알 수 없습니다.또한 존재하는 경우 이벤트의 사용방법이나 처리방법도 알 수 없습니다.싱크에는 이벤트가 나타나는 즉시 반응을 적용할 책임이 있습니다.이 반응은 싱크 자체에 의해 완전히 제공되거나 제공되지 않을 수 있습니다.예를 들어 싱크에서는 이벤트를 필터링, 변환 및 다른 컴포넌트로 전송하는 역할만 수행하거나 이러한 이벤트에 대한 자체적인 반응을 제공할 수 있습니다.이벤트 채널은 이벤트 방출기에서 이벤트 소비자에게 이벤트가 전송되는 도관입니다.이벤트의 올바른 분포에 대한 지식은 이벤트 [citation needed]채널 내에서만 존재합니다.이벤트 채널의 물리적인 실장은 메시지 지향 미들웨어나 포인트 투 포인트 통신 등의 기존 컴포넌트를 기반으로 할 수 있습니다.이는 보다 적절한 트랜잭션 이그제큐티브[clarify] 프레임워크가 필요할 수 있습니다.

이벤트 지향 아키텍처를 중심으로 시스템을 구축하면 분산 컴퓨팅 모델의 수평적 확장성을 단순화하고 장애에 대한 복원력을 높일 수 있습니다.이는 애플리케이션 상태를 여러 병렬 스냅샷 간에 복사하여 고가용성을 [2]확보할 수 있기 때문입니다.새로운 이벤트는 어디에서나 시작할 수 있지만, 보다 중요한 것은 도착 즉시 업데이트되는 데이터스토어 네트워크를 통해 전파됩니다.노드 추가도 간단합니다.어플리케이션 상태의 복사본을 가져와 일련의 이벤트를 전송하고 [3]실행할 수 있습니다.

수신 [4][5]이벤트에서 발생하는 트리거에 의해 서비스가 활성화될 수 있으므로 이벤트 기반 아키텍처는 서비스 지향 아키텍처(SOA)를 보완할 수 있습니다.이 패러다임은 특히 싱크대에서 독립형[clarify] 경영진이 제공되지 않을 때 유용합니다.

SOA 2.0은 이전에 알려지지 않았던 인과 관계를 활용하여 새로운 이벤트 [vague]패턴을 형성함으로써 SOA 및 EDA 아키텍처가 제공하는 의미를 보다 풍부하고 강력한 수준으로 발전시킵니다.이 새로운 비즈니스 인텔리전스 패턴은 이전에는 [vague]달성할 수 없었던 인식된 패턴에 부가가치 정보를 주입함으로써 기업에 기하급수적인 가치를 부여하는 자율적인 인적 처리 또는 자동 처리를 촉발합니다.

이벤트 구조

이벤트는 이벤트 헤더와 이벤트 본문의 두 부분으로 구성될 수 있습니다.이벤트 헤더에는 이벤트 이름, 이벤트 타임스탬프, 이벤트 유형 등의 정보가 포함될 수 있습니다.이벤트 본문은 검출된 상태 변경에 대한 상세 정보를 제공합니다.이벤트 본문은 이벤트 자체의 발생에 대한 반응으로 적용될 수 있는 패턴 또는 논리와 혼동해서는 안 됩니다.

이벤트 플로우 레이어

이벤트 드리븐 아키텍처는 이벤트(즉, 중요한 시간 상태 또는 사실)의 감지에서 시작하여 이벤트 구조의 형태로 기술적 표현의 생성으로 [6]진행되며 해당 이벤트에 대한 반응의 빈 세트가 아닌 것으로 끝나는 4개의 논리 계층 위에 구축될 수 있다.

이벤트 제작자

첫 번째 논리 레이어는 이벤트프로듀서로, 팩트를 검출해, 그 팩트를 이벤트메시지로 나타냅니다.예를 들어 이벤트 제작자는 이메일 클라이언트, 전자상거래 시스템, 모니터링 에이전트 또는 물리적 센서 유형일 수 있습니다.

이렇게 다양한 데이터 소스 집합에서 수집된 데이터를 평가를 위해 표준화된 단일 형식의 데이터로 변환하는 것은 이 첫 번째 논리 계층의 [6]설계 및 구현에 있어 중요한 작업입니다.그러나 이벤트가 강한 선언적 프레임임을 고려하면 어떤 정보 조작도 쉽게 적용할 수 있으므로 높은 수준의 [citation needed]표준화가 필요하지 않습니다.

이벤트 채널

이것은 두 번째 논리층입니다.이벤트 채널은 이벤트 생성기에서 수집된 정보를 이벤트엔진[6] 또는 싱크대로 전파하는 메커니즘입니다.이것은 TCP/IP 접속 또는 임의의 유형의 입력 파일(플랫, XML 형식, 이메일 등)일 수 있습니다.여러 이벤트 채널을 동시에 열 수 있습니다.일반적으로 이벤트 처리 엔진은 이를 거의 실시간으로 처리해야 하므로 이벤트 채널은 비동기적으로 읽힙니다.이벤트는 큐에 저장되며 나중에 이벤트 처리 엔진에 의해 처리되기를 기다립니다.

이벤트 처리 엔진

이벤트 처리 엔진은 이벤트를 식별하고 적절한 응답을 선택하여 실행하는 논리 계층입니다.또, 다수의 어설션을 트리거 할 수도 있습니다.예를 들어, 이벤트 처리 엔진에 들어오는 이벤트가 재고가 적은 제품 ID일 경우 "Order product ID" 및 "Notify people"[6]과 같은 반응을 일으킬 수 있습니다.

다운스트림 이벤트 주도형 액티비티

이것은 이벤트의 결과가 표시되는 논리 레이어입니다.이 작업은 여러 가지 방법 및 형태로 수행될 수 있습니다. 예를 들어, 이메일이 누군가에게 전송되고 [6]응용 프로그램이 화면에 일종의 경고를 표시할 수 있습니다.싱크(이벤트 처리 엔진)에 의해 제공되는 자동화 수준에 따라 다운스트림액티비티가 필요 없는 경우가 있습니다.

이벤트 처리 스타일

이벤트 처리에는 심플, 스트림, 컴플렉스의 3가지 일반적인 스타일이 있습니다.이 세 가지 스타일은 성숙한 이벤트 중심 [6]아키텍처에서 함께 사용되는 경우가 많습니다.

간단한 이벤트 처리

단순한 이벤트 처리란 특정 측정 가능한 조건의 변화와 직접 관련된 이벤트를 말합니다.단순한 이벤트 처리에서는 다운스트림액션을 시작하는 주목할 만한 이벤트가 발생합니다.단순 이벤트 처리는 일반적으로 작업의 실시간 흐름을 유도하기 위해 사용되므로 지연 시간과 [6]비용을 줄일 수 있습니다.

예를 들어, 센서가 타이어 공기압 또는 주변 온도의 변화를 감지하여 간단한 이벤트를 생성할 수 있습니다.차량의 타이어 공기압이 잘못되면 센서로부터 간단한 이벤트가 생성되어 타이어 상태를 운전자에게 알려주는 노란색 신호가 트리거됩니다.

이벤트 스트림 처리

Event Stream Processing(ESP; 이벤트스트림 처리)에서는 일반 이벤트와 주의 이벤트가 모두 발생합니다.통상의 이벤트(오더, RFID 송신)는, 통지가 없는지를 스크리닝 해, 정보 가입자에게 스트리밍 됩니다.이벤트 스트림 처리는 일반적으로 기업 내 및 기업 주변에서 실시간 정보 흐름을 유도하기 위해 사용되며, 이를 통해 적시에 의사결정을 [6]할 수 있습니다.

복잡한 이벤트 처리

복합 이벤트 처리(CEP)를 사용하면 단순 이벤트와 일반 이벤트의 패턴을 고려하여 복잡한 이벤트가 발생했음을 추론할 수 있습니다.복잡한 이벤트 처리는 이벤트의 합류를 평가한 후 액션을 수행합니다.이벤트(주의사항 또는 일반)는 이벤트 유형을 넘나들며 장기간에 걸쳐 발생할 수 있습니다.이벤트 상관관계는 인과관계, 시간관계 또는 공간관계일 수 있습니다.CEP는 고도의 이벤트인터프리터, 이벤트 패턴의 정의와 매칭, 상관기법의 채용을 필요로 한다.CEP는 일반적으로 비즈니스 이상 징후, 위협 및 [6]기회를 탐지하고 대응하기 위해 사용됩니다.

온라인 이벤트 처리

Online Event Processing(OLEP; 온라인 이벤트 처리)은 비동기 분산 이벤트 로그를 사용하여 복잡한 이벤트를 처리하고 영속적인 [7]데이터를 관리합니다.OLEP를 사용하면 이기종 시스템 간에 복잡한 시나리오의 관련 이벤트를 안정적으로 구성할 수 있습니다.따라서 매우 유연한 배포 패턴과 높은 확장성을 구현할 수 있으며 강력한 일관성을 제공합니다.그러나 처리 시간의 상한을 보장할 수는 없습니다.

매우 느슨한 커플링과 잘 분산되어 있습니다.

이벤트 드리븐 아키텍처는 매우 느슨하게 결합되어 있으며 적절하게 분포되어 있습니다.이 아키텍처의 훌륭한 분포는 이벤트가 거의 모든 것이 될 수 있고 거의 모든 곳에 존재하기 때문에 존재합니다.이 아키텍처는 이벤트 자체가 그 원인에 대한 결과를 알지 못하기 때문에 매우 느슨하게 연결되어 있습니다. 예를 들어, 현관문이 열렸을 때 정보를 기록하는 알람 시스템이 있다면,[6] 문이 열렸을 때 알람 시스템이 정보를 추가하는 것을 도어 자체는 알지 못합니다.

시멘틱 커플링 및 추가 연구

이벤트 기반 아키텍처는 공간, 시간 및 동기화 간에 느슨한 결합을 통해 정보 교환 및 분산 워크플로우를 위한 확장 가능한 인프라를 제공합니다.단, 이벤트아키텍처는 이벤트 서브스크립션과 패턴을 통해 기본 이벤트스키마 및 값의 의미와 밀접하게 관련되어 있습니다.스마트 시티 및 센서 웹과 같은 크고 개방적인 배치에서 사건의 의미적 이질성이 높기 때문에 사건 기반 시스템을 개발하고 유지하는 것이 어렵다.사건 기반 시스템 내에서 의미적 결합을 다루기 위해 사건의 대략적인 의미적 일치를 사용하는 것은 활발한 [8]연구 영역이다.

구현 및 예시

자바 스윙

Java Swing API는 이벤트 기반 아키텍처를 기반으로 합니다.이는 특히 Swing의 배경에서 사용자 인터페이스 관련 컴포넌트와 기능을 제공하려는 동기 부여와 함께 잘 작동합니다.API는 명명법 규칙(예: "ActionListener" 및 "ActionEvent")을 사용하여 이벤트 문제를 연관시키고 정리합니다.특정 이벤트를 인식할 필요가 있는 클래스는 적절한 리스너를 구현하고 상속된 메서드를 덮어쓰고 이벤트를 실행하는 개체에 추가됩니다.예를 들면, 다음과 같습니다.

일반의 학급 Foo 패널 확장 JPanel 용구 액션 리스트너 {     일반의 Foo 패널() {         잘 하는 군요();          JButton btn = 신규 JButton("클릭 미!");         btn.add Action Listener(이것.);          이것..더하다(btn);     }      @ 무효     일반의 무효 actionPerformed(ActionEvent ae) {         시스템..나가..인쇄("버튼 클릭하고 있어.");     } }

또는, 다른 구현의 선택은 개체에 익명의 클래스로 람다 표기법(자바 1.8부터)를 사용하여 듣는 사람을 넣는 것이다.아래는 예가 있습니다. 

일반의 학급 Foo 패널 확장 JPanel {     일반의 Foo 패널() {         잘 하는 군요();          JButton btn = 신규 JButton("클릭 미!");         btn.add Action Listener(ae -> 시스템..나가..인쇄("버튼 클릭하고 있어."));         이것..더하다(btn);     } }

자바스크립트

(() =>. {   'use 엄격한 ';    학급 EventEmitter {     생성자() {       이것..이벤트 = 신규 지도();     }      에(이벤트, 청취자) {       한다면 (typeof 청취자 !== '기능') {         던지다 신규 타입 에러('청취자는 함수여야 함');       }       허락하다 청취자 = 이것..이벤트.얻다(이벤트);       한다면 (!청취자) {         청취자 = 신규 세트();         이것..이벤트.세트(이벤트, 청취자);        }       청취자.더하다(청취자);       돌아가다 이것.;     }      쉬는(이벤트, 청취자) {       한다면 (!논쟁들.길이) {         이것..이벤트.분명한();       } 또 다른 한다면 (논쟁들.길이 === 1) {         이것..이벤트.삭제하다(이벤트);       } 또 다른 {         컨스턴트 청취자 = 이것..이벤트.얻다(이벤트);         한다면 (청취자) {           청취자.삭제하다(청취자);         }       }       돌아가다 이것.;     }      방출하다(이벤트, ...args) {       컨스턴트 청취자 = 이것..이벤트.얻다(이벤트);       한다면 (청취자) {         위해서 (허락하다 청취자 의 청취자) {           청취자.적용합니다.(이것., args);         }       }       돌아가다 이것.;     }   }    이것..이벤트 이미터 = 이벤트 이미터; })();

사용방법:

컨스턴트 이벤트 = 신규 이벤트 이미터(); 이벤트.에('푸', () => { 콘솔.로그.('푸'); }); 이벤트.방출하다('푸'); // "foo"를 출력합니다. 이벤트.쉬는('푸'); 이벤트.방출하다('푸'); // 아무 일도 일어나지 않음

오브젝트 파스칼

이벤트는 오브젝트 파스칼 언어의 기본 요소 중 하나입니다.유니캐스트 모델(1 대 1)은 여기서 사용됩니다.즉, 송신자는 한 명의 수신자에게만 정보를 보냅니다.이 제한에는 특별한 이벤트청취자가 필요하지 않다는 장점이 있습니다.이벤트 자체는 다른 개체의 메서드에 대한 포인터입니다.포인터가 비어 있지 않으면 이벤트 발생 시 이벤트핸들러가 호출됩니다.이벤트는 일반적으로 GUI를 지원하는 클래스에서 사용됩니다.하지만 이벤트 신청 분야는 이곳뿐만이 아니다.다음 코드는 이벤트 사용 예시입니다.

구성 단위 마이 커스텀 클래스;    인터페이스  사용하다   반;    유형   {자체 이벤트 정의}   TACident 이벤트 = 절차.(송신자: 토브젝트; 컨스턴트 에바루: 정수) 의 물건;    TMy Custom Object(TMy Custom Object) = 학급(토브젝트)   사적인     FData: 정수;              // 클래스의 단순 필드 예제     사고: TACident 이벤트; // 이벤트 - 일부 개체의 메서드에 대한 참조     변경: TNotify 이벤트;     // 이벤트 - 일부 개체의 메서드에 대한 참조     절차. 데이터 설정(가치: 정수); // 클래스의 필드 값을 설정하는 메서드   보호되고 있다     절차. 사고(컨스턴트 에바루: 정수); 가상; // 자신의 정의에 따라 이벤트를 생성하는 메서드     절차. 변경; // VCL 라이브러리의 정의에 따라 이벤트를 생성하는 메서드   일반의     생성자 만들다; 가상;   // 클래스 생성자     파괴자 파괴하다; 덮어쓰다;  // 클래스 소멸자   출판된     소유물 데이터.: TACident 이벤트 읽어주세요 FData 쓰다 데이터 설정; // 클래스 속성 선언     소유물 OnAccident(온사고): TACident 이벤트 읽어주세요 사고 쓰다 사고; // 클래스 외부에 이벤트 노출     소유물 온체인지: TNotify 이벤트 읽어주세요 변경 쓰다 변경;         // 클래스 외부에 이벤트 노출     절차. 곱셈 기준(컨스턴트 에바루: 정수);  // 이벤트에 대한 자체 정의를 사용하는 메서드   끝.;    실행  생성자 TMy Custom Object(TMy Custom Object).만들다; 시작한다.   FData := 0; 끝.;  파괴자 TMy Custom Object(TMy Custom Object).파괴하다; 시작한다.   FData := 0;   상속된 파괴하다; 끝.;  절차. TMy Custom Object(TMy Custom Object).사고(컨스턴트 에바루: 정수); 시작한다.   한다면 맡겨진(사고)    그리고나서 사고(자신, 에바루); 끝.;  절차. TMy Custom Object(TMy Custom Object).변경; 시작한다.   한다면 맡겨진(변경)    그리고나서 변경(자신); 끝.;  절차. TMy Custom Object(TMy Custom Object).곱셈 기준(컨스턴트 에바루: 정수); 시작한다.   FData := FData * 에바루;   한다면 FData > 1000000    그리고나서 사고(FData); 끝.;  절차. TMy Custom Object(TMy Custom Object).데이터 설정(가치: 정수); 시작한다.   한다면 FData << 고객명 >>님 가치    그리고나서     시작한다.      FData := 가치;      변경;     끝.; 끝..

생성된 클래스는 다음과 같이 사용할 수 있습니다.

... 절차. TMy Form(TMyForm).커스텀 정보 표시(송신자: 토브젝트); 시작한다.   한다면 송신자 이 TMy Custom Object(TMy Custom Object)    그리고나서 Show Message(메시지 표시)('데이터가 변경되었습니다.'); 끝.;  절차. TMy Form(TMyForm).퍼포먼스 어시던트(송신자: 토브젝트; 컨스턴트 에바루: 정수); 시작한다.   한다면 송신자 이 TMy Custom Object(TMy Custom Object)    그리고나서 Show Message(메시지 표시)('데이터가 1000000을 넘었습니다!'새로운 값: ' + 에바루.ToString(ToString)); 끝.; ... {지정된 클래스의 개체인 변수 삭제} 변화하다   LMy 오브젝트: TMy Custom Object(TMy Custom Object);  ... {개체의 표시} LMy 오브젝트 := TMy Custom Object(TMy Custom Object).만들다; ... {이벤트에 메서드 추가} LMy 오브젝트.온체인지 := 마이폼.커스텀 정보 표시; LMy 오브젝트.OnAccident(온사고) := 마이폼.퍼포먼스 어시던트; ... {더 이상 필요하지 않은 개체 삭제} LMy 오브젝트.공짜;  ...

「 」를 참조해 주세요.

기사들

레퍼런스

  1. ^ K. Mani Chandy 이벤트 기반 응용 프로그램:California Institute of Technology, 2006년, 비용, 이점 및 설계 접근법
  2. ^ Martin Fowler, 이벤트 소싱, 2005년 12월
  3. ^ 마틴 파울러, 병렬 모델, 2005년 12월
  4. ^ Hanson, Jeff (January 31, 2005). "Event-driven services in SOA". JavaWorld. Retrieved 2020-07-21.
  5. ^ Sliwa, Carol (May 12, 2003). "Event-driven architecture poised for wide adoption". Computerworld. Retrieved 2020-07-21.
  6. ^ a b c d e f g h i j 브렌다 M.Michelson, 이벤트 주도 아키텍처 개요, Patricia Seybold Group, 2006년 2월 2일
  7. ^ "Online Event Processing - ACM Queue". queue.acm.org. Retrieved 2019-05-30.
  8. ^ Hasan, Souleiman, Sean O'Rain, 그리고 Edward Curry. 2012."이질적인 이벤트의 대략적인 의미 일치"제6회 ACM International Conference on Distributed Event-Based Systems(DEBS 2012)에서 252~263.독일 베를린: ACM. "DOI"

외부 링크