Szerkesztés

Kiszolgáló nélküli webalkalmazás

Microsoft Entra ID
Azure API Management
Azure Blob Storage
Azure Content Delivery Network
Azure Functions
Azure Monitor

Ez a referenciaarchitektúra egy kiszolgáló nélküli webalkalmazást jelenít meg. Az alkalmazás statikus tartalmakat szolgál ki az Azure Blob Storage-ból, és implementál egy API-t az Azure Functions használatával. Az API adatokat olvas be az Azure Cosmos DB-ből, és visszaadja az eredményeket a webalkalmazásnak.

GitHub-embléma Az architektúra két referencia-implementációja érhető el a GitHubon: Drone Delivery App (ARM & Azure Pipelines) és To Do App (Bicep &GitHub Actions).

Architektúra

Egy kiszolgáló nélküli webalkalmazás referenciaarchitektúrájának ábrája.

Töltse le az architektúra Visio-fájlját.

A kiszolgáló nélküli kifejezés két különböző, de egymáshoz kapcsolódó jelentéssel rendelkezik:

  • Háttérszolgáltatás (BaaS). A háttérbeli felhőszolgáltatások, például az adatbázisok és a tárolók olyan API-kat biztosítanak, amelyek lehetővé teszik az ügyfélalkalmazások számára, hogy közvetlenül ezekhez a szolgáltatásokhoz csatlakozzanak.
  • Szolgáltatásként (FaaS) működik. Ebben a modellben a "függvény" egy kódrészlet, amely a felhőben van üzembe helyezve, és egy olyan üzemeltetési környezetben fut, amely teljesen absztrakciót biztosít a kódot futtató kiszolgálókon.

Mindkét definíció közös elképzelése, hogy a fejlesztőknek és a DevOps személyzetének nem kell kiszolgálókat telepítenie, konfigurálnia vagy kezelnie. Ez a referenciaarchitektúra a FaaS-ra összpontosít az Azure Functions használatával, bár az Azure Blob Storage-ból származó webes tartalmak kiszolgálása példa lehet a BaaS-ra. A FaaS néhány fontos jellemzője:

  1. A számítási erőforrásokat a platform szükség szerint dinamikusan foglalja le.
  2. Használatalapú díjszabás: Csak a kód végrehajtásához használt számítási erőforrásokért kell fizetnie.
  3. A számítási erőforrások igény szerint skálázhatók a forgalom alapján, anélkül, hogy a fejlesztőnek bármilyen konfigurációt kellene elvégeznie.

A függvények végrehajtása külső eseményindító esetén történik, például HTTP-kérés vagy üzenetsorra érkező üzenet esetén. Ez természetessé teszi az eseményvezérelt architektúrastílust a kiszolgáló nélküli architektúrák esetében. Az architektúra összetevői közötti munka összehangolásához érdemes lehet üzenetközvetítőket vagy pub/almintákat használni. Ha segítségre van szüksége az Azure üzenetkezelési technológiái közötti választáshoz, tekintse meg az üzeneteket kézbesítő Azure-szolgáltatások kiválasztása című témakört.

Összetevők

Az architektúra az alábbi összetevőkből áll:

Blob Storage. A statikus webes tartalmak, például HTML-, CSS- és JavaScript-fájlok az Azure Blob Storage-ban vannak tárolva, és statikus webhely-üzemeltetéssel szolgálnak ki az ügyfeleknek. Minden dinamikus interakció JavaScript-kódon keresztül történik, amely hívásokat indít a háttér API-k felé. A weblap megjelenítéséhez nincs kiszolgálóoldali kód. A statikus webhely üzemeltetése támogatja az indexdokumentumokat és az egyéni 404 hibaoldalakat.

CDN. Az Azure Content Delivery Network (CDN) használatával gyorsítótárazhatja a tartalmakat az alacsonyabb késés és a tartalom gyorsabb kézbesítése érdekében, valamint HTTPS-végpontot biztosít.

Függvényalkalmazások. Az Azure Functions egy kiszolgáló nélküli számítási lehetőség. Eseményvezérelt modellt használ, amelyben egy kódrészletet (egy "függvényt") hív meg egy eseményindító. Ebben az architektúrában a függvény akkor lesz meghívva, amikor egy ügyfél HTTP-kérelmet küld. A kérés mindig egy API-átjárón keresztül lesz irányítva, az alábbiakban leírtak szerint.

