Mik azok a mikroszolgáltatások?

Befejeződött

A felhő vezérli a mai alkalmazásfejlesztést és informatikai rendszerek kezelését. A modern felhőalkalmazások gyorsnak, agilisnak, nagymértékben méretezhetőnek és megbízhatónak kell lenniük.

A tárolók használatával olyan alkalmazásokat helyezhet üzembe, amelyek megfelelnek az összes követelménynek. De ha egy alkalmazást egy tárolóba helyezünk anélkül, hogy követné a stratégiai tervezési mintát, olyan, mintha bejutunk egy járműbe, és abban reménykedünk, hogy térkép vagy GPS használata nélkül találjuk meg az utat egy új városhoz. Előfordulhat, hogy a célhelyen végzi, de az útvonal valószínűleg nem lesz közvetlen vagy leghatékonyabb.

Ebben a forgatókönyvben hasznos a mikroszolgáltatás-architektúra. A mikroszolgáltatások olyan megközelítést biztosítanak a szoftverfejlesztéshez és üzembe helyezéshez, amely tökéletesen megfelel a modern felhőalkalmazások rugalmasságára, méretezhetőségére és megbízhatóságára vonatkozó követelményeknek.

Mi az a mikroszolgáltatás-architektúra?

A mikroszolgáltatás-architektúrában a nagy alkalmazások kisebb szolgáltatásokra oszlanak. Minden szolgáltatás a saját folyamatában fut, és más folyamatokkal kommunikál olyan protokollokkal, mint a HTTP/HTTPS, a WebSocket vagy az Advanced Message Queuing Protocol (AMQP). Minden mikroszolgáltatás egy adott, végpontok közötti tartományt vagy üzleti képességet valósít meg egy adott környezethatáron belül. Minden mikroszolgáltatást önállóan kell fejleszteni, és egymástól függetlenül üzembe helyezhetőnek kell lenniük. Végül minden mikroszolgáltatásnak rendelkeznie kell a kapcsolódó tartományadat-modellel és a tartománylogikával. A mikroszolgáltatások különböző adattárolási technológiákon (SQL, NoSQL) és különböző programozási nyelveken alapulhatnak.

A mikroszolgáltatások néhány fő jellemzője az alábbiak:

  • Kicsik, függetlenek és lazán össze vannak állítva.
  • Minden mikroszolgáltatás külön kódbázissal rendelkezik, amelyet egy kis fejlesztői csapat kezelhet.
  • Egymástól függetlenül vannak üzembe helyezve. A csapat a teljes alkalmazás újraépítése és ismételt üzembe helyezése nélkül frissíthet egy meglévő mikroszolgáltatást.
  • Megőrzik az adataikat vagy a külső állapotukat a saját adatbázisaikban. A monolitikus architektúrától eltérően a mikroszolgáltatások nem osztanak meg adatbázisokat.
  • Jól definiált API-k használatával kommunikálnak egymással. Az egyes szolgáltatások belső megvalósítási részletei rejtve vannak a többi szolgáltatás elől.
  • Támogatják a poliglot programozást . A webalkalmazást alkotó mikroszolgáltatásoknak például nem kell ugyanazt a technológiai vermet, kódtárat vagy keretrendszert megosztaniuk.

Miért érdemes mikroszolgáltatás-architektúra használatával fejleszteni?

A mikroszolgáltatások általában egyszerűbb ügyfélkövetelmény-funkciókat foglalnak magában, amelyek vertikális felskálázhatók vagy skálázhatók. Ezeket egymástól függetlenül is tesztelheti, üzembe helyezheti és kezelheti. A mikroszolgáltatás-megközelítés egyik fontos előnye, hogy a csapatokat inkább az ügyfélforgatókönyvek vezérlik, mint egy adott technológia használatával. Minden kis fejlesztői csapat egy ügyfélforgatókönyv alapján fejleszt egy mikroszolgáltatást. A csapat az általa használt technológiákat választja ki.

A mikroszolgáltatások hosszú távú rugalmasságot biztosítanak. A mikroszolgáltatások támogatják az összetett, nagy és nagy mértékben méretezhető rendszerek karbantarthatóságát azáltal, hogy lehetővé teszik, hogy számos egymástól függetlenül üzembe helyezhető szolgáltatáson alapuló alkalmazásokat hozzon létre, amelyek mindegyike részletes és autonóm életciklussal rendelkezik.

