Programozás 5.
A tárgy a szoftverarchitektúra és a rendszerek közötti kommunikáció alapjait mutatja be. Két kérdésre keres választ: hogyan szerveződhet egy alkalmazás egyetlen telepítési egységbe vagy több önálló szolgáltatásba, és hogyan kommunikálhatnak ezek a részek egymással és a klienssel.
Az architektúrák közül a monolit, a moduláris monolit és a mikroszerviz kap külön hangsúlyt; a többi stílus (rétegzett, hexagonális, microkernel, SOA, service-based, serverless, eseményvezérelt) az összevetéshez kapcsolódik. Az összehasonlítás szempontjai a csatolás, a deployolhatóság, a skálázás, az adatkezelés, a konzisztencia, a hibakezelés, valamint a csapat- és üzemeltetési költség. A kommunikációs rész a szinkron és aszinkron együttműködéstől a távoli hívások hibakezelésén, az API-stílusokon (REST, RPC és gRPC, GraphQL) és az üzenetsorokon át a pollingig, a long pollingig, az SSE-ig és a WebRTC-ig, végül a WebSocketig vezet. A tananyag elméleti jellegű, futtatandó kódot nem tartalmaz.
Architektúra: nézetek és kompromisszumok
Az első fejezet a közös szókincset adja meg, amelyre a további fejezetek épülnek. Megkülönbözteti a kódszerkezetet, a futási szerkezetet és a telepítési szerkezetet, megnevezi azokat a minőségi jellemzőket, amelyek között minden architektúra kompromisszumot köt, és bemutatja, hogyan lehet határokat keresni egy rendszerben. A fejezet végén az architektúraábrák olvasása és a döntések rögzítése következik.
Egy telepítési egységben: a monolit és belső szerkezetei
Ez a fejezet azokat az architektúrákat veszi sorra, amelyekben a rendszer egyetlen telepítési egységként fut. Először a monolit alapfogalma következik, majd három belső szerkezet: a rétegzett, a hexagonális és a moduláris felépítés, végül a bővítményekre épülő microkernel. A fejezet azt mutatja meg, hogy a „monolit” nem rendezetlenséget jelent, és hogy a belső határ erőssége a hálózat nélkül is tervezhető.
Szolgáltatásokra bontott architektúrák
Ez a fejezet azokat a stílusokat hasonlítja össze, amelyekben a rendszer több, külön futó egységből áll. A SOA, a service-based és a mikroszerviz egyre finomabb felbontást jelent, a serverless pedig futtatási modell. A fejezet kiemelten foglalkozik a „mikroszerviz = jobb” tévhittel és az elosztott monolittal, a végén pedig a választás szempontjaival és a fokozatos átalakítással.
Eseményvezérelt architektúrák, CQRS és event sourcing
Az „eseményvezérelt” szó négy különböző dolgot jelölhet, ezért a fejezet először szétválasztja őket. Ezután részletesen megnézi az event sourcinget és a CQRS-t, amelyek gyakran együtt szerepelnek, mégsem azonosak. A fejezet végén a kompromisszumok következnek: követhetőség, sémaváltozás, végső konzisztencia és az, mikor nem érdemes eseményvezérelt szerkezetet választani.
Adatok és konzisztencia elosztott rendszerben
Amint a rendszer önálló adatgazdákra bomlik, a több részt érintő művelet már nem fér egyetlen adatbázis-tranzakcióba. A fejezet az adatgazdaságtól és a konzisztenciamodellektől indul, majd három megoldást mutat: a sagát, az outbox–inbox párt és a kétfázisú commitot. A cél nem a minták receptszerű ismertetése, hanem annak megértése, hogy melyik mit garantál, és mit nem.
Kommunikációs alapok: szinkron és aszinkron
Amint a rendszer részei külön folyamatban futnak, a helyi hívásból hálózati hívás lesz, és új időbeli és hibahelyzetek jelennek meg. A fejezet a távoli hívás természetétől indul, megkülönbözteti a szinkron és az aszinkron együttműködést, majd a késleltetés, a szerződés és a hibatűrés alapvető eszközeit tárgyalja: az időkeretet, az ismétlést, az idempotenciát, a megszakítót és a szolgáltatások közti biztonságot. A következő fejezetek konkrét kommunikációs módszerei ezekre az alapokra épülnek.
Szinkron API-k és belépési pontok
A fejezet a kérés–válasz alapú szolgáltatásközi interfészek fő stílusait hasonlítja össze: a REST-szemléletű HTTP API-t, az RPC-t és a gRPC-t, valamint a GraphQL-t. Ezután azt vizsgálja, hogyan jut el a kérés a megfelelő szolgáltatáshoz: gateway, reverse proxy, BFF, szolgáltatásfelderítés, terheléselosztás és service mesh. A stílusok ugyanazon szempontok mentén kerülnek összevetésre, hogy a választás indokolható legyen.
Aszinkron üzenetküldés és webhook
Az üzenetközvetítő időben és rendelkezésre állásban elválaszthatja a küldőt a fogadótól. A fejezet a sor, a publish–subscribe és a tartós napló eltérő modelljét hasonlítja össze, majd a nyugták jelentését és a kézbesítési garanciákat, a sorrendet, az ismétlést és a hibás üzenetek kezelését, végül a lassú fogyasztó visszahatását tárgyalja. A webhook a szerver–szerver aszinkron értesítés HTTP-alapú változata, ezért e fejezet zárja.
Frissítés a szerver felől: polling, long polling, SSE és WebRTC
A HTTP kérés–válasz alapú, a szerver magától nem szólhat a kliensnek. A fejezet azokat a módszereket veszi sorra, amelyekkel az adat mégis eljut a klienshez: az ismételt lekérdezéstől (polling) a nyitva tartott kérésen (long polling) és a szerveroldali eseményfolyamon (SSE) át a közvetlen peerkapcsolatig (WebRTC). Minden módszernél ugyanazokat a szempontokat veszi sorra, hogy a tartós, kétirányú WebSocket (10. fejezet) előtt látszódjon, mit old meg és mit nem.
WebSocket
A WebSocket tartós, kétirányú üzenetkapcsolatot ad a kliens és a szerver között, ezért a kommunikációs módszerek sorának végén áll. A fejezet a protokoll működésével kezdődik, majd megmutatja, mit kell az alkalmazásnak magának megterveznie: az üzenetek jelentését, az újracsatlakozást és az állapot visszaszinkronizálását, a skálázást és a lassú kliensek kezelését, végül a biztonságot és a hibakeresést. Az utolsó lecke az eddig megismert módszereket egy táblázatban veti össze, és megmutatja, hogyan helyezkedik el köztük a Socket.IO.
Programozás 5.
A tárgy a szoftverarchitektúra és a rendszerek közötti kommunikáció alapjait mutatja be. Két kérdésre keres választ: hogyan szerveződhet egy alkalmazás egyetlen telepítési egységbe vagy több önálló szolgáltatásba, és hogyan kommunikálhatnak ezek a részek egymással és a klienssel.
Az architektúrák közül a monolit, a moduláris monolit és a mikroszerviz kap külön hangsúlyt; a többi stílus (rétegzett, hexagonális, microkernel, SOA, service-based, serverless, eseményvezérelt) az összevetéshez kapcsolódik. Az összehasonlítás szempontjai a csatolás, a deployolhatóság, a skálázás, az adatkezelés, a konzisztencia, a hibakezelés, valamint a csapat- és üzemeltetési költség. A kommunikációs rész a szinkron és aszinkron együttműködéstől a távoli hívások hibakezelésén, az API-stílusokon (REST, RPC és gRPC, GraphQL) és az üzenetsorokon át a pollingig, a long pollingig, az SSE-ig és a WebRTC-ig, végül a WebSocketig vezet. A tananyag elméleti jellegű, futtatandó kódot nem tartalmaz.
Architektúra: nézetek és kompromisszumok
Az első fejezet a közös szókincset adja meg, amelyre a további fejezetek épülnek. Megkülönbözteti a kódszerkezetet, a futási szerkezetet és a telepítési szerkezetet, megnevezi azokat a minőségi jellemzőket, amelyek között minden architektúra kompromisszumot köt, és bemutatja, hogyan lehet határokat keresni egy rendszerben. A fejezet végén az architektúraábrák olvasása és a döntések rögzítése következik.
Egy telepítési egységben: a monolit és belső szerkezetei
Ez a fejezet azokat az architektúrákat veszi sorra, amelyekben a rendszer egyetlen telepítési egységként fut. Először a monolit alapfogalma következik, majd három belső szerkezet: a rétegzett, a hexagonális és a moduláris felépítés, végül a bővítményekre épülő microkernel. A fejezet azt mutatja meg, hogy a „monolit” nem rendezetlenséget jelent, és hogy a belső határ erőssége a hálózat nélkül is tervezhető.
Szolgáltatásokra bontott architektúrák
Ez a fejezet azokat a stílusokat hasonlítja össze, amelyekben a rendszer több, külön futó egységből áll. A SOA, a service-based és a mikroszerviz egyre finomabb felbontást jelent, a serverless pedig futtatási modell. A fejezet kiemelten foglalkozik a „mikroszerviz = jobb” tévhittel és az elosztott monolittal, a végén pedig a választás szempontjaival és a fokozatos átalakítással.
Eseményvezérelt architektúrák, CQRS és event sourcing
Az „eseményvezérelt” szó négy különböző dolgot jelölhet, ezért a fejezet először szétválasztja őket. Ezután részletesen megnézi az event sourcinget és a CQRS-t, amelyek gyakran együtt szerepelnek, mégsem azonosak. A fejezet végén a kompromisszumok következnek: követhetőség, sémaváltozás, végső konzisztencia és az, mikor nem érdemes eseményvezérelt szerkezetet választani.
Adatok és konzisztencia elosztott rendszerben
Amint a rendszer önálló adatgazdákra bomlik, a több részt érintő művelet már nem fér egyetlen adatbázis-tranzakcióba. A fejezet az adatgazdaságtól és a konzisztenciamodellektől indul, majd három megoldást mutat: a sagát, az outbox–inbox párt és a kétfázisú commitot. A cél nem a minták receptszerű ismertetése, hanem annak megértése, hogy melyik mit garantál, és mit nem.
Kommunikációs alapok: szinkron és aszinkron
Amint a rendszer részei külön folyamatban futnak, a helyi hívásból hálózati hívás lesz, és új időbeli és hibahelyzetek jelennek meg. A fejezet a távoli hívás természetétől indul, megkülönbözteti a szinkron és az aszinkron együttműködést, majd a késleltetés, a szerződés és a hibatűrés alapvető eszközeit tárgyalja: az időkeretet, az ismétlést, az idempotenciát, a megszakítót és a szolgáltatások közti biztonságot. A következő fejezetek konkrét kommunikációs módszerei ezekre az alapokra épülnek.
Szinkron API-k és belépési pontok
A fejezet a kérés–válasz alapú szolgáltatásközi interfészek fő stílusait hasonlítja össze: a REST-szemléletű HTTP API-t, az RPC-t és a gRPC-t, valamint a GraphQL-t. Ezután azt vizsgálja, hogyan jut el a kérés a megfelelő szolgáltatáshoz: gateway, reverse proxy, BFF, szolgáltatásfelderítés, terheléselosztás és service mesh. A stílusok ugyanazon szempontok mentén kerülnek összevetésre, hogy a választás indokolható legyen.
Aszinkron üzenetküldés és webhook
Az üzenetközvetítő időben és rendelkezésre állásban elválaszthatja a küldőt a fogadótól. A fejezet a sor, a publish–subscribe és a tartós napló eltérő modelljét hasonlítja össze, majd a nyugták jelentését és a kézbesítési garanciákat, a sorrendet, az ismétlést és a hibás üzenetek kezelését, végül a lassú fogyasztó visszahatását tárgyalja. A webhook a szerver–szerver aszinkron értesítés HTTP-alapú változata, ezért e fejezet zárja.
Frissítés a szerver felől: polling, long polling, SSE és WebRTC
A HTTP kérés–válasz alapú, a szerver magától nem szólhat a kliensnek. A fejezet azokat a módszereket veszi sorra, amelyekkel az adat mégis eljut a klienshez: az ismételt lekérdezéstől (polling) a nyitva tartott kérésen (long polling) és a szerveroldali eseményfolyamon (SSE) át a közvetlen peerkapcsolatig (WebRTC). Minden módszernél ugyanazokat a szempontokat veszi sorra, hogy a tartós, kétirányú WebSocket (10. fejezet) előtt látszódjon, mit old meg és mit nem.
WebSocket
A WebSocket tartós, kétirányú üzenetkapcsolatot ad a kliens és a szerver között, ezért a kommunikációs módszerek sorának végén áll. A fejezet a protokoll működésével kezdődik, majd megmutatja, mit kell az alkalmazásnak magának megterveznie: az üzenetek jelentését, az újracsatlakozást és az állapot visszaszinkronizálását, a skálázást és a lassú kliensek kezelését, végül a biztonságot és a hibakeresést. Az utolsó lecke az eddig megismert módszereket egy táblázatban veti össze, és megmutatja, hogyan helyezkedik el köztük a Socket.IO.