API Management. Az Azure API Management egy API-átjárót biztosít, amely a HTTP-függvény előtt helyezkedik el. Az API Management használatával közzéteheti és kezelheti az ügyfélalkalmazások által használt API-kat. Az átjáró használata segít leválasztani az előtér-alkalmazást a háttér API-król. Az API Management például átírhatja az URL-címeket, átalakíthatja a kéréseket a háttérrendszer elérése előtt, beállíthatja a kérések vagy válaszfejléceket stb.

Az API Management olyan átfogó szempontok megvalósítására is használható, mint például:

  • Használati kvóták és díjkorlátok kikényszerítése
  • OAuth-jogkivonatok érvényesítése hitelesítéshez
  • Forrásközi kérelmek engedélyezése (CORS)
  • Válaszok gyorsítótárazása
  • Monitorozási és naplózási kérelmek

Ha nincs szüksége az API Management által biztosított összes funkcióra, egy másik lehetőség a Functions Proxyk használata. Az Azure Functions ezen funkciója lehetővé teszi egyetlen API-felület definiálását több függvényalkalmazáshoz úgy, hogy útvonalakat hoz létre a háttérfüggvényekhez. A függvény-proxyk korlátozott átalakításokat is végrehajthatnak a HTTP-kéréseken és -válaszokon. Az API Management azonban nem biztosítja ugyanazokat a gazdag, szabályzatalapú képességeket.

Azure Cosmos DB. Az Azure Cosmos DB egy többmodelles adatbázis-szolgáltatás. Ebben a forgatókönyvben a függvényalkalmazás lekéri a dokumentumokat az Azure Cosmos DB-ből az ügyfél HTTP GET-kérelmeire válaszul.

Microsoft Entra ID (Microsoft Entra ID). A felhasználók a Microsoft Entra-azonosítójuk hitelesítő adataival jelentkeznek be a webalkalmazásba. A Microsoft Entra ID egy hozzáférési jogkivonatot ad vissza az API-hoz, amelyet a webalkalmazás az API-kérések hitelesítésére használ (lásd : Hitelesítés).

Azure Monitor. Az Azure Monitor a megoldásban üzembe helyezett Azure-szolgáltatások teljesítménymetrikáit gyűjti. Ha ezeket egy irányítópulton vizualizálja, áttekintheti a megoldás állapotát. Emellett alkalmazásnaplókat is gyűjtött.

Azure Pipelines. Az Azure Pipelines egy folyamatos integrációs (CI) és folyamatos kézbesítési (CD) szolgáltatás, amely létrehozza, teszteli és üzembe helyezi az alkalmazást.

GitHub Actions. A munkafolyamat egy automatizált folyamat (CI/CD), amelyet a GitHub-adattárban állított be. Bármilyen projektet létrehozhat, tesztelhet, csomagolhat, kiadhat vagy üzembe helyezhet a GitHubon egy munkafolyamattal.

Forgatókönyv részletei

Lehetséges használati esetek

Ez a drónkézbesítési megoldás ideális a repülőgépek, a repülés, a repülés és a robotika iparág számára.

Ajánlások

Függvényalkalmazás-csomagok

Az Azure Functions két üzemeltetési modellt támogat. A használati tervvel a rendszer automatikusan lefoglalja a számítási teljesítményt a kód futtatásakor. Az App Service-csomagban a kódhoz virtuális gépek készlete van lefoglalva. Az App Service-csomag határozza meg a virtuális gépek számát és a virtuális gép méretét.

Vegye figyelembe, hogy az App Service-csomag nem szigorúan kiszolgáló nélküli, a fent megadott definíciónak megfelelően. A programozási modell azonban ugyanaz – ugyanaz a függvénykód futtatható egy használati tervben és egy App Service-csomagban is.

Az alábbiakban néhány tényezőt érdemes figyelembe venni a használni kívánt tervtípus kiválasztásakor:

  • Hideg kezdés. A használati csomag esetén a nemrég nem meghívott függvények további késést fognak eredményezni a következő futtatáskor. Ez a további késés a futtatókörnyezet kiosztásának és előkészítésének köszönhető. Ez általában a másodpercek sorrendjétől függ, de számos tényezőtől függ, beleértve a betöltendő függőségek számát is. További információ: A kiszolgáló nélküli hidegindítás ismertetése. A hidegindítás általában nagyobb gondot jelent az interaktív számítási feladatok (HTTP-triggerek) esetében, mint az aszinkron üzenetvezérelt számítási feladatok (üzenetsor- vagy eseményközpontok eseményindítói), mivel a további késést a felhasználók közvetlenül megfigyelik.
  • Időtúllépési időszak. A használati tervben a függvény végrehajtása egy konfigurálható időtartam után (legfeljebb 10 percig) időtúllépést eredményez.
  • Virtuális hálózatok elkülönítése. Az App Service-csomag használatával a függvények az App Service-környezeten belül futhatnak, amely egy dedikált és elkülönített üzemeltetési környezet.
  • Díjszabási modell. A használati terv számlázása a végrehajtások száma és az erőforrás-felhasználás (memória × végrehajtási idő) alapján történik. Az App Service-csomag számlázása óránként történik a virtuálisgép-példány termékváltozata alapján. A fogyasztási csomag gyakran olcsóbb lehet, mint egy App Service-csomag, mivel csak a használt számítási erőforrásokért kell fizetnie. Ez különösen akkor igaz, ha a forgalom csúcsokat és vályúkat tapasztal. Ha azonban egy alkalmazás állandó nagy mennyiségű átviteli sebességet tapasztal, egy App Service-csomag alacsonyabb költséggel járhat, mint a használati terv.
  • Skálázás. A fogyasztási modell nagy előnye, hogy szükség szerint dinamikusan skálázható a bejövő forgalom alapján. Bár ez a skálázás gyorsan megtörténik, még mindig van egy felfelé irányuló időszak. Egyes számítási feladatok esetében érdemes lehet szándékosan túlterhelni a virtuális gépeket, hogy a forgalomkitöréseket nulla felfutási idő mellett tudja kezelni. Ebben az esetben fontolja meg egy App Service-csomag használatát.

Függvényalkalmazás határai

Egy függvényalkalmazás egy vagy több függvény végrehajtását üzemelteti. Egy függvényalkalmazással több függvényt csoportosíthat logikai egységként. A függvényalkalmazásokban a függvények ugyanazokat az alkalmazásbeállításokat, üzemeltetési tervet és üzembe helyezési életciklust osztják meg. Minden függvényalkalmazásnak saját állomásneve van.

Függvényalkalmazások használatával csoportosíthatja az azonos életciklust és beállításokat használó függvényeket. Az azonos életciklust nem használó függvényeket különböző függvényalkalmazásokban kell üzemeltetni.

Fontolja meg a mikroszolgáltatások megközelítését, ahol minden függvényalkalmazás egy mikroszolgáltatást jelöl, amely több kapcsolódó függvényből állhat. A mikroszolgáltatás-architektúrában a szolgáltatásoknak laza összekapcsolással és magas funkcionális kohézióval kell rendelkezniük. A lazán összekapcsolt szolgáltatás azt jelenti, hogy anélkül módosíthatja az egyik szolgáltatást, hogy egyidejűleg más szolgáltatásokat kellene frissítenie. Az összetartó azt jelenti, hogy egy szolgáltatásnak egyetlen, jól meghatározott célja van. Ezekről az ötletekről további információt a mikroszolgáltatások tervezése: Tartományelemzés című témakörben talál.

Függvénykötések

Ha lehetséges, használja a Functions-kötéseket. A kötések deklaratív módon csatlakoztatják a kódot az adatokhoz, és integrálhatók más Azure-szolgáltatásokkal. Egy bemeneti kötés feltölt egy bemeneti paramétert egy külső adatforrásból. A kimeneti kötés elküldi a függvény visszatérési értékét egy adatgyűjtőnek, például egy üzenetsornak vagy adatbázisnak.

