Webová aplikace bez serveru

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure Functions

Azure Monitor

Tato referenční architektura ukazuje bezserverovou webovou aplikaci. Aplikace obsluhuje statický obsah ze služby Azure Blob Storage a implementuje rozhraní API pomocí Azure Functions. Rozhraní API čte data ze služby Azure Cosmos DB a vrací výsledky do webové aplikace.

Logo GitHubu Na GitHubu jsou k dispozici dvě referenční implementace pro tuto architekturu: aplikace pro doručování pomocí dronů (ARM a Azure Pipelines) a aplikace To Do (Bicep a GitHub Actions).

Architektura

Diagram znázorňující referenční architekturu pro bezserverovou webovou aplikaci

Stáhněte si soubor aplikace Visio s touto architekturou.

Pojem bezserverový 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á umožňují klientským aplikacím připojovat se přímo k těmto službám.
Funguje jako služba (FaaS). V tomto modelu je "funkce" součástí kódu, který je nasazený do cloudu a běží v hostitelském prostředí, které zcela abstrahuje servery, které kód spouští.

Obě definice mají společný názor, že vývojáři a pracovníci DevOps nemusí nasazovat, konfigurovat ani spravovat servery. Tato referenční architektura se zaměřuje na FaaS s využitím Azure Functions, i když poskytování webového obsahu ze služby Azure Blob Storage může být příkladem BaaS. Mezi důležité vlastnosti FaaS patří:

Výpočetní prostředky se přidělují dynamicky podle potřeby platformy.
Ceny založené na spotřebě: Poplatky se účtují jenom za výpočetní prostředky použité ke spuštění kódu.
Výpočetní prostředky se škálují na vyžádání na základě provozu, aniž by vývojář museli provádět žádnou konfiguraci.

Funkce se spouští, když dojde k externímu triggeru, například požadavek HTTP nebo zpráva přicházející do fronty. Díky tomu je styl architektury řízený událostmi přirozený pro bezserverové architektury. 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čí zprávy.

Komponenty

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ádají ve službě Azure Blob Storage a obsluhují se klientům pomocí hostování statických webů. Veškerá dynamická interakce probíhá prostřednictvím kódu JavaScriptu, který volá back-endová rozhraní API. K vykreslení webové stránky neexistuje žádný kód na straně serveru. Hostování statického webu podporuje indexové dokumenty a vlastní chybové stránky 404.

CDN. Pomocí služby Azure Content Delivery Network (CDN) můžete obsah ukládat do mezipaměti pro zajištění nižší latence a rychlejšího doručování obsahu a také poskytnutí koncového bodu HTTPS.

Aplikace funkcí. Azure Functions je bezserverová výpočetní možnost. Používá model řízený událostmi, kde aktivační událost vyvolá část kódu ("funkce"). 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, jak je popsáno níže.

API Management. Azure API Management poskytuje bránu rozhraní API, která se nachází před funkcí HTTP. Službu API Management můžete použít k publikování a správě rozhraní API používaných klientskými aplikacemi. Použití brány pomáhá oddělit front-endovou aplikaci od back-endových rozhraní API. Služba API Management může například přepsat adresy URL, transformovat požadavky dříve, než se dostanou k back-endu, nastaví hlavičky požadavků nebo odpovědí atd.

Službu API Management je možné použít také k implementaci průřezových aspektů, jako jsou:

Vynucení kvót využití a omezení četnosti
Ověřování tokenů OAuth
Povolení žádostí mezi zdroji (CORS)
odpovědi na Ukládání do mezipaměti
Monitorování a protokolování požadavků

Pokud nepotřebujete všechny funkce poskytované službou API Management, další možností je použít proxy služby Functions. Tato funkce Azure Functions umožňuje definovat jednu plochu rozhraní API pro více aplikací funkcí vytvořením tras do back-endových funkcí. Proxy funkce můžou také provádět omezené transformace požadavků a odpovědí HTTP. Neposkytují ale stejné bohaté možnosti založené na zásadách služby API Management.

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

Microsoft Entra ID (Microsoft Entra ID). Uživatelé se k webové aplikaci přihlašují pomocí svých přihlašovacích údajů Microsoft Entra ID . Microsoft Entra ID 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 Azure Monitor shromažďuje metriky výkonu o službách Azure nasazených v řešení. Vizualizací těchto prvků na řídicím panelu můžete získat přehled o stavu řešení. Také shromáždil protokoly aplikací.

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

GitHub Actions. Pracovní postup je automatizovaný proces (CI/CD), který jste nastavili v úložišti GitHub. Pomocí pracovního postupu můžete vytvářet, testovat, balit, vydávat nebo nasazovat jakýkoli projekt na GitHubu.

Podrobnosti scénáře

Potenciální případy použití

Toto řešení doručování pomocí dronů je ideální pro letecké, letecké, letecké a robotické odvětví.

Doporučení

Plány function app

Azure Functions podporuje dva modely hostování. S plánem spotřeby se výpočetní výkon automaticky přidělí, když je váš kód spuštěný. S plánem služby App Service se pro váš kód přidělí sada virtuálních počítačů. Plán služby App Service definuje počet virtuálních počítačů a velikost virtuálního počítače.

Mějte na paměti, že plán služby App Service není podle výše uvedené definice výhradně bez serveru. Programovací model je ale stejný – stejný kód funkce může běžet jak v plánu Consumption, tak v plánu služby App Service.

Tady je několik faktorů, které je potřeba vzít v úvahu při výběru typu plánu, který chcete použít:

Studený start. U plánu Consumption se při příštím spuštění funkce, která se nevyvolala v poslední době, způsobí další latenci. Tato další latence je způsobená přidělením a přípravou prostředí runtime. Obvykle je to v pořadí sekund, ale závisí na několika faktorech, včetně počtu závislostí, které je potřeba načíst. Další informace naleznete v tématu Principy bezserverového studeného startu. Studený start je obvykle větší obavou pro interaktivní úlohy (triggery HTTP) než asynchronní úlohy řízené zprávami (triggery fronty nebo centra událostí), protože další latence je přímo pozorována uživateli.
Časový limit. V plánu Consumption vyprší časový limit provádění funkce po konfigurovatelném časovém období (maximálně 10 minut).
Izolace virtuální sítě. Použití plánu služby App Service umožňuje spouštění funkcí uvnitř služby App Service Environment, což je vyhrazené a izolované hostitelské prostředí.
Cenový model. Plán consumption se účtuje počtem spuštění a spotřebou prostředků (paměť × době provádění). Plán služby App Service se účtuje každou hodinu na základě skladové položky instance virtuálního počítače. Plán consumption může být často levnější než plán služby 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 vaše dopravní špičky a průsely. Pokud ale aplikace používá konstantní vysokou propustnost svazku, může plán služby App Service stát méně než plán consumption.
Škálování. Velkou výhodou modelu consumption 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 existuje období zvětšování. U některých úloh můžete chtít virtuální počítače záměrně převést, abyste mohli zpracovávat nárůsty provozu s nulovým časem. V takovém případě zvažte plán služby App Service.

Hranice aplikace funkcí

Aplikace funkcí hostuje provádění jedné nebo více funkcí. Aplikaci funkcí můžete použít k seskupení několika funkcí jako logické jednotky. V rámci aplikace funkcí sdílejí funkce stejné nastavení aplikace, plán hostování a životní cyklus nasazení. Každá aplikace funkcí má vlastní název hostitele.

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

Zvažte přístup k mikroslužbám, kdy každá aplikace funkcí představuje jednu mikroslužbu, která se může skládat z několika souvisejících funkcí. V architektuře mikroslužeb by měly mít služby volné spojení a vysokou funkční soudržnost. Volně svázané znamená, že můžete změnit jednu službu, aniž byste museli aktualizovat další služby najednou. Cohesive znamená, že služba má jeden dobře definovaný účel. Další informace o těchto nápadech najdete v tématu Návrh mikroslužeb: Analýza domény.

Vazby funkcí

Pokud je to možné, použijte vazby functions. Vazby poskytují deklarativní způsob připojení kódu k datům a integraci s dalšími službami Azure. Vstupní vazba naplní vstupní parametr z externího zdroje dat. Výstupní vazba odešle návratovou hodnotu funkce do datové jímky, například do fronty nebo databáze.

Například GetStatus funkce v referenční implementaci používá vstupní vazbu Azure Cosmos DB. Tato vazba je nakonfigurovaná pro vyhledání dokumentu ve službě Azure Cosmos DB pomocí parametrů dotazu převzatých z řetězce dotazu v požadavku HTTP. Pokud se dokument najde, předá se funkci jako parametr.

[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)
{
  ...
}

Pomocí vazeb nemusíte psát kód, který komunikuje přímo se službou, což usnadňuje kód funkce a také abstrahuje podrobnosti o zdroji dat nebo jímce. V některých případech ale možná budete potřebovat složitější logiku, než poskytuje vazba. V takovém případě použijte sady SDK klienta Azure přímo.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Škálovatelnost

Functions. V případě plánu Consumption se trigger HTTP škáluje na základě provozu. Počet souběžných instancí funkcí je omezený, ale každá instance může zpracovat více než jeden požadavek najednou. V případě plánu služby App Service se trigger HTTP škáluje podle počtu instancí virtuálních počítačů, což může být pevná hodnota nebo automatické škálování na základě sady pravidel automatického škálování. Informace najdete v tématu Škálování a hostování azure Functions.

Azure Cosmos DB. Kapacita propustnosti služby Azure Cosmos DB se měří v jednotkách žádostí (RU). Propustnost 1 RU odpovídá propustnosti potřebné k získání 1kB dokumentu. Pokud chcete škálovat kontejner Azure Cosmos DB po 10 000 RU, musíte 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ů najdete v tématu Dělení a škálování ve službě Azure Cosmos DB.

API Management. Služba API Management může škálovat na více instancí a podporuje automatické škálování založené na pravidlech. Proces škálování trvá aspoň 20 minut. Pokud dojde k nárůstu provozu, měli byste zřídit maximální očekávaný provoz. 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.

Zotavení po havárii

Toto nasazení se nachází v jedné oblasti Azure. Pokud chcete odolnější přístup k zotavení po havárii, využijte funkce geografické distribuce v různých službách:

SLUŽBA API Management podporuje nasazení ve více oblastech, které je možné použít k distribuci jedné instance služby API Management napříč libovolným počtem oblastí Azure. Další informace najdete v tématu Nasazení instance služby Azure API Management do několika oblastí Azure.
Pomocí Traffic Manageru směrujte požadavky HTTP do primární oblasti. Pokud se aplikace funkcí spuštěná v této oblasti stane nedostupnou, Traffic Manager může převzít služby při selhání do sekundární oblasti.
Azure Cosmos DB podporuje více oblastí zápisu, což umožňuje zápisy do libovolné oblasti, kterou přidáte do účtu služby Azure Cosmos DB. Pokud nepovolíte více zápisů, můžete převzít služby při selhání primární oblasti zápisu. Klientské sady SDK služby Azure Cosmos DB a vazby funkce Azure Functions automaticky zpracovávají převzetí služeb při selhání, takže nemusíte aktualizovat žádná nastavení konfigurace aplikace.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Ověřování

Rozhraní GetStatus API v referenční implementaci používá k ověřování požadavků ID Microsoft Entra. Microsoft Entra ID podporuje protokol OpenID Připojení, což je ověřovací protokol 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 implicitní tok udělení je vhodný. (Viz Který tok OAuth 2.0 mám použít?). Tady je celkový tok:

Uživatel ve webové aplikaci klikne na odkaz Přihlásit se.
Prohlížeč je přesměrován na přihlašovací stránku Microsoft Entra.
Uživatel se přihlásí.
Microsoft Entra ID přesměruje zpět do klientské aplikace, včetně přístupového tokenu v fragmentu adresy URL.
Když webová aplikace volá rozhraní API, zahrnuje přístupový token v hlavičce Ověřování. ID aplikace se odešle jako deklarace identity cílové skupiny ('aud') v přístupovém tokenu.
Back-endové rozhraní API ověří přístupový token.

Konfigurace ověřování:

Zaregistrujte aplikaci v tenantovi Microsoft Entra. Tím se vygeneruje ID aplikace, které klient obsahuje s přihlašovací adresou URL.
Povolte ověřování Microsoft Entra v aplikaci funkcí. Další informace najdete v tématu Ověřování a autorizace ve službě Azure App Service.
Přidejte zásadu validate-jwt do služby API Management, abyste požadavek předem autorizovali ověřením přístupového tokenu.

Další podrobnosti najdete v souboru readme GitHubu.

Doporučujeme vytvořit samostatné registrace aplikací v Microsoft Entra ID pro klientskou aplikaci a back-endové rozhraní API. Udělte klientské aplikaci oprávnění k volání rozhraní API. Tento přístup poskytuje flexibilitu při definování více rozhraní API a klientů a řízení oprávnění pro každou z nich.

V rámci rozhraní API použijte obory k tomu, aby aplikace jemně odstupňovaly kontrolu nad tím, jaká oprávnění požadují od uživatele. Rozhraní API může Read mít například obory a Write konkrétní klientská aplikace může uživatele požádat o autorizaci Read oprávnění.

Autorizace

V mnoha aplikacích musí back-endové rozhraní API zkontrolovat, jestli má uživatel oprávnění k provedení dané akce. Doporučujeme použít autorizaci založenou na deklarací identity, kde informace o uživateli předávají zprostředkovatel identity (v tomto případě ID Microsoft Entra) a používá se k rozhodování o autorizaci. Když například zaregistrujete aplikaci v Microsoft Entra ID, můžete definovat sadu rolí aplikace. Když se uživatel přihlásí k aplikaci, Microsoft Entra ID obsahuje roles deklaraci identity pro každou roli, kterou uživatel udělil, včetně rolí zděděných prostřednictvím členství ve skupině.

Token ID, který Microsoft Entra ID vrátí klientovi, obsahuje některé deklarace identity uživatele. V aplikaci funkcí jsou tyto deklarace identity k dispozici v hlavičce X-MS-CLIENT-PRINCIPAL požadavku. Je ale jednodušší číst tyto informace z dat vazby. Pro jiné deklarace identity použijte Microsoft Graph k dotazování Microsoft Entra ID. (Uživatel musí při přihlašování odsouhlasit tuto akci.)

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

CORS

V této referenční architektuře webová aplikace a rozhraní API nesdílely 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 označuje jako zásada stejného původu a brání škodlivému webu ve čtení citlivých dat z jiného webu. Pokud chcete povolit požadavek mezi zdroji, přidejte do brány služby API Management 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 je atribut allow-credentials pravdivý. Tím se v prohlížeči autorizuje odeslání přihlašovacích údajů (včetně souborů cookie) s žádostí. V opačném případě prohlížeč ve výchozím nastavení neodesílá přihlašovací údaje s požadavkem mezi zdroji.

Poznámka:

Buďte velmi opatrní při nastavení povolených přihlašovacích údajů na hodnotu true, protože to znamená, že web může odeslat přihlašovací údaje uživatele do vašeho rozhraní API jménem uživatele, aniž by uživatel věděl. Musíte důvěřovat povolenému původu.

Vynucení HTTPS

Pokud chcete maximální zabezpečení, v rámci kanálu žádosti vyžadovat HTTPS:

CDN. Azure CDN ve výchozím nastavení podporuje HTTPS v *.azureedge.net subdoméně. Pokud chcete v CDN povolit HTTPS pro vlastní názvy domén, přečtěte si kurz : Konfigurace HTTPS pro vlastní doménu Azure CDN.
Hostování statického webu. V účtu úložiště povolte možnost Vyžadovat zabezpečený přenos. Pokud je tato možnost povolená, účet úložiště povoluje jenom požadavky ze zabezpečených připojení HTTPS.

API Management. Nakonfigurujte rozhraní API tak, aby používala pouze protokol HTTPS. Můžete to nakonfigurovat na webu Azure Portal nebo prostřednictvím šablony Resource Manageru:

{
    "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" ]
    },
    ...
}

Funkce Azure Functions. Povolte nastavení Pouze HTTPS.

Uzamčení aplikace funkcí

Všechna volání funkce by měla projít bránou rozhraní API. Můžete toho dosáhnout následujícím způsobem:

Nakonfigurujte aplikaci funkcí tak, aby vyžadovala klíč funkce. Brána SLUŽBY API Management bude obsahovat klíč funkce při volání aplikace funkcí. Tím zabráníte klientům v přímém volání funkce a obejít bránu.
Brána služby API Management má statickou IP adresu. Omezte funkci Azure Functions tak, aby povolovala pouze volání z této statické IP adresy. Další informace najdete v tématu Aplikace Azure Omezení statické IP adresy služby. (Tato funkce je dostupná jenom pro služby úrovně Standard.)

Ochrana tajných klíčů aplikací

Neukládejte tajné kódy aplikací, jako jsou přihlašovací údaje databáze, do kódu nebo konfiguračních souborů. Místo toho použijte nastavení aplikace, která jsou uložená zašifrovaná v Azure. Další informace najdete v tématu Zabezpečení ve službě Aplikace Azure a Azure Functions.

