A Leaflet blog engine architektúrája

Leaflet? Az mi?

Jogosan merül fel a kérdés, hogy mi egyáltalán a Leaflet? A Leaflet egy Java nyelven, Spring (Boot) keretrendszerben fejlesztett blog engine, mely a korábbi PHP nyelven és CakePHP keretrendszerben fejlesztett engine-emet hivatott leváltani. Igyekeztem amennyire csak lehetett követni a keretrendszer, komponensek, és persze a nyelv friss verzióit használni, azok újdonságait kihasználni, így jelenlegi állapotban a rendszer OpenJDK 11-en fordul és fut, több-kevesebb sikerrel a Java 9-ben debütált JigSaw modulrendszert is használja, illetve a Spring Framework 5.1, valamint Spring Boot 2.1 verzióin alapul. Mókás "történelmi" tény, hogy a fejlesztés kezdetén (majdnem 3 évvel ezelőtt - nos igen, ahogy időm engedte, úgy haladtam vele...) még - nyilvánvalóan - Java 8-on és Spring 4-en futott a rendszer, WAR csomagolással, standalone Tomcat alatt. A Leaflet életében aztán nagy váltásnak számított a Boot-ra való átállás, azzal számos új lehetőség is megnyílt.

Tehát csak egy blog engine?

Lényegében. És igazából mégsem. A Leaflet koncepciója egy jóbarátommal való társalgás során született meg, ahol kicsit talán megalomán ötletek fogalmazódtak meg, ám a koncepció mégis e gondolatok köré épült és a jelenlegi elképzelések alapján a Leaflet, és az azt támogató microservice/application stack a cél felé vezető útnak csupán az első állomása. Az új, modern felépítésű engine lehetőségek százait nyitotta meg, számtalan ötlet vár még megvalósításra, köztük az a bizonyos cél, amiről még később ejtek pár szót.

A koncepció

Egy software sikerességét a koncepciója határozza meg. A Leaflet esetében ez talán hat kifejezéssel foglalható össze: olcsón fenntartható, hibatűrő, egyszerű, rugalmas, megbízható és biztonságos. Kicsit talán utópisztikusan hangozhat és valószínűleg sajnos soha nem fogja felvenni a versenyt egy olyan megoldással amit több százan fejlesztenek hosszú évekig, de a fejlesztés során ezen szempontok elsődleges fontosságúnak számítottak. Legfőképp - és ez az, amiben a Leaflet valami újat akart mutatni -, az olcsón fenntartható, mégis hibatűrő architektúra. Az elképzelés az volt, hogy a rendszer képes legyen a tartalom kiszolgálására akár a teljes backend rendszer kiesése esetén is. Persze, microservice architektúrában a komponensek replikáltan futnak (tehát mindenből legalább kettő, de inkább több instance, lehetőleg külön fizikai gépeken), ennek fenntartása azonban drága, továbbá olyan problémák megoldására is szükség lehet (főleg az adatbázis tekintetében), melyek egy kisebb blog üzemeltetésénél fölösleges költségeket indukálhatnak. A Leaflet ezzel némiképp szembemenve, a kiesések, telepítések idejére egy külön komponensnek adja át a forgalmat, mely ugyan nem képes kezelni komplex felhasználói interakciókat (úgy mint regisztráció, kommentezés), azonban adatbázis nélkül, in-memory tükröt fenntartva a tárolt bejegyzésekről képes áthidalni azt az időt, amíg a backend nem képes a kérések kiszolgálására. A komponens a Content Backup Failover System (röviden CBFS) nevet kapta - és természetesen már egy sikeres éles tesztfázison is túl van. A rendszer számára így jelenleg akár egyetlen VPS instance is elégséges.

Megbízhatóság és biztonság szempontjából több fejlesztés is került a rendszerbe. A stack működéséről Graphite gyűjt metrikákat, így könnyen észlelhetőek a terhelt időszakok, láthatóvá válnak a problémás, sokáig tartó műveletek. A microservice-ek közti REST alapú kommunikációt a Netflix által fejlesztett Hystrix library védi, amely alapvetően a komponensek közti forgalmat szabályozza, megakadályozva ezzel a server alkalmazás túlterhelését. A felhasználói munkafolyamatok rövid lejáratú JWT tokenekhez kötöttek, a kiosztott tokeneket pedig a rendszer követi megakadályozandó a visszaéléseket. Az authentikáció nélkül is elérhető felhasználói műveletek (úgy mint a regisztráció, vagy a jelszó helyreállítás) Google ReCaptcha védelemmel vannak ellátva, mely természetesen a backend oldalon is újraellenőrzésre kerül.

Az egyszerűséget tekintve törekedtünk mind a telepítés és üzemeltetés, mind a management szempontjából minimalizálni a szükséges erőbefektetést. Előbbi tekintetében talán a legtöbbet a Spring Boot-ra való átállás segített, így minimális erőbefektetéssel viszonylag gyorsan lehet üzembe helyezni a rendszert. Persze, van még hova fejlődni, így a jövőbeli tervek fontos alapkövét képzi a rendszer "Dockeresítése", mely lehetőséget nyitna többek között a rendszer gyors költöztetésére, illetve maga az üzembe helyezés is legfeljebb néhány percet igényelne. Management szempontjából minden érdem jóbarátomat illeti, az általa tervezett és fejlesztett minimalista-material designra építő adminisztrációs felületnek hála a rendszer karbantartása, tartalmak létrehozása az eddigi legkényelmesebb amivel valaha találkoztam. Külön köszönet az általa fejlesztett Calmdown markdown editor integrálásáért - aki hasonló szerkesztő implementálására készül, mindenképp ajánlom megtekintését (igen ez nyílt reklám volt :) ).

Az architektúra

A Leaflet stack jelenleg 4 microservice-t, 2 különböző adatbázis motort, és 2 front-end alkalmazást jelent, illetve készül még egy Android alatt futtatható kliens is. A kommunikációs vonalakat is figyelembe véve a stack a képen látható módon épül fel (céljuk alább részletesen):

A MySQL adatbázis instance tárolja a felhasználókat, bejegyzéseket, kommenteket - alapvetően minden tartalmat, relációs adatbázismotor lévén normalizált, megbízható, konzisztens formában. Ezzel szemben a MongoDB instance jelenleg két célt szolgál: egyrészt ide futnak be a TLP nevű log feldolgozó alkalmazás által kezelésbe vett log üzenetek, másrészt a TMS fordítás-kezelőben létrehozott nyelvi csomagok is itt vannak tárolva.

A service layerben a backend és az azt támogató microservice-ek helyezkednek el. A Tiny Log Processor (TLP) egy kisméretű, a fentebb már említett MongoDB NoSQL adatbázis motort használó egyszerű log feldolgozó alkalmazás. A logok egy egyedi Logback appender implementáció segítségével jutnak el ide, mely async módon küldi el az alkalmazások logjait, az eredeti LoggerEvent objektumot szerializálva. A TLP végül a teljes log üzenetet letárolja dokumentumként. A TLP ezután egy REST endpointot biztosít a logokban való szűrésre. A Translation Management Service (TMS) feladatai a nyelvi csomagok feldolgozása, tárolása, illetve azok rendelkezésre bocsátása az azokat használó alkalmazások számára. A Content Backup Failover System (CBFS) adja a failover funkcionalitás lelkét. Működése két részre bontható. Az első a tartalom "biztonsági mentését" végző ütemezett job. Ez minden hajnalban végigpásztázza a publikus útvonalakat, figyelembe véve a lapozást is, majd a backend alkalmazás válaszában levő JSON payload-ot módosítás nélkül menti le egy embedded in-memory H2 adatbázis instance-ba. A kulcsok minden esetben az adott tartalom elérését szolgáló útvonalak. Ennek segítségével, működésének második lépcsője a tartalom alkalmi kiszolgálása. Egyszerűen ez úgy történik, hogy az alkalmazásokat a külvilággal összekapcsoló Apache képes eldönteni - failover proxy konfiguráció segítségével -, hogy a backend vagy a CBFS kapja a kérést. Nyilván utóbbi abban az esetben aktiválódik csak, ha az Apache képtelen elérni a backendet, mert az például le van állítva. Ilyen esetekben átmenetileg a forgalom a CBFS felé van továbbküldve, melynek a backend endpointjaival megegyező endpointjai képesek ugyanazt a választ visszaadni, mint amit a backend adna. Természetesen a CBFS nem kommunikál visszafele a backenddel, így ahogy azt már említettem nem képes az összetett felhasználói műveletek kiszolgálására - azonban a backend kiesése esetén a forgalom javát továbbra is biztosítani tudja.

A front-end layerben levő alkalmazások a Leaflet Content Front Application (LCFA), mely a látogatói forgalmat szolgálja ki (éppen ezt az alkalmazást használod Te is), illetve az adminisztrációs feladatokat ellátó Leaflet Management System (LMS). Ezek fölött helyezkedik el egy Apache instance, mely az alkalmazások külső és belső kommunikációját vezérli, illetve minden egyéb támogató alkalmazás, úgy mint a Graphite (metrika feldolgozás), Grafana (metrika vizualizálás) és a Jenkins (continuous integration).

A Leaflet jövője

Számtalan továbbfejlesztési ötlet lóg a levegőben, melyek jó része még a közeljövőben be fog kerülni a rendszerbe, de vannak egészen hosszútávú ötletek is. Előbbiek közé tartozik a blogon tevékenykedő írók bio-szerű profilja, integráció néhány közösségi platformmal, hírlevél feliratkozás, illetve kisebb (inkább nagyobb) ráncfelvarrás a látogatói felületen. Távolabbi tervek között szerepel a TLP bővítése egyedi query language feldolgozóval, illetve a Leaflet stack felbontása több, kisebb, specifikus microservice-re (például külön komponens a JWT tokenek kezelésre, külön a látogatói front kiszolgálásásra, ami levenné egyúttal a terhet a MySQL adatbázisról, stb.), ezutóbbival pedig lehetőség nyílna akár a Leaflet platform kiszolgálóvá alakítására is - de ez még messze van :).

Szóval lehetőségek bőven akadnak, igyekszem őket meg is valósítani, közben pedig ellátni Titeket, visszatérő és új olvasóimat minőségi szakmai tartalommal. Ha kérdésetek, észrevételetek akad, netán észrevesztek egy bugot, bátran írjatok kommentben, vagy a láblécben található email címen.

Köszönöm megtisztelő figyelmeteket!

A Leaflet stack repositoryjai

Komment írásához jelentkezz be
Bejelentkezés