Bevezetés
Az informatikai technológiák és módszertanok rohamos fejlődésének egyik elkerülhetetlen velejárója a felhasználók az alkalmazások felé támasztott elvárásainak jelentős átalakulása.
A számos aspektusból párat kiemelve a reakcióidő, a rendelkezésre állás, a kezelt adatmennyiség és az elérhető eszközök témákat illetően a felhasználói elvárásokban és szokásokban bekövetkezett változások azt eredményezik, hogy a régen kialakított és alkalmazott szoftverarchitektúrák nem feltétlenül tudják kielégíteni a mai felhasználó minden igényét, ezáltal újabb és újabb architektúrák alakulnak ki, melyek kisebb-nagyobb teret hódítanak meg a piacon.
Ilyen szoftverarchitektúra a manapság egyre divatosabb microservice architektúra (MSA), mely a SOA (szolgáltatás-orientált architektúra) egy továbbgondolt változata, melyben az egyes szolgáltatások kisebbek, csak 1-1 elemi funkciót valósítanak meg, ezáltal még egyszerűbbé téve azok fejlesztését, tesztelését és üzemeltetését. Az MSA-ban kialakított szolgáltatások autonóm, egyedileg skálázható, rugalmas és gyors entitásai a rendszernek. Az architektúra hatékonyságának egyik alappillére a szolgáltatások közötti laza csatolás, melynek egyik eszköze az aszinkron kommunikáció.
Aszinkron kommunikáció
Míg szinkron kommunikáció eseténa hívó fél a hívás után mindaddig blokkolva marad, amíg a kérésre meg nem érkezik a válasz, addig aszinkron kommunikáció esetén a hívó fél a kérés elküldését követően a válasz megvárása nélkül el tud kezdeni foglalkozni soron következő feladatával, majd később a válasz beérkezését követően dolgozza fel azt.
Az aszinkron kommunikáció megvalósításának legelterjedtebb eszköze valamilyen üzenetsor használata, melynek lényege, hogy két rendszer egymás között egy köztes üzenetsoron keresztül kommunikál egymással, mely üzenetsor garantálja a biztos és csak egyszeri üzenettovábbítást, és nem feltételezi, hogy címzett rendszer a kérés pillanatában rendelkezésre áll, így addig tárolhatja az üzenetet, amíg a hívott fél ki nem veszi azt az üzenetsorból.
A rendszerek közötti, üzenetsoron keresztüli aszinkron kommunikációnak két típusa létezik:
Point-to-Point
Ezen modell használatával két rendszer kommunikációja valósítható meg, ahol az egyik aküldő (Producer), a másik a fogadó fél (Consumer). A küldő fél beteszi az üzenetet az üzenetsorba, amit a fogadó fél valamikor kivesz onnan. A válasz küldését és fogadását ugyanezen elv mentén, rendszerint egy másik üzenetsoron keresztül valósítják meg.
Publish/Subscribe
Ezt a modellt használva egy rendszer által küldött üzenet több címzetthez juttatható el anélkül, hogy az üzenetet többször ki kellene küldeni. Ebben a megvalósításban a küldő fél egy topic-ra publikálja üzenetét, melyet minden, az adott topic-ra feliratkozott fogadó fél megkap.
Számosgyártó készített már fizetős vagy open-source üzenetsor megvalósításokat, melyek mindegyikének megvannak a maga előnyei és hátrányai, emiatt egy ilyen rendszer kiépítésénél körültekintően kell választani a lehetőségek tárházából. A legismertebb termékek: IBM MQ, Apache Kafka, Apache ActiveMQ Artemis, RabbitMQ, Oracle Weblogic JMS
A publish/subscribe használatával olyan működési modell is kialakítható egyarchitektúrán belül, ahol az egyes szolgáltatások csak bizonyos események hatására végeznek számítási műveletet, egyéb esetben pedig várnak az eseményekbe következtére. Ezt a modellt hívjuk eseményvezérelt működésnek.
Eseményvezérelt kommunikáció az MSA-ban
Az MSA-ban kialakított szolgáltatások egymással történő kommunikációjuk segítségével valósítják megazt az üzleti folyamatot, melynek végtermékeként előáll a szolgáltatandó üzleti érték. A kommunikációs lánc lehet végtelenül egyszerű (pl. egyetlen microservice hívás), de előfordulhat, hogy komplex hívások sorozata által tud csak előállni a kívánt adatstruktúra. Utóbbi esetben gondoskodni kell arról,hogy a szolgáltatások a megfelelő sorrendben és időben kerüljenek meghívásra, és szükség esetén a híváslánc egy tranzakción belül történjen meg.
Sok esetben a szolgáltatások helyes sorrendben való meghívását és az általuk küldött válaszok feldolgozását egy erre a célra kinevezett kompozit logikát tartalmazó szolgáltatás végzi. Ez történhet normál HTTP csatornán, szinkron módon, a szigorú sorrendiséget betartva, de adott esetben ezeket a hívásokat egymástól teljesen párhuzamosan, aszinkron módon, valamilyen üzenetsoron keresztüli események elsütésével is elvégezheti. Előbbi esetet orchesztrációnak, utóbbit pedig az eseményekre való reagálásból adódóan reaktív működésnek nevezzük. Az üzenetsort ebben az esetben event bus-nak vagy event backbone-nak nevezzük, mely a publish/subscribe modellnél megismert topic-ot reprezentálja, ahová a szolgáltatások publikálhatják eseményüket, más szolgáltatások pedig feliratkozhatnak rájuk.
Nem nehéz elképzelni, hogy a párhuzamosított, eseményvezérelt működés sokkal gyorsabb, rövidebb válaszidejű rendszert eredményez, viszont ahol fontos a hívások sorrendisége, és egymás utánisága, ott nem használható. A valóságban általában olyan rendszerekkel találkozhatunk, ahol az orchesztrációs és reaktív módszerek egyfajta hibridje van alkalmazva.
Az ábrán egy MSA-ban megvalósított rendszer egy részlete látható, ahol narancs színnel vanjelölve a kompozit szolgáltatás, mely a kék és zöld szolgáltatásokat szinkronmódon, HTTP csatornán szólítja meg, ugyanakkor publikál egy eseményt is az event backbone-on, melyre a kék és lila szolgáltatások vannak feliratozva, így reagálni tudnak a sárga szolgáltatás eseményére.
A párhuzamosítás és az üzenetsorok működéséből fakadóelőnyök mellett az eseményvezérelt kommunikáció az elosztott rendszerek egyik állandó problémájára, a tranzakciókezelésre is nyújt megoldási lehetőségeket tervezési minták formájában.
Cikkünk második, befejező része az eseményvezérelt programozás tervezési mintáiról, és az azokáltal nyújtott tranzakciókezelési lehetőségekről fog szólni.
