Jegyzet
Az oldalhoz való hozzáférés engedélyezést igényel. Próbálhatod be jelentkezni vagy könyvtárat váltani.
Az oldalhoz való hozzáférés engedélyezést igényel. Megpróbálhatod a könyvtár váltását.
Azure DevOps
Az építészek és fejlesztők nehezen határozzák meg a mikroszolgáltatások megfelelő méretét. Az útmutatás gyakran hangsúlyozza a túl nagy vagy túl kicsi szélsőségek elkerülését, de ez a tanács a gyakorlatban homályos lehet. Ha azonban egy gondosan megtervezett tartománymodellből indul ki, könnyebben meghatározhatja az egyes mikroszolgáltatások megfelelő méretét és hatókörét.
Ez a cikk egy drónkézbesítési szolgáltatást használ futó példaként. A forgatókönyvről és a kapcsolódó referencia-megvalósításró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 határos környezetet, a szállítási határos környezetet, és azonosítottunk egy entitásokat, összesítéseket és tartományi szolgáltatásokat az adott határos környezethez.
Most már készen állunk a tartománymodellről az alkalmazástervezésre. Az alábbi módszerekkel mikroszolgáltatásokat hozhat létre a tartománymodellből.
Kezdje egy határolt környezettel. A mikroszolgáltatások funkciói általában nem terjednek ki egynél több határos környezetre. Definíció szerint egy határolt környezet egy adott tartománymodell határát jelöli. Ha úgy találja, hogy egy mikroszolgáltatás különböző tartománymodelleket kever össze, előfordulhat, hogy vissza kell lépnie, és finomítania kell a tartományelemzést.
Ezután tekintse meg a tartománymodell összesítéseit. Az aggregátumok gyakran jó jelöltek a mikroszolgáltatások számára. A jól megtervezett összesítések a jól megtervezett mikroszolgáltatások számos jellemzőjét jelenítik meg:
- Az aggregátumok üzleti követelményekből származnak, nem pedig olyan technikai szempontokból, mint az adathozzáférés vagy az üzenetkezelés.
- Az aggregátumnak nagy funkcionális kohézióval kell rendelkeznie.
- Az aggregátum a tartósság határa.
- Az aggregátumokat lazán kell összekapcsolni.
A tartományi szolgáltatások a mikroszolgáltatásokra is jó jelöltek. A domainekhez kapcsolódó szolgáltatások állapot nélküli műveletek több aggregátum között. Tipikus példa egy több mikroszolgáltatást tartalmazó munkafolyamat. A Drone Delivery alkalmazás egy példát mutat be.
Fontolja meg a nem funkcionális követelményeket. Tekintse meg az olyan tényezőket, mint a csapat mérete, az adattípusok, a technológiák, a méretezhetőségi követelmények, a rendelkezésre állási követelmények és a biztonsági követelmények. Ezek a tényezők azt okozhatják, hogy egy mikroszolgáltatást több kisebb szolgáltatásra bont. Más esetekben előfordulhat, hogy több mikroszolgáltatást egyesít egyetlen mikroszolgáltatásba.
Miután azonosította az alkalmazás mikroszolgáltatásait, ellenőrizze a tervét az alábbi feltételek szerint:
Minden szolgáltatásnak egyetlen felelőssége van.
A szolgáltatások között nincsenek csevegőhívások. Ha a funkciók két szolgáltatásra való felosztása túlzottan beszédessé teszi őket, annak az lehet a tünete, hogy ezek a függvények ugyanabba a szolgáltatásba tartoznak.
Minden szolgáltatás elég kicsi ahhoz, hogy önállóan dolgozó kis csapat építse.
Nincsenek egymástól függő elemek, amelyekhez két vagy több szolgáltatás együttes üzembe helyezésére van szükség. Minden szolgáltatásnak külön üzembe helyezhetőnek kell lennie anélkül, hogy újra üzembe kellene helyeznie másokat.
A szolgáltatások nincsenek szorosan összekapcsolva, és egymástól függetlenül is fejlődhetnek.
A szolgáltatáshatárok célja az adatkonzisztenciával vagy integritással kapcsolatos problémák elkerülése. Bizonyos esetekben az adatkonzisztencia fenntartása a kapcsolódó funkciók egyetlen mikroszolgáltatásba való csoportosítását jelenti. Az erős konzisztencia azonban nem mindig szükséges. Az elosztott rendszerek stratégiákat biztosítanak a végleges konzisztencia kezelésére, és a szolgáltatások felbontásának előnyei gyakran meghaladják a kezelés összetettségét.
Mindenekelőtt fontos, hogy pragmatikus legyen, és ne feledje, hogy a tartományalapú tervezés iteratív folyamat. Ha kétségei vannak, kezdje a durva szemcsés mikroszolgáltatásokkal. A mikroszolgáltatások két kisebb szolgáltatásra való felosztása egyszerűbb, mint a funkciók újrabontása több meglévő mikroszolgáltatásban.
Példa: Mikroszolgáltatások meghatározása a Drone Delivery alkalmazáshoz
A fejlesztői csapat korábban azonosította a négy aggregátumot, a kézbesítést, a csomagokat, a drónt és a fiókot, valamint két tartományi szolgáltatást, a Schedulert és a Felügyelőt.
A kézbesítés és a csomag nyilvánvaló jelölt a mikroszolgáltatások számára. Az Ütemező és a Felügyelő koordinálja a többi mikroszolgáltatás által végzett tevékenységeket, ezért érdemes ezeket a tartományi szolgáltatásokat mikroszolgáltatásként implementálni.
A drón és a fiók azért érdekes, mert más kötött környezetekhez tartoznak. Az egyik lehetőség az, hogy az Ütemező közvetlenül meghívja a Drónt és a Fiókhoz kötött 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 határokkal határolt környezetben. Ezek a mikroszolgáltatások a határos környezetek között közvetítenék 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 makettszolgáltatásokat hoztunk létre számukra. 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 környezetre a másik határos környezet adatséma, vagy jobb, ha ehhez a határos környezethez van igazítva egy séma?
A másik határos környezet örökölt rendszer? Ha igen, létrehozhat egy olyan szolgáltatást, amely korrupciógá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önnyen kommunikálhat 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.
A csapat eddig nem tekintette a nem funkcionális követelményeket. Az alkalmazás átviteli sebességére vonatkozó igények kiértékelése után a fejlesztői csapat létrehoz egy külön betöltési mikroszolgáltatást az ügyfélkérések kezeléséhez. Ez a mikroszolgáltatás úgy valósítja meg a terhelés simítását , hogy a bejövő kéréseket egy pufferbe helyezi feldolgozás céljából. Az Ütemező ezután felolvassa a pufferből érkező kéréseket, és implementálja a munkafolyamatot.
A nem funkcionális követelmények arra is késztetik a csapatot, hogy még egy szolgáltatást hozzanak létre. A meglévő szolgáltatások a csomagok valós idejű ütemezésére és kézbesítésére összpontosítanak. A rendszernek azonban a kézbesítési előzményeket is hosszú távú tárolóban kell tárolnia az adatelemzéshez. Kezdetben a csapat fontolóra vette, hogy ezt a feladatot a kézbesítési szolgáltatás részévé teszi. Az előzményelemzés adattárolási követelményei azonban eltérnek a repülés közbeni műveletek követelményeitől. További információkért tekintse meg az adatokkal kapcsolatos szempontokat. Ennek eredményeként a csapat létrehozott egy külön Kézbesítési előzmények szolgáltatást. Ez a szolgáltatás figyeli a Kézbesítési szolgáltatás DeliveryTracking eseményeit, és hosszú távú tárolóba írja őket.
Az alábbi ábrán az alábbi ábrán látható a terv:
Töltsön le egy Visio-fájlt az architektúráról.
Következő lépések
Ezen a ponton tisztában kell lennie az egyes mikroszolgáltatások céljával és funkcióival a tervezés során. Most már létrehozhatja a rendszert.