A referencia-implementáció függvénye például GetStatus az Azure Cosmos DB bemeneti kötését használja. Ez a kötés úgy van konfigurálva, hogy megkeressen egy dokumentumot az Azure Cosmos DB-ben a HTTP-kérésben szereplő lekérdezési sztringből vett lekérdezési paraméterek használatával. Ha a dokumentum megtalálható, a rendszer paraméterként továbbítja a függvénynek.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Kötések használatával nem kell olyan kódot írnia, amely közvetlenül a szolgáltatáshoz beszél, ami egyszerűbbé teszi a függvénykódot, és elvonja az adatforrás vagy fogadó részleteit is. Bizonyos esetekben azonban a kötésnél összetettebb logikára lehet szükség. Ebben az esetben használja közvetlenül az Azure-ügyfél SDK-jait.

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Méretezhetőség

Functions. A használati terv esetében a HTTP-eseményindító a forgalom alapján skálázódik. Az egyidejű függvénypéldányok száma korlátozott, de mindegyik példány egyszerre több kérést is feldolgozhat. App Service-csomag esetén a HTTP-eseményindító a virtuálisgép-példányok számának megfelelően skálázható, amely rögzített érték lehet, vagy automatikusan skálázható az automatikus méretezési szabályok alapján. További információ: Azure Functions skálázás és üzemeltetés.

Azure Cosmos DB. Az Azure Cosmos DB átviteli sebességének mérése kérelemegységekben (RU) történik. Az 1-RU átviteli sebesség megfelel az 1KB-dokumentum lekéréséhez szükséges átviteli sebességnek. Ahhoz, hogy egy Azure Cosmos DB-tároló 10 000 RU-ra skálázható legyen, meg kell adnia egy partíciókulcsot a tároló létrehozásakor, és minden létrehozott dokumentumban tartalmaznia kell a partíciókulcsot. További információ a partíciókulcsokról: Partíció és méretezés az Azure Cosmos DB-ben.

API Management. Az API Management vertikálisan felskálázható, és támogatja a szabályalapú automatikus skálázást. A skálázási folyamat legalább 20 percet vesz igénybe. Ha a forgalom kipukkan, a várt maximális kipukkadási forgalmat kell kiépnie. Az automatikus skálázás azonban hasznos az óránkénti vagy napi forgalomváltozások kezeléséhez. További információ: Azure API Management-példány automatikus méretezése.

Vészhelyreállítás

Az itt látható üzembe helyezés egyetlen Azure-régióban található. A vészhelyreállítás rugalmasabb megközelítéséhez használja ki a különböző szolgáltatások földrajzi eloszlási funkcióit:

  • Az API Management támogatja a többrégiós üzembe helyezést, amely egyetlen API Management-példány bármilyen számú Azure-régióban való terjesztésére használható. További információ: Azure API Management szolgáltatáspéldány üzembe helyezése több Azure-régióban.

  • A Traffic Managerrel HTTP-kéréseket irányíthat az elsődleges régióba. Ha az adott régióban futó függvényalkalmazás elérhetetlenné válik, a Traffic Manager feladatátvételt végezhet egy másodlagos régióban.

  • Az Azure Cosmos DB több írási régiót is támogat, amely lehetővé teszi az írást az Azure Cosmos DB-fiókhoz hozzáadott bármely régióba. Ha nem engedélyezi a több írást, továbbra is feladatátvételt végezhet az elsődleges írási régión. Az Azure Cosmos DB ügyféloldali SDK-k és az Azure-függvénykötések automatikusan kezelik a feladatátvételt, így nem kell frissítenie az alkalmazáskonfigurációs beállításokat.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

Hitelesítés

A GetStatus referencia-implementáció API-ja a Microsoft Entra-azonosítót használja a kérések hitelesítéséhez. A Microsoft Entra ID támogatja az OpenID Csatlakozás protokollt, amely az OAuth 2 protokollra épülő hitelesítési protokoll.

Ebben az architektúrában az ügyfélalkalmazás egy egyoldalas alkalmazás (SPA), amely a böngészőben fut. Az ilyen típusú ügyfélalkalmazások nem tudják elrejteni az ügyfél titkos kódját vagy az engedélyezési kódot, ezért az implicit engedélyezési folyamat megfelelő. (Lásd: Melyik OAuth 2.0-folyamatot használjam?). A teljes folyamat a következő:

  1. A felhasználó a webalkalmazásban a "Bejelentkezés" hivatkozásra kattint.
  2. A böngésző átirányítja a Microsoft Entra bejelentkezési oldalát.
  3. A felhasználó bejelentkezik.
  4. A Microsoft Entra ID visszairányítja az ügyfélalkalmazást, beleértve egy hozzáférési jogkivonatot is az URL-töredékben.
  5. Amikor a webalkalmazás meghívja az API-t, az tartalmazza a hozzáférési jogkivonatot a Hitelesítési fejlécben. Az alkalmazásazonosítót a rendszer a hozzáférési jogkivonat célközönségi (aud) jogcímeként küldi el.
  6. A háttér API ellenőrzi a hozzáférési jogkivonatot.

A hitelesítés konfigurálása:

  • Alkalmazás regisztrálása a Microsoft Entra-bérlőben. Ez létrehoz egy alkalmazásazonosítót, amelyet az ügyfél a bejelentkezési URL-címmel együtt tartalmaz.

  • Engedélyezze a Microsoft Entra-hitelesítést a függvényalkalmazásban. További információkért lásd: Hitelesítés és engedélyezés az Azure App Service-ben.

  • Adja hozzá a validate-jwt szabályzatot az API Managementhez a kérelem előzetes engedélyezéséhez a hozzáférési jogkivonat érvényesítésével.

További részletekért tekintse meg a GitHub-olvasót.

Ajánlott külön alkalmazásregisztrációkat létrehozni a Microsoft Entra-azonosítóban az ügyfélalkalmazáshoz és a háttér API-hoz. Adjon engedélyt az ügyfélalkalmazásnak az API meghívásához. Ezzel a módszerrel rugalmasan definiálhat több API-t és ügyfelet, és szabályozhatja az egyes alkalmazások engedélyeit.

Az API-k hatóköreinek használatával részletesen szabályozhatja az alkalmazások számára, hogy milyen engedélyeket kérnek egy felhasználótól. Előfordulhat például, hogy egy API rendelkezik és hatókörökkel rendelkezikRead, és egy adott ügyfélalkalmazás megkérheti a felhasználót, hogy csak engedélyeket engedélyezzenRead.Write

Engedélyezés

Számos alkalmazásban a háttér API-nak ellenőriznie kell, hogy a felhasználó rendelkezik-e engedéllyel egy adott művelet végrehajtására. Javasoljuk, hogy jogcímalapú hitelesítést használjon, ahol az identitásszolgáltató (ebben az esetben a Microsoft Entra ID) továbbítja a felhasználó adatait, és az engedélyezési döntések meghozatalára szolgál. Ha például regisztrál egy alkalmazást a Microsoft Entra ID-ban, meghatározhatja az alkalmazásszerepkörök egy készletét. Amikor egy felhasználó bejelentkezik az alkalmazásba, a Microsoft Entra-azonosító tartalmazza roles a felhasználó által biztosított szerepkörökre vonatkozó jogcímet, beleértve a csoporttagságon keresztül öröklő szerepköröket is.

A Microsoft Entra ID által az ügyfélnek visszaadott azonosító jogkivonat tartalmazza a felhasználó egyes jogcímeit. A függvényalkalmazásban ezek a jogcímek a kérelem X-MS-CLIENT-PRINCIPAL fejlécében érhetők el. Egyszerűbb azonban elolvasni ezeket az információkat a kötési adatokból. Egyéb jogcímek esetén a Microsoft Graph használatával kérdezheti le a Microsoft Entra-azonosítót. (A felhasználónak a bejelentkezéskor hozzá kell adnia ezt a műveletet.)

További információ: Az ügyfélidentitások használata.

CORS

Ebben a referenciaarchitektúrában a webalkalmazás és az API nem azonos eredetű. Ez azt jelenti, hogy amikor az alkalmazás meghívja az API-t, az egy forrásközi kérés. A böngésző biztonsági beállításai megakadályozzák, hogy egy weblap AJAX-kérelmeket küldjön egy másik tartományba. Ezt a korlátozást azonos eredetű szabályzatnak nevezzük, és megakadályozza, hogy egy rosszindulatú webhely bizalmas adatokat olvasson egy másik webhelyről. A forrásközi kérések engedélyezéséhez adjon hozzá egy forrásközi erőforrás-megosztási (CORS) szabályzatot az API Management-átjáróhoz:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

Ebben a példában az allow-credentials attribútum igaz. Ez engedélyezi a böngészőnek, hogy hitelesítő adatokat küldjön (beleértve a cookie-kat is) a kéréssel. Ellenkező esetben a böngésző alapértelmezés szerint nem küld hitelesítő adatokat a forrásközi kéréssel.

Feljegyzés

Ügyeljen arra, hogy az engedélyezési hitelesítő adatok értéke igaz legyen, mert ez azt jelenti, hogy a webhely a felhasználó nevében elküldheti a felhasználó hitelesítő adatait az API-nak anélkül, hogy a felhasználó értesült volna róla. Megbízhatónak kell lennie az engedélyezett forrásban.

HTTPS kényszerítése

A maximális biztonság érdekében https-t kell igényelni a kérési folyamat során:

  • CDN. Az Azure CDN alapértelmezés szerint támogatja a HTTPS-t az *.azureedge.net altartományon. Ha engedélyezni szeretné a HTTPS-t a CDN-ben egyéni tartománynevekhez, tekintse meg az oktatóanyagot: HTTPS konfigurálása egyéni Azure CDN-tartományon.

  • Statikus webhely üzemeltetése. Engedélyezze a "Biztonságos átvitel szükséges" beállítást a Storage-fiókban. Ha ez a beállítás engedélyezve van, a tárfiók csak a biztonságos HTTPS-kapcsolatokból érkező kéréseket engedélyezi.

  • API Management. Konfigurálja az API-kat, hogy csak HTTPS protokollt használjanak. Ezt az Azure Portalon vagy Resource Manager-sablonnal konfigurálhatja:

    {
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

  • Azure Functions-függvények. Engedélyezze a "CSAK HTTPS" beállítást.

A függvényalkalmazás zárolása

A függvényhez intézett összes hívásnak az API-átjárón kell keresztülhaladnia. Ezt a következőképpen érheti el:

  • Konfigurálja a függvényalkalmazást úgy, hogy függvénykulcsot igényeljen. Az API Management-átjáró tartalmazza a függvénykulcsot, amikor meghívja a függvényalkalmazást. Ez megakadályozza, hogy az ügyfelek közvetlenül meghívják a függvényt, megkerülve az átjárót.

  • Az API Management-átjáró statikus IP-címmel rendelkezik. Korlátozza az Azure-függvényt, hogy csak az adott statikus IP-címről érkező hívásokat engedélyezze. További információ: Azure-alkalmazás Szolgáltatás statikus IP-korlátozásai. (Ez a funkció csak standard szintű szolgáltatásokhoz érhető el.)

Titkos alkalmazáskulcsok védelme

Ne tárolja az alkalmazás titkos kulcsait, például az adatbázis hitelesítő adatait a kódban vagy a konfigurációs fájlokban. Ehelyett használja az Azure-ban titkosítottan tárolt alkalmazásbeállításokat. További információ: Security in Azure-alkalmazás Service and Azure Functions.

Másik lehetőségként az alkalmazáskulcsokat a Key Vaultban is tárolhatja. Ez lehetővé teszi a titkos kódok tárolásának központosítását, azok terjesztésének szabályozását, valamint a titkos kódok elérésének módját és állapotát. További információ: Azure-webalkalmazás konfigurálása a Key Vault titkos kulcsainak beolvasásához. Vegye figyelembe azonban, hogy a Functions eseményindítói és kötései betöltik a konfigurációs beállításokat az alkalmazásbeállításokból. Az eseményindítók és kötések nincs beépített módon konfigurálva a Key Vault titkos kulcsainak használatára.

DevOps

Előtérbeli üzembe helyezés

A referenciaarchitektúra előtere egy egyoldalas alkalmazás, amely a JavaScript kiszolgáló nélküli háttér API-jait és statikus tartalmakat biztosít, amelyek gyors felhasználói élményt nyújtanak. Az alábbiakban néhány fontos szempontot érdemes figyelembe venni egy ilyen alkalmazás esetében:

  • Az alkalmazást egységesen üzembe helyezheti a felhasználók számára egy globálisan használatra kész CDN-vel, a felhőben tárolt statikus tartalommal. Így nincs szükség dedikált webkiszolgálóra. Az első lépésekhez olvassa el az Azure Storage-fiók integrálása az Azure CDN-sel című cikket. Biztonságossá teheti az alkalmazást HTTPS használatával. További javaslatokért olvassa el a tartalomkézbesítési hálózatok használatának ajánlott eljárásait.
  • Egy gyors és megbízható CI/CD-szolgáltatás, például az Azure Pipelines vagy a GitHub Actions használatával automatikusan létrehozhat és üzembe helyezhet minden forrásváltozást. A forrásnak egy online verziókövetési rendszerben kell lennie. Az Azure Pipelines további részleteiért olvassa el az első folyamat létrehozása című témakört. Az Azure-hoz készült GitHub Actionsről további információt az Alkalmazások üzembe helyezése az Azure-ban című témakörben talál.
  • Tömörítse a webhelyfájlokat a CDN sávszélesség-felhasználásának csökkentése és a teljesítmény javítása érdekében. Az Azure CDN lehetővé teszi a tömörítést menet közben a peremkiszolgálókon. Másik lehetőségként a referenciaarchitektúra üzembe helyezési folyamata tömöríti a fájlokat, mielőtt üzembe helyezené őket a Blob Storage-ban. Ez csökkenti a tárolási követelményeket, és a CDN-korlátozásoktól függetlenül nagyobb szabadságot biztosít a tömörítési eszközök kiválasztásához.
  • A CDN-nek képesnek kell lennie kiüríteni a gyorsítótárát , hogy minden felhasználó a legfrissebb tartalmat szolgálja ki. Gyorsítótár-törlésre akkor van szükség, ha a buildelési és üzembe helyezési folyamatok nem atomiak, például ha a régi fájlokat az ugyanabban a forrásmappában lévő újonnan létrehozott fájlokra cserélik.
  • Előfordulhat, hogy egy másik gyorsítótár-stratégia, például a címtárak használatával történő verziószámozás nem igényel törlést a CDN-ből. Az előtérbeli alkalmazás buildelési folyamata minden újonnan létrehozott verzióhoz létrehoz egy új könyvtárat. Ez a verzió atomi egységként lesz feltöltve a Blob Storage-ba. Az Azure CDN csak egy befejezett üzembe helyezés után mutat erre az új verzióra.
  • Növelje a gyorsítótár TTL-jének növelését az erőforrásfájlok hosszabb ideig, hónapokon át tartó gyorsítótárazásával. Ha meg szeretné győződni arról, hogy a gyorsítótárazott fájlok frissülnek a módosításukkor, az újraépítéskor ujjlenyomattal bizonyosodjon meg a fájlnevekről. Ez az előtérbeli alkalmazás ujjlenyomatot ad az összes fájlról, kivéve a nyilvános elérésű fájlokat, például index.html. Mivel a index.html gyakran frissül, a gyorsítótár frissítését okozó megváltozott fájlneveket tükrözi. További információt a webes tartalom lejáratának kezelése az Azure CDN-ben című témakörben talál.

Háttérbeli üzembe helyezés

A függvényalkalmazás üzembe helyezéséhez javasoljuk, hogy használjon csomagfájlokat ("Futtatás csomagból"). Ezzel a módszerrel feltölt egy zip-fájlt egy Blob Storage-tárolóba, és a Functions-futtatókörnyezet írásvédett fájlrendszerként csatlakoztatja a zip-fájlt. Ez egy atomi művelet, amely csökkenti annak az esélyét, hogy egy sikertelen üzembe helyezés inkonzisztens állapotban hagyja az alkalmazást. Emellett javíthatja a hideg kezdési időket, különösen Node.js alkalmazások esetében, mivel az összes fájl egyszerre felcserélődik.

API-verziószámozás

Az API egy szolgáltatás és az ügyfelek közötti szerződés. Ebben az architektúrában az API-szerződés az API Management rétegben van definiálva. Az API Management két különálló, de egymást kiegészítő verziószámozási fogalmat támogat:

  • A verziók lehetővé teszik, hogy az API-felhasználók igényeiknek megfelelően válasszanak egy API-verziót, például v1 és v2.

  • A módosítások lehetővé teszik az API-rendszergazdák számára, hogy nem kompatibilitástörő módosításokat hajtsanak végre egy API-ban, és üzembe helyezhesse ezeket a módosításokat, valamint egy változásnaplót, amely tájékoztatja az API-felhasználókat a változásokról.

Ha egy API-ban kompatibilitástörő változást hoz létre, tegyen közzé egy új verziót az API Managementben. Helyezze üzembe az új verziót egymás mellett az eredeti verzióval egy külön függvényalkalmazásban. Ez lehetővé teszi a meglévő ügyfelek áttelepítését az új API-ba az ügyfélalkalmazások feltörése nélkül. Végül megszüntetheti az előző verziót. Az API Management számos verziószámozási sémát támogat: URL-elérési utat, HTTP-fejlécet vagy lekérdezési sztringet. Az API-verziószámozással kapcsolatos általános információkért lásd : RESTful webes API verziószámozása.

Olyan frissítések esetén, amelyek nem törik meg az API-módosításokat, helyezze üzembe az új verziót egy átmeneti ponton ugyanabban a függvényalkalmazásban. Ellenőrizze, hogy az üzembe helyezés sikeres volt-e, majd cserélje le a szakaszos verziót az éles verzióra. Korrektúra közzététele az API Managementben.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

Az Azure díjkalkulátorával megbecsülheti költségeit. Fontolja meg ezeket a pontokat az architektúra költségeinek optimalizálásához.

Azure Functions

Az Azure Functions két üzemeltetési modellt támogat.

  • Használati terv.

    A számítási teljesítmény automatikusan le lesz foglalva a kód futtatásakor.

  • App Service-csomag.

    A kódhoz virtuális gépek készlete van lefoglalva. Ez a csomag határozza meg a virtuális gépek számát és a virtuális gép méretét.

Ebben az architektúrában a rendszer meghív egy függvényt, amikor egy ügyfél HTTP-kérelmet küld. Mivel ebben a használati esetben nem várható állandó nagy mennyiségű átviteli sebesség, a használati terv azért ajánlott, mert csak a használt számítási erőforrásokért kell fizetnie.

Azure Cosmos DB

Az Azure Cosmos DB óránként számláz a kiosztott átviteli sebességért és a felhasznált tárterületért. A kiosztott átviteli sebesség másodpercenkénti kérelemegységekben (RU/s) van kifejezve, amely a tipikus adatbázis-műveletekhez, például beszúrásokhoz, olvasásokhoz használható. Az ár a fenntartott ru/s kapacitáson alapul.

A tárterület a tárolt adatokhoz és indexekhez használt összes GB-ra kiszámlázva van.

További információkért tekintse meg az Azure Cosmos DB díjszabási modelljét .

Ebben az architektúrában a függvényalkalmazás lekéri a dokumentumokat az Azure Cosmos DB-ből az ügyfél HTTP GET-kérelmeire válaszul. Az Azure Cosmos DB költséghatékony ebben az esetben, mivel az olvasási műveletek jelentősen olcsóbbak, mint ru/s-on kifejezett írási műveletek.

Content Delivery Network

A számlázási sebesség a számlázási régiótól függően eltérhet attól függően, hogy a forráskiszolgáló hol kézbesíti a tartalmat a végfelhasználónak. Az ügyfél fizikai helye nem a számlázási régió. A CDN-t elérő HTTP- vagy HTTPS-kérések számlázható eseménynek tekintendők, amely magában foglalja az összes választípust: siker, hiba vagy egyéb. A különböző válaszok eltérő forgalommennyiségeket eredményezhetnek.

Ebben a referenciaarchitektúrában az üzembe helyezés egyetlen Azure-régióban található.

A költségek csökkentése érdekében fontolja meg a gyorsítótár TTL növelését úgy, hogy hosszabb ideig gyorsítótárazza az erőforrásfájlokat, és beállítja a tartalomon a lehető leghosszabb TTL-t.

További információt a Microsoft Azure Well-Architected Framework Költség szakaszában talál.

A forgatókönyv üzembe helyezése

Az architektúra referencia-implementációjának üzembe helyezéséhez tekintse meg a GitHub-olvasót.

Következő lépések

Termékdokumentáció:

További modulok:

A referencia-implementációval kapcsolatos további információkért olvassa el a Kód útmutatóját: Kiszolgáló nélküli alkalmazás az Azure Functions használatával.

Kapcsolódó útmutató: