Felszabadulva a monolitból

div id = “184e66f46f”>

A monolit szabálykód majmok

A Conio-nál minden azzal kezdődött, amit általában „monolitnak” hívnak. Vagyis egyetlen kódbázis, amely tartalmazza a teljes alkalmazás mindent: annak frontend komponenseit, backend komponenseit, API szolgáltatásait, háttérfeladatait; pokol, még szkripteket is elárul. És az elején nagyon jól működött. Csak néhány szoftvermérnök, akik a kódbázis külön területein dolgoznak (így a kódváltási ütközéseknek nagyon kevés az esélye), könnyen telepíthetők. Teljes mértékben összpontosítson az alkalmazásfunkciók megírására, anélkül, hogy sok minden miatt aggódna. Hogyan közelítettük meg a telepítést? Mivel csak néhány béta ügyfél ismeri az örökösödő előrehaladást, nem volt igazi kérdés a szolgáltatások egy időre történő leállítása, a teljes kódbázis bevezetése (függetlenül attól, hogy az általános változások milyen kicsiek vagy nagyok voltak, és hogy tartalmazzák-e az adatbázis-migrációkat), majd újból előhozza a szolgáltatásokat.

Határozottan kielégítő volt látni, hogy egy termék az alapoktól kezdve formálódik, és elismerést kap a végfelhasználóktól. Azt azonban nagyon jól tudtuk, hogy ez a megközelítés nem felel meg egy modern Fintech vállalatnak.

És akkor mi van?

A legtöbb szoftveralkalmazásban az ügyfelek meglehetősen toleránsak. Igen, a Whatsapp leállhat, és néhány órás üzemszünet következhet be: ez mindenképpen kellemetlenség, de nem észlelt probléma. Ugyanez vonatkozik a Pokemon Go-ra vagy a kedvenc játékalkalmazására. A azonban nem ez a helyzet, ha pénzről van szó : a hangulat megváltozik, ha nem tud bejelentkezni a bankszámlájára, vagy nem tud kereskedelmi műveleteket végeznek. Ez még ennél is rosszabb a kriptovaluta alkalmazások esetében: a legtöbben emlékeznek a múlt hírhedt baklövéseire, és amikor csak rövid ideig sem képesek hozzáférni a kriptopénz alapjaikhoz, spekulációk merülnek fel. Jogos. Ez a te pénzed, és kevés vagy semmilyen problémád nem lehet, amikor használni akarod.

A fenti Monolith nem alkalmas ilyen forgatókönyvre: a termelés kódbázisának bármilyen módosítása teljes telepítést igényel, a kapcsolódó leállásokkal. Minden nap azon dolgozunk, hogy javítsuk szolgáltatásainkat a hibák kijavításával, a felületünk még barátságosabbá tételével, a régi funkcionalitások eltávolításával és azokkal, amelyek jobban használhatók. Ezeket a frissítéseket gyakran naponta adjuk ki, hogy ügyfeleink azonnali hasznot húzhassanak, és arra törekszünk, hogy ne befolyásolják az ügyfél tapasztalatait. Vagyis bármilyen formát készítünk a színfalak mögött, láthatatlannak kell lennie a külvilág számára (legalábbis a legtöbbször). Ezért eltávolodtunk a Monolith-tól, és úgy döntöttünk, hogy a „Microservices architektúra” nevet viseljük.

Evolution a Microservices

A masszív, szorosan összeragasztott egyetlen kódbázis most kisebb részekre bomlik, amelyek mindegyike egy adott szolgáltatást jelent. Amikor végrehajtják, a szolgáltatások szinkron módon kommunikálnak egymással a szokásos HTTP protokollon keresztül és aszinkron módon várakozási sorokon keresztül (például a RabbitMQ és az Apache Kafka kezeli).

Interakciók a mikroszolgáltatások architektúrájában

Elég kihívást jelent a monolit kisebb részekre bontása, de nagyon megéri az erőfeszítés. Katonai szempontból nagyon hasonlít ahhoz, amit Julius Caesar tett Gallia nagy területének állandó uralkodása érdekében: „ oszd meg és hódíts t.”

1) A termék folyamatosan telepíthető. A kódfrissítés most már csak egy mikroszolgáltatásra vonatkozik: a legtöbb esetben azonnal telepíthető a termelésbe, és kiadható az ügyfélre gyakorolt ​​hatás nélkül.

2) A kód könnyebben kezelhető. Vállalati szervezet szempontjából a dolgok megváltoznak, amikor egy 2 szoftvermérnökből álló csapat 10 szoftvermérnökből áll. Eredményesebb és kevesebb kódütközéssel jár, amikor minden csapat tagja felelős a saját mikroszolgáltatásáért.

3) A kódot könnyebb fenntartani. A Microservices architektúra természeténél fogva megköveteli az interfész meghatározását a külvilággal való kommunikációhoz (legyen az frontend alkalmazás vagy más háttérszolgáltatás), és minden más szempontból teljesen el van szigetelve. Ez lehetővé teszi az alkalmazás egyes összetevőinek áttekintését, újratervezését vagy akár teljes átírását a semmiből (akár más nyelveken is, ha ez kényelmes), anélkül, hogy ez befolyásolná a többit.

4) A teljesítmény javítható. Minden egyes mikroszolgáltatás használhatja a legmegfelelőbb nyelvet. A nehéz kriptográfiai számítási komponenseket például optimalizálhatjuk a C-ben, míg az API-szolgáltatásokat a Pythonban és a hosszú távú feladatokat a Go-ban.

5) Javított kódszigetelés és biztonság. Mindegyik mikroszolgáltatás futtatható a saját Docker-tárolójában, ezáltal kiváltságok elkülönítését, hálózati és adatszegregációt biztosítva, és a növekedési fázis szempontjából kiemelkedően fontos, hatalmas skálázhatósági potenciált.

Akkor a Microservices a válasz?

Természetesen nem létezik ingyenes ebéd. A Microservices architektúrának saját nehéz kihívásai is vannak:

1) Műveleti összetettség. A DevOps mérnökeire mindenképpen szükség van az új telepítési folyamat bonyolultabbá tételéhez.

2) A hardver felfújódik. A mikroszolgáltatásokat gyakran Docker konténerekben futtatják; amint szaporodik a mikroszolgáltatások száma, egyre nagyobb kihívást jelent a teljes alkalmazás futtatása ugyanazon a hardveren, mint korábban.

3) Interkommunikációs rezsiköltség: az egyes kéréseknek szükségük lehet egy vagy több különböző felhasználóval való interakcióra. mikroszolgáltatások a hálózaton keresztül. Ez megnövelt késleltetést okozhat, és átmeneti hibáknak lehet kitéve. A rugalmas szolgáltatások megvalósítása, valamint az egész rendszer méretezhetőségének javítása érdekében az interakciókat aszinkron üzenetküldésre kell áthelyezni (pl. Apache Kafka és / vagy RabbitMQ használatával)

4) Végső következetesség. Ez valószínűleg a legnehezebb kihívás a Microservices architektúrának. Egyetlen mikroszolgáltatás esetén RDBMS tranzakciók hozhatók létre annak határain belül. . Sajnos, az elosztott architektúrákban azonban gyakran felmerül az a kérdés, hogy több tranzakcióval kell foglalkozni, amelyek nem ugyanazon határokon belül vannak. Ennek eredményeként a rendszer illegális és helyrehozhatatlan állapotba kerülhet. Az ilyen problémák enyhítése érdekében a Conio különböző stratégiákat alkalmaz:

  1. A tartományvezérelt tervezés gyakorlatát követve bontsa szét a magasabb szintű tartományokat aldomainekké, és szűkítse őket egyedileg korlátozott összefüggésekbe ; minden egyes bekötött kontextus mikroszolgáltatásként valósul meg, ahol tranzakciós határokat alkalmaznak. Ez megoldja annak lehetőségét, hogy bizonyos aldomainek esetében inkonzisztenciák legyenek.
  2. Végezzen el idempotens aszinkron interakciókat, amelyek előbb-utóbb megoldják az inkonzisztenciákat.
  3. Amikor csak lehetséges, kerülje a több aldomainet magában foglaló műveletet. / li>

5) Komplex jelentéskészítés. Mivel minden aldomain egy meghatározott, korlátozott kontextusban él, a több altartományt magában foglaló összetett jelentéseknél több adatforrás adatainak lekérdezésére lehet szükség: ez negatív hatással lehet mind a tartományok expresszivitására, mind a rendszer méretezhetőségére. Itt a Conio -ban CQRS architektúrát fogadtunk el a háttérirodai tevékenységek és üzleti elemzési jelentések támogatása érdekében.

6 ) Naplózási rendszer. Az elosztott rendszer minden eleme hozzájárul az egész rendszer naplójának létrehozásához. Ugyanakkor olyan eszközöket kell bevezetni, amelyek létrehozhatják a szükséges kapcsolatokat az összes ilyen szétválasztott napló között annak érdekében, hogy az egyes interakciókhoz egységes napló legyen. Itt, a Conio-ban, az ELK (ElasticSearch, Logstash, Kibana) verem használatával tároljuk és lekérdezzük a naplóadatokat: minden napló gazdagodik a szükséges korrelációs azonosítókkal, amelyek lehetővé teszik a fent említett egységes naplót.

Soha ne állítsd le az evolúciót

Vállalásunk? A kezdeti egyetlen kódbázis lebontását hosszú távú feladatnak kell tekinteni , örökös finomításokkal. A Conio-nál néhány évbe tellett, amikor lépésről lépésre 1 masszív kódbázisról 100 mikroszolgáltatásra léptünk át. Elérkeztünk egy olyan ponthoz, ahol valóban büszkék vagyunk az eredményekre, ugyanakkor folytatjuk a feltárást. Többféle új optimalizálás létezik: a Docker Swarm-ról Kubernetesre? A backend-for-frontend szolgáltatásainak átállítása szerver nélküli lambda függvényekre? Teljes folyamatos üzembe helyezési műveletre váltás? A lehetőségek végtelenek.

Itt számos témát és technológiát érintettünk. A következő cikkekben további részleteket osztunk meg eredményeinkről és előrehaladásunkról. Ha tetszik, nyugodtan kommenteljen, és mondja el nekünk tapasztalatait.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük