Microservices

Question 1

Történeti áttekintés

Answer 1

Enterprise integration architektúra nagyvállalatoknál. Itt legacy kód van, nem szeretnek hozzányúlni, mert nehéz dolgozni vele. Ennek ellenére fontos adatok vannak ezekben. Ezekhez a nagy kódokhoz egy új csapat nehezen tud hozzáadni új appot, vagy egyáltalán fenntartani a meglévőt.

Question 2

Monolitikus architektúra

Answer 2

Egy csapat agilis módszerrel fejleszt egy alkalmazást egy adatbázissal egészen addig, amíg nem kell még egy meg még egy csapat… Mivel egy adatbázis és egy alkalmazás van, ezért mindenkinek ugyanazt a nyelvet kell használnia. Aki utoljára csatlakozik, annak az összes technológiát ismernie kell. A telepítése release train-en keresztül megy, szinkronban kell mozogni: fejlesztők fejlesztenek, majd tesztelők tesztelnek, közben a fejlesztők az újat fejlesztik, majd végül - ha vége a tesztelési fázisnak - a rendszergazdák kiadják. Ez az architektúra nehezen skálázható és üzemeltethető. Minél nagyobb, annál nagyobb szerverek kellenek. Az alkalmazás nehezen reprodukálható. Előnye, hogy könnyű elkezdeni.

Question 3

Monolitikus vs Microservices

Answer 3

A twitter, az eBay és az Amazon is monolitikusan indult, a nyomai még mindig megvannak ennek az architektúrának, azonban egy idő után problémák voltak a skálázhatósággal, komplexitással és agilitással, ezért lépniük kellett. Microservicekre tértek át, azonban ez egy hosszú folyamat volt. A Microservice-k követik a single responsibility elvet, adott műveletnek, osztálynak, komponensek egy oka kell, hogy legyen. Egy módosítás a rendszerben egy csapathoz kell tartozzon. Ha egy változtatáshoz túl sok mindent kell módosítani, akkor annak kicsi a fókusza. Egy deploymentben kell összpontosuljon egy service.

Question 4

Microservice csapat, nagyság

Answer 4

Microserviceknél egy csapatnak akkorának kell lenni, hogy kb 2 pizzával jól lakjanak (3-12 ember), ez agilis módszertanhoz jól illeszkedő csapat méret. Egy csapat több Microservicért is felelhet. Egy Microservice nagysága akkora, hogy egy csapat 2 hét alatt újra kell tudja írja, akár más technológiával. A Microservicek hálózaton keresztül kommunikálnak egymással, így könnyen szétválaszthatóak lesznek.

Question 5

Microservices skálázhatóság

Answer 5

Míg a monolitikus rendszerek csak vertikálisan tudnak skálázódni (ami meglehetősen korlátozott a hardver erőforrások miatt), addig a Microservicek képesek horizontálisan is skálázódni. A vertikálisnak fizikális kötöttségei vannak. A horizontális azt jelenti, hogy több gépen fut, azokon szétosztjuk a Microserviceket. Itt emiatt ritkán kell a vertikális skálázódás, de lehetséges. A clouddal a skálázhatóság automatizálhatóvá vált.

Question 6

Microservices polyglotizmus

Answer 6

A Microserviceknél jelen van a polyglotizmus, ami a többnyelvűség: egy-egy Microservice íródhat különböző nyelveken, míg monolitikusnál ki kell választani egy nyelvet és ahhoz kell tartani magunkat végig. Ennek a lecserélése nagyon költséges folyamat. Microservice-nél csak a kommunikációs feltételeket kell betartani.

Question 7

Microservices adattárolás

Answer 7

Microserviceknél alkalmazhatunk NoSQL-t, amivel sokkal szélesebb spektrumú adattárolás bevezetésére van lehetőség. Migrálás könnyebbé válik.

Question 8

Microservices telepítés

Answer 8

A telepítés a monolitikus nézetnél egyre nehezebb és bonyolultabb a program növekedésével. Az egészet kell mindig, kis változtatás esetén is. Több csapat is változtatgat, ezért állandó kommunikáció kell köztük. Egyre nagyobb lesz a konfiguráció és az időigény. Egy idő után a történeti tudás lesz a fontos, ki van ott régóta, aki ismeri stb. Microservicenel a servicért felelős csapat önállóan meg kell tudnia oldani, mert csak egy service telepítődik. Kis változtatás hamar végbemegy. Amíg a kommunikáció nem sérül a többi service ezt nem észleli. Telepítés alatt nem szeretnénk, hogy a rendszer leálljon, ez a monolitikusnál sokkal nehezebb feladat.

