Uitdagingen en maatregelen
Een event georiënteerde benadering wijkt in een aantal opzichten af van bijvoorbeeld een gegevens- of procesgerichte benadering. Onderstaande tabel toont aspecten waarop oplossingen die vooral met het request-response patroon werken, verschillen van event-driven oplossingen.
| Aspect | Request-response patroon | Event-driven patroon |
| Communicatie | 1-weg
(van A naar B) |
2-weg
(van A naar B en B naar A) |
| Koppeling | Sterk gekoppeld
(afhankelijk van elkaar) |
Los gekoppeld
(onafhankelijk van elkaar) |
| Tijdigheid | Synchroon
(A wacht op verwerking en resultaat van B) |
Veelal asynchroon
(A wacht niet op verwerking door B) |
| Schaalbaarheid | Moeilijker schaalbaar
(B krijgt het drukkers als aantal A’s groeit) |
Makkelijk schaalbaar
(via toevoegen nieuwe consumers) |
| Consistentie | Strong consistentie
(altijd consistent) |
Eventual consistency (tijdelijk niet consistent) |
| Foutafhandeling | Eenvoudig
(door syncrhoniteit) |
Complex
(door asynchroniteit) |
Uitdagingen[bewerken]
Realiseren van event-driven oplossingen brengt een aantal uitdagingen met zich mee. Bij het ontwerpen en realiseren van oplossingen moet daar rekening mee worden gehouden om te voorkomen dat er in de praktijk problemen optreden.
- Complexiteit in architectuur en beheer: Events worden vaak gebruikt om informatie uit te wisselen tussen applicaties in gedistribueerde omgevingen. Naarmate het aantal events en applicaties toeneemt, wordt lastig om overzicht te houden over aan wie, wanneer, welke events zijn verstrekt. Dit kan leiden tot fouten of inconsistenties.
- Debuggen en foutafhandeling: Het debuggen van event-driven systemen kan lastig zijn omdat events vaak asynchroon worden verwerkt. Het is moeilijker om de exacte volgorde van events te bepalen en te analyseren wat er precies gebeurd tijdens verwerking.
- Foutafhandeling: Wanneer er fouten optreden moeten die goed worden afgehandeld. Een van de risico's als dit niet gebeurd, is dat events vaker worden verstrekt of, erger nog, verloren gaan en afnemers nooit bereiken.
- Volgordelijkheid: Het kan belangrijk zijn dat afnemers events in de juiste volgorde ontvangen. Bijvoorbeeld bij applicaties waar de volgorde belangrijk is, zoals financiële of administratieve systemen.
- Inconsistentie: Mede door het asynchroon verwerken van events, kunnen gegevens tijdelijk inconsistent zijn. Na verloop van tijd moeten gegevens weer consistent zijn ('eventual consistency').
- Correcties: Wanneer aanbieders fouten maken en die later corrigeren, ontvangen afnemers eerst een event met foutieve informatie en daarna een event met de juiste informatie.
- Afnemers moeten rekening houden met de mogelijkheid dat een event foutieve informatie kan bevatten. Bijvoorbeeld door eerst een periode te wachten voor een kritische transactie wordt uitgevoerd of door een compenserende transactie uit te voeren als later een event met gecorrigeerde gegevens volgt.
- Vertraging: event-driven systemen moeten snelle verwerking van informatie ondersteunen. Maar er kan soms vertraging optreden bij het uitwisselen van events. Dit kan een negatieve invloed hebben op de reactietijd van het systeem of, bij samenwerking tussen meerdere applicaties, tot inconsistenties.
- Overbelasting: Een plotselinge stroom van events kan leiden tot overbelasting van applicaties. Event-verstrekking moet in die gevallen tijdelijk kunnen worden vertraagd ('throttling').
- Systeemaanpassingen: Veel bestaande (legacy)systemen werken gegevens-georiënteerd. Het aanpassen van deze systemen om events te kunnen verwerken kost tijd en geld.
- Monitoring en auditing: Continu monitoren is ingewikkelder bij gedistribueerde systemen en gebeurtenissen die asynchroon worden verwerkt. Dit kan auditing en logging uitdagend maken, vooral als er een nauwkeurige audit trail nodig is.
Maatregelen[bewerken]
Om aanwezige uitdagingen het hoofd te bieden zijn verschillende soorten maatregelen mogelijk. Hieronder worden een aantal te treffen maatregelen beschreven.
- Kennis opdoen: Zorg voor kennis van event-driven architectuur. Zonder voldoende kennis is er een (te) groot risico dat projecten niet succesvol verlopen. Onder andere binnen de financiële en logistieke sector is al veel ervaring opgedaan met event georiënteerd werken en zijn er best-practices waar gebruik van kan worden gemaakt.
- Consistentie borgen: Pas mechanismen toe om events altijd in de juiste volgorde te verwerken. Bijvoorbeeld via versienummering. timestamping en het gebruik van vaker uit te voeren (idempotente) operaties. Als er tijdelijk inconsistenties kunnen zijn, moet hier bij verwerking rekening mee worden gehouden.
- Betrouwbaarheid verbeteren: Gebruik specialistische (middleware)applicaties die de benodigde complexe technische functionaliteit bieden. Bijvoorbeeld voor message queues waarmee events kunnen worden opgeslagen voordat ze worden verwerkt, retry-mechanismen die zorgen voor automatische herverzending van events na verstoringen of fouten en dead-letter queues om events die niet zijn te verwerken te bewaren voor later onderzoek en afhandeling, rate limiting en throttling om het aantal events dat per seconde wordt verstrekt te beperken.
- Inzicht en robuusteheid verbeteren: Gebruik gespecialiseerde systeemtools, zoals monitoringtools voor continu toezicht op de verwerking van gebeurtenissen, loggingtools voor voor uitgebreide logging van verwerking, 'circuit breakers' die zorgen dat bij disfunctioneren van een bepaalde component de rest van het systeem blijft werken, tracing om de volledige reis van een event te kunnen volgen.
- Events aggregeren: Aggregeer veel kleine, snel opeenvolgende events zodat het aantal verstrekkingen naar afnemers beperkt blijft. Hierdoor blijft het aantal event en de bijbehorende systeembelasting beperkt.
Conclusie[bewerken]
Event-georiënteerde oplossingen kunnen grote voordelen bieden, maar zijn niet altijd eenvoudig te realiseren. Net zoals bij andersoortige oplossingen moet rekening worden gehouden met de omstandigheden waarbinnen een toepassing moet werken. Welke mogelijkheden hebben betrokken organisaties en applicaties? Wat voor onvoorziene omstandigheden kunnen zich voordoen? Hoe erg is het als er bepaalde fouten optreden? Antwoorden op dit soort vragen bepalen sterk mee of en hoe event-driven oplossingen geschikt zijn.