Mik azok a microservice tervezési minták?
A mikroszolgáltatás független alkalmazáskomponensekből áll, amelyek egy rendszer számára specifikus funkciókat hajtanak végre. Egyetlen példánya vagy több példánya is lehet a funkcionális követelmények alapján.
A kliensoldali (webes felület és mobilos UI) és a köztes rétegekben lévő más integrált szolgáltatásokkal együtt ezek a mikroszolgáltatások mindegyike egy teljes architektúrát alkot.
Az ilyen mikroszolgáltatás-architektúra tervezése, fejlesztése és telepítése azonban kihívásokkal jár, mint például:
- Közös hozzáférés kezelése
- Adatkonzisztencia
- Szolgáltatások biztonsága
- Szolgáltatások közötti kommunikáció
Itt jönnek a képbe a mikroszolgáltatás tervezési minták (microservice design patterns)!
Ezek olyan referenciaarchitektúrás minták, amelyek segítenek a szolgáltatások hatékonyabb adminisztrációjában, ezeknek a kihívásoknak a leküzdésében és a teljesítmény maximalizálásában.
Sőt, a mikroszolgáltatásokban az Ön felhasználási eseteihez megfelelő tervezési minták alkalmazása növelheti a komponensek újrafelhasználhatóságát, ami végül a fejlesztési idő és erőfeszítések csökkenését eredményezi.
Idővel az újrafelhasználhatóság kiküszöböli a szükségtelen újrafejlesztést az alkalmazás módosításainál.
A 10 legfontosabb microservice tervezési minta
Fontos megjegyezni, hogy a mikroszolgáltatás tervezési minták nem csodaszerek!
Minden tervezési mintának megvannak a maga előnyei és hátrányai.
A következőkben az alábbi 12 tervezési mintát mutatjuk be röviden:
- Strangler Fig
- SAGA
- Aggregator
- Event Source
- CQRS
- Sidecar
- Database per microservice
- Backend For Frontends (BFF)
- Api Gateway
- Circuit Braker
1. Strangler Fig minta
A Strangler mintát eredetileg Martin Fowler mutatta be 2004-ben a “StranglerFigApplication” című blogbejegyzésében.
Egy meglévő alkalmazás mikroszolgáltatásokra való áttelepítése során kihívást jelenthet az alkalmazás elérhetőségének fenntartása, de a Strangler minta hatékonyan segít ennek kezelésében.
Ez a minta lehetővé teszi a kód fokozatos és megbízható átalakítását.
Olyan módszert ír le, ahol a csapat egy adott időpontban egy új mikroszolgáltatásba helyezi át a konkrét funkciókat.
A legjobb, hogy a változtatások inkrementálisak, folyamatosan figyeltek, jól meghatározottak, és a dolgok rosszul működésének esélye meglehetősen alacsony.
Ezért, ha az alkalmazás elérhetősége az egyik legfontosabb prioritás, akkor ez a minta működik a legjobban, és biztosítja egy olyan rendszer kiépítését, amelyben már jó teszt lefedettség van.
Az áttelepítés során egy API Gateway (API kapu) funkcionál homlokzatként (Facade), amely a felhasználói kéréseket a megfelelő alkalmazáshoz irányítja.
Egy ilyen homlokzat biztosítja az alkalmazás elérhetőségét.
Ezenkívül lehetővé teszi a fejlesztői csapatok számára, hogy saját ütemükben haladjanak az átállítással, külső kötelezettségek nélkül.
Amint az áttelepítés befejeződik, a monolit architektúra “megfojtásra” kerül, azaz a monolitikus alkalmazás készen áll a nyugdíjazásra.
Példa: Shopify
A Shopify a strangler mintával strukturálta át a “shop” osztályt.
A Shopify RoR kódbázisának egyik legkritikusabb része a “Shop” modell, amely több mint 3000 sornyi kódot tartalmaz.
Amikor a Shopify egy kisebb vállalat volt, a “Shop” célja egyértelmű volt, de ahogy nőtt, a vállalat sokkal összetettebbé vált, és a “Shop” modell üzleti céljai teljesen eltérőek lettek.
Végül a “Shop” meghatározása homályossá vált. A tiszta kód és a jól definiált szoftverarchitektúra híveként a Shopify-nak megoldást kellett találnia a probléma kezelésére.
Végül a Strangler Fig mintát választották az átalakításhoz.
A vállalat elejétől fogva egy dolgot tudott: a Shopify szüneteltetés nélküli működésének garantálása kritikus fontosságú volt, és egy teljesen új rendszerre való egyszeri áttérés katasztrófa-receptnek tűnt.
Ezért tűnt a Strangler Fig minta tökéletes megközelítésnek.
A Shopify fokozatosan kezdte meg az átállást az új rendszerre, de eközben a régi rendszert is fenntartotta, amíg biztosak nem voltak benne, hogy az új rendszer az elvárásoknak megfelelően működik.
Ezenkívül a Shopify kidolgozott egy 7 lépéses részletes folyamatot a beállításoknak a “Shop” módból történő kinyerésére.
Összefoglalva a “Strangler Pattern” lehetséges alkalmazási területei:
1. Fokozatos átállás:
- A monolitikus alkalmazás fokozatos lebontása mikroszolgáltatásokra
- A funkcionalitás fokozatos áthelyezése az új mikroszolgáltatásokba
- A régi és az új kódok párhuzamos futtatása egy ideig
2. Kockázatcsökkentés:
- A hibák izolálása az új mikroszolgáltatásokban
- Az alkalmazás folyamatos elérhetőségének biztosítása
- A visszaállás lehetősége a régi rendszerre
3. Architektúrális rugalmasság:
- Lehetővé teszi a különböző technológiák használatát a mikroszolgáltatásokban
- Független skálázhatóság a mikroszolgáltatások számára
- Javítja az alkalmazás karbantarthatóságát
4. Hosszú távú fenntarthatóság:
- Megkönnyíti a jövőbeli változtatások és fejlesztések bevezetését
- Javítja az alkalmazás teljesítményét és megbízhatóságát
- Támogatja a DevOps gyakorlatokat
