Mikroszolgáltatás-orientált alkalmazás tervezése

Jótanács

Ez a tartalom egy részlet a '.NET Microservices Architecture for Containerized .NET Applications' című eBook-ból, amely elérhető a .NET Docs oldalon, vagy ingyenesen letölthető PDF formátumban, amely offline módban is olvasható.

PDF letöltése

Ez a szakasz egy hipotetikus kiszolgálóoldali vállalati alkalmazás fejlesztésére összpontosít.

Alkalmazás specifikációi

A hipotetikus alkalmazás üzleti logika végrehajtásával, adatbázisok elérésével, majd HTML-, JSON- vagy XML-válaszok visszaadásával kezeli a kérelmeket. Azt fogjuk mondani, hogy az alkalmazásnak támogatnia kell a különböző ügyfeleket, beleértve az egyoldalas alkalmazásokat (SA-kat) futtató asztali böngészőket, a hagyományos webalkalmazásokat, a mobil webalkalmazásokat és a natív mobilalkalmazásokat. Az alkalmazás egy API-t is közzétehet harmadik felek számára, hogy felhasználják. Képesnek kell lennie arra is, hogy mikroszolgáltatásait vagy külső alkalmazásait aszinkron módon integrálja, így ez a megközelítés segít a mikroszolgáltatások rugalmasságában részleges hibák esetén.

Az alkalmazás az alábbi típusú összetevőkből áll:

• A bemutató részei. Ezek az összetevők felelősek a felhasználói felület kezeléséért és a távoli szolgáltatások használatáért.

• Tartomány- vagy üzleti logika. Ez az összetevő az alkalmazás tartománylogikája.

• Adatbázis-hozzáférési logika. Ez az összetevő az adatbázisok (SQL vagy NoSQL) eléréséért felelős adatelérési összetevőkből áll.

• Alkalmazásintegrációs logika. Ez az összetevő egy üzenetközvetítőn alapuló üzenetkezelési csatornát is tartalmaz.

Az alkalmazás magas skálázhatóságot igényel, ugyanakkor lehetővé teszi a vertikális alrendszerek önálló felskálázását, mivel egyes alrendszerek méretezhetősége nagyobb lesz, mint mások.

Az alkalmazásnak több infrastruktúra-környezetben (több nyilvános felhőben és helyszíni környezetben) kell üzembe helyeznie, és ideális esetben platformfüggetlennek kell lennie, képesnek kell lennie a Linuxról a Windowsra (vagy fordítva) könnyen áttérni.

Fejlesztői csapat környezete

Az alkalmazás fejlesztési folyamatával kapcsolatban a következőket is feltételezzük:

• Több fejlesztői csapat is van, amelyek az alkalmazás különböző üzleti területeire összpontosítanak.

• Az új csapattagok gyorsan hatékonyan dolgozhatnak, és az alkalmazásnak könnyen érthetőnek és módosíthatónak kell lennie.

• Az alkalmazás hosszú távú fejlődéssel és folyamatosan változó üzleti szabályokkal fog rendelkezni.

• Jó hosszú távú karbantarthatóságra van szüksége, ami azt jelenti, hogy rugalmassággal kell dolgoznia az új változások jövőbeni megvalósításakor, miközben több alrendszert is frissíthet, és minimális hatással van a többi alrendszerre.

• Szeretné gyakorolni az alkalmazás folyamatos integrációját és folyamatos üzembe helyezését.

• Az alkalmazás fejlesztése során ki szeretné használni az újonnan megjelenő technológiákat (keretrendszereket, programozási nyelveket stb.). Az új technológiákra való áttéréskor nem szeretné az alkalmazás teljes migrálását elvégezni, mert az magas költségeket eredményezne, és hatással lenne az alkalmazás kiszámíthatóságára és stabilitására.

Architektúra kiválasztása

Mi legyen az alkalmazástelepítési architektúra? Az alkalmazás specifikációi és a fejlesztési környezet erősen azt sugallják, hogy az alkalmazást úgy kell kialakítani, hogy az autonóm alrendszerekbe bontja azt együttműködő mikroszolgáltatások és tárolók formájában, ahol a mikroszolgáltatások tárolók.

Ebben a megközelítésben minden szolgáltatás (tároló) összetartó és szűk körben kapcsolódó függvényeket valósít meg. Egy alkalmazás például olyan szolgáltatásokból állhat, mint a katalógusszolgáltatás, a rendelési szolgáltatás, a kosárszolgáltatás, a felhasználói profilszolgáltatás stb.

A mikroszolgáltatások olyan protokollokkal kommunikálnak, mint a HTTP (REST), de aszinkron módon is (például AMQP használatával), amikor csak lehetséges, különösen akkor, ha a frissítéseket integrációs eseményekkel propagálják.

A mikroszolgáltatások egymástól függetlenül tárolókként vannak kifejlesztve és üzembe helyezve. Ez a megközelítés azt jelenti, hogy a fejlesztőcsapatok anélkül fejleszthetnek és helyezhetnek üzembe egy bizonyos mikroszolgáltatást, hogy az hatással lenne más alrendszerekre.

Minden mikroszolgáltatás saját adatbázissal rendelkezik, így teljesen leválasztható más mikroszolgáltatásokról. Szükség esetén a különböző mikroszolgáltatásokból származó adatbázisok közötti konzisztenciát alkalmazásszintű integrációs események (logikai eseménybuszon keresztül) valósítják meg, a parancs- és lekérdezési felelősség elkülönítése (CQRS) szerint. Emiatt az üzleti korlátozásoknak át kell vennie a több mikroszolgáltatás és a kapcsolódó adatbázisok közötti végleges konzisztenciát.

eShopOnContainers: Referenciaalkalmazás a tárolók használatával üzembe helyezett .NET- és mikroszolgáltatásokhoz

Annak érdekében, hogy az architektúrára és a technológiákra összpontosíthasson ahelyett, hogy olyan feltételezett üzleti tartományra gondolna, amelyet esetleg nem ismer, egy jól ismert üzleti tartományt választottunk ki – nevezetesen egy egyszerűsített e-kereskedelmi (e-shop) alkalmazást, amely termékkatalógust jelenít meg, megrendeléseket fogad el az ügyfelektől, ellenőrzi a leltárt, és egyéb üzleti funkciókat végez. Ez a tárolóalapú alkalmazásforráskód az eShopOnContainers GitHub-adattárban érhető el.

Az alkalmazás több alrendszerből áll, köztük több áruházi felhasználói felületi előtérből (egy webalkalmazásból és egy natív mobilalkalmazásból), valamint a háttérbeli mikroszolgáltatásokból és tárolókból az összes szükséges kiszolgálóoldali művelethez, több API Gateway használatával, konszolidált belépési pontként a belső mikroszolgáltatásokhoz. A 6–1. ábra a referenciaalkalmazás architektúráját mutatja be.

6-1. ábra. Az eShopOnContainers referenciaalkalmazás-architektúrája fejlesztési környezethez

A fenti ábra azt mutatja, hogy a mobil- és SPA-ügyfelek egyetlen API-átjáróvégpontokkal kommunikálnak, amelyek ezután kommunikálnak a mikroszolgáltatásokkal. A hagyományos webes ügyfelek kommunikálnak az MVC mikroszolgáltatásokkal, amelyek az API-átjárón keresztül kommunikálnak a mikroszolgáltatásokkal.

Üzemeltetési környezet. A 6–1. ábrán több tároló is látható egyetlen Docker-gazdagépen belül. Ez a helyzet akkor, ha egyetlen Docker-gazdagépen helyezi üzembe a docker-compose up paranccsal. Ha azonban vezénylőt vagy tárolófürtöt használ, az egyes tárolók egy másik gazdagépen (csomóponton) futhatnak, és bármelyik csomópont tetszőleges számú tárolót futtathat, ahogyan azt az architektúra szakasz korábbi részében ismertettük.

Kommunikációs architektúra. Az eShopOnContainers alkalmazás a funkcionális művelet típusától függően két kommunikációs típust használ (lekérdezések és frissítések és tranzakciók):

• HTTP-ügyfél-mikroszolgáltatások közötti kommunikáció API-átjárókon keresztül. Ez a módszer lekérdezésekhez és az ügyfélalkalmazások frissítési vagy tranzakciós parancsainak elfogadásakor használatos. Az API-átjárók használatát a későbbi szakaszok részletesen ismertetik.

• Aszinkron eseményalapú kommunikáció. Ez a kommunikáció egy eseménybuszon keresztül történik a frissítések mikroszolgáltatások közötti propagálása vagy a külső alkalmazásokkal való integráció érdekében. Az eseménybusz bármilyen üzenetközvetítő infrastruktúra-technológiával implementálható, például a RabbitMQ-val, vagy magasabb szintű (absztrakciós szintű) szolgáltatásbuszokkal, mint például az Azure Service Bus, az NServiceBus, a MassTransit vagy a Brighter.

Az alkalmazás mikroszolgáltatások készleteként van üzembe helyezve tárolók formájában. Az ügyfélalkalmazások az API-átjárók által közzétett nyilvános URL-címeken keresztül kommunikálhatnak a tárolóként futó mikroszolgáltatásokkal.

Adatelkentség mikroszolgáltatásonként

A mintaalkalmazásban minden mikroszolgáltatás saját adatbázissal vagy adatforrással rendelkezik, bár az összes SQL Server-adatbázis egyetlen tárolóként van üzembe helyezve. Ez a tervezési döntés csak azért született meg, hogy a fejlesztő egyszerűen beszerezhesse a kódot a GitHubról, klónozza és nyissa meg a Visual Studióban vagy a Visual Studio Code-ban. Vagy azt is megteheti, hogy egyszerűvé teszi az egyéni Docker-rendszerképek fordítását a .NET CLI és a Docker CLI használatával, majd üzembe helyezheti és futtathatja őket Egy Docker fejlesztői környezetben. A tárolók adatforrásokhoz való használata akár percek alatt is lehetővé teszi a fejlesztők számára a létrehozást és üzembe helyezést anélkül, hogy külső adatbázist vagy bármilyen más, az infrastruktúrától (felhőtől vagy helyszínitől) függő adatforrást kellene kiépíteni.

A valódi termelési környezetben a magas rendelkezésre állás és méretezhetőség érdekében az adatbázisoknak felhőben vagy helyszíni adatbázis-kiszolgálókon kell alapulniuk, azonban nem tárolókban.

Ezért a mikroszolgáltatások (és az alkalmazásban lévő adatbázisok) üzembehelyezési egységei Docker-tárolók, a referenciaalkalmazás pedig egy többtárolós alkalmazás, amely a mikroszolgáltatások alapelveit foglalja magában.

További erőforrások

• eShopOnContainers GitHub-adattár. A referenciaalkalmazás forráskódja
  https://aka.ms/eShopOnContainers/

A mikroszolgáltatás-alapú megoldások előnyei

Egy ilyen mikroszolgáltatás-alapú megoldásnak számos előnye van:

Mindegyik mikroszolgáltatás viszonylag kicsi – könnyen kezelhető és fejleszthető. Ezek konkrétan a következők:

• A fejlesztők könnyen megérthetik és gyorsan elkezdhetik a munkát, így jó hatékonyságot érhetnek el.

• A tárolók gyorsan elindulnak, ami hatékonyabbá teszi a fejlesztőket.

• A Visual Studio-hoz hasonló IDE-k gyorsan betölthetnek kisebb projekteket, ami hatékonyabbá teszi a fejlesztőket.

• Minden mikroszolgáltatás megtervezhető, fejleszthető és üzembe helyezhető más mikroszolgáltatásoktól függetlenül, ami rugalmasságot biztosít, mivel a mikroszolgáltatások új verzióit gyakran könnyebb üzembe helyezni.

Az alkalmazás egyes területeit felskálázhatja. Előfordulhat például, hogy a katalógusszolgáltatást vagy a kosárszolgáltatást fel kell skálázni, a rendelési folyamatot azonban nem. A mikroszolgáltatási infrastruktúra sokkal hatékonyabb lesz a horizontális felskálázáskor használt erőforrások tekintetében, mint egy monolitikus architektúra.

A fejlesztési munkát több csapat között oszthatja meg. Minden szolgáltatás egyetlen fejlesztői csapat tulajdonában lehet. Minden csapat a többi csapattól függetlenül kezelheti, fejlesztheti, üzembe helyezheti és skálázhatja szolgáltatását.

A problémák elszigeteltebbek. Ha egy szolgáltatásban probléma merül fel, a rendszer csak az adott szolgáltatást érinti először (kivéve, ha nem a megfelelő kialakítást használja, a mikroszolgáltatások közötti közvetlen függőségekkel), és más szolgáltatások továbbra is kezelhetik a kéréseket. Ezzel szemben a monolitikus üzembehelyezési architektúra egyik hibásan működő összetevője a teljes rendszert leállíthatja, különösen akkor, ha erőforrásokat, például memóriaszivárgást igényel. Emellett, ha egy mikroszolgáltatással kapcsolatos probléma megoldódott, csak az érintett mikroszolgáltatást helyezheti üzembe anélkül, hogy az hatással lenne az alkalmazás többi részére.

