Mikroszolgáltatások modellezése tartományelemzéssel
A mikroszolgáltatások egyik legnagyobb kihívása az egyes szolgáltatások határainak meghatározása. Az általános szabály az, hogy a szolgáltatásnak "egy dolgot" kell tennie – de ennek a szabálynak a gyakorlatba való átültetése gondos gondolkodást igényel. Nincs olyan mechanikai folyamat, amely a "megfelelő" kialakítást eredményezi. Alaposan át kell gondolnia üzleti tartományát, követelményeit és céljait. Ellenkező esetben előfordulhat, hogy egy olyan, nem kívánt jellemzőket mutató tervvel rendelkezik, mint például a szolgáltatások közötti rejtett függőségek, a szoros összekapcsolás vagy a rosszul megtervezett felületek. Ez a cikk a mikroszolgáltatások tervezésének tartományalapú megközelítését mutatja be.
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.
Bevezetés
A mikroszolgáltatásokat üzleti képességekre kell tervezni, nem pedig olyan horizontális rétegekre, mint az adathozzáférés vagy az üzenetkezelés. Emellett laza összekapcsolásuknak és nagy funkcionális kohéziójuknak kell lennie. A mikroszolgáltatások lazán kapcsolódnak egymáshoz , ha anélkül módosíthatja az egyik szolgáltatást, hogy egyidejűleg más szolgáltatásokat kellene frissítenie. A mikroszolgáltatások akkor egységesek , ha egyetlen, jól meghatározott céllal rendelkezik, például felhasználói fiókok kezelése vagy a kézbesítési előzmények nyomon követése. A szolgáltatásnak magában kell foglalnia a tartományi tudást, és el kell absztrakciót létrehoznia az ügyfelektől. Az ügyfélnek például képesnek kell lennie egy drón ütemezésére anélkül, hogy tisztában lenne az ütemezési algoritmus részleteivel vagy a drónflotta kezelésének módjával.
A tartományalapú tervezés (Domain-driven design, rövidítve DDD) olyan keretrendszert kínál, amely végigvezet a jól megtervezett mikroszolgáltatásokig tartó út nagy részén. A DDD két elkülöníthető fázisa a stratégiai és a taktikai fázis. A stratégiai DDD során a rendszer nagyléptékű struktúráját definiálják. A stratégiai DDD segítségével biztosítható, hogy az architektúra mindig az üzleti képességekre koncentráljon. A taktikai DDD a tartománymodell megalkotásához használható tervezési mintázatokat kínál. Ilyen mintázatok például az entitások, összesítések és a tartományi szolgáltatások. Ezek a taktikai mintázatok segítenek az egyszerre lazán kapcsolódó és összetartó mikroszolgáltatások megtervezésében.
Ebben a cikkben és a következőben végigvezetjük az alábbi lépéseket, és alkalmazzuk őket a Drone Delivery alkalmazásra:
Elsőként ismerje meg az alkalmazás funkcióira vonatkozó követelményeket az üzleti tartomány elemzésével. Ennek a lépésnek az eredménye a tartomány informális leírása, amelyből kidolgozható a tartományi modellek egy formálisabb halmaza.
Ezután definiálja a tartomány kötött környezeteit . Minden körülhatárolt környezet tartalmaz egy tartománymodellt, amely a nagyobb alkalmazás egy adott altartományának felel meg.
A körülhatárolt környezeten belül taktikai DDD-mintázatok használatával definiálhatók entitások, összesítések és tartományi szolgáltatások.
Az előző lépés eredményei alapján azonosíthatja az alkalmazás mikroszolgáltatásait.
Ebben a cikkben az első három lépést tárgyaljuk, amelyek elsősorban a DDD-vel foglalkoznak. A következő cikkben azonosítjuk a mikroszolgáltatásokat. Fontos azonban megjegyezni, hogy a DDD iteratív, folyamatban lévő folyamat. A szolgáltatáshatárok nincsenek kőbe vévéve rögzítve. Az alkalmazások fejlődésével dönthet úgy, hogy a szolgáltatást több kisebb szolgáltatásra bontja.
Megjegyzés
Ez a cikk nem mutatja be a teljes és átfogó tartományelemzést. Szándékosan rövidre tartottuk a példát, hogy bemutassa a főbb szempontokat. A DDD háttérének megismeréséhez Eric Evans Tartományalapú tervezés című könyvét, a fogalmat bevezető művet ajánljuk. Egy másik hasznos referencia Vaughn Vernon könyve, a Tartományalapú tervezés implementálása.
Forgatókönyv: Drónos kézbesítés
A Fabrikam vállalat egy drónos szállítási szolgáltatást indít. A cég egy drónokból álló flottát kezel. A vállalkozások regisztrálnak a szolgáltatásban, és a felhasználók kérhetik egy termék drónos kézbesítését. Amikor az ügyfél ütemezi a felvételt, egy háttérrendszer hozzárendel egy drónt, és értesíti a felhasználót a várható szállítási időről. Amíg a kézbesítés folyamatban van, az ügyfél nyomon követheti a drón helyét, miközben a becsült érkezési időpont folyamatosan frissül.
Ez a forgatókönyv egy viszonylag összetett tartományt foglal magába. A vállalat számára problémát jelenthet a drónok ütemezése, a csomagok nyomon követése, a felhasználói fiókok felügyelete, valamint az előzményadatok tárolása és elemzése. Ezenkívül a Fabrikam gyorsan piacra szeretne lépni, majd gyors iterációkat kíván végezni, új funkciók és képességek hozzáadásával. Az alkalmazásnak felhőszinten kell üzemelnie, magas szolgáltatási szintű célkitűzéssel (service level objective, SLO). A Fabrikam emellett arra számít, hogy a rendszer különböző részeinek nagyon eltérő adattárolási és lekérdezési igényei lesznek. A megfontolandó szempontok alapján a Fabrikam azt a döntést hozta, hogy egy mikroszolgáltatási architektúrát választ a Drone Delivery alkalmazáshoz.
A tartomány elemzése
A DDD-megközelítéssel mikroszolgáltatásokat tervezhet, így minden szolgáltatás természetes módon illeszkedik a funkcionális üzleti követelményekhez. Segít elkerülni azt a csapdát, hogy a szervezeti határok vagy a technológiai döntések diktálják a tervet.
A kód írása előtt madártávlatból kell látnia a létrehozott rendszert. A DDD az üzleti tartomány modellezésével és egy tartományi modell létrehozásával kezdődik. A tartományi modell az üzleti tartomány absztrakt modellje. Leszűri és elrendezi a tartománnyal kapcsolatos ismereteket, és közös nyelvet kínál a fejlesztők és a tartományi szakértők számára.
Az első lépés az üzleti funkciók és azok kapcsolatai feltérképezése. Ez feltehetően a tartományi szakértők, a szoftvertervezők és más érdekeltek együttműködését igénylő feladat lesz. Meghatározott formalizmusra nincs szükség. A diagramot egy papírlapra vagy egy táblára is felvázolhatja.
A diagram kitöltése közben már kezdheti felismerni az elkülönülő altartományokat. Melyik funkciók függnek össze szorosan? Melyik funkciók alapvetők az üzlet szempontjából, és melyek nyújtanak kiegészítő szolgáltatásokat? Milyen a függőségi gráf? Ebben a kezdeti fázisban nem kell a technológiák és az implementáció részleteivel foglalkoznia. Azokat a helyeket ugyanakkor fel kell jegyeznie, ahol az alkalmazásnak integrálódnia kell olyan külső rendszerekkel, mint a CRM, a kifizetések feldolgozása vagy a számlázási rendszerek.
Példa: Drónkézbesítési alkalmazás
Néhány kezdeti tartományelemzés után a Fabrikam csapata létrehozott egy durva vázlatot, amely a Drone Delivery tartományt ábrázolja.
- A szállítás a diagram középpontjába kerül, mivel ez az üzlet alapvető eleme. A funkció engedélyezéséhez a diagram minden más funkciója létezik.
- A drónkezelés az üzlet alapvető feladata is. A drónkezeléshez szorosan kapcsolódó funkciók közé tartozik a drónok javítása és prediktív elemzés használata annak előrejelzésére, hogy a drónok mikor igényelnek karbantartást és karbantartást.
- Az ETA-elemzés időbecslést ad a csomagfelvételhez és a kézbesítéshez.
- A harmadik féltől származó szállítás lehetővé teszi, hogy az alkalmazás alternatív szállítási módszereket ütemezzen, ha a csomagot nem lehet teljes egészében drónnal szállítani.
- A drónmegosztás az alapvető üzleti tevékenység lehetséges kiterjesztése. A vállalat bizonyos órákban többlet drónkapacitással rendelkezhet, és olyan drónokat bérelhet ki, amelyek egyébként tétlenek lennének. Ez a funkció nem lesz a kezdeti kiadásban.
- A videófelügyelet egy másik terület, amellyel a vállalat később terjeszkedhet.
- A felhasználói fiókok, az invoicing és a call center olyan altartományok, amelyek támogatják az alapvető üzletmenetet.
Figyelje meg, hogy a folyamat ezen pontján még nem hoztunk döntéseket az implementálásról vagy a technológiákról. Egyes alrendszerek külső szoftverrendszerekre vagy külső szolgáltatásokra is kiterjedhetnek. Ennek ellenére az alkalmazásnak kommunikálnia kell ezekkel a rendszerekkel és szolgáltatásokkal, ezért fontos, hogy belefoglalja őket a tartománymodellbe.
Megjegyzés
Ha egy alkalmazás külső rendszertől függ, fennáll annak a kockázata, hogy a külső rendszer adatsémája vagy API-ja kiszivárog az alkalmazásba, ami végső soron veszélyezteti az architektúra kialakítását. Ez különösen igaz azokra az örökölt rendszerekre, amelyek nem követik a modern ajánlott eljárásokat, és konvolúciós adatsémákat vagy elavult API-kat használhatnak. Ebben az esetben fontos, hogy a külső rendszerek és az alkalmazás között jól meghatározott határ legyen. Erre a célra fontolja meg a Strangler Fig minta vagy a Korrupció elleni réteg minta használatát.
Körülhatárolt környezetek definiálása
A tartományi modell a valós világ objektumai – felhasználók, drónok, csomagok stb. – ábrázolását is magában foglalja. Ez azonban nem jelenti azt, hogy a rendszer minden részének ugyanúgy kell ábrázolnia ugyanazokat a dolgokat.
A drónjavítást és prediktív elemzést kezelő alrendszereknek például a drónok számos fizikai jellemzőjének meg kell jelenniük, például a karbantartási előzményeiknek, a megtett útjuknak, az életkoruknak, a modellszámuknak, a teljesítményjellemzőiknek stb. Egy szállítás ütemezésekor viszont mindez nem számít. Az ütemezési alrendszernek csak azt kell tudnia, hogy a drón elérhető, és hogy várhatóan mikor veszi fel és kézbesíti a szállítmányt.
Ha egyetlen modellt próbálnánk alkotni ehhez a két alrendszerhez, az szükségtelenül bonyolult volna. A modell ráadásul nehezen fejlődne a későbbiekben, hiszen minden módosítást a különálló alrendszereken dolgozó több csapat igényeinek megfelelően kellene végrehajtani. Ezért többnyire érdemesebb külön modelleket tervezni ugyanannak a valós entitásnak (ebben az esetben egy drónnak) két különböző környezetbeli leképezésére. Minden modell csak az abban az adott környezetben lényeges funkciókat és jellemzőket tartalmazza.
Itt jön létre a kötött környezetek DDD-koncepciója. Egy körülhatárolt környezet nem más, mint a tartománynak az a része, amelyben egy adott tartományi modell érvényes. Az előző diagramon a működés csoportosítható aszerint, hogy a különböző funkciók közös tartományi modellen osztoznak-e.
A határolt környezetek nem feltétlenül elkülönülnek egymástól. Ebben a diagramban a határolókeretes környezeteket összekötő folytonos vonalak olyan helyeket jelölnek, ahol két határolókeretes környezet kommunikál. A szállítás például a felhasználói fiókoktól függ az ügyfelek adatainak lekéréséhez, valamint a Drónkezeléstől, hogy a flottából származó drónokat ütemezzen.
A Tartományalapú tervezés című könyvben Eric Evans számos mintát ismertet a tartománymodell integritásának fenntartásához, amikor egy másik, korlátozott környezettel kommunikál. A mikroszolgáltatások egyik fő alapelve, hogy a szolgáltatások jól meghatározott API-kon keresztül kommunikálnak. Ez a megközelítés két mintának felel meg, amelyeket az Evans open host service-nek és közzétett nyelvnek hív. Az Open Host Service fogalma az, hogy egy alrendszer formális protokollt (API- t) határoz meg más alrendszerek számára, hogy kommunikáljanak vele. A Publish Language ezt az elképzelést azzal bővíti, hogy közzéteszi az API-t egy olyan űrlapon, amelyet más csapatok az ügyfelek írására használhatnak. Az API-k mikroszolgáltatásokhoz való tervezéséről szóló cikkben az OpenAPI-specifikáció (korábbi nevén Swagger) használatával határozzuk meg a REST API-k nyelvfüggetlen felületének JSON- vagy YAML-formátumban kifejezett leírását.
A folyamat hátralevő részében a szállítási keretre összpontosítunk.
Következő lépések
A tartományelemzés befejezése után a következő lépés a taktikai DDD alkalmazása a tartománymodellek pontosabb definiálásához.
Kapcsolódó források (lehet, hogy a cikkek angol nyelvűek)
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: