> Nem nagyon látom hasznát ennek...
Próbálok egy példát írni.
Van egy szelepvezérlőd és hőmérséklet mérő szenzor, valamint egy hőmérséklet szabályozó alapján szeretnéd vezérelni.
Hová tegyük a vezérlő programocskát?
A megoldásodnál gondolom a szelepvezérlőhöz kerülne, az kérdezné le a hőmérséklet mérő szenzort és a hőmérséklet szabályozót, majd ezen értékek alapján nyitna vagy zárna (vagy nem változtat az állapotán).
Kevés eszköz, szépen és egyszerűen meg lehet oldani a megoldásoddal!
Elkezd bonyolódni a helyzet ha újabb szenzorok jönnek. Ha több szenzor alapján akarunk szabályozni, akkor minden esetben amikor új szenzor kerül a rendszerbe, akkor:
- a szelepvezérlőt erről tájékoztatni kell (pl. a programját módosítani),
- kezelni kell azt az estet, ha egy vagy több szenzor egy ideig nem válaszol,
- ha egy szenzor többször sem válaszol, akkor ezt valahogy tudatni kellene a felhasználóval,
- ha egy szenzor többször sem válaszol, akkor egy idő után már nem is szabad kérdezni (circuit breaker),
- a szenzorok lekérését lehetőleg párhuzamosan kell megoldani.
Tehát itt a szenzor vezérlő programja már elkezd bonyolódni.
Újabb problémák merülnek fel, ha több szelepvezérlő is van. Ilyenkor mindegyik szelepvezérlőben ott lesz a kis programocska. Mindegyik lekéri a szenzorok értékeit, ezzel az a probléma, hogy a szenzor nem tud úgy működni, hogy X másodpercenként mér egyet, majd mély álomba vonul. Neki minden esetben, ha kérdezik, akkor fel kell ébredjen és válaszolnia kell. További probléma lehet, ha a szelepvezérlőknek együtt kell működniük, pl. ha >2 fok az eltérés, akkor 3-nak kell nyitni, ha >1, akkor kettőnek, ha >0, akkor csak egynek. Ennek az algoritmusát és szinkronizációját megint elég bonyolult lehet megoldani.
Message brokeres megoldásnál a szenzoroknak annyi feladatuk van, hogy X időközönként mérnek, majd publikálják az eredményt, majd mély alvásba vonulhatnak. A hőmérséklet szabályozó esetén, ha változik az érték, akkor egyből publikál, ha nem változik, akkor X időközönként, hasonlóan, mint a szenzorok.
A szelepvezérlőknek annyi a feladatuk, hogy ha kapnak egy nyitás parancsot, akkor nyitnak, ha zárást, akkor zárnak, illetve esetlegesen ezek is küldhetnek státusz jelentést magukról.
Tehát az eszközökön nagyon buta kis programocskák futnának, amiket nem nagyon kellene sohasem megváltoztatni.
Lenne egy kis programocska, ami Y időközönként összegyűjti a szenzorok és hőmérséklet szabályozó értékeit, majd azok alapján nyitás és/vagy zárás parancsokat küldene a szelepvezérlőknek.
Külön egy egyszerű programocska intézheti a monitorozást, egy másik a hibakezelést, egy harmadik lehet Dashboard, egy negyedik vezérlő panel, ...
Ezekben az a jó, hogy nagyon egyszerű kis programocskák, egy képernyőre kiférnek, egyetlen helyen tudják intézni az összes service, összes eszköz hibáit, státuszait.
Egy másik előny, hogy az adatok folyamatosan gyűlnek és amikor akciózni kell, akkor azonnal tud reagálni, nem kell várni semmire.
> Tehát azzal egyszerűsítem és növelem a rendszer rendelkezésre állását, hogy beleteszek egy vagy több SPOF eszközt?
A message brokert rakhatod cluster-be is, két három RPi-ra, akkor nincs SPOF. Az egyszerűsítés a kis programocskáknál jelentkezik. Mindegyik csak egy problémát old meg egyszerűen és röviden, valamint az üzleti logikák egy helyen vannak megvalósítva.
Nem akarok senkit sem rábeszélni semmire, csak arra akarom felhívni a figyelmet, hogy van egy másik út is. Természetesen, mint minden eszköznek, ennek is vannak előnyei, hátrányai. Sajnos ez sem silver bullet! :-)