Miért érdemes mikroszolgáltatás-megközelítést használni az alkalmazások létrehozásához?

A szoftverfejlesztők számára nem újdonság, ha az alkalmazást összetevő részekre kell felvenni. A rétegzett megközelítés általában háttértárral, középső szintű üzleti logikával és kezelőfelülettel (UI) rendelkezik. Az elmúlt néhány évben megváltozott, hogy a fejlesztők elosztott alkalmazásokat készítenek a felhőhöz.

Íme néhány változó üzleti igény:

  • Olyan szolgáltatás, amely nagy léptékben készült és működik, hogy új földrajzi régiókban lévő ügyfelekhez jusson el.
  • A szolgáltatások és képességek gyorsabb rendelkezésre állása az ügyfelek igényeinek rugalmas kielégítéséhez.
  • Továbbfejlesztett erőforrás-használat a költségek csökkentése érdekében.

Ezek az üzleti igények befolyásolják az alkalmazások készítésének módját .

További információ a mikroszolgáltatások Azure-beli megközelítéséről : Mikroszolgáltatások: Felhőn alapuló alkalmazásforradalom.

Monolitikus és mikroszolgáltatások tervezési megközelítése

Az alkalmazások idővel fejlődnek. A sikeres alkalmazások úgy fejlődnek, hogy hasznosak a felhasználóknak. A sikertelen alkalmazások nem fejlődnek, és idővel elavultak lesznek. Íme a kérdés: mennyit tud ma a követelményekről, és mit fognak ezek a jövőben? Tegyük fel például, hogy egy jelentéskészítő alkalmazást készít a vállalat egyik részlegéhez. Biztos benne, hogy az alkalmazás csak a vállalat hatókörén belül érvényes, és hogy a jelentések nem lesznek hosszúak. Az Ön megközelítése eltér attól, mint például egy olyan szolgáltatás létrehozása, amely több tíz millió ügyfélnek nyújt videótartalmat.

Néha az, hogy valamit kihozunk az ajtón mint megvalósíthatósági igazolást, az a fő tényező. Tudja, hogy az alkalmazás később újratervezhető. Kevés értelme van a túltervezésnek, amit soha nem használnak fel. Ezzel szemben, amikor a vállalatok felhőre építenek, a növekedés és a használat várható. A növekedés és a méret kiszámíthatatlan. Szeretnénk gyorsan prototípust készíteni, miközben tudjuk, hogy olyan úton járunk, amely képes kezelni a jövőbeli sikereket. Ez a lean indítási megközelítés: buildelés, mérés, tanulás és iterálás.

Az ügyfél/kiszolgáló korszakában a rétegzett alkalmazások létrehozására összpontosítottunk az egyes rétegekben meghatározott technológiák használatával. A monolitikus alkalmazás kifejezése megjelent ezen megközelítések leírására. Az interfészek a rétegek között készültek, és az egyes szinteken belüli összetevők között szorosabban összekapcsolt kialakítást használtak. A fejlesztők olyan osztályokat terveztek és faktoráltak, amelyeket kódtárakba állítottak össze, és néhány végrehajtható fájlba és DLL-be kapcsoltak össze.

A monolitikus tervezési megközelítésnek vannak előnyei. A monolitikus alkalmazások tervezése gyakran egyszerűbb, az összetevők közötti hívások pedig gyorsabbak, mivel ezek a hívások gyakran folyamatközi kommunikáción (IPC) keresztül vannak. Emellett mindenki egyetlen terméket tesztel, amely általában az emberi erőforrások hatékonyabb felhasználása. A hátránya az, hogy szoros kapcsolat van a rétegzett rétegek között, és az egyes összetevők nem skálázhatók. Ha javításokat vagy frissítéseket kell végeznie, meg kell várnia, amíg mások befejezik a tesztelést. Nehezebb agilisnak lenni.

