Mi a mikroszolgáltatás megfelelő mérete? Gyakran hall valamit a hatása, "nem túl nagy, és nem túl kicsi" - és bár ez természetesen helyes, ez nem túl hasznos a gyakorlatban. Ha azonban egy gondosan megtervezett tartománymodellből indul ki, sokkal egyszerűbb a mikroszolgáltatásokra vonatkozó érvek magyarázata.
Ez a cikk egy drónos kézbesítési szolgáltatást használ futó példaként. A forgatókönyvről és a kapcsolódó referencia-implementációról itt olvashat bővebben.
Tartománymodelltől a mikroszolgáltatásokig
Az előző cikkben egy drónkézbesítési alkalmazáshoz kötött környezeteket határoztunk meg. Ezután részletesebben megvizsgáltuk az egyik ilyen kötött környezetet, a szállítási határos környezetet, és azonosítottuk az adott határos környezet entitásainak, összesítéseinek és tartományi szolgáltatásainak egy halmazát.
Most már készen állunk rá, hogy a tartományi modell tervezéséről áttérjünk az alkalmazáséra. Bemutatunk egy módszert, amellyel mikroszolgáltatások származtathatók a tartományi modellből.
Induljon ki egy körülhatárolt környezetből. Egy mikroszolgáltatás működése nem terjedhet ki egy körülhatárolt környezeten túlra. Egy körülhatárolt környezet definíció szerint egy adott tartományi modell határát jelöli ki. Ha azt tapasztalja, hogy egy mikroszolgáltatás különböző tartományi modelleket vegyít, ez azt jelzi, hogy vissza kell lépnie, és finomítania kell a tartományelemzést.
Ez után vizsgálja meg a tartományi modell összesítéseit. Az összesítések gyakran alkalmas mikroszolgáltatás-jelöltek. Egy jól megtervezett összesítés egy jól megtervezett mikroszolgáltatás számos jellemzőjével rendelkezik. Ilyenek például a következők:
- Az összesítéseket üzleti követelményekből származtatják, nem pedig olyan technikai megfontolásokból, mint az adathozzáférés és az üzenetküldés.
- Egy összesítésnek erős funkcionális kohézióval kell rendelkeznie.
- Az összesítések megőrzési határok.
- Az összesítéseknek lazán kapcsolódóknak kell lenniük.
A tartományi szolgáltatások is mikroszolgáltatásnak alkalmas jelöltek. A tartományi szolgáltatások több összesítésen végzett, állapot nélküli műveletek. Erre jellemző példa egy több mikroszolgáltatást érintő munkafolyamat. Ilyen példát látunk majd a Drone Delivery alkalmazásban.
Utolsóként vegye figyelembe a nem funkcionális követelményeket. Olyan tényezőket kell megvizsgálnia, mint a csapat mérete, az adattípusok, a technológiák, valamint a skálázhatósági, rendelkezésre állási és biztonsági követelmények. Ezek a tényezők elvezethetnek a mikroszolgáltatás tovább-bontásához két vagy több kisebb szolgáltatásra, vagy éppen ellenkezőleg, több mikroszolgáltatás egyesítéséhez.
Miután azonosította a mikroszolgáltatásokat az alkalmazásban, ellenőrizze a kialakítást a következő feltételek szerint:
- Minden szolgáltatásnak egyetlen felelőssége van.
- A szolgáltatások között nincsenek csevegőüzenetek. Ha a funkciók két szolgáltatásra való felosztása túlzottan beszédessé teszi őket, az azt a jelenséget okozhatja, hogy ezek a függvények ugyanabba a szolgáltatásba tartoznak.
- Minden szolgáltatás elég kicsi ahhoz, hogy egy önállóan dolgozó kis csapat felépítse.
- Nincsenek olyan függőségek, amelyekhez két vagy több szolgáltatást kell üzembe helyezni a zárolási lépésben. Mindig lehetségesnek kell lennie egy szolgáltatás üzembe helyezésére anélkül, hogy más szolgáltatásokat helyezne üzembe.
- A szolgáltatások nincsenek szorosan összekapcsolva, és egymástól függetlenül fejlődhetnek.
- A szolgáltatáshatárok nem okoznak problémákat az adatkonzisztenciával vagy az integritással kapcsolatban. Néha fontos fenntartani az adatkonzisztenciát azáltal, hogy a funkciókat egyetlen mikroszolgáltatásba helyezi. Ennek ellenére gondolja át, hogy valóban erős konzisztenciára van-e szüksége. Vannak stratégiák az elosztott rendszerek végleges konzisztenciájának kezelésére, és a szolgáltatások felbontásának előnyei gyakran meghaladják a végleges konzisztencia kezelésének kihívásait.
Mindennél fontosabb a gyakorlatiasság, és annak szem előtt tartása, hogy a tartományalapú tervezés egymásra épülő lépésekből álló folyamat. Kétség esetén nagyobb mikroszolgáltatásokból induljon ki. Egy mikroszolgáltatást egyszerűbb két kisebb szolgáltatásra bontani, mint több meglévő mikroszolgáltatás működését újrabontani.
Példa: Mikroszolgáltatások meghatározása a Drone Delivery alkalmazáshoz
Ne feledje, hogy a fejlesztői csapat azonosította a négy összesítést – kézbesítés, csomag, drón és fiók – és két tartományi szolgáltatást, a Schedulert és a felügyelőt.
A kézbesítés és a csomag kézenfekvő jelöltek a mikroszolgáltatásokra. Az ütemező és a felügyelő koordinálja a más mikroszolgáltatások által végzett tevékenységeket, ezért érdemes ezeket a tartományi szolgáltatásokat mikroszolgáltatásként megvalósítani.
A drón és a fiók azért érdekes, mert más korlátozott környezetekhez tartoznak. Az egyik lehetőség az, hogy az Ütemező közvetlenül meghívja a Drón és a Fiók által határolt környezeteket. Egy másik lehetőség a drón- és fiók-mikroszolgáltatások létrehozása a szállítási keretes környezetben. Ezek a mikroszolgáltatások a kötött környezetek között közvetítenek a Szállítási környezethez jobban illő API-k vagy adatsémák felfedésével.
A drón és a fiók által határolt környezetek részletei túlmutatnak ezen útmutató hatókörén, ezért a referencia-implementációban létrehoztunk nekik szimulált szolgáltatásokat. De íme néhány tényező, amelyet figyelembe kell venni ebben a helyzetben:
Milyen hálózati terhelést jelent a közvetlen hívás a másik határos környezetbe?
Alkalmas erre a kontextusra a többi határolókeretes környezet adatséma, vagy jobb, ha ehhez a határolókerethez igazított sémát használ?
A másik határos környezet örökölt rendszer? Ha igen, létrehozhat egy olyan szolgáltatást, amely sérülésgátló rétegként működik az örökölt rendszer és a modern alkalmazás közötti fordításhoz.
Mi a csapatstruktúra? Könnyű kommunikálni a másik határos környezetért felelős csapattal? Ha nem, a két környezet között közvetítő szolgáltatás létrehozása segíthet csökkenteni a csapatközi kommunikáció költségeit.
Eddig nem tekintettünk semmilyen nem funkcionális követelményre. Az alkalmazás átviteli sebességére vonatkozó követelményekre gondolva a fejlesztői csapat úgy döntött, hogy létrehoz egy külön betöltési mikroszolgáltatást, amely az ügyfélkérések betöltéséért felelős. Ez a mikroszolgáltatás úgy valósítja meg a terhelésszintezést , hogy a bejövő kéréseket egy pufferbe helyezi feldolgozásra. Az ütemező beolvassa a kéréseket a pufferből, és végrehajtja a munkafolyamatot.
A nem funkcionális követelmények miatt a csapat egy további szolgáltatást hozott létre. Az eddigi összes szolgáltatás a csomagok valós idejű ütemezésének és kézbesítésének folyamatáról szólt. A rendszernek azonban minden kézbesítés előzményeit hosszú távú tárolóban kell tárolnia az adatelemzéshez. A csapat úgy vélte, hogy ez a kézbesítési szolgáltatás felelőssége. Az adattárolási követelmények azonban meglehetősen eltérőek az előzményelemzés és a repülés közbeni műveletek esetében (lásd az adatokkal kapcsolatos szempontokat). Ezért a csapat úgy döntött, hogy létrehoz egy külön Kézbesítési előzmények szolgáltatást, amely figyeli a DeliveryTracking eseményeket a kézbesítési szolgáltatásból, és hosszú távú tárolóba írja az eseményeket.
Az alábbi ábrán a terv látható:
Töltse le az architektúra Visio-fájlját.
Következő lépések
Ezen a ponton tisztában kell lennie az egyes mikroszolgáltatások rendeltetésével és funkcióival. Most már létrehozhatja a rendszert.