Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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 csak egy dolgot kell tennie, de a szabály gyakorlatba helyezése gondos gondolkodást igényel. Nincs olyan mechanikai folyamat, amely a megfelelő kialakítást eredményezte. Alaposan át kell gondolnia az üzleti tartományt, a követelményeket, az architektúra jellemzőit (más néven nem funkcionális követelményeket) és a 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 több alkalmazásfejlesztést igényelnek a módosítá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 megfelelő referencia-megvalósításról további információt a mikroszolgáltatás-architektúra tervezése című témakörben talál.
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-ben a rendszer nagy léptékű struktúráját határozza meg. 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ák segítenek a lazán összekapcsolt és összetartó mikroszolgáltatások tervezé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. További információkat a DDD-ről Eric Evans Domain-Driven Design című könyvében találhat, amely először bevezette ezt a kifejezést. Egy másik jó referenciamunka Vaughn Vernon Domain-Driven Design megvalósítá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 meglehetősen összetett tartományt tartalmaz. A legfontosabb üzleti problémák közé tartozik a drónok ütemezése, a csomagok nyomon követése, a felhasználói fiókok kezelése, valamint az előzményadatok tárolása és elemzése. A Fabrikam arra is törekszik, hogy gyorsan piacra jusson, és gyorsan iteráljon, új funkciókkal és képességekkel bővítve. Az alkalmazásnak felhőszinten kell működnie, és meg kell felelnie egy magas szolgáltatási szintű célkitűzésnek. A Fabrikam azt is elvárja, hogy a rendszer különböző részei eltérő követelményeket támasztjanak az adattárolásra és a lekérdezésre vonatkozóan. Ezek a szempontok arra vezetnek, hogy a Fabrikam mikroszolgáltatás-architektúrát vezet be a Drone Delivery alkalmazáshoz.
A tartomány elemzése
A DDD-megközelítés segít mikroszolgáltatások tervezésében, hogy minden szolgáltatás természetes módon illeszkedjen 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.
Mielőtt bármilyen kódot ír, ismernie kell a buildelt 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. Lepárlja és rendszerezi a tartományi ismereteket, és közös nyelvet biztosít a fejlesztők és a tartományi szakértők számára.
Kezdje az összes üzleti függvény és azok kapcsolatainak leképezésével. Ez a munka olyan együttműködés lehet, amely tartományszakértőket, szoftverfejlesztőket és más érdekelt feleket is magában foglal. 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 során elkezdheti azonosítani a különálló altartományokat. Melyik funkciók függnek össze szorosan? Mely függvények képezik az üzleti alapokat, és mely függvények nyújtanak kiegészítő szolgáltatásokat? Mi 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. Ennek ellenére meg kell jegyeznie, hogy az alkalmazásnak integrálnia kell a külső rendszerekkel, például az ügyfélkapcsolat-kezeléssel, a fizetésfeldolgozással vagy a számlázási rendszerekkel.
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öbblet 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 kiszivároghat az alkalmazásba. Ez a fajta szivárgás veszélyeztetheti az architektúra kialakítását. Ez különösen gyakori az olyan örökölt rendszerek esetében, amelyek nem követik a modern ajánlott eljárásokat, és konvolúciós adatsémákat vagy elavult API-kat használhatnak. Ezekben az esetekben fontos egy jól meghatározott határt kialakítani a külső rendszer és az alkalmazás között. Ennek a határnak a kikényszerítéséhez fontolja meg a Strangler fügemintát vagy a korrupció elleni rétegmintá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é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 a határolt környezetek DDD-koncepciója kerül előtérbe. A határolt környezet határozza meg a tartományon belüli határt, ahol egy adott tartománymodell érvényes. Az előző diagramra hivatkozva csoportosíthatja a funkciókat annak alapján, hogy a különböző függvények ugyanazt a tartománymodellt használják-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.