A mikroszolgáltatások kezelik ezeket a hátrányokat, és jobban összhangban vannak az előző üzleti követelményekkel. Ugyanakkor előnyökkel és kötelezettségekkel is rendelkeznek. A mikroszolgáltatások előnye, hogy ezek általában egyszerűbb üzleti funkciókat foglalnak magában, amelyeket egymástól függetlenül lehet fel- vagy leskálázni, tesztelni, üzembe helyezni és kezelni. A mikroszolgáltatás-megközelítés egyik fontos előnye, hogy a csapatokat jobban üzleti forgatókönyvek vezérlik, mint a technológia. Egy mikroszolgáltatást kisebb csapatok fejlesztenek az ügyfél igényei szerint, tetszőleges technológiával.

Más szóval a szervezetnek nem kell szabványosítania a technológiát a mikroszolgáltatási alkalmazások karbantartásához. A saját szolgáltatásokkal rendelkező csapatok a csapat szakértelmén vagy a probléma megoldásához legmegfelelőbb megoldáson alapulva tehetik meg a számukra megfelelőt. A gyakorlatban az ajánlott technológiák, például egy adott NoSQL-tároló vagy webalkalmazás-keretrendszer használata előnyösebb.

A mikroszolgáltatások hátránya, hogy több különálló entitást kell kezelnie, és összetettebb üzembe helyezéseket és verziószámozást kell kezelnie. A mikroszolgáltatások közötti hálózati forgalom nő, ahogy a megfelelő hálózati késések is. Sok forgalmas, részletes szolgáltatás okozhat teljesítmény rémálom. A függőségek megtekintését segítő eszközök nélkül nehéz a teljes rendszert látni.

A szabványok lehetővé teszik a mikroszolgáltatások megközelítését azáltal, hogy megadja, hogyan kommunikálhat, és csak a szükséges dolgokat tolerálhatja egy szolgáltatásból, nem pedig merev szerződéseket. Fontos, hogy ezeket a szerződéseket előre definiálja a tervben, mert a szolgáltatások egymástól függetlenül frissülnek. A mikroszolgáltatás-megközelítéssel történő tervezés egy másik leírása a "részletes szolgáltatásorientált architektúra (SOA).

A mikroszolgáltatások tervezési megközelítése a legegyszerűbben a szolgáltatások leválasztott összevonásáról szól, amely független módosításokat hajt végre az egyes és elfogadott kommunikációs szabványokon.

Ahogy egyre több felhőalkalmazás készül, a felhasználók felfedezték, hogy a teljes alkalmazás független, forgatókönyv-központú szolgáltatásokra való felbontása jobb hosszú távú megközelítés.

Alkalmazásfejlesztési megközelítések összehasonlítása

Service Fabric platform application development

  1. A monolitikus alkalmazások tartományspecifikus funkciókat tartalmaznak, és általában funkcionális rétegekre, például webes, üzleti és adatrétegekre vannak felosztva.

  2. Egy monolitikus alkalmazást több kiszolgálón/virtuális gépen/tárolón klónozva skálázhat.

  3. A mikroszolgáltatási alkalmazások a funkciókat különálló, kisebb szolgáltatásokra bontják.

  4. A mikroszolgáltatások megközelítése az egyes szolgáltatások egymástól függetlenül történő üzembe helyezésével skálázható fel, és ezen szolgáltatások példányait kiszolgálók/virtuális gépek/tárolók között hozza létre.

A mikroszolgáltatás-alapú tervezés nem minden projekthez megfelelő, de jobban igazodik a korábban ismertetett üzleti célkitűzésekhez. A monolitikus megközelítéstől kezdve érdemes lehet, ha tudja, hogy később lehetősége lesz átdolgozni a kódot egy mikroszolgáltatás-kialakításra. Általában monolitikus alkalmazással kezdünk, és fokozatosan bontjuk fel, kezdve azokkal a funkcionális területekkel, amelyeknek méretezhetőbbnek vagy rugalmasabbnak kell lenniük.

