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 egy szolgáltatásnak "egy dolgot" kell tennie – de ennek a szabálynak a gyakorlatban történő üzembe helyezé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, architektúrajellemzőit (más néven nem funkcionális követelményeket) és célokat. Ellenkező esetben olyan haphazard kialakítással rendelkezhet, amely néhány nemkívánatos jellemzőt mutat, például rejtett függőségeket a szolgáltatások között, szoros összekapcsolást vagy rosszul megtervezett interfészeket. Ez a cikk a mikroszolgáltatások tervezésének tartományalapú megközelítését mutatja be. A szolgáltatáshatárok kiértékelése folyamatos munkamennyiség a változó számítási feladatokon. Néha a kiértékelés a meglévő határok újradefiniált definícióit eredményezi, amelyek további alkalmazásfejlesztést igényelnek a változások kezeléséhez.
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.
Bevezetés
A mikroszolgáltatásokat üzleti képességek köré kell tervezni, nem pedig horizontális rétegekre, például adathozzáférésre vagy üzenetkezelésre. Emellett laza összekapcsolásuknak és magas funkcionális kohéziójuknak kell lennie. A mikroszolgáltatások lazán össze vannak állítva , 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 ismerné az ütemezési algoritmus részleteit vagy a drónflotta kezelését. Az architektúra jellemzőit minden mikroszolgáltatás esetében meg kell határozni, hogy megfeleljen a tartományproblémáinak, ahelyett, hogy az egész rendszerre vonatkozóan definiálva lenne. Előfordulhat például, hogy az ügyféloldali mikroszolgáltatásoknak teljesítményre, rendelkezésre állásra, hibatűrésre, biztonságra, tesztelhetőségre és rugalmasságra van szükségük. Előfordulhat, hogy egy háttérbeli mikroszolgáltatásnak csak hibatűréssel és biztonsággal kell rendelkeznie. Ha a mikroszolgáltatások szinkron kommunikációval rendelkeznek egymással, a köztük lévő függőség gyakran ugyanazt az architektúrajellemzőt igényli.
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 a következő 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 adja meg a tartomány határolt 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őben rögzítve. Az alkalmazások fejlődése során dönthet úgy, hogy a szolgáltatást több kisebb szolgáltatásra bontja.
Feljegyzé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 a főbb szempontokat szemléltetjük. 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 egy funkcionális üzleti követelményhez. Segít elkerülni, hogy a szervezeti határok vagy a technológiai döntések diktálják a tervezést.
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ánymodell 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 egy durva vázlatot készített, amely a Drone Delivery tartományt ábrázolja.
- A szállítás a diagram középpontjába kerül, mivel ez a vállalkozás alapvető feladata. A funkció engedélyezéséhez a diagram minden más funkciója létezik.
- A drónkezelés a vállalat 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éseket biztosít 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. Előfordulhat, hogy a vállalat bizonyos órákban túl sok drónkapacitással rendelkezik, é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, a számlázás és a call center olyan altartományok, amelyek támogatják az alapvető üzletmenetet.
Figyelje meg, hogy a folyamat ezen szakaszában nem hoztunk döntéseket a megvalósításról vagy a technológiákról. Egyes alrendszerek külső szoftverrendszereket vagy külső szolgáltatásokat is tartalmazhatnak. 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.
Feljegyzés
Ha egy alkalmazás külső rendszertől függ, fennáll annak a kockázata, hogy a külső rendszer adatséma vagy API-ja beszivárog az alkalmazásba, ami végső soron veszélyezteti az architektúratervet. Ez különösen igaz azokra az örökölt rendszerekre, amelyek nem feltétlenül 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 jól meghatározott határ legyen a külső rendszerek és az alkalmazás között. Fontolja meg a Strangler fügemintát vagy a korrupció elleni rétegmintát erre a célra.
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ét kell képviselniük, például a karbantartási előzményeiket, a futásteljesítményüket, az életkorukat, a modellszámukat, a teljesítményjellemzőket 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 határolt 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 különülnek el egymástól. Ebben a diagramban a határolt környezeteket összekötő szilárd vonalak olyan helyeket jelölnek, ahol két határos 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 drónokat ütemezzen a flottából.
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, határos 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 Evans open host service-nek és közzétett nyelvnek hív. Az Open Host Service lényege, hogy egy alrendszer egy formális protokollt (API- t) határoz meg más alrendszerek számára a vele való kommunikációhoz. A Publish Language kibővíti ezt az ötletet, ha az API-t olyan formában teszi közzé, amelyet más csapatok használhatnak ügyfelek írására. A mikroszolgáltatásokHOZ készült API-k 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 nyelvi-agnosztikus felületi leírását JSON vagy YAML formátumban kifejezve.
Ennek az útnak a hátralévő részében a szállítási keret kontextusára összpontosítunk.
Következő lépések
A tartományelemzés elvégzése után a következő lépés a taktikai DDD alkalmazása, a tartománymodellek pontosabb definiálása.