În contextul evoluției rapide a arhitecturii software, comunicarea eficientă și coordonarea între diversele componente și servicii existente sunt esențiale. Broker Pattern (model bazat pe intermediari) reprezintă o soluție structurată care răspunde acestor provocări, prin promovarea principiului loose coupling (asociere slabă) și a scalabilității în cadrul sistemelor distribuite.
În esență, Broker Pattern funcționează ca un intermediar între componente și sisteme. Abstractizând logica de comunicare și coordonare, facilitează o arhitectură de sistem care să fie scalabilă și decuplată. Modelul are la bază trei componente: broker (intermediarul), producers (producătorii), și consumers (consumatorii). Brokerul este componenta centrală responsabilă cu recepționarea, filtrarea și livrarea mesajelor. Producătorii generează mesajele ce urmează să fie procesate, în timp ce consumatorii se abonează la acestea și monitorizează diversele tipuri de mesaje ca să acționeze pe baza lor. Brokerul funcționează precum un intermediar care redirecționează mesajele către recipienți relevanți, pe baza unor reguli predefinite și care gestionează distribuția evenimentelor către abonați multipli. Designul facilitează comunicarea directă, fără a fi necesară partajarea de informații între partidele implicate în comunicare.
Să analizăm un scenariu real pentru a vedea cum se comportă Broker Pattern în acțiune. Un eveniment Order Completed (comandă finalizată) este publicat în broker. Brokerul transmite apoi acest eveniment către inventar, către sistemul de facturare și către serviciul de notificări. Este posibil ca fiecare din aceste servicii să mai trebuiască să aducă date suplimentare din alte locații, demonstrând capacitatea modelului de a decupla sistemele eficient. În cadrul unei alte instanțe, un mesaj Process Payment (procesare plată) este trimis de la serviciul comenzi către serviciul plăți prin broker, mesaj care conține toate datele necesare ca parte din payload (transfer). Aceste exemple demonstrează rolul versatil al unui broker atât în gestionarea evenimentelor, cât și în redirecționarea mesajelor.
Este esențial să înțelegem distincția dintre evenimente și mesaje pentru a folosi Broker Pattern eficient. Evenimentele presupun modificări semnificative de stare sau de ocurență în cadrul sistemului. De asemenea, evenimentele respectă modelul publish-subscribe (publicare-abonare) unde la un eveniment pot reacționa mai mulți abonați. Evenimentele sunt transmise/distribuite tuturor părților implicate, promovând decuplarea, deoarece agenții care publică nu trebuie să știe cine sunt agenții abonați. Invers, mesajele reprezintă comunicarea sau datele trimise de o componentă altei componente, tipic după model point-to-point. Acest fapt presupune o cuplare sau o asociere mai strânsă, din moment ce expeditorul știe cine este destinatarul. Mesajele sunt cereri directe pentru a face ceva sau a primi o anume informație.
O coadă de mesaje păstrează mesajele pentru un eventual consum, după modelul FIFO, în timp ce un broker de mesaje gestionează cozile de mesaje, funcționând mai mult ca un service bus care redirecționează traficul și care decuplează componentele de sistem.
Event-Driven Architecture (EDA - arhitectura bazată pe evenimente) este o paradigmă de design în cadrul căreia componentele sistemului comunică și reacționează la evenimente. Broker Pattern joacă un rol important în EDA, având rolul de coloană vertebrală care redirecționează și livrează evenimentele eficient și fiabil.
În cadrul sistemelor de monitorizare în timp real din sănătate, de exemplu, semnele vitale ale pacienților sunt monitorizate continuu prin dispozitive interconectate. Aceste dispozitive generează evenimente de fiecare dată când apar măsurători anormale, precum bătăi cardiace neregulate sau schimbări drastice de tensiune. Un broker redirecționează aceste evenimente esențiale furnizorilor relevanți și sistemelor de alertă. Acest lucru atrage după sine atenția și intervenția cadrului medical, deci implicit salvarea de vieți. De exemplu, un monitor cardiac cu IoT ar putea detecta un ritm cardiac neregulat pe care să îl trimită către broker. Acest broker trimite evenimentul mai departe unui sistem de alertă ce notifică personalul medical, datele fiind logate într-un sistem electronic, iar printr-o aplicație mobilă se trimite o notificare pe telefon mobil pacientului sau familiei.
În cadrul serviciilor financiare, detecția fraudei în timp real este crucială pentru a proteja clienții și integritatea instituțiilor financiare. Tranzacțiile sunt monitorizate continuu, iar activitățile suspecte, precum retragerile mari de numerar sau tranzacțiile rapide și consecutive generează evenimente care, prin broker, sunt trimise unui sistem de detecție a fraudelor și ofițerilor responsabili de conformitate, pentru a se lua măsuri imediate. De exemplu, dacă pe contul unui utilizator se înregistrează, într-un timp foarte scurt, un număr mare de tranzacții, datele acestor tranzacții sunt trimise către broker. Acest broker redirecționează informația unui serviciu de detecție fraudă care analizează tiparul și, dacă e considerat suspicios, generează o alertă pentru echipa de conformitate care poate îngheța contul temporar. Acest mecanism de detecție rapidă și de răspuns imediat previne activitățile frauduloase și reduce potențialele pierderi financiare.
În sistemele distribuite, Broker Pattern are un rol crucial în coregrafie și orchestrare. Coregrafia implică un sistem în care componentele reacționează la evenimente după care decid independent care sunt următorii pași de urmat. În acest caz, brokerul se asigură că evenimentele sunt transmise tuturor componentelor relevante fără ca aceste componente să-și cunoască una alteia identitatea. De exemplu, pe o platformă e-commerce, un eveniment prin care se finalizează o comandă generează o actualizare a inventarului, procesarea plății și trimiterea notificărilor, toate coordonate de un broker.
Pe de altă parte, orchestrarea presupune un coordonator care gestionează interacțiunea dintre componente. Brokerul facilitează comunicarea dintre orchestrator și componente, asigurându-se că atât comenzile, cât și răspunsurile sunt redirecționate corect. Într-un sistem de rezervări de călătorie, un orchestrator gestionează rezervările de zboruri, hoteluri și mașini, folosind un broker pentru a se comunica cu fiecare serviciu și a gestiona răspunsurile.
SAGA pattern este un tipar de design care gestionează tranzacțiile ce implică microservicii multiple. Practic, sparge o tranzacție mare în tranzacții mai mici, în pași mai mici coordonați de servicii multiple. Brokerul joacă un rol vital în coordonarea acestor pași, asigurându-se că fiecare pas din tranzacția SAGA este transmis serviciilor relevante și că sunt generate tranzacții compensatorii, dacă apar erori. Păstrând mesajele și încercând să le retrimită, brokerul crește fiabilitatea tranzacțiilor distribuite. De exemplu, într-un sistem ce gestionează comenzi, finalizarea unei comenzi presupune pași multipli precum verificarea inventarului, procesarea plății și trimiterea comenzii. Dacă plata eșuează, brokerul inițiază acțiuni compensatorii precum actualizarea inventarului cu noul stoc și anularea livrării.
Azure oferă o serie de servicii care reflectă principiile Broker Pattern, permițând construcția de arhitecturi robuste și decuplate. Fiecare serviciu Azure deservește unor scopuri specifice, oferind flexibilitate adaptată la diverse studii de caz. Prezentăm în detaliu cum funcționează serviciile și de ce acestea sunt ideale pentru scenariile asociate.
Azure Service Bus Queues permit producătorilor să ordoneze mesajele într-o coadă de mesaje pe care consumatorii o pot procesa.
Exemplu: O aplicație web pune comenzile într-o coadă, în timp ce serviciile backend procesează aceste comenzi.
Industria e-commerce: Când un client efectuează o comandă pe un site e-commerce, detaliile comenzii sunt trimise sub formă de mesaj către Service Bus Queue.
Mesajul este stocat/ținut în coada de mesaje până când serviciile backend (de exemplu, procesarea comenzilor, gestionarea inventarului) îl pot procesa.
Serviciul de procesare comenzi verifică periodic coada de mesaje, preia următorul mesaj și procesează comanda prin următorii pași: actualizare de inventar, plată client, generare de detalii de expediere.
Fiabilitate: Mesajele (comenzile) nu se pierd, chiar dacă serviciile backend sunt temporar indisponibile, permițându-se procesarea comenzilor.
Reîncercare automată: Livrarea mesajelor este repetată, reîncercată în cazul unor erori tranzitorii, aspect prioritar pentru a păstra nivelul de satisfacție al clienților în e-commerce.
Decuplare: Producătorii (aplicația web) și consumatorii (serviciile backend) nu trebuie să fie online simultan, ceea ce se traduce în scalare independentă și mentenanță independentă, aspect esențial în gestionarea perioadelor când se efectuează foarte multe cumpărături.
Exemplu suplimentar: Se poate realiza un sistem de bilete unde rezervările sunt puse într-o coadă și sunt procesate de servicii diferite responsabile cu alocarea locurilor și confirmarea plății. Datorită acestui fapt, sistemul rămâne fiabil și răspunde cererii, chiar și în perioadele cu cerere crescută (de pildă, vânzarea biletele de concert).
Azure Service Bus Topics oferă suport pentru un mecanism de mesaje pe tiparul publicare-abonare unde producătorii publică mesaje în topicuri, iar abonații primesc mesaje pe baza abonamentelor lor.
Exemplu: O aplicație publică pe un topic mesaje legate de activitatea utilizatorilor, în timp ce microserviciile se abonează pentru a efectua diverse acțiuni.
Platforme Social Media: Aplicația publică într-un topic mesaje legate de activitățile utilizatorilor (de exemplu, postări, aprecieri, comentarii).
Diverse microservicii se abonează la un topic pe baza funcției: un serviciu actualizează feedul utilizatorilor, un alt serviciu actualizează notificările, iar un alt serviciu analizează interacțiunea utilizatorilor.
Fiecare serviciu abonat primește doar mesajele relevante operațiunilor sale și le procesează în consecință.
Filtrare de mesaje: Abonații primesc doar mesajele de care sunt interesați, reducându-se procesarea care nu este necesară și mărindu-se eficiența, ceea ce este vital pentru interacțiunile social media în timp real.
Scalabilitate: Se oferă suport pentru abonați multipli pe un singur topic, ceea ce permite serviciilor (actualizarea feedurilor, notificări, data analitice) să scaleze independent, aspect esențial în gestionarea a milioane de utilizatori.
Flexibilitate: Se pot adăuga abonați noi fără a modifica producătorii existenți sau alți abonați, permițând extensibilitate și integrare facilă.
Exemplu suplimentar: Într-o aplicație financiară, evenimentele de tranzacționare sunt publicate pe un topic, iar serviciile se abonează pentru a gestiona procesele de evaluare a riscului, de conformitate și de raportare. Astfel, fiecare funcție poate procesa tranzacțiile independent, în același timp menținându-se integritatea generală a sistemului.
Azure Event Hubs este menit pentru ingestia și procesarea în timp real a unor volume mari de evenimente.
Exemplu: Dispozitivele IoT trimit date de tip senzor către un nod centralizator de evenimente unde se poate efectua atât analiză, cât și procesare backend.
Industria medicală: Monitoarele cardiace ce includ componente IoT ( precum monitoare cardiace, manșete pentru măsurarea presiunii arteriale) trimit date legate de semnele vitale ale pacienților către un Event Hub (nod centralizator de evenimente), în mod continuu.
Event Hub capturează și stochează datele temporar.
Serviciile de procesare backend, precum platformele analitice în timp real sau sistemele AI de monitorizare a stării de sănătate, citesc datele din Event Hub pentru a detecta anomalii și a oferi diagnostice posibile.
Procesare de date: Se pot ingera milioane de evenimente pe secundă, ceea ce este potrivit pentru aplicațiile medicale ce generează continuu cantități mari de date.
Latență redusă: Datele se procesează aproape în timp real, aspect crucial pentru intervențiile medicale ce trebuie efectuate la timp.
Partiționare: Evenimentele de intrare sunt distribuite pe mai multe partiții în vederea procesării paralele, a performanței ridicate și a fiabilității aplicațiilor importante pentru viață.
Exemplu suplimentar: O aplicație ce face streaming live de evenimente sportive trimite scoruri sau punctaje către Event Hubs, unde sunt procesate actualizările și datele analitice. Astfel, fanii primesc informații de ultimă oră, în timp real, în timpul meciului.
Azure Event Grid simplifică programarea bazată pe evenimente prin gestiunea redirecționării evenimentelor.
Exemplu: O aplicație cloud emite evenimente către Event Grid de fiecare dată când se generează evenimente pentru activități precum crearea de resurse, ceea ce declanșează acțiuni în Azure Functions sau Logic Apps.
Servicii financiare: Când se creează un cont nou într-o aplicație bancară, aplicația emite un eveniment către Event Grid.
Event Grid redirecționează evenimentul către abonații predefiniți, precum sunt sistemele de detecție fraudă, instrumentele de audit și conformitate, dar și fluxurile de onboarding pentru clienți.
Fiecare abonat reacționează la eveniment executând acțiuni relevante, precum verificarea contului în ceea ce privește activități suspecte, conformitatea la regulamente și generarea de emailuri și tutoriale pentru clienții noi.
Integrare: Se integrează cu diverse servicii Azure și componente webhooks customizate, ceea ce permite lansarea mai rapidă a fluxurilor complexe din cadrul serviciilor financiare.
Scalabilitate: Se realizează o scalare automată pentru a se face față la volume mari de evenimente, ceea ce permite aplicației bancare să gestioneze crearea unui număr mare de conturi și de actualizări.
Filtrare de evenimente: Se identifică evenimentele țintă relevante pentru abonați specifici, ceea ce permite gestionarea eficientă a evenimentelor și reducerea timpului alocat pentru procesări inutile, ceea ce îmbunătățește calitatea securității și a gradului de conformitate.
Exemplu suplimentar: O platformă e-commerce folosește Event Grid pentru a genera fluxuri de lucru pentru procesarea comenzilor, actualizarea inventarului și generarea de notificări când se efectuează o achiziție. Comunicarea și actualizările eficiente îmbunătățesc nivelul de satisfacție a clienților.
Broker Pattern oferă o abordare flexibilă și scalabilă a comunicării și a coordonării în cadrul sistemelor distribuite. Suita de servicii Azure, incluzând Service Bus Queues, Service Bus Topics, Event Hubs și Event Grid se aliniază perfect principiilor Broker Pattern, ceea ce permite programatorilor să construiască arhitecturi robuste și decuplate. Folosind aceste unelte, organizațiile se pot asigura că dețin sisteme scalabile, fiabile și ușor de menținut. Fiecare serviciu este adaptat unor nevoi specifice, asigurând performanță optimă și eficiență în studii de caz diverse.
Choreography pattern - Azure Architecture Center \| Microsoft Learn
Publisher-Subscriber pattern - Azure Architecture Center \| Microsoft Learn
Queue-Based Load Leveling pattern - Azure Architecture Center \| Microsoft Learn
Priority Queue pattern - Azure Architecture Center \| Microsoft Learn
Event Sourcing pattern - Azure Architecture Center \| Microsoft Learn
Saga pattern - Azure Design Patterns \| Microsoft Learn
Azure Service Bus messaging - queues, topics, and subscriptions - Azure Service Bus \| Microsoft Learn
Azure Event Grid documentation \| Microsoft Learn
de Vlad Petrean
.jpg)