Mikroszolgáltatás-megközelítés használata esetén számos kisebb szolgáltatás alkalmazását fogja összeállítani. Ezek a szolgáltatások olyan tárolókban futnak, amelyek egy gépfürtön vannak üzembe helyezve. A kisebb csapatok olyan szolgáltatást fejlesztenek, amely egy adott forgatókönyvre összpontosít, és egymástól függetlenül tesztelik, verziózzák, üzembe helyezik és skálázzák az egyes szolgáltatásokat, hogy a teljes alkalmazás fejlődjön.

Mik azok a mikroszolgáltatások?

A mikroszolgáltatásoknak különböző definíciói vannak. A mikroszolgáltatások ezen jellemzőinek többsége azonban széles körben elfogadott:

  • Egy ügyfél vagy üzleti forgatókönyv beágyazása. Milyen problémát old meg?
  • Egy kis mérnöki csapat fejlesztette ki.
  • Bármilyen programozási nyelven, bármilyen keretrendszerrel megírva.
  • Kódból és opcionálisan állapotból áll, amelyek mindegyike független verziószámozott, üzembe helyezhető és skálázható.
  • Más mikroszolgáltatásokkal is kommunikálhat jól meghatározott felületeken és protokollokon keresztül.
  • Egyedi névvel (URL-címekkel) rendelkezik, amelyek a helyük feloldására szolgálnak.
  • Hibák esetén konzisztens és elérhető marad.

Összegezve:

A mikroszolgáltatás-alapú alkalmazások kis méretű, egymásétól független verziójú és skálázható, ügyfélközpontú szolgáltatásokból állnak, amelyek szabványos protokollokkal, jól definiált interfészeken keresztül kommunikálnak egymással.

Bármilyen programozási nyelven, bármilyen keretrendszer használatával megírva

Fejlesztőkként szeretnénk szabadon kiválasztani egy nyelvet vagy keretrendszert a képességeinktől és a létrehozandó szolgáltatás igényeitől függően. Egyes szolgáltatások esetében a C++ teljesítménybeli előnyeit minden másnál magasabbra értékelheti. Mások számára a C# vagy a Java által kapott egyszerű felügyelt fejlesztés fontosabb lehet. Bizonyos esetekben előfordulhat, hogy egy adott partnerkódtárat, adattárolási technológiát vagy módszert kell használnia a szolgáltatás ügyfelek számára történő felfedéséhez.

A technológia kiválasztása után figyelembe kell vennie a szolgáltatás működési vagy életciklus-felügyeletét és skálázását.

Lehetővé teszi a kód és az állapot független verziószámzását, üzembe helyezését és skálázását

Függetlenül attól, hogy hogyan írja meg a mikroszolgáltatásokat, a kódnak és opcionálisan az állapotnak egymástól függetlenül kell üzembe helyeznie, frissítenie és méreteznie. Ezt a problémát nehéz megoldani, mert az Ön által választott technológiákon múlik. A skálázáshoz a kód és az állapot particionálásának (vagy horizontális particionálásának) megértése kihívást jelent. Ha a kód és az állapot különböző technológiákat használ, ami manapság gyakori, a mikroszolgáltatás üzembehelyezési szkriptjeinek mindkettőt skálázniuk kell. Ez az elkülönítés az agilitásról és a rugalmasságról is szól, így a mikroszolgáltatások némelyikét anélkül frissítheti, hogy egyszerre kellene mindegyiket frissítenie.

Térjünk vissza a monolitikus és mikroszolgáltatási megközelítések összehasonlításához egy pillanatra. Ez az ábra az állapottárolási megközelítések közötti különbségeket mutatja be:

Állapottárolás a két megközelítéshez

Service Fabric platform state storage

A monolitikus megközelítés a bal oldalon egyetlen adatbázissal és meghatározott technológiák rétegével rendelkezik.