Egy másik előny, hogy a mikroszolgáltatások egymástól függetlenül méretezhetők fel. Ahelyett, hogy egyetlen, monolitikus alkalmazással rendelkezne, amelyet egységként kell felskáláznia, inkább skálázhat ki bizonyos mikroszolgáltatásokat. Csak a nagyobb feldolgozási teljesítményt vagy hálózati sávszélességet igénylő funkcionális területet skálázhatja az igény támogatásához, ahelyett, hogy az alkalmazás más olyan területeit skálázhatja, amelyeket nem kell skálázni. Ez költségmegtakarítást jelent, mert kevesebb hardverre van szüksége.

Diagram that shows how microservices can scale across virtual machines.

A mikroszolgáltatás-megközelítés lehetővé teszi az egyes mikroszolgáltatások agilis változásait és gyors iterációját, mivel az összetett, nagy és méretezhető alkalmazások adott, kis területeit módosíthatja.

A finomszemcsés mikroszolgáltatás-alapú alkalmazások megtervezése lehetővé teszi a folyamatos integrációt és a folyamatos teljesítést. Emellett felgyorsítja az új függvények alkalmazásba való továbbítását. A mikroszolgáltatásokat önállóan futtathatja és tesztelheti, és önállóan fejlesztheti őket, miközben egyértelmű szerződéseket tart fenn a szolgáltatások között. Mindaddig, amíg nem módosítja az interfészeket vagy a szerződéseket, módosíthatja a mikroszolgáltatások belső megvalósítását, vagy új funkciókat adhat hozzá más mikroszolgáltatások feltörése nélkül.

Milyen szerepet játszanak a tárolók?

A tárolók a szoftverfejlesztés olyan megközelítései, amelyekben egy alkalmazás vagy szolgáltatás, annak függőségei és konfigurációja (az üzembehelyezési jegyzékfájlként absztrakció) tárolórendszerképként van csomagolva. A tárolóalapú alkalmazást egységként tesztelheti, és tárolórendszerkép-példányként telepítheti a gazdagép operációs rendszerén.

Ahogyan a szállítókonténerek lehetővé teszik a különféle áruk szállítását hajóval, vonattal vagy teherautóval, a szoftvertárolók a szoftvertelepítés szabványos egységeiként működnek, amelyek különböző kódokat és függőségeket tartalmazhatnak. A fejlesztők és az informatikai szakemberek tárolóalapú szoftverekkel telepíthetnek kódot és függőségeket a környezetekben, és csak kis mértékben vagy egyáltalán nem módosíthatók.

Ha úgy hangzik, mintha egy alkalmazás tárolóba helyezése nagyszerű módszer lenne a mikroszolgáltatás-architektúra mintájának implementálására, akkor az is. A tárolók használatának előnyei szinte pontosan megegyeznek a mikroszolgáltatás-architektúra előnyeivel.

Diagram that shows multiple containers running on a single host.

Feljegyzés

Az alkalmazások tárolóba helyezése nem az egyetlen módja a mikroszolgáltatások üzembe helyezésének. A mikroszolgáltatásokat egyéni szolgáltatásként is üzembe helyezheti Azure-alkalmazás Szolgáltatásban, virtuális gépeken vagy bármilyen módon. A tárolók az üzembehelyezési eszközök, amelyeket a modul további részében használunk a mikroszolgáltatásainkhoz.

A tárolók másik előnye a méretezhetőség. A rövid távú feladatokhoz használható új tárolók létrehozásával gyorsan skálázhatja a skálázást. Alkalmazás szempontjából a rendszerképek példányosítása (tároló létrehozása) hasonló egy folyamat, például egy szolgáltatás vagy webalkalmazás példányosításához.

Röviden: a tárolók az elkülönítés, a hordozhatóság, az agilitás, a méretezhetőség és a vezérlés előnyeit kínálják az alkalmazás teljes életciklus-munkafolyamatában.

A modulban buildelt mikroszolgáltatások egy Docker-tárolóban futnak, amelyet a .NET CLI használatával tesznek közzé.

.NET SDK-tároló közzététele

A .NET 7-ben a .NET SDK lehetővé tette tárolólemezképek létrehozását a dotnet publish parancson keresztül. Az ehhez szükséges eszközök számos következtetést hajtanak végre a projekt tulajdonságai és kimenetei alapján. A .NET ezután ugyanazt a képet hozza létre, amelyet egy Dockerfile létrehozna. Egy új alkalmazás létrehozása és képként való közzététele akár két parancsot is igénybe vehet:

dotnet new webapi
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

Az előző .NET CLI-parancsok létrehoznak egy új webes API-t, és tárolóként teszik közzé az alkalmazást:

  • Linux operációs rendszerként való célzás (--os linux).
  • X64-architektúra (--arch x64) megadása.
  • A kiadási konfiguráció (-c kiadás) használata.

A létrehozott tároló számos aspektusát vezérelheti az MSBuild tulajdonságokon keresztül. Általánosságban elmondható, hogy ha egy Dockerfile parancsával beállíthat néhány konfigurációt, ugyanezt megteheti az MSBuild használatával is.

Miért érdemes mikroszolgáltatásokat létrehozni a .NET-ben?

A .NET Core-tól kezdve az aktuális iterációkig a .NET-et úgy alakítottuk ki, hogy először natív felhőbeli legyen. Platformfüggetlen, így a Docker-rendszerkép a Linux egy ízén alapulhat, és a .NET-kód továbbra is fut. A Microsoft már létrehozott .NET-lemezképeket a Dockerhez. A .NET is rendkívül gyors. A ASP.NET Kestrel webkiszolgáló rutinszerűen felülmúlja a többi webkiszolgálót.

Docker

A Docker egy nyílt forráskódú platform , amellyel automatizálhatja az alkalmazások hordozható, önellátó tárolókként való üzembe helyezését, amelyek a felhőben vagy a helyszínen futtathatók. A Docker az a vállalat is, amely előlépteti és fejleszti ezt a technológiát. A Docker szervezetként együttműködik a felhő- és Linux- és Windows-szállítókkal, beleértve a Microsoftot is.

A Docker-tárolók bárhol futtathatók: a helyszínen az ügyfél adatközpontjában, egy külső szolgáltatóban vagy a felhőben. A Docker-lemezképtárolók natív módon futtathatók Linuxon és Windowson.

Mi az a kép?

Amikor egy fejlesztő a Dockert használja, létrehoz egy alkalmazást vagy szolgáltatást, majd egy tárolórendszerképbe csomagolja az alkalmazást vagy szolgáltatást és annak függőségeit. A rendszerkép az alkalmazás vagy szolgáltatás statikus ábrázolása, valamint annak konfigurációja és függőségei.

A rendszerkép a futtatáskor tárolóvá válik. A tároló egy lemezkép memóriabeli példánya.

A tárolólemezkép állandó. A rendszerkép létrehozása után a rendszerkép nem módosítható. Mivel a rendszerképek nem módosíthatók, ha módosítania kell az alkalmazást vagy szolgáltatást és annak függőségeit, hozzon létre egy új lemezképet. Ez a funkció garantálja, hogy az éles környezetben használt imageF ugyanaz a rendszerkép, amelyet a fejlesztéshez és teszteléshez használnak.

Mi a Dockerfile?

A Dockerfile egy szöveges fájl, amely útmutatást tartalmaz a Docker-rendszerképek létrehozásához. A Dockerfile-fájlok írása minimális szkriptnyelven történik, amely képek készítésére és konfigurálására szolgál. A Dockerfile-fájlok a rendszerkép létrehozásához szükséges műveleteket is dokumentálják egy alaprendszerképtől kezdve.

Az alkalmazást tartalmazó Docker-rendszerkép létrehozásához általában egy alaprendszerkép azonosításával kell kezdenie. Ezután további fájlokat és konfigurációt adhat hozzá az alaprendszerképhez. A megfelelő alapszintű lemezkép azonosításához elsőként érdemes egy olyan kész lemezképet keresni a Docker Hubon, amely már tartalmaz egy alkalmazás-keretrendszert, továbbá egy Linux-disztribúció (pl. Ubuntu vagy Alpine) összes segédprogramját és eszközét. Ha például egy tárolóba csomagolni kívánt ASP.NET alkalmazással rendelkezik, a Microsoft közzétesz egy mcr.microsoft.com/dotnet/aspnet nevű lemezképet, amely már tartalmazza a ASP.NET futtatókörnyezetet.

A rendszerképeket testre szabhatja, ha alaprendszerképet tartalmazó tárolót indít el, majd módosítja azt. A módosítások általában olyan tevékenységeket foglalnak magukban, mint a fájlok másolása a tárolóba a helyi fájlrendszerből, és különböző eszközök és segédprogramok futtatása a kód fordításához.

A Dockerfile olyan utasítások készlete, amelyek olyan Docker-rendszerképet hoznak létre, amely pontosan az alkalmazás futtatásához szükséges szoftverrel rendelkezik, beleértve magát az alkalmazást is.

1.

Az alábbi forgatókönyvek közül melyik lenne a mikroszolgáltatásra való jelöltség?

2.

Milyen rendeltetése van egy Docker-rendszerképnek a mikroszolgáltatás-architektúra mintájában?

3.

Mi a különbség a tároló és a rendszerkép között?