Arquitectura guiada per esdeveniments

L'arquitectura guiada per esdeveniments (EDA) és un paradigma d'arquitectura de programari relacionat amb la producció i detecció d' esdeveniments. Les arquitectures basades en esdeveniments són de naturalesa evolutiva i proporcionen un alt grau de tolerància a errors, rendiment i escalabilitat. No obstant això, són complexos i intrínsecament difícils de provar. Les EDA són bones per a càrregues de treball complexes i dinàmiques.

Visió general

Un esdeveniment es pot definir com "un canvi significatiu d'estat". Per exemple, quan un consumidor compra un cotxe, l'estat del cotxe canvia de "en venda" a "vengut". L'arquitectura del sistema d'un concessionari d'automòbils pot tractar aquest canvi d'estat com un esdeveniment l'ocurrència del qual es pot donar a conèixer a altres aplicacions dins de l'arquitectura. Des d'una perspectiva formal, el que es produeix, publica, propaga, detecta o consumeix és un missatge (normalment asíncron) anomenat notificació d'esdeveniment, i no l'esdeveniment en si mateix, que és el canvi d'estat que va desencadenar l'emissió del missatge. Els esdeveniments no viatgen, només succeeixen. No obstant això, el terme esdeveniment s'utilitza sovint metonímicament per designar el missatge de notificació en si, cosa que pot generar certa confusió. Això es deu al fet que sovint es dissenyen arquitectures basades en esdeveniments sobre arquitectures basades en missatges, on aquest patró de comunicació requereix que una de les entrades sigui només text, el missatge, per diferenciar com s'ha de gestionar cada comunicació.

Aquest patró arquitectònic es pot aplicar mitjançant el disseny i la implementació d'aplicacions i sistemes que transmeten esdeveniments entre components i serveis de programari poc acoblats. Un sistema basat en esdeveniments normalment consta d'emissors (o agents) d'esdeveniments, consumidors d'esdeveniments (o embornals) i canals d'esdeveniments. Els emissors tenen la responsabilitat de detectar, reunir i transferir esdeveniments. Un emissor d'esdeveniments no coneix els consumidors de l'esdeveniment, ni tan sols sap si existeix un consumidor i, en cas que existeixi, no sap com s'utilitza o es processa posteriorment l'esdeveniment. Els lavabos tenen la responsabilitat d'aplicar una reacció tan bon punt es presenta un esdeveniment. La reacció pot o no ser completament proporcionada pel propi lavabo. Per exemple, el lavabo pot tenir la responsabilitat de filtrar, transformar i reenviar l'esdeveniment a un altre component o pot proporcionar una reacció autònoma a aquest esdeveniment. Els canals d'esdeveniments són conductes en què els esdeveniments es transmeten des dels emissors d'esdeveniments als consumidors d'esdeveniments. El coneixement de la correcta distribució dels esdeveniments està present exclusivament dins del canal d'esdeveniments. La implementació física dels canals d'esdeveniments es pot basar en components tradicionals com ara programari intermedi orientat a missatges o comunicació punt a punt que podria requerir un transactional executive framework més adequat.

La construcció de sistemes al voltant d'una arquitectura basada en esdeveniments simplifica l'escalabilitat horitzontal en models de computació distribuïda i els fa més resistents als errors. Això es deu al fet que l'estat de l'aplicació es pot copiar en diverses instantànies paral·leles per a una alta disponibilitat. Els nous esdeveniments es poden iniciar a qualsevol lloc, però el que és més important es propaguen per la xarxa de magatzems de dades actualitzant-se cadascun a mesura que arriben. Afegir nodes addicionals també es fa trivial: simplement podeu fer una còpia de l'estat de l'aplicació, alimentar-lo amb un flux d'esdeveniments i executar-lo.

L'arquitectura basada en esdeveniments pot complementar l'arquitectura orientada a serveis (SOA) perquè els serveis es poden activar mitjançant activadors activats en esdeveniments entrants. Aquest paradigma és especialment útil sempre que la pica no ofereix cap self-contained executive.

SOA 2.0 evoluciona les implicacions que les arquitectures SOA i EDA proporcionen a un nivell més ric i robust aprofitant relacions causals desconegudes anteriorment per formar un nou patró d'esdeveniments. Aquest nou patró d'intel·ligència empresarial activa un processament humà autònom o automatitzat que afegeix un valor exponencial a l'empresa injectant informació de valor afegit al patró reconegut que no s'hauria pogut aconseguir anteriorment.

Topologies

L'arquitectura basada en esdeveniments té dues topologies principals: "topologia de corredor", on els components transmeten esdeveniments a tot el sistema sense cap orquestrador. Proporciona el màxim rendiment i escalabilitat. Mentre que a la "topologia del mediador" hi ha un orquestrador central que controla el flux de treball dels esdeveniments. Proporciona un millor control i capacitat de gestió d'errors. També podeu utilitzar un model híbrid i combinar aquestes dues topologies.

Tipus d'esdeveniments

Hi ha diferents tipus d'esdeveniments a EDA, i les opinions sobre la seva classificació poden variar. Segons Yan Cui, hi ha dues categories clau d'esdeveniments:

Esdeveniments de domini

Els esdeveniments de domini signifiquen esdeveniments importants dins d'un domini empresarial específic. Aquests esdeveniments es restringeixen a un context limitat i són vitals per preservar la lògica empresarial. Normalment, els esdeveniments de domini tenen càrregues útils més lleugeres, que contenen només la informació necessària per al processament. Això es deu al fet que els oients d'esdeveniments generalment es troben dins del mateix servei, on els seus requisits s'entenen més clarament.

Esdeveniments d'integració

D'altra banda, els esdeveniments d'integració serveixen per comunicar canvis en diferents contextos limitats. Són crucials per garantir la coherència de les dades a tot el sistema. Els esdeveniments d'integració solen tenir càrregues útils més complexes amb atributs addicionals, ja que les necessitats dels oients potencials poden diferir significativament. Això sovint condueix a un enfocament més exhaustiu de la comunicació, donant lloc a una sobrecomunicació per garantir que tota la informació rellevant es comparteix de manera eficaç.

Estructura de l'esdeveniment

Un esdeveniment pot tenir dues parts, la capçalera de l'esdeveniment i el cos de l'esdeveniment també conegut com a càrrega útil de l'esdeveniment. La capçalera de l'esdeveniment pot incloure informació com ara el nom de l'esdeveniment, el segell de temps de l'esdeveniment i el tipus d'esdeveniment. La càrrega útil de l'esdeveniment proporciona els detalls del canvi d'estat detectat. El cos d'un esdeveniment no s'ha de confondre amb el patró o la lògica que es pot aplicar en reacció a l'ocurrència de l'esdeveniment en si.

Hi ha dos mètodes principals per estructurar les càrregues útils d'esdeveniments en arquitectures basades en esdeveniments:

1. Tots els atributs necessaris es poden incloure a la càrrega útil: aquest mètode millora la velocitat i l'escalabilitat, però pot comportar problemes de coherència de les dades a causa de la presència de múltiples sistemes de registre. A més, pot introduir problemes d'acoblament de segells i ample de banda a escala.
2. Aquest mètode implica incloure només claus o identificadors, cosa que permet als consumidors obtenir les dades necessàries de fonts de dades externes, com ara bases de dades. Tot i que aquest enfocament és menys escalable i més lent a causa de la necessitat de consultes a la base de dades, minimitza l'ús d'ample de banda i redueix els problemes d'acoblament.

Aquests mètodes representen dos extrems d'un espectre més que opcions binàries. Els arquitectes han de dimensionar acuradament les càrregues útils de l'esdeveniment per satisfer les necessitats específiques dels consumidors d'esdeveniments.