A jobb oldali mikroszolgáltatás-megközelítés egy összekapcsolt mikroszolgáltatások diagramját ábrázolja, ahol az állapot jellemzően a mikroszolgáltatásra terjed ki, és különböző technológiákat használnak.

Monolitikus megközelítésben az alkalmazás általában egyetlen adatbázist használ. Egy adatbázis használatának előnye, hogy egyetlen helyen található, ami megkönnyíti az üzembe helyezést. Minden összetevőnek egyetlen táblája lehet az állapotának tárolására. A csapatoknak szigorúan el kell különíteni az állapotot, ami kihívást jelent. Elkerülhetetlen, hogy valaki egy meglévő ügyféltáblához adjon hozzá egy oszlopot, összekapcsoljon a táblák között, és függőségeket hozzon létre a tárolási rétegben. Miután ez megtörtént, nem lehet skálázni az egyes összetevőket.

A mikroszolgáltatás-megközelítésben minden szolgáltatás kezeli és tárolja a saját állapotát. Minden szolgáltatás felelős azért, hogy a kódot és az állapotot együtt skálázhassa a szolgáltatás igényeinek megfelelően. Hátránya, hogy ha az alkalmazás adataiból nézeteket vagy lekérdezéseket kell létrehoznia, több állapottárolóban kell lekérdezést elvégeznie. Ezt a problémát általában egy külön mikroszolgáltatás oldja meg, amely több mikroszolgáltatásra kiterjedő nézetet hoz létre. Ha több rögtönzött lekérdezést kell futtatnia az adatokon, fontolja meg az egyes mikroszolgáltatások adatainak írását egy adattárház-szolgáltatásba offline elemzés céljából.

A mikroszolgáltatások verziószámozottak. Előfordulhat, hogy egy mikroszolgáltatás különböző verziói egymás mellett futnak. Egy mikroszolgáltatás újabb verziója meghiúsulhat a frissítés során, ezért vissza kell állítani egy korábbi verzióra. A verziószámozás az A/B-teszteléshez is hasznos, ahol a különböző felhasználók a szolgáltatás különböző verzióit használják. Gyakori például, hogy egy adott ügyfélcsoport számára frissít egy mikroszolgáltatást, hogy tesztelje az új funkciókat, mielőtt szélesebb körben elérhetővé teszi azt.

Más mikroszolgáltatásokkal kommunikál jól definiált felületeken és protokollokon keresztül

Az elmúlt 10 évben széles körű információk jelentek meg a szolgáltatásorientált architektúrák kommunikációs mintáiról. A szolgáltatáskommunikáció általában REST-megközelítést használ HTTP- és TCP-protokollokkal, szerializálási formátumként pedig XML vagy JSON protokollt. A felület szempontjából a webes tervezési megközelítésről van szó. De semmi sem akadályozhatja meg a bináris protokollok vagy a saját adatformátumok használatát. Vegye figyelembe, hogy a felhasználók nehezebben fogják használni a mikroszolgáltatásokat, ha ezek a protokollok és formátumok nem érhetők el nyíltan.

Egyedi névvel (URL-cím) rendelkezik a hely feloldásához

A mikroszolgáltatásnak mindenhol címezhetőnek kell lennie, ahol fut. Ha gépekre gondol, és melyik futtat egy adott mikroszolgáltatást, a dolgok gyorsan elromolhatnak.

Ugyanúgy, ahogyan a DNS felold egy adott URL-címet egy adott gépre, a mikroszolgáltatásnak egyedi névre van szüksége, hogy az aktuális helye felderíthető legyen. A mikroszolgáltatásoknak olyan címezhető nevekre van szükségük, amelyek függetlenek az általuk futtatott infrastruktúrától. Ez azt jelenti, hogy interakció van a szolgáltatás üzembe helyezése és a felderítése között, mivel szükség van egy szolgáltatásregisztrációs adatbázisra. Ha egy gép meghibásodik, a beállításjegyzék-szolgáltatásnak meg kell adnia, hogy hová helyezték át a szolgáltatást.

Továbbra is konzisztens és elérhető hibák esetén

A váratlan hibák kezelése az egyik legnehezebb megoldandó probléma, különösen az elosztott rendszerekben. A fejlesztőkként írt kód nagy része a kivételek kezelésére szolgál. A tesztelés során a legtöbb időt a kivételkezeléssel is töltjük. A folyamat nagyobb szerepet játszik, mint a hibák kezelésére vonatkozó kód írása. Mi történik, ha a mikroszolgáltatást futtató gép meghibásodik? Észlelnie kell a hibát, ami önmagában nehéz probléma. De újra kell indítania a mikroszolgáltatást is.

A rendelkezésre állás érdekében a mikroszolgáltatásoknak ellenállónak kell lenniük a hibáknak, és újra kell tudniuk indulni egy másik gépen. A rugalmassági követelmények mellett az adatok nem vesznek el, és az adatoknak konzisztensnek kell maradniuk.

A rugalmasság nehezen érhető el, ha hibák történnek egy alkalmazásfrissítés során. Az üzembe helyezési rendszerrel dolgozó mikroszolgáltatásnak nem kell helyreállítania. Meg kell határoznia, hogy továbbléphet-e az újabb verzióra, vagy visszaállhat-e egy korábbi verzióra a konzisztens állapot fenntartása érdekében. Meg kell fontolnia néhány kérdést, például azt, hogy elegendő gép áll-e rendelkezésre a továbblépéshez, és hogyan állíthatja helyre a mikroszolgáltatás korábbi verzióit. A döntések meghozatalához szükség van a mikroszolgáltatásra az állapotinformációk kibocsátásához.

Állapotjelentések és diagnosztikák

Nyilvánvalónak tűnhet, és gyakran figyelmen kívül hagyják, de egy mikroszolgáltatásnak jelentenie kell az állapotát és a diagnosztikát. Ellenkező esetben a művelet szempontjából kevés betekintést nyerhet az állapotába. A diagnosztikai események független szolgáltatások halmaza közötti korrelációja, valamint a gépi óraeltérések kezelése az eseménysorrend értelmezéséhez kihívást jelent. Ugyanúgy, ahogyan egy mikroszolgáltatással kommunikál az elfogadott protokollokkal és adatformátumokkal, szabványosítania kell az állapot- és diagnosztikai események naplózásának módját, amelyek végül egy eseménytárba kerülnek lekérdezéshez és megtekintéshez. Mikroszolgáltatás-megközelítéssel a különböző csapatoknak egyetlen naplózási formátumot kell elfogadniuk. Konzisztens megközelítésre van szükség az alkalmazás diagnosztikai eseményeinek teljes megtekintéséhez.

Az állapot eltér a diagnosztikától. Az állapot a mikroszolgáltatás aktuális állapotát jelenti a megfelelő műveletek elvégzéséhez. Jó példa a rendelkezésre állás fenntartására szolgáló frissítési és üzembehelyezési mechanizmusok használata. Bár előfordulhat, hogy egy szolgáltatás egy folyamat összeomlása vagy a gép újraindítása miatt jelenleg nem megfelelő állapotban van, a szolgáltatás továbbra is működőképes lehet. Az utolsó dolog, amire szüksége van, hogy rosszabbá tegye a helyzetet egy frissítés elindításával. A legjobb módszer az, ha először megvizsgálja a mikroszolgáltatást, vagy időt hagy a helyreállításra. A mikroszolgáltatásokból származó egészségügyi események segítenek megalapozott döntéseket hozni, és tulajdonképpen önjavító szolgáltatásokat létrehozni.

Útmutató mikroszolgáltatások tervezéséhez az Azure-ban

Az Azure-beli mikroszolgáltatások tervezésével és létrehozásával kapcsolatos útmutatásért látogasson el az Azure architektúraközpontjába.

