Azure-beli számítási lehetőség kiválasztása mikroszolgáltatásokhoz

  • Cikk

A számítás kifejezés azon számítási erőforrások futtatási modelljére utal, amelyeken az alkalmazás fut. Mikroszolgáltatás-architektúra esetén két megközelítés különösen népszerű:

  • Dedikált csomópontokon (virtuális gépeken) futó szolgáltatásokat kezelő szolgáltatásvezénylő.
  • Kiszolgáló nélküli architektúra, amely szolgáltatásfüggvényeket (FaaS) használ.

Bár nem ez az egyetlen lehetőség, mindkettő bevált módszer a mikroszolgáltatások létrehozására. Az alkalmazások mindkét módszert magukban foglalhatják.

Szolgáltatásvezénylők

A vezénylő kezeli a szolgáltatások egy csoportjának üzembe helyezésével és kezelésével kapcsolatos feladatokat. Ilyen feladat például a szolgáltatások üzembe helyezése a csomópontokon, a szolgáltatások állapotának monitorozása, a nem megfelelő állapotú szolgáltatások újraindítása, a hálózati forgalom terheléselosztása a szolgáltatáspéldányok között, szolgáltatásfelderítés, a szolgáltatáspéldányok számának skálázása és konfigurációs frissítések alkalmazása. A népszerű vezénylők közé tartozik a Kubernetes, a Service Fabric, a DC/OS és a Docker Swarm.

Az Azure platformon vegye figyelembe a következő lehetőségeket:

  • Az Azure Kubernetes Service (AKS) felügyelt Kubernetes-szolgáltatás. Az AKS üzembe helyezi a Kubernetes-t, és elérhetővé teszi a Kubernetes API-végpontokat, de üzemelteti és felügyeli a Kubernetes vezérlősíkját, elvégzi az automatikus frissítéseket, az automatikus javításokat, az automatikus skálázást és egyéb felügyeleti feladatokat. Az AKS-t "Kubernetes API-k szolgáltatásként" tekintheti.

  • Az Azure Container Apps egy Kubernetesre épülő felügyelt szolgáltatás, amely absztrahálja a tárolóvezénylés és más felügyeleti feladatok összetettségét. A Container Apps leegyszerűsíti a tárolóalapú alkalmazások és mikroszolgáltatások telepítését és felügyeletét kiszolgáló nélküli környezetben, miközben biztosítja a Kubernetes funkcióit.

  • A Service Fabric egy elosztott rendszerplatform mikroszolgáltatások csomagolására, üzembe helyezésére és kezelésére. A mikroszolgáltatások tárolókként, bináris végrehajtható fájlokként vagy Reliable Servicesként helyezhetők üzembe a Service Fabricben. A Reliable Services programozási modell használatával a szolgáltatások közvetlenül használhatják a Service Fabric programozási API-kat a rendszer lekérdezéséhez, állapotjelentéshez, konfiguráció- és kódmódosításokról szóló értesítések fogadásához, valamint más szolgáltatások felderítéséhez. A Service Fabric egyik fő különbsége az állapotalapú szolgáltatások Reliable Collections használatával történő létrehozására összpontosít.

  • Más lehetőségek, például a Docker Enterprise kiadás IaaS-környezetben is futtathatók az Azure-ban. Az üzembehelyezési sablonokat a Azure Marketplace találja.

Tárolók

Néha az emberek úgy beszélnek a tárolókról és a mikroszolgáltatásokról, mintha ugyanaz lennének. Bár ez nem igaz – nincs szükség tárolókra a mikroszolgáltatások létrehozásához – a tárolóknak vannak olyan előnyei, amelyek különösen fontosak a mikroszolgáltatások szempontjából, például:

  • Hordozhatóság. A tárolólemezképek önálló csomagok, amelyek kódtárak vagy más függőségek telepítése nélkül futnak. Ez megkönnyíti az üzembe helyezést. A tárolók gyorsan elindíthatók és leállhatók, így új példányokat indíthat el a nagyobb terhelés kezelése vagy a csomóponthibák utáni helyreállítás érdekében.

  • Sűrűség. A tárolók egyszerűek a virtuális gépek futtatásához képest, mivel operációsrendszer-erőforrásokat osztanak meg. Ez lehetővé teszi több tároló egyetlen csomópontra való csomagolását, ami különösen akkor hasznos, ha az alkalmazás sok kis szolgáltatásból áll.

  • Erőforrás-elkülönítés. Korlátozhatja a tárolók számára elérhető memória- és PROCESSZORmennyiséget, ami segít biztosítani, hogy egy elszabadult folyamat ne kimerítse a gazdagép erőforrásait. További információt a Válaszfal minta című témakörben talál.