Question 9

Microservices kommunikáció

Answer 9

Kommunikációs szempontból monolitikusnál komponens vagy direkt hívások vannak, esetleg adatbázison keresztül, ritkán van távoli kommunikáció. Microservicenél a kommunikáció nagyobb fejtörést okoz, mert csak hálózaton keresztül kommunikálnak: ha az egyik átkerül másik infrastruktúrába, akkor is meg kell találniuk egymást. Amíg a kommunikáció nyelv független, addig a polyglotizmus nem sérül. Rest vagy http kommunikációval ez megoldható.

Ismert (Remote Procedure Call) keretrendszerek a gRPC, vagy az Apache THRIFT
● Hatékony, kompakt kommunikáció: GRPC és THRIFT bináris protokollokat használnak, amelyek hatékonyabbak a szöveges HTTP-nél, és kisebb méretű adatcsomagokkal teszik lehetővé a gyorsabb és hatékonyabb hálózati kommunikációt.
● Erősebb Típusosság: Mindkét keretrendszer erős típusosságot biztosít, amely lehetővé teszi a fejlesztők számára a szigorúbb ellenőrzést és könnyebb hibakeresést.

Question 10

Monolitikus vs microservices teljesítmény különbség

Answer 10

Vannak teljesítmény különbségek a kommunikációs módszereknél. Bizonyos réteg alatt használhatunk más protokollt. Async kommunikáció esetén mindig van egy üzenet továbbító közeg (pl. Kafka(topic alapú), vagy RabbitMQ(queue alapú)).
● Hibatűrésben is van különbség a két technológia között.
○ Monolitikusnál könnyen átgyűrűzik a hiba más komponensekbe.
○ Microserviceknél ha egy rendszer leáll, csak a közvetlen környezete észleli. Ha építünk be hibatűrési algoritmust, akkor a közvetlen környezet is védve lesz. Ez egy biztosíték, így nem gyűrűzik tovább a hiba.

A Microservice hátrányai: infrastruktúra béli komplexitás, futtatási környezet sokkal összetettebb, több technológia, könnyű ebben elveszni. Fontos, hogy vannak központi servicek: log, metrikák stb. Minden csapatnak hozzá kell ezekhez férni. Ezeknek gyorsnak kell lenniük. Nagyobb hálózati teljesítmény kell a hálózati kommunikáció miatt. Nem könnyű ezeket a rendszereket fejleszteni.

Question 11

Microservices deisgn patterns

Answer 11

• Kommunikáció
• Közös adatbázis (anti pattern)
• Szinkron kommunikáció
• Aszinkron kommunikáció
• Függőségek kezelése
  
  • Shared library (anti pattern)
  • Technical boundary (anti pattern)
  • Integrációs portok pattern

Question 12

Kommunikáció
(Microservices deisgn patterns)

Answer 12

API az egyik alappillére, megfelelő tulajdonságokkal kell rendelkeznie, hogy egyszerű legyen, könnyen használható legyen, a ráépülő fejlesztés gördülékeny legyen, kevés hibával. API követelmények: kompatibilitás régebbi verziókkal, technológia függetlenség, implementáció teljes elrejtése a kliens felől (pl adatbázis lecserélése ne hasson ki rá, egyszerűség).

Question 13

Közös adatbázis (anti pattern)
(Microservices deisgn patterns)

Answer 13

Általában monolitikus átmigrálásnál szokott lenni. Nem jó, mert nem kompatibilis visszafelé, ehhez régi verziókhoz régi adatbázisok kellenek. Ha valamit adott adatbázisban módosítani akarunk, azt mindenkinek tudnia kell. Nem lesz ettől nyelv független sem. Minden servicenek ezt kell használnia. Nem követhető, mert nem tudjuk melyik táblát melyik service módosította. Sokszor inkonzisztenciát okoz.

Question 14

Szinkron kommunikáció
(Microservices deisgn patterns)

Answer 14

Két service között szinkron metódus hívás (pl rest). Ezeknek a protokolloknak jól definiált interface van a technológiailag függetlennek mondható http miatt, így gyorsan fejleszthető egy vékony kliens. Hátránya, hogy több helyen problémája lehet a szinkron kommunikációval. Nehézkes a hibakezelés, ha a küldő félnél hiba van, ilyenkor timeout implementálás kell: kompenzálni kell a hívó felé, ha a hívott félnél van a hiba, nem tud különbséget tenni. Itt van lehetőség a visszafelé kompatibilitásra, ilyenkor a migráció nehézkés. Ha mindenki átáll az újra, akkor a régit megszüntetjük.

Question 15

Aszinkron kommunikáció
(Microservices deisgn patterns)

Answer 15

Üzenetküldő közeg, bizonyos garanciával vannak továbbítva az üzenetek. A sorrendiség garantált. Mindig van egy 3. fél, aki az üzenetek továbbításáért, tárolásáért, konzisztensen tartásáért felel. Ha a hívott fél nem elérhető, akkor az üzenetek tárolva maradnak. Amint csatlakozik továbbítva lesz felé. Rugalmas, hibatűrő kommunikációs mód. Visszafelé kompatibilitás lehetséges üzenetenként és csatornánként is. Nem érdemes sokáig fenntartani a visszafele kompatibilitást.

Question 16

Függőségek kezelése
(Microservices deisgn patterns)

Answer 16

• Függőségek kezelése:
  
  • Shared library (anti pattern)
    Közös funkciókat közös könyvtárba akarunk kiemelni, ezek száma folyamatosan nő. Jobb esetben szét vannak választva. Nem Microservice kompatibilis. Átláthatatlan, változtatásokat mindegyiken végre kell hajtani. Nem programnyelv független, Egyre komplexebb, nagyobb kódbázis, nem mindig kompatibilis visszafelé, körülményes az implementáció.
  • Technical boundary (anti pattern):
    Serviceket úgy választjuk szét, mintha monolitikus lenne, egymásra épülnek majd. Mindig szinkronba kell lenniük, ha a felső service igényei nőnek, akkor lehet, hogy túl komplex lesz, üzleti logika. Minél jobban nő annál átláthatatlanabb lesz, lassabb teljesítmény, kerülendő.
  • Integrációs portok pattern:
    Szinkron és aszinkron hívások, legrugalmasabbak.

Question 17

Konzisztencia

Answer 17

• CAP tétel: adatbázisokat kategóriákba lehet sorolni:
  
  • Consistency
    
    • Olyan adatbázisok, amelyek inkább késleltetik a választ, minthogy inkonzisztens adatot mutassanak a kliens felé. Általában kisebb teljesítménnyel rendelkeznek és lassabbak.
  • Availability
    
    • Azokat az adatbázisokat tartalmazza, amik nem a konzisztenciát választják, hanem inkább gyorsan és minél nagyobb elérhetőségben szolgáltatják az adatot a kliensnek. Itt gyakran inkonzisztensek az adatok, viszont sokszori elérés után tudják garantálni a konzisztenciát.
  • Partition Tolerance
    
    • Horizontálisan skálázott adatbázisok. Az ilyen adatbázisokra hálózati tagolódás jellemző, és hibatűrőek a hálózati problémákkal szemben.
  • A CAP tétel azt mondja ki, hogy lehetetlen olyan adatbázist létrehozni, ami mindhárom tulajdonsággal rendelkezik. Egyszerre csak kettő teljesülhet.
  • CA
    
    • Ide tartoznak az RDBMS (Relational Database Management System) típusú adatbázisok, azaz a relációs adatbázisok.
  • CP
    
    • MongoDB, Redis stb.
  • AP
    
    • Cassandra, Dynamo stb.
  • Two-phase commit (anti pattern):
    Konzisztensnek maradni próbáló adatbázisok használják. Adatok ugyanúgy legyenek elérhetőek. Minden erőforrás ugyanazt végezze. Hálózati tagozódást nehezen viseli, ezért anti pattern.
    
    • 1. fázis: Preparáció. Koordináta erőforrást lekérdezi, felkészíti a tranzakcióra, ha szólnak, hogy mehet, akkor 2. fázis.
    • 2. fázis: Tranzakció kiadása. Hálózati tagozódás esetén nem minden erőforrás tudja visszavenni a tranzakciókat. Nincs a hibákra felkészítve.
  • Eventual consistency:
    Lehet inkonzisztencia, bizonyos idő után a háttérben megtörténik a szinkronizáció. Hálózati tagozódás lehet.
  • Event sourcing:
    Általában aszinkronnál. Minden üzleti műveletnél esemény küldésé egy csatornára. Erre bármennyien feliratkozhatnak. Ezeket elérhetővé tesszük, idempotens műveletek: ugyanazon eventek többszöri feldolgozása esetén is ugyanarra az eredményre jut. Minden eseményhez egyedi id-t kötünk, fogadó rögzíti, ha látta már.

Question 18

Skálázhatóság

Answer 18

A Microservicek inkább horizontálisan, üzemeltetés kevésbé problémás. Kérdés, hogy mikor és hogyan osszuk el a terhelést, vagyis mi a skálázhatóság logikája. Ezeket load balancerek végzik, ezeknek tudniuk kell mi hol érhető el. Automatikusan kell tudniuk a dolgokat, configgal frissülnie kell, ha valami elindul. Kell tudniuk egy servicet kihagyni.
* HTTP load balancerek:
Érkezik http protokoll, routot meg tudják változtatni, cookie segítségével ugyanabban a serviceben lehet küldeni, ha kell. Akár https-ként is szolgálhat. Kliensről érkezik a kérés, a load balancerek tudják kezelni a titkos kulcsokat. Belső hálózaton http-vel kommunikálnak mert gyorsabb, és ott már biztonságos.
* Service registry pattern:
Minden Microservice elérésének rögzítésére szolgál. Vagy egy másik önálló Microservice valósítja meg. Ez kommunikál a load balancerekkel. Milyen Microserice milyen ip-n, porton érhető el? Segíti az automatizálást.
* API gateway pattern:
Egységes belépési port a többi heterogén service felé. Suffix alapján dönti el, merre menjen tovább (egy újabb absztrakciós réteg). Különböző verziójú API-kat lehet vele kezelni. Adott API-hoz plusz logikát is adhatunk: biztonsági funkciók, monitorozás stb.

Question 19

Deployment

Answer 19

• Blue-green pattern:
  
  • Blue és green klaszterek. Verzió frissítésnél green a régi, blue az új. Hátrány: ha ugyanazt a teljesítményt akarjuk nyújtani, ahhoz kétszer annyi szerver kell. Idő alatt átirányítjuk az új felé a forgalmat. Nem szüntetjük meg a régit rögtön, probléma esetén gyorsan visszaállunk.
• Canary-release pattern:
  
  • Egy servicet cserélünk ki: amíg ezt konfiguráljuk addig az útvonalat kivéve a teljesítményben alacsonyabb igényű. Ha ennél a servicenél minden rendben, akkor szép lassan többit is cseréljük.
• Containerization pattern:
  
  • Alkalmazást belépési port, futtatási környezetet egy egységbe zárjuk. Interfacet containerbe csomagoljuk. Verziózható lesz és másik szerveren letölthető. Az egységes belépési port nagy előny. Processzek egy fejlettebb változata.
  • Biztonságosabb egyik container másikkal nem beszélhet, nem érik el egymást. Docker nagyon népszerű itt.
• Container architektúrák (nem pattern):
  Egységes API, ami ezeknek interfacet ad, hogy azokat futtathassák. Kubernetes: deklaratív módon lehet nekik megmondani, mi kell nekünk. Gyakran van bennük más pattern is.

Question 20

Observability

Answer 20

3 része van: logs, metrics, tracing.
Központiak, komplex infrastruktúra, fontos, hogy egységes interface legyen, egységes módon rendelkezésre kell állniuk, Aggregálják az adatokat. Több servicen átívelő kéréseket is meg tudnak valósítani és hibakeresésnél is fontosak. Rengeteg adat érkezik, ezeket kezelniük kell.
Tracing: TraceID, kérés végig követése, minden loadernek továbbítania kell, vissza lehet követni a hívási útvonalat: kiderül melyik művelet volt gyorsabb/lassabb.

Question 21

Resilience-hibatűrés:

Answer 21

● TimeOut:
Minden szinkron hívásnál van egy timeout period ami után hibás a hívás. Jól kell beállítani, felül kell vizsgálni őket. Hívott fél nem válaszol, akkor error/exception keletkezik. Microserviceknél rövid időre érdemes állítani: pl 1s.
● Circuit breakers:
Ha valamelyik szolgáltatás nem elérhető ezt a patternt érdemes beépíteni. Nem gyűrűzik tovább a hiba tőle, ez egy biztosíték. Egy idő után a tőle függőek újra probálkoznak.
● Health checks:
Adott servicen belül képes-e egy hozzá delegált feladatot elvégezni, vagy sem. Általában egy status kód (pl HTTP 200), de lehet komplexebb logika is. Ha hibás a válasz akkor a forgalom megszűnik ebbe az irányba.
● Defaults & fullbacks:
Megpróbálnak egy nem teljesen pontos, de valami adatot adni (pl cache-ből, vagy default értéket).
● Rate limiting:
Hívóktól mekkora forgalom érkezhet be. Mennyit tudnak ellátni, ne legyen túl sok hívás, bizonyos rate után maradékra egy automatikus hibás választ ad vagy lassít. Így korlátozhatóak a hívások. Néha szükség lehet ennek a service szintjén való implementálására.