Service Fabric mint mikroszolgáltatási platform

Az Azure Service Fabric akkor jelent meg, amikor a Microsoft a dobozos, jellemzően monolitikus termékekről a szolgáltatások nyújtására váltott. A nagy méretű szolgáltatások, például az Azure SQL Database és az Azure Cosmos DB felépítésének és működtetésének tapasztalata, a Service Fabric. A platform idővel tovább fejlődött, ahogy egyre több szolgáltatás fogadta el. A Service Fabricnek nem csak az Azure-ban, hanem különálló Windows Server-környezetekben is futnia kellett.

A Service Fabric célja a szolgáltatások létrehozásának és futtatásának nehéz problémáinak megoldása, valamint az infrastruktúra-erőforrások hatékony használata, hogy a csapatok mikroszolgáltatás-megközelítéssel oldhassák meg az üzleti problémákat.

A Service Fabric segítségével mikroszolgáltatás-megközelítést használó alkalmazásokat hozhat létre a következők megadásával:

  • Olyan platform, amely rendszerszolgáltatásokat nyújt a sikertelen szolgáltatások üzembe helyezéséhez, frissítéséhez, észleléséhez és újraindításához, szolgáltatások felderítéséhez, üzenetek átirányításához, állapotkezeléshez és állapotfigyeléséhez.
  • Tárolókban vagy folyamatokként futó alkalmazások üzembe helyezésének képessége. A Service Fabric egy tároló- és folyamatvezénylő.
  • Hatékony programozási API-k, amelyekkel mikroszolgáltatásként hozhat létre alkalmazásokat: ASP.NET Core, Reliable Actors és Reliable Services. Kaphat például állapot- és diagnosztikai adatokat, vagy kihasználhatja a beépített magas rendelkezésre állást.

A Service Fabric nem egyszerű a szolgáltatás felépítésével kapcsolatban, és bármilyen technológiát használhat. De olyan beépített programozási API-kat is biztosít, amelyek megkönnyítik a mikroszolgáltatások létrehozását.

Meglévő alkalmazások migrálása a Service Fabricbe

A Service Fabric segítségével újra felhasználhatja a meglévő kódot, és új mikroszolgáltatásokkal modernizálhatja azt. Az alkalmazás modernizálásának öt fázisa van, és bármelyik szakaszban elindíthatja és leállíthatja azt. A szakaszok a következők:

  1. Kezdje egy hagyományos monolitikus alkalmazással.
  2. Áttelepítése. Tárolók vagy vendég végrehajtható fájlok használata meglévő kód futtatásához a Service Fabricben.
  3. Modernizálják. Adjon hozzá új mikroszolgáltatásokat a meglévő tárolóalapú kóddal együtt.
  4. Innovációra. Szükség szerint bontsa mikroszolgáltatásokra a monolitikus alkalmazást.
  5. Alkalmazások átalakítása mikroszolgáltatásokká. Meglévő monolitikus alkalmazások átalakítása vagy új zöldmezős alkalmazások létrehozása.

Migration to microservices

Ne feledje, hogy bármelyik szakaszban elkezdheti és leállíthatja a pontokat. Nem kell továbblépnie a következő szakaszra.

Tekintsünk meg példákat ezekre a szakaszokra.

Migrate
Két okból sok vállalat a meglévő monolitikus alkalmazásokat tárolókba migrálja:

  • Költségcsökkentés a meglévő hardverek konszolidálása és eltávolítása, vagy az alkalmazások nagyobb sűrűségű futtatása miatt.
  • Konzisztens üzembehelyezési szerződés a fejlesztés és a műveletek között.