Kiszolgáló nélküli (szolgáltatásként működő függvények)

Kiszolgáló nélküli architektúrával nem kezelheti a virtuális gépeket és a virtuális hálózati infrastruktúrát. Ehelyett kódot telepít, és az üzemeltetési szolgáltatás kezeli, hogy a kódot egy virtuális gépre helyezze és végrehajtsa. Ez a megközelítés általában az eseményalapú eseményindítókkal koordinált kis részletes függvényeket részesíti előnyben. Egy üzenetsorba helyezett üzenet például aktiválhat egy függvényt, amely beolvassa az üzenetsort, és feldolgozza az üzenetet.

Azure Functions egy kiszolgáló nélküli számítási szolgáltatás, amely különböző függvénytriggereket támogat, beleértve a HTTP-kéréseket, a Service Bus-üzenetsorokat és az Event Hubs-eseményeket. A teljes listát az eseményindítók és kötések fogalmainak Azure Functions című témakörben találja. Érdemes lehet Azure Event Grid is, amely egy felügyelt esemény-útválasztási szolgáltatás az Azure-ban.

Vezénylő vagy kiszolgáló nélküli?

Íme néhány tényező, amelyet érdemes figyelembe venni a vezénylői és a kiszolgáló nélküli megközelítés közötti választáskor.

Kezelhetőség A kiszolgáló nélküli alkalmazások könnyen kezelhetők, mivel a platform az összes számítási erőforrást kezeli. Bár a vezénylő elvonja a fürtök kezelésének és konfigurálásának néhány aspektusát, nem rejti el teljesen a mögöttes virtuális gépeket. A vezénylővel olyan problémákra kell gondolnia, mint a terheléselosztás, a processzor- és memóriahasználat, valamint a hálózatkezelés.

Rugalmasság és szabályozás. A vezénylők nagy mértékben szabályozhatják a szolgáltatások és a fürt konfigurálását és kezelését. A kompromisszum további összetettség. A kiszolgáló nélküli architektúra bizonyos fokú vezérlést ad meg, mert ezek a részletek absztrakciósak.

Hordozhatóság. Az itt felsorolt vezénylők (Kubernetes, DC/OS, Docker Swarm és Service Fabric) a helyszínen vagy több nyilvános felhőben is futtathatók.

Alkalmazásintegráció. Bonyolult lehet egy összetett alkalmazás létrehozása kiszolgáló nélküli architektúrával, mivel számos kis független függvény koordinálására, üzembe helyezésére és kezelésére van szükség. Az Azure-ban az egyik lehetőség az, hogy az Azure Logic Apps használatával koordinálja a Azure Functions halmazát. Erre a megközelítésre példa: Az Azure Logic Appsszel integrálható függvény létrehozása.

Költség. Egy vezénylővel a fürtön futó virtuális gépekért kell fizetnie. Kiszolgáló nélküli alkalmazás esetén csak a ténylegesen felhasznált számítási erőforrásokért kell fizetnie. Mindkét esetben figyelembe kell vennie a további szolgáltatások, például a tárolás, az adatbázisok és az üzenetkezelési szolgáltatások költségeit.

Skálázhatóság. Azure Functions a bejövő események száma alapján automatikusan méretezhető az igényeknek megfelelően. Egy vezénylővel vertikálisan felskálázhatja a fürtön futó szolgáltatáspéldányok számát. A méretezéshez további virtuális gépeket is hozzáadhat a fürthöz.

A referencia-implementáció elsősorban a Kubernetes-t használja, de Azure Functions egy szolgáltatáshoz, nevezetesen a Kézbesítési előzmények szolgáltatáshoz. Azure Functions jó választás volt ehhez a szolgáltatáshoz, mivel eseményvezérelt számítási feladat. Egy Event Hubs-eseményindító használatával meghívta a függvényt, a szolgáltatásnak minimális mennyiségű kódra volt szüksége. Emellett a Kézbesítési előzmények szolgáltatás nem része a fő munkafolyamatnak, így a Kubernetes-fürtön kívül történő futtatása nincs hatással a felhasználó által kezdeményezett műveletek végpontok közötti késésére.

Következő lépések

Szolgáltatások közötti kommunikáció