Případně můžete ukládat tajné kódy aplikací ve službě Key Vault. To vám umožní centralizovat ukládání tajných kódů, řídit jejich distribuci a monitorovat, jak a kdy se k tajným kódům přistupuje. Další informace najdete v tématu Konfigurace webové aplikace Azure pro čtení tajného kódu ze služby Key Vault. Mějte ale na paměti, že triggery a vazby služby Functions načítají nastavení konfigurace z nastavení aplikace. Neexistuje žádný integrovaný způsob konfigurace triggerů a vazeb pro použití tajných kódů služby Key Vault.

DevOps

Nasazení front-endu

Front-end této referenční architektury je jednostráková aplikace s JavaScriptem, která přistupuje k bezserverovým back-endovým rozhraním API a statický obsah poskytuje rychlý uživatelský zážitek. Tady je několik důležitých aspektů pro takovou aplikaci:

Nasaďte aplikaci jednotně uživatelům v široké geografické oblasti s globálními sítěmi CDN se statickým obsahem hostovaným v cloudu. Tím se zabrání nutnosti vyhrazeného webového serveru. Začněte tím, že si přečtete integraci účtu úložiště Azure s Azure CDN . Zabezpečte aplikaci pomocí protokolu HTTPS. Další doporučení najdete v osvědčených postupech pro používání sítí pro doručování obsahu.
Pomocí rychlé a spolehlivé služby CI/CD, jako je Azure Pipelines nebo GitHub Actions, můžete automaticky sestavovat a nasazovat všechny změny zdroje. Zdroj musí být umístěn v online systému správy verzí. Další podrobnosti o Službě Azure Pipelines najdete v tématu Vytvoření prvního kanálu. Další informace o GitHub Actions pro Azure najdete v tématu Nasazení aplikací do Azure.
Komprimujte soubory webu, abyste snížili spotřebu šířky pásma sítě CDN a zlepšili výkon. Azure CDN umožňuje kompresi za běhu na hraničních serverech. Kanál nasazení v této referenční architektuře také zkomprimuje 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 při výběru nástrojů pro kompresi bez ohledu na omezení CDN.
Síť CDN by měla být schopná vymazat mezipaměť , aby se zajistilo, že všichni uživatelé budou obsluhovat nejnovější obsah. Vymazání mezipaměti se vyžaduje, pokud procesy sestavení a nasazení nejsou atomické, například pokud nahradí staré soubory nově sestavenými ve stejné složce původu.
Jiná strategie mezipaměti, jako je správa verzí pomocí adresářů, nemusí vyžadovat vyprázdnění cdN. Kanál buildu 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í nasazení.
Zvyšte hodnotu TTL mezipaměti tím, že soubory prostředků ukládáte do mezipaměti delší dobu, což trvá několik měsíců. Pokud chcete zajistit, aby se soubory uložené v mezipaměti aktualizovaly při změně, otiskem prstu po opětovném vytvoření souboru. Tato front-endová aplikace otisky prstů všechny soubory s výjimkou veřejně přístupných souborů, jako jsou index.html. Vzhledem k tomu, že index.html se často aktualizuje, odráží změněné názvy souborů, které způsobují aktualizaci mezipaměti. Další informace najdete v tématu Správa vypršení platnosti webového obsahu v Azure CDN .

Back-endové nasazení

Pokud chcete nasadit aplikaci funkcí, doporučujeme použít soubory balíčků (Spustit z balíčku). Pomocí tohoto přístupu nahrajete soubor ZIP do kontejneru Blob Storage a modul runtime Functions připojí soubor ZIP jako systém souborů jen pro čtení. Jedná se o atomickou operaci, která snižuje pravděpodobnost, že neúspěšné nasazení opustí aplikaci v nekonzistentním stavu. Může také zlepšit časy studeného spuštění, zejména pro Node.js aplikace, protože všechny soubory se prohodí najednou.

Správa verzí API

Rozhraní API je kontrakt mezi službou a klienty. V této architektuře je kontrakt rozhraní API definovaný ve vrstvě SLUŽBY API Management. API Management podporuje dva odlišné, ale doplňkové koncepty správy verzí:

Verze umožňují uživatelům rozhraní API zvolit verzi rozhraní API na základě jejich potřeb, například verze 1 a v2.
Revize umožňují správcům rozhraní API provádět v rozhraní API změny, které nejsou zásadní, a nasazovat tyto změny spolu s protokolem změn, který informuje uživatele rozhraní API o těchto změnách.