A költségcsökkentések egyszerűek. A Microsoftnál számos meglévő alkalmazást tárolóba rendeznek, ami több millió dolláros megtakarítást eredményez. A konzisztens üzembe helyezést nehezebb kiértékelni, de ugyanilyen fontos. Ez azt jelenti, hogy a fejlesztők kiválaszthatják a számukra megfelelő technológiákat, de a műveletek csak egyetlen módszert fogadnak el az alkalmazások üzembe helyezéséhez és kezeléséhez. Ez enyhíti a műveleteket attól, hogy a különböző technológiák támogatásának összetettségével kell foglalkoznia anélkül, hogy a fejlesztőknek csak bizonyos technológiák kiválasztására kellene kényszeríteniük őket. Lényegében minden alkalmazás önálló üzembehelyezési rendszerképekbe van tárolóba helyezve.

Sok szervezet áll meg itt. Már megvannak a tárolók előnyei, és a Service Fabric biztosítja a teljes felügyeleti élményt, beleértve az üzembe helyezést, a frissítéseket, a verziószámozást, a visszaállításokat és az állapotfigyelést.

Modernizálják
A modernizálás az új szolgáltatások hozzáadása a meglévő tárolóalapú kóddal együtt. Ha új kódot szeretne írni, a legjobb, ha kis lépéseket tesz a mikroszolgáltatások útvonalán. Ez új REST API-végpont vagy új üzleti logika hozzáadását jelentheti. Ily módon megkezdheti az új mikroszolgáltatások létrehozásának folyamatát, és gyakorolhatja azok fejlesztését és üzembe helyezését.

Újítás
A mikroszolgáltatás-megközelítés alkalmazkodik a változó üzleti igényekhez. Ebben a szakaszban el kell döntenie, hogy megkezdi-e a monolitikus alkalmazás szolgáltatásokra való felosztását vagy az innovációt. A klasszikus példa az, amikor egy munkafolyamat-üzenetsorként használt adatbázis feldolgozási szűk keresztmetszetté válik. A munkafolyamat-kérelmek számának növekedésével a munkát el kell osztani skálázásra. Vegye fel az alkalmazásnak azt a részét, amely nem skálázható, vagy amelyet gyakrabban kell frissíteni, majd ossza fel mikroszolgáltatásként és innovációként.

Alkalmazások átalakítása mikroszolgáltatásokká
Ebben a szakaszban az alkalmazás teljes mértékben mikroszolgáltatásokból áll (vagy ezekre van felosztva). Ehhez a ponthoz a mikroszolgáltatásokon kell áttérnie. Itt kezdheti, de ehhez mikroszolgáltatás-platform nélkül kell segítenie, hogy jelentős befektetést igényeljen.

Megfelelőek a mikroszolgáltatások az alkalmazásomhoz?

Esetleg. A Microsoftnál, mivel üzleti okokból egyre több csapat kezdett felhőt létrehozni, sokan felismerték a mikroszolgáltatás-szerű megközelítés előnyeit. A Bing például évek óta használ mikroszolgáltatásokat. Más csapatok esetében a mikroszolgáltatás-alapú megközelítés új volt. A csapatok úgy találták, hogy nehéz problémákat kell megoldaniuk a fő erőterületeken kívül. Ezért nyerte el a Service Fabric a szolgáltatások építésének technológiájaként a vontatást.

A Service Fabric célja, hogy csökkentse a mikroszolgáltatás-alkalmazások készítésének összetettségét, hogy ne kelljen annyi költséges újratervezésen átesnie. Kezdjen kicsiben, igény szerint skálázza, elavulttá teszi a szolgáltatásokat, adjon hozzá újakat, és fejlődjön az ügyfélhasználattal. Azt is tudjuk, hogy sok más problémát még meg kell oldani, hogy a mikroszolgáltatások könnyebben kezelhetők legyenek a legtöbb fejlesztő számára. A tárolók és az aktor programozási modellje az adott irányba tett kis lépések példái. Biztosak vagyunk abban, hogy a mikroszolgáltatás-megközelítés megkönnyítése érdekében további újítások jelennek meg.

Következő lépések