Webová aplikace bez serveru

Tato referenční architektura ukazuje bez serverů webovou aplikaci. Aplikace poskytuje statický obsah z azure blob Storage a implementuje rozhraní API pomocí Azure Functions. Rozhraní API čte data z Cosmos DB a vrací výsledky do webové aplikace.

GitHub: Drone Delivery App (ARM & Azure Pipelines) a To Do App (Bicep & GitHub Actions).

Stáhněte si SVG této architektury.

Pojem bez serveru má dva odlišné, ale související významy:

• Back-end jako služba (BaaS). Back-endové cloudové služby, jako jsou databáze a úložiště, poskytují rozhraní API, která klientským aplikacím umožňují připojit se přímo k těmto službám.
• Funguje jako služba (FaaS). V tomto modelu je "funkce" část kódu, která je nasazená v cloudu a běží v hostitelském prostředí, které zcela abstrahuje servery, na které se kód spouští.

Obě definice mají společnou myšlenku, že vývojáři a DevOps nemusí nasazovat, konfigurovat ani spravovat servery. Tato referenční architektura se zaměřuje na FaaS s využitím Azure Functions, i když jako příklad BaaS může sloužit webový obsah z Azure Blob Storage. Mezi důležité charakteristiky FaaS existují:

1. Výpočetní prostředky se přidělují dynamicky podle potřeby platformy.
2. Ceny založené na spotřebě: Účtují se vám jenom výpočetní prostředky použité ke spuštění kódu.
3. Výpočetní prostředky se škálují na vyžádání na základě provozu, aniž by vývojáři potřebovali nějakou konfiguraci.

Funkce se spouštějí, když dojde k externímu triggeru, jako je požadavek HTTP nebo zpráva přicházející do fronty. Díky tomu je styl architektury řízený událostmi přirozený pro architektury bez serveru. Pokud chcete koordinovat práci mezi komponentami v architektuře, zvažte použití zprostředkovatelů zpráv nebo vzorů pub/sub. Nápovědu k výběru mezi technologiemi zasílání zpráv v Azure najdete v tématu Volba mezi službami Azure, které doručují zprávy.

Architektura

Tato architektura se skládá z následujících součástí:

Blob Storage. Statický webový obsah, jako jsou soubory HTML, CSS a JavaScript, se ukládá ve službě Azure Blob Storage a poskytuje klientům pomocí hostování statického webu. Veškerá dynamická interakce probíhá prostřednictvím kódu JavaScriptu, který volá back-endová rozhraní API. Pro vykreslení webové stránky není k dispozici žádný kód na straně serveru. Hostování statického webu podporuje indexové dokumenty a vlastní chybové stránky 404.

CDN. Azure Content Delivery Network (CDN) můžete použít k ukládání obsahu do mezipaměti pro zajištění nižší latence a rychlejšího doručování obsahu a také k poskytování koncového bodu HTTPS.

Function Apps. Azure Functions je možnost výpočetních prostředků bez serveru. Používá model řízený událostmi, ve kterém je část kódu ("funkce") vyvolána triggerem. V této architektuře se funkce vyvolá, když klient vytvoří požadavek HTTP. Požadavek se vždy směruje přes bránu rozhraní API, která je popsaná níže.

API Management. API Management poskytuje bránu rozhraní API, která se nachází před funkcí HTTP. Pomocí nástroje API Management a spravovat rozhraní API používaná klientskými aplikacemi. Použití brány pomáhá oddělení front-endové aplikace od rozhraní API back-endu. Můžete například API Management adresy URL, transformovat požadavky před tím, než se dostanou do back-endu, nastavit hlavičky požadavku nebo odpovědi atd.

API Management lze použít také k implementaci průřezových problémů, jako jsou:

• Vynucování kvót využití a omezení přenosové rychlosti
• Ověřování tokenů OAuth pro ověřování
• Povolení žádostí mezi zdroji (CORS)
• Ukládání do mezipaměti odpovědi
• Monitorování a protokolování požadavků

Pokud nepotřebujete všechny funkce, které poskytuje API Management, další možností je použít functions proxies. Tato funkce Azure Functions umožňuje definovat jedno rozhraní API pro více aplikací funkcí vytvořením tras do back-endových funkcí. V případě požadavků a odpovědí HTTP mohou také provádět omezené transformace. Neposkytují ale stejné bohaté možnosti založené na zásadách jako API Management.

Cosmos DB. Cosmos DB je databázová služba s více modely. V tomto scénáři aplikace funkcí načítá dokumenty z Cosmos DB v reakci na požadavky HTTP GET z klienta.

Azure Active Directory (Azure AD). Uživatelé se k webové aplikaci přihlašují pomocí svých přihlašovacích údajů Azure AD. Azure AD vrátí přístupový token pro rozhraní API, který webová aplikace používá k ověřování požadavků rozhraní API (viz Ověřování).

Azure Monitor Monitorování shromažďuje metriky výkonu služeb Azure nasazených v řešení. Když je vizualizujete na řídicím panelu, získáte přehled o stavu řešení. Shromáždil také protokoly aplikací.

Azure Pipelines. Pipelines je služba kontinuální integrace (CI) a průběžného doručování (CD), která vytváří, testuje a nasazovat aplikaci.

GitHub Actions . Pracovní postup je automatizovaný proces (CI/CD), který nastavíte ve svém GitHub úložiště. Pomocí pracovního postupu můžete sestavovat, testovat, zabalovat, vydat nebo GitHub libovolný projekt.

Doporučení

Plány aplikací funkcí

Azure Functions podporuje dva modely hostování. S plánem Consumption se výpočetní výkon při spuštění kódu automaticky přidělí. V App Service plánu se pro váš kód přidělí sada virtuálních počítače. Plán App Service definuje počet virtuálních počítače a velikost virtuálního počítače.

Všimněte si, App Service plán není výhradně bez serveru podle výše uvedené definice. Programovací model je stejný, ale stejný kód funkce může běžet jak v plánu Consumption, tak v App Service — plánu.

Při výběru typu plánu, který se má použít, je třeba vzít v úvahu některé faktory:

• Studený start: U plánu Consumption bude při příštím spuštění funkce, která nebyla nedávno vyvolána, vyšší latence. Tato další latence je způsobená přidělováním a přípravou prostředí modulu runtime. Obvykle je v řádu sekund, ale závisí na několika faktorech, včetně počtu závislostí, které je potřeba načíst. Další informace najdete v tématu Principy bez serveru ve studeném startu. Studený start je obvykle důležitější pro interaktivní úlohy (triggery HTTP) než asynchronní úlohy řízené zprávami (triggery fronty nebo centra událostí), protože další latenci přímo pozorují uživatelé.
• Časový limit : V plánu Consumption časový limit spuštění funkce po konfigurovatelném časovém období (maximálně na 10 minut)
• Izolace virtuální sítě. Použití App Service umožňuje spouštění funkcí v rámci App Service Environment ,což je vyhrazené a izolované hostitelské prostředí.
• Cenový model. Plán Consumption se účtuje podle počtu spuštění a spotřeby prostředků (doba × provádění paměti). Plán App Service se účtuje po hodině na základě SKU instance virtuálního počítače. Plán Consumption může být často levnější než plán App Service, protože platíte jenom za výpočetní prostředky, které používáte. To platí zejména v případě, že provoz zažívá špičky a procháčky. Pokud ale u aplikace dochází k konstantní vysoké propustnosti, může App Service plán nižší než plán Consumption.
• Škálování: Velkou výhodou modelu spotřeby je, že se dynamicky škáluje podle potřeby na základě příchozího provozu. I když k tomuto škálování dochází rychle, stále dochází k období zkostňování. U některých úloh můžete chtít virtuální počítače záměrně přetížením, abyste mohli zpracovávat shluky provozu s nulovou dobu náběhu. V takovém případě zvažte App Service plán.

Hranice aplikace Function App

Aplikace funkcí hostuje spuštění jedné nebo více funkcí. Pomocí aplikace funkcí můžete seskupit několik funkcí dohromady jako logickou jednotku. V rámci aplikace funkcí sdílejí funkce stejné nastavení aplikace, plán hostování a životní cyklus nasazení. Každá aplikace funkcí má svůj vlastní název hostitele.

Pomocí aplikací funkcí můžete seskupit funkce, které sdílejí stejný životní cyklus a nastavení. Funkce, které nesdílejí stejný životní cyklus, by se měly hostovat v různých aplikacích Function App.

Vezměte v úvahu přístup k mikroslužbám, kde každá aplikace Function App představuje jednu mikroslužbu, která se může skládat z několika souvisejících funkcí. V architektuře mikroslužeb by služby měly mít volnou spojování a vysokou funkční soudržnost. Volně spárované znamená, že můžete změnit jednu službu, aniž by bylo potřeba aktualizovat další služby ve stejnou dobu. Soudržně znamená, že služba má jediný, přesně definovaný účel. Další diskuzi o těchto nápadech najdete v tématu navrhování mikroslužeb: analýza domén.

Vazby funkcí

Pokud je to možné, používejte vazby funkcí. Vazby poskytují deklarativní způsob, jak připojit váš kód k datům a integrovat s dalšími službami Azure. Vstupní vazba naplní vstupní parametr z externího zdroje dat. Výstupní vazba odesílá návratovou hodnotu funkce do datové jímky, jako je například fronta nebo databáze.

například GetStatus funkce v referenční implementaci používá vstupní vazbuCosmos DB. tato vazba je nakonfigurována tak, aby vyhledala dokument v Cosmos DB pomocí parametrů dotazu, které jsou pořízeny z řetězce dotazu v požadavku HTTP. Pokud je dokument nalezen, je předán funkci jako parametr.

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

Pomocí vazeb nemusíte psát kód, který se domluví přímo ke službě, což usnadňuje kód funkce a také vyabstrakce podrobnosti o zdroji dat nebo jímky. V některých případech ale můžete potřebovat složitější logiku, než poskytuje vazba. V takovém případě můžete přímo použít klientské sady SDK Azure.

Aspekty zabezpečení

Funkce. Pro plán spotřeby se aktivační událost HTTP škáluje podle provozu. Počet souběžných instancí funkcí je omezen, ale každá instance může zpracovávat více požadavků současně. U App Serviceho plánu se aktivační událost HTTP škáluje podle počtu instancí virtuálních počítačů, což může být pevná hodnota nebo může automaticky škálovat na základě sady pravidel automatického škálování. Informace najdete v tématu Azure Functions škálování a hostování.

Cosmos DB. kapacita propustnosti pro Cosmos DB se měří v jednotkách žádosti (RU). Propustnost 1-RU odpovídá propustnosti, která je potřeba k získání 1 KB dokumentu. aby bylo možné škálovat Cosmos DB kontejner po 10 000 RU, je nutné při vytváření kontejneru zadat klíč oddílu a zahrnout klíč oddílu do každého dokumentu, který vytvoříte. další informace o klíčích oddílů naleznete v tématu partition and scale in Azure Cosmos DB.

API Management. API Management může škálovat a podporuje automatické škálování na základě pravidel. Proces škálování trvá aspoň 20 minut. Pokud je provoz v nárůstu, měli byste zřídit maximální zatížení, které očekáváte. Automatické škálování je ale užitečné pro zpracování hodinových nebo denních odchylek v provozu. Další informace najdete v tématu Automatické škálování instance služby Azure API Management.

Aspekty zotavení po havárii

Zde uvedené nasazení se nachází v jedné oblasti Azure. Pro zajištění odolného přístupu k zotavení po havárii využijte funkce geografické distribuce v různých službách:

• API Management podporuje nasazení ve více oblastech, které se dá použít k distribuci jedné instance API Management napříč libovolným počtem oblastí Azure. Další informace najdete v tématu nasazení instance služby Azure API Management Service do několika oblastí Azure.

• k směrování požadavků HTTP do primární oblasti použijte Traffic Manager . pokud Function App běžící v této oblasti nebude k dispozici, Traffic Manager může převzít služby při selhání do sekundární oblasti.

• Cosmos DB podporuje více oblastí pro zápis, které umožňují zápisy do libovolné oblasti, kterou přidáte do účtu Cosmos DB. Pokud nepovolíte vícenásobný zápis, můžete u primární oblasti pro zápis stále převzít služby při selhání. sady sdk klienta Cosmos DB a vazby funkce Azure automaticky zpracovávají převzetí služeb při selhání, takže nemusíte aktualizovat žádné konfigurační nastavení aplikace.

Důležité informace o zabezpečení

Authentication

GetStatusRozhraní API v referenční implementaci používá službu Azure AD k ověřování požadavků. Azure AD podporuje protokol OpenID Připojení, což je protokol ověřování založený na protokolu OAuth 2.

V této architektuře je klientská aplikace jednostránkové aplikace (SPA), která běží v prohlížeči. Tento typ klientské aplikace nemůže zachovat tajný klíč klienta ani autorizační kód, takže je vhodný tok implicitního udělení. (Podívejte se , který tok OAuth 2,0 mám použít?). Zde je celkový tok:

1. Uživatel klikne na odkaz přihlásit ve webové aplikaci.
2. Prohlížeč přesměruje přihlašovací stránku služby Azure AD.
3. Uživatel se přihlásí.
4. Azure AD přesměrovává zpátky na klientskou aplikaci, včetně přístupového tokenu v fragmentu adresy URL.
5. Když webová aplikace volá rozhraní API, zahrnuje token přístupu v hlavičce ověřování. ID aplikace se odešle jako deklarace cílové skupiny (' AUD ') v přístupovém tokenu.
6. Back-endové rozhraní API ověřuje přístupový token.

Konfigurace ověřování:

• Zaregistrujte aplikaci v tenantovi Azure AD. Tím se vygeneruje ID aplikace, které klient zahrnuje s přihlašovací adresou URL.

• Povolte ověřování Azure AD v rámci Function App. Další informace najdete v tématu Ověřování a autorizace ve službě Azure App Service.

• Přidejte zásadu Validate-JWT , která API Management k předběžné autorizaci žádosti ověřením přístupového tokenu.

další podrobnosti najdete v souboru readme GitHub.

V Azure AD se doporučuje vytvářet samostatné registrace aplikací pro klientskou aplikaci a back-endové rozhraní API. Udělte klientské aplikaci oprávnění volat rozhraní API. Tento přístup vám dává flexibilitu při definování více rozhraní API a klientů a řízení oprávnění pro každý z nich.

V rámci rozhraní API se pomocí oborů poskytují přesnější kontrolu nad tím, jaká oprávnění od uživatele požadují. Rozhraní API může mít například Read Write obory a a konkrétní klientská aplikace může požádat uživatele o autorizaci Read oprávnění.

Autorizace

V mnoha aplikacích musí back-endové rozhraní API ověřit, jestli má uživatel oprávnění k provedení dané akce. Doporučuje se použít autorizaci založenou na deklaracích, kde informace o uživateli přenáší poskytovatel identity (v tomto případě Azure AD) a používají se k rozhodování o autorizaci. Například při registraci aplikace ve službě Azure AD můžete definovat sadu aplikačních rolí. Když se uživatel do aplikace přihlásí, Azure AD zahrnuje roles deklaraci identity pro každou roli, kterou uživatel udělil, včetně rolí, které jsou zděděné prostřednictvím členství ve skupině.

Token ID, který služba Azure AD vrátí klientovi, obsahuje některé deklarace identity uživatele. V rámci aplikace Function App jsou tyto deklarace identity k dispozici v hlavičce X-MS-CLIENT-PRINCIPAL požadavku. Je ale jednodušší tyto informace z vazeb dat číst. pro jiné deklarace identity použijte Microsoft Graph k dotazování služby Azure AD. (Uživatel musí při přihlašování souhlasit s touto akcí.)

Další informace najdete v tématu práce s identitami klientů.

CORS

V této referenční architektuře nesdílejí webové aplikace a rozhraní API stejný původ. To znamená, že když aplikace volá rozhraní API, jedná se o požadavek mezi zdroji. Zabezpečení prohlížečů brání webovým stránkám v odesílání požadavků AJAX na jinou doménu. Toto omezení se nazývá zásady stejného původu a brání škodlivému webu v čtení citlivých dat z jiné lokality. Pokud chcete povolit žádost o více zdrojů, přidejte do API Management brány zásadu sdílení prostředků mezi zdroji (CORS):

<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>

V tomto příkladu má atribut Allow-Credentials hodnotu true. Tím se v prohlížeči autorizuje odeslání přihlašovacích údajů (včetně souborů cookie) do žádosti. V opačném případě prohlížeč ve výchozím nastavení neposílá přihlašovací údaje s žádostí o více zdrojů.

Vynucení protokolu HTTPS

Pro maximum zabezpečení, vyžadovat HTTPS v rámci kanálu žádosti:

• CDN. *.azureedge.netve výchozím nastavení podporuje Azure CDN v subdoméně HTTPS. pokud chcete povolit HTTPS v CDN pro vlastní názvy domén, přečtěte si téma kurz: konfigurace HTTPS ve Azure CDN vlastní doméně.

• Hostování statického webu. povolte u Storage účtu možnostzabezpečený přenos je povinný. Pokud je tato možnost povolena, účet úložiště povoluje pouze požadavky ze zabezpečených připojení HTTPS.

• API Management. Nakonfigurujte rozhraní API jenom na použití protokolu HTTPS. Tuto možnost můžete nakonfigurovat v Azure Portal nebo pomocí Správce prostředků šablony:

  {
      "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. Povolte nastavenípouze https.

Uzamknutí aplikace Function App

Všechna volání funkce by měla projít přes bránu API. Můžete to dosáhnout následujícím způsobem:

• Nakonfigurujte aplikaci Function App, aby vyžadovala klíč funkce. Brána API Management bude při volání aplikace Function App zahrnovat klíč funkce. To brání klientům ve volání funkce přímo a obejít bránu.

• Brána API Management má STATICKOU IP adresu. Omezí funkci Azure Function, aby povolovala pouze volání z této statické IP adresy. Další informace najdete v tématu Azure App Service omezení statických IP adres. (Tato funkce je k dispozici pouze pro služby úrovně Standard.)

Ochrana tajných klíčů aplikací

Neukládejte tajné klíče aplikace, jako jsou přihlašovací údaje databáze, do kódu nebo konfiguračního souboru. Místo toho použijte nastavení aplikace, která jsou uložená v Azure, která jsou šifrovaná. Další informace najdete v tématu zabezpečení v Azure App Service a Azure Functions.

Alternativně můžete ukládat tajné klíče aplikace do Key Vault. To vám umožní centralizovat úložiště tajných kódů, řídit jejich distribuci a sledovat, jak a kdy se k tajným klíčům přistupoval. Další informace najdete v tématu Konfigurace webové aplikace Azure pro čtení tajného klíče z Key Vault. Všimněte si ale, že triggery funkcí a vazby načítají nastavení konfigurace z nastavení aplikace. Neexistuje žádný vestavěný způsob, jak nakonfigurovat triggery a vazby, aby používaly Key Vault tajných klíčů.

Důležité informace o DevOps

Nasazení front-endu

Front-end této referenční architektury je jediná stránková aplikace s JavaScriptem, který přistupuje k back-endové rozhraním API bez serveru a statickým obsahem, který poskytuje rychlé uživatelské prostředí. Následující informace jsou důležité pro takovou aplikaci:

• aplikaci můžete nasadit jednotně pro uživatele v rámci geografické geografické oblasti s CDNou, která je v globálním prostředí připravena, se statickým obsahem hostovaným v cloudu. Předejdete tak nutnosti vyhrazenému webovému serveru. pokud chcete začít, přečtěte si téma věnované integraci účtu Azure storage s Azure CDN . Zabezpečte svoji aplikaci pomocí protokolu HTTPS. Další doporučení najdete v tématu osvědčené postupy pro používání služby Content Delivery Network .
• k automatickému sestavení a nasazení každé změny zdrojového kódu můžete použít rychlou a spolehlivou službu CI/CD, například Azure Pipelines nebo GitHub akce. Zdroj musí být v online systému správy verzí. pokud chcete získat další informace o Azure Pipelines, přečtěte si téma vytvoření prvního kanálu. další informace o akcích GitHub pro azure najdete v tématu nasazení aplikací do azure.
• zkomprimujte soubory webu, abyste snížili využití šířky pásma na CDN a vylepšili výkon. Azure CDN umožňuje komprimaci na hraničních serverech průběžně komprimovat. Další možností je, že kanál nasazení v této referenční architektuře komprimuje soubory před jejich nasazením do úložiště objektů BLOB. tím se sníží požadavek na úložiště a získáte větší volnost v výběru kompresních nástrojů bez ohledu na omezení CDN.
• CDN by měl být schopný vyprázdnit svou mezipaměť , aby všichni uživatelé mohli doručovat co nejaktuálnější obsah. Vyprázdnění mezipaměti je vyžadováno, pokud procesy sestavení a nasazení nejsou atomické, například pokud nahrazují staré soubory nově vytvořenými ve stejné zdrojové složce.
• Jiné strategie mezipaměti, jako je například Správa verzí pomocí adresářů, nemusí vyprázdnit CDN. Kanál sestavení v této front-endové aplikaci vytvoří nový adresář pro každou nově vytvořenou verzi. Tato verze se nahraje jako atomická jednotka do úložiště objektů BLOB. Azure CDN odkazuje na tuto novou verzi až po dokončeném nasazení.
• Zvyšte hodnotu TTL mezipaměti uložením souborů prostředků do mezipaměti po delší dobu, zahrnující měsíce. Chcete-li se ujistit, že jsou soubory uložené v mezipaměti aktualizovány při jejich změně, při opětovném vytvoření otiskem prstů názvy souborů. Tato front-endové aplikace otiskují všechny soubory s výjimkou veřejných souborů, jako je například index.html. Vzhledem k tomu, že se index.html často aktualizuje, odráží změněné názvy souborů způsobující aktualizaci mezipaměti. další informace najdete v tématu správa vypršení platnosti webového obsahu v Azure CDN .

Nasazení back-endu

K nasazení aplikace Function App doporučujeme použít soubory balíčku ("spustit z balíčku"). pomocí tohoto přístupu nahrajete soubor zip do kontejneru Blob Storage a modul runtime funkcí připojí soubor zip jako systém souborů určený jen pro čtení. Toto je atomická operace, která snižuje pravděpodobnost, že nasazení, které selhalo, ponechá aplikaci v nekonzistentním stavu. Může také zlepšit časy počátečního startu, zejména pro Node.js aplikace, protože všechny soubory jsou zaměněny najednou.

Správa verzí rozhraní API

Rozhraní API je smlouva mezi službou a klienty. V této architektuře je smlouva rozhraní API definovaná na API Management vrstvě. API Management podporuje dvě odlišná, ale doplňkové koncepty správy verzí:

• Verze umožňují spotřebitelům rozhraní API zvolit verzi rozhraní API podle svých potřeb, například v1 vs v2.

• Revize umožňují správcům rozhraní API vytvářet nenáročné změny v rozhraní API a nasazovat tyto změny společně s protokolem změn a informovat uživatele rozhraní API o změnách.

Pokud provedete zásadní změnu v rozhraní API, publikujte v API Management novou verzi. Nasaďte novou verzi vedle sebe s původní verzí, a to v samostatném Function App. To vám umožní migrovat stávající klienty na nové rozhraní API bez přerušení klientských aplikací. Nakonec můžete vyřadit předchozí verzi. API Management podporuje několik schémat správy verzí: cestu URL, hlavičku HTTP nebo řetězec dotazu. Další informace o tom, jak se správou verzí rozhraní API obecně, najdete v tématu Správa verzí RESTful webového rozhraní API.

V případě aktualizací, které neruší změny rozhraní API, nasaďte novou verzi do přípravného slotu ve stejné Function App. Ověřte, že nasazení proběhlo úspěšně, a potom Proměňte verzi v produkčním prostředí. Publikování revize v API Management.

Důležité informace o nákladech

K odhadu nákladů použijte cenovou kalkulačku Azure. Vezměte v úvahu tyto body a optimalizujte náklady na tuto architekturu.

Azure Functions

Azure Functions podporuje dva modely hostování.

• Plán spotřeby.

  Výpočetní výkon se automaticky přidělí, když je váš kód spuštěný.

• App Service plán.

  Pro váš kód jsou přiděleny sady virtuálních počítačů. Tento plán definuje počet virtuálních počítačů a velikost virtuálního počítače.

V této architektuře je funkce vyvolána, když klient provede požadavek HTTP. Vzhledem k tomu, že v tomto případu použití není očekávána konstantní propustnost s vysokým objemem, doporučuje se plán spotřeby , protože platíte pouze za výpočetní prostředky, které používáte.

Azure Cosmos DB

pro zřízenou propustnost a spotřebované úložiště po hodinách se Azure Cosmos DB účty. Zřízená propustnost je vyjádřena v jednotkách žádosti za sekundu (RU/s), která se dá použít pro typické databázové operace, jako jsou Insert, čtení. Cena je založena na kapacitě v RU/s, kterou si vyhradíte.

Storage se fakturuje za každou GB použitou pro uložená data a index.

další informace najdete v tématu Cosmos DB cenového modelu .

v této architektuře aplikace functions načte dokumenty z Cosmos DB v reakci na požadavky HTTP GET od klienta. Cosmos DATABÁZE je v tomto případě nákladově efektivní, protože operace čtení jsou významně levnější než operace zápisu vyjádřené na RU/s.

Content Delivery Network

Fakturační sazba se může lišit v závislosti na oblasti fakturace na základě umístění zdrojového serveru, který daný obsah doručuje koncovému uživateli. Fyzické umístění klienta není fakturační oblast. jakýkoli požadavek HTTP nebo HTTPS, který je v CDN, je fakturovatelná událost, která zahrnuje všechny typy odpovědí: úspěch, selhání nebo jiné. Různé odpovědi mohou generovat různé objemy provozu.

V této referenční architektuře se nasazení nachází v jedné oblasti Azure.

Pokud chcete snížit náklady, zvažte zvýšení hodnoty TTL mezipaměti uložením souborů prostředků do mezipaměti po delší dobu a nastavením nejdelší hodnoty TTL na váš obsah.

další informace najdete v části s náklady v Microsoft Azure Well-Architected Framework.

Nasazení řešení

informace o nasazení referenční implementace pro tuto architekturu najdete v souboru readme GitHub.

Další kroky

Další informace o implementaci reference najdete v článku návod kódu: aplikace bez serveru s Azure Functions.

Související pokyny:

• Osvědčené postupy pro používání sítě CDN
• Model hostování statického obsahu