Pokud v rozhraní API provedete zásadní změnu, publikujte novou verzi ve službě API Management. Nasaďte novou verzi souběžně s původní verzí v samostatné aplikaci funkcí. Díky tomu můžete migrovat stávající klienty do nového rozhraní API bez přerušení klientských aplikací. Nakonec můžete předchozí verzi přestat používat. Api Management podporuje několik schémat správy verzí: cestu URL, hlavičku HTTP nebo řetězec dotazu. Další informace o správě verzí rozhraní API obecně najdete v tématu Správa verzí webového rozhraní RESTful API.

V případě aktualizací, které nejsou zásadními změnami rozhraní API, nasaďte novou verzi do přípravného slotu ve stejné aplikaci funkcí. Ověřte, že nasazení proběhlo úspěšně, a pak prohoďte fázovanou verzi s produkční verzí. Publikování revize ve službě API Management

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

K odhadu nákladů použijte cenovou kalkulačku Azure. Zvažte tyto body pro optimalizaci nákladů na tuto architekturu.

Azure Functions

Azure Functions podporuje dva modely hostování.

Plán Consumption

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

Pro váš kód se přidělí sada 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 se funkce vyvolá, když klient vytvoří požadavek HTTP. Vzhledem k tomu, že se v tomto případě použití neočekává konstantní vysoká propustnost, doporučuje se plán Consumption, protože platíte jenom za výpočetní prostředky, které používáte.

Azure Cosmos DB

Azure Cosmos DB účtuje zřízenou propustnost a spotřebované úložiště po hodinách. Zřízená propustnost se vyjadřuje v jednotkách žádostí za sekundu (RU/s), které se dají použít pro typické databázové operace, jako jsou vložení, čtení. Cena vychází z kapacity v RU/s, kterou si rezervujete.

Úložiště se účtuje za každou GB použitou pro uložená data a index.

Další informace najdete v cenovém modelu služby Azure Cosmos DB.

V této architektuře aplikace funkcí načítá dokumenty ze služby Azure Cosmos DB v reakci na požadavky HTTP GET z klienta. Azure Cosmos DB je v tomto případě nákladově efektivní, protože operace čtení jsou výrazně levnější než operace zápisu vyjádřené u RU/s.

Content Delivery Network

Fakturační sazba se může lišit v závislosti na oblasti fakturace v závislosti na umístění zdrojového serveru, který doručuje obsah koncovému uživateli. Fyzické umístění klienta není fakturační oblastí. Jakýkoli požadavek HTTP nebo HTTPS, který se dostane do CDN, je fakturovatelná událost, která zahrnuje všechny typy odpovědí: úspěch, selhání nebo jiný. Různé odpovědi můžou 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 tím, že soubory prostředků ukládáte do mezipaměti po delší dobu a nastavíte nejdelší možnou hodnotu TTL obsahu.

Další informace najdete v části Náklady v architektuře Microsoft Azure Well-Architected Framework.

Nasazení tohoto scénáře

Pokud chcete nasadit referenční implementaci pro tuto architekturu, přečtěte si soubor readme GitHubu.

Další kroky

Dokumentace k produktu:

Moduly learn:

Další informace o referenční implementaci najdete v průvodci kódem: Bezserverová aplikace se službou Azure Functions.

Související pokyny:

Webová aplikace bez serveru

Architektura

Komponenty

Podrobnosti scénáře

Potenciální případy použití

Doporučení

Plány function app

Hranice aplikace funkcí

Vazby funkcí

Důležité informace

Škálovatelnost

Zotavení po havárii

Zabezpečení

Ověřování

Autorizace

CORS

Vynucení HTTPS

Uzamčení aplikace funkcí

Ochrana tajných klíčů aplikací

DevOps

Nasazení front-endu

Back-endové nasazení

Správa verzí API

Optimalizace nákladů

Azure Functions

Azure Cosmos DB

Content Delivery Network

Nasazení tohoto scénáře

Další kroky

Váš názor

Váš názor

Další materiály

Webová aplikace bez serveru

Architektura

Komponenty

Podrobnosti scénáře

Potenciální případy použití

Doporučení

Plány function app

Hranice aplikace funkcí

Vazby funkcí

Důležité informace

Škálovatelnost

Zotavení po havárii

Zabezpečení

Ověřování

Autorizace

CORS

Vynucení HTTPS

Uzamčení aplikace funkcí

Ochrana tajných klíčů aplikací

DevOps

Nasazení front-endu

Back-endové nasazení

Správa verzí API

Optimalizace nákladů

Azure Functions

Azure Cosmos DB

Content Delivery Network

Nasazení tohoto scénáře

Další kroky

Související prostředky

Váš názor

Váš názor

Další materiály