A legújabb technológiákat használhatja. Mivel önállóan is elkezdheti a szolgáltatások fejlesztését, és egymás mellett futtathatja azokat (a tárolóknak és a .NET-nek köszönhetően), célszerűen használhatja a legújabb technológiákat és keretrendszereket, ahelyett, hogy az egész alkalmazás régebbi veremén vagy keretrendszerén ragadna.

A mikroszolgáltatás-alapú megoldások hátrányai

Az ilyen mikroszolgáltatás-alapú megoldásoknak is vannak hátrányai:

Elosztott alkalmazás. Az alkalmazás terjesztése összetettebbé teszi a fejlesztőket a szolgáltatások tervezésekor és létrehozásakor. A fejlesztőknek például szolgáltatásközi kommunikációt kell implementálniuk olyan protokollokkal, mint a HTTP vagy az AMQP, ami összetettebbé teszi a tesztelést és a kivételkezelést. Emellett késést is hozzáad a rendszerhez.

Az üzembe helyezés összetettsége. Egy több tucat mikroszolgáltatás-típussal rendelkező alkalmazásnak nagyfokú méretezhetőséget igényel (képesnek kell lennie arra, hogy sok példányt hozzon létre szolgáltatásonként, és ezek a szolgáltatások számos gazdagépen egyenletesen legyenek elosztva), ami jelentős üzembe helyezési összetettséget eredményez az IT műveletek és felügyelet számára. Ha nem mikroszolgáltatás-orientált infrastruktúrát (például vezénylőt és ütemezőt) használ, ez a további összetettség sokkal több fejlesztési erőfeszítést igényelhet, mint maga az üzleti alkalmazás.

Atomi tranzakciók. Több mikroszolgáltatás közötti atomi tranzakciók általában nem lehetségesek. Az üzleti követelményeknek több mikroszolgáltatás közötti végleges konzisztenciát kell elfogadniuk. További információkért tekintse meg az idempotens üzenetfeldolgozás kihívásait.

Nagyobb globális erőforrásigény (teljes memória, meghajtók és hálózati erőforrások az összes kiszolgálóhoz vagy gazdagéphez). Sok esetben, amikor egy monolitikus alkalmazást mikroszolgáltatás-megközelítésre cserél le, az új mikroszolgáltatás-alapú alkalmazás által igényelt kezdeti globális erőforrások mennyisége nagyobb lesz, mint az eredeti monolitikus alkalmazás infrastruktúraigénye. Ennek a megközelítésnek az az oka, hogy a nagyobb részletesség és az elosztott szolgáltatások globálisabb erőforrásokat igényelnek. Tekintettel azonban az erőforrások alacsony költségeire és annak az előnyére, hogy a monolitikus alkalmazások fejlesztésekor a hosszú távú költségekhez képest az alkalmazás bizonyos területeit felskálázhatják, az erőforrások megnövekedett felhasználása általában jó kompromisszum a nagy, hosszú távú alkalmazások számára.

Problémák a közvetlen ügyfél-mikroszerviz kommunikációval kapcsolatban. Ha az alkalmazás nagy, több tucat mikroszolgáltatással, kihívást és korlátozást jelent, ha az alkalmazás közvetlen ügyfél–mikroszolgáltatás kommunikációt igényel. Az egyik probléma az ügyfél igényei és az egyes mikroszolgáltatások által közzétett API-k közötti esetleges eltérés. Bizonyos esetekben előfordulhat, hogy az ügyfélalkalmazásnak számos külön kérést kell küldenie a felhasználói felület megírására, ami az interneten keresztül nem hatékony, és mobilhálózaton nem praktikus. Ezért az ügyfélalkalmazásból a háttérrendszerbe irányuló kérelmeket minimalizálni kell.

A közvetlen ügyfél-mikroszolgáltatások közötti kommunikáció másik problémája, hogy egyes mikroszolgáltatások olyan protokollokat használnak, amelyek nem webbarátak. Az egyik szolgáltatás használhat bináris protokollt, míg egy másik szolgáltatás AMQP-üzenetkezelést. Ezek a protokollok nem tűzfalbarátak, és belsőleg használják a legjobban. Az alkalmazásoknak általában olyan protokollokat kell használniuk, mint a HTTP és a WebSocket a tűzfalon kívüli kommunikációhoz.

Ennek a közvetlen ügyfél-szolgáltatás megközelítésnek egy másik hátránya, hogy megnehezíti az ilyen mikroszolgáltatások szerződéseinek újrabontását. Idővel előfordulhat, hogy a fejlesztők módosítani szeretnék a rendszer szolgáltatásokra való particionálásának módját. Egyesíthetnek például két szolgáltatást, vagy feloszthatnak egy szolgáltatást két vagy több szolgáltatásra. Ha azonban az ügyfelek közvetlenül kommunikálnak a szolgáltatásokkal, az ilyen típusú újrabontás megszakíthatja az ügyfélalkalmazásokkal való kompatibilitást.

Ahogy az architektúra szakaszban is említettük, egy mikroszolgáltatásokon alapuló összetett alkalmazás tervezésekor és létrehozásakor az egyszerűbb közvetlen ügyfél-mikroszolgáltatások közötti kommunikációs megközelítés helyett több finomszemcsés API Gateway használatát is fontolóra veheti.

A mikroszolgáltatások particionálása. Végül, függetlenül attól, hogy milyen megközelítést alkalmaz a mikroszolgáltatás-architektúrához, egy másik kihívás a végpontok közötti alkalmazások több mikroszolgáltatásba való particionálásának eldöntése. Ahogy az útmutató architektúra szakaszában is említettük, számos technika és megközelítés érhető el. Alapvetően meg kell határoznia az alkalmazás olyan területeit, amelyek elválasztva vannak a többi területtől, és amelyekben alacsony a kemény függőségek száma. Ez a megközelítés sok esetben használati eset alapján igazodik a particionálási szolgáltatásokhoz. Az e-shop alkalmazásban például van egy rendelési szolgáltatásunk, amely a rendelési folyamathoz kapcsolódó összes üzleti logikáért felelős. Rendelkezünk a katalógusszolgáltatással és a kosár szolgáltatással is, amely más képességeket valósít meg. Ideális esetben minden szolgáltatásnak csak kis feladatkészlettel kell rendelkeznie. Ez a megközelítés hasonló az osztályokra alkalmazott egyetlen felelősségi elvhez (SRP), amely szerint egy osztálynak csak egy oka lehet a változásra. Ebben az esetben azonban a mikroszolgáltatásokról van szó, így a hatókör nagyobb lesz, mint egy osztály. A mikroszolgáltatásoknak mindenekelőtt autonómnak kell lenniük, teljes körűnek kell lenniük, beleértve a saját adatforrásaiért való felelősséget is.

Külső és belső architektúra és tervezési minták

A külső architektúra egy több szolgáltatásból álló mikroszolgáltatás-architektúra, amely az útmutató architektúra szakaszában leírt alapelveket követi. Azonban az egyes mikroszolgáltatások jellegétől függően és a választott magas szintű mikroszolgáltatás-architektúrától függetlenül gyakori és néha ajánlott különböző belső architektúrákkal rendelkezni, amelyek különböző mintákon alapulnak a különböző mikroszolgáltatásokhoz. A mikroszolgáltatások különböző technológiákat és programozási nyelveket is használhatnak. A 6–2. ábra ezt a sokféleséget szemlélteti.

6-2. ábra. Külső és belső architektúra és tervezés

Az eShopOnContainers-mintánkban például a katalógus, a kosár és a felhasználói profil mikroszolgáltatásai egyszerűek (alapvetően CRUD-alrendszerek). Ezért a belső architektúra és a kialakítás egyszerű. Előfordulhat azonban, hogy más mikroszolgáltatásokkal is rendelkezik, például a rendelési mikroszolgáltatással, amely összetettebb, és a folyamatosan változó üzleti szabályokat képviseli, nagy fokú tartományösszetettséggel. Ilyen esetekben érdemes lehet speciálisabb mintákat implementálni egy adott mikroszolgáltatáson belül, például a tartományalapú tervezési (DDD) megközelítésekkel definiáltakat, ahogyan azt a mikroszolgáltatást rendelő eShopOnContainersben végezzük . (Ezeket a DDD-mintákat a későbbiekben tekintjük át abban a részben, amely ismerteti az eShopOnContainers rendelések mikroszolgáltatásának a megvalósítását.)

A mikroszolgáltatásonként eltérő technológia másik oka lehet az egyes mikroszolgáltatások jellege. Például jobb lehet egy olyan funkcionális programozási nyelvet használni, mint az F#, vagy akár egy olyan nyelvet, mint az R, ha AI-t és gépi tanulási tartományokat céloz meg, nem pedig egy objektumorientáltabb programozási nyelvet, például a C#-ot.

A lényeg az, hogy minden mikroszolgáltatás különböző tervezési mintákon alapuló belső architektúrával rendelkezhet. Nem minden mikroszolgáltatást kell speciális DDD-minták használatával implementálni, mert az túltervezést jelentene. Hasonlóképpen, a folyamatosan változó üzleti logikával rendelkező összetett mikroszolgáltatások nem implementálhatók CRUD-összetevőként, vagy gyenge minőségű kóddal is végződhetnek.

Az új világ: több architekturális minta és többplatformos mikroszolgáltatások

A szoftvertervezők és fejlesztők számos architektúramintát használnak. Az alábbiakban néhányat (az architektúrastílusok és az architektúraminták keveredése):

• Egyszerű CRUD, egyszintű, egyrétegű.

• Hagyományos N-rétegű.

• Domain-Driven N rétegű tervezés.

• Tiszta architektúra (az eShopOnWeb-hez hasonlóan)

• Parancs- és lekérdezési felelősség elkülönítése (CQRS).

• Event-Driven architektúra (EDA).

Számos technológiával és nyelvvel is létrehozhat mikroszolgáltatásokat, például ASP.NET Core Webes API-kat, NancyFxet, ASP.NET Core SignalR-t (.NET Core 2 vagy újabb verzióval érhető el), F#, Node.js, Python, Java, C++, GoLang stb.

A lényeg az, hogy semmilyen konkrét architektúraminta vagy stílus, sem egy adott technológia nem megfelelő minden helyzetben. A 6–3. ábra olyan megközelítéseket és technológiákat mutat be (bár nem adott sorrendben), amelyek különböző mikroszolgáltatásokban használhatók.

6-3. ábra. Több architekturális minta és a poliglott mikroszolgáltatások világa

A több architekturális minta és a többrétegű mikroszolgáltatások azt jelentik, hogy nyelveket és technológiákat keverhet és egyeztethet az egyes mikroszolgáltatások igényeivel, és továbbra is beszélhetnek egymással. A 6–3. ábrán látható módon a számos mikroszolgáltatásból álló alkalmazásokban (a tartományalapú tervezési terminológiában kötött környezetek, vagy egyszerűen "alrendszerek" autonóm mikroszolgáltatásokként) eltérő módon implementálhatja az egyes mikroszolgáltatásokat. Mindegyik különböző architektúramintával rendelkezhet, és az alkalmazás jellegétől, üzleti igényeitől és prioritásaitól függően különböző nyelveket és adatbázisokat használhat. Bizonyos esetekben a mikroszolgáltatások hasonlóak lehetnek. Ez azonban általában nem így van, mivel az egyes alrendszerek környezethatárai és követelményei általában eltérőek.

Például egy egyszerű CRUD karbantartási alkalmazás esetében nem feltétlenül érdemes DDD-mintákat tervezni és implementálni. Az alapvető tartomány vagy az alapvető üzletmenet esetében azonban előfordulhat, hogy fejlettebb mintákat kell alkalmaznia az üzleti összetettség folyamatosan változó üzleti szabályokkal való kezeléséhez.

Különösen akkor, ha több alrendszerből álló nagy alkalmazásokkal foglalkozik, nem szabad egyetlen legfelső szintű architektúrát alkalmazni egyetlen architektúramintán alapulva. A CQRS-t például nem szabad legfelső szintű architektúraként alkalmazni egy egész alkalmazáshoz, de bizonyos szolgáltatások esetében hasznos lehet.

Nincs ezüstgolyó vagy egyetlen megfelelő architektúraminta minden egyes esetre. Nem lehet "egy architektúra mintával irányítani mindet". Az egyes mikroszolgáltatások prioritásaitól függően mindegyik esetében különböző megközelítést kell választani, ahogyan azt a következő szakaszokban is kifejtjük.

ElőzőKövetkező