Aspekty služby Aplikace Azure a Azure Functions pro víceklientské prostředí

Azure
Azure App Service
Azure Functions

Aplikace Azure Service je výkonná platforma pro hostování webových aplikací. Služba Azure Functions založená na infrastruktuře služby App Service umožňuje snadno vytvářet bezserverové výpočetní úlohy a výpočetní úlohy řízené událostmi. Obě služby se často používají ve víceklientských řešeních.

Funkce služby Aplikace Azure a Azure Functions, které podporují víceklientské prostředí

služba Aplikace Azure a Azure Functions zahrnují řadu funkcí, které podporují víceklientské prostředí.

Vlastní názvy domén

Aplikace Azure Služba umožňuje používat DNS se zástupnými znaků a přidávat vlastní certifikáty TLS se zástupnými cardy. Pokud používáte subdomény specifické pro tenanty, umožňují certifikáty DNS a TLS se zástupnými čísly snadno škálovat na velký počet tenantů bez nutnosti ruční rekonfigurace pro každého nového tenanta.

Pokud používáte vlastní názvy domén specifických pro tenanta, můžete mít velký počet vlastních názvů domén, které je potřeba přidat do aplikace. Může být těžkopádný ke správě velkého množství vlastních názvů domén, zejména pokud vyžadují jednotlivé certifikáty TLS. App Service poskytuje spravované certifikáty TLS, které snižují potřebnou práci při práci s vlastními doménami. Existuje však omezení, která je potřeba vzít v úvahu, například kolik vlastních domén se dá použít u jedné aplikace.

Integrace se službou Azure Front Door

Služba App Service a Azure Functions se integrují se službou Azure Front Door, aby fungovaly jako internetová komponenta vašeho řešení. Azure Front Door umožňuje přidat firewall webových aplikací (WAF) a ukládání do mezipaměti edge a poskytuje další optimalizace výkonu. Toky provozu můžete snadno překonfigurovat tak, aby směrovat provoz do různých back-endů na základě měnících se obchodních nebo technických požadavků.

Když používáte Azure Front Door s víceklientovou aplikací, můžete ho použít ke správě vlastních názvů domén a k ukončení připojení TLS. Aplikace služby App Service se pak nakonfiguruje s jedním názvem hostitele a veškerý provoz prochází do této aplikace, což vám pomůže vyhnout se správě vlastních názvů domén na více místech.

Diagram showing requests coming into Front Door using a variety of host names. The requests are passed to the App Service app using a single host name.

Stejně jako v předchozím příkladu je možné službu Azure Front Door nakonfigurovat tak, aby upravovala hlavičkuHost požadavku. Původní Host hlavička odeslaná klientem se rozšíří prostřednictvím X-Forwarded-Host hlavičky a kód aplikace může použít tuto hlavičku k mapování požadavku na správného tenanta.

Upozorňující

Pokud vaše aplikace odesílá soubory cookie nebo odpovědi na přesměrování, musíte věnovat zvláštní pozornost. Změny v hlavičce požadavku Host můžou tyto odpovědi zneplatnit. Další informace najdete v osvědčených postupech pro zachování názvů hostitelů.

Pomocí privátních koncových bodů nebo omezení přístupu ke službě App Service můžete před dosažením aplikace zajistit, aby provoz protékal službou Front Door.

Další informace o používání služby Azure Front Door ve víceklientských řešeních najdete v tématu Použití služby Azure Front Door ve víceklientských řešeních.

Ověřování a autorizace

Aplikace Azure Služba může ověřovat ověřovací tokeny jménem vaší aplikace. Když App Service obdrží požadavek, zkontroluje, jestli jsou splněné všechny následující podmínky:

  • Požadavek obsahuje token.
  • Token je platný.
  • Žádost je autorizovaná.

Pokud některé z podmínek nejsou splněné, služba App Service může žádost zablokovat nebo může uživatele přesměrovat na vašeho zprostředkovatele identity, aby se mohl přihlásit.

Pokud vaši tenanti jako svůj systém identit používají ID Microsoft Entra, můžete nakonfigurovat službu Aplikace Azure Service tak, aby pomocí koncového bodu /common ověřili tokeny uživatele. Tím se zajistí, že bez ohledu na tenanta Microsoft Entra uživatele se jejich tokeny ověří a přijmou.

Službu Aplikace Azure můžete také integrovat s Azure AD B2C pro ověřování uživatelů.

Další informace:

Omezení přístupu

Provoz do aplikace můžete omezit pomocí omezení přístupu. Můžete je použít k určení rozsahů IP adres nebo virtuálních sítí, které se můžou připojit k aplikaci.

Při práci s víceklientovým řešením mějte na paměti maximální počet pravidel omezení přístupu. Pokud například potřebujete vytvořit pravidlo omezení přístupu pro každého tenanta, můžete překročit maximální povolený počet pravidel. Pokud potřebujete větší počet pravidel, zvažte nasazení reverzního proxy serveru, jako je Azure Front Door.

Modely izolace

Při práci s víceklientovým systémem pomocí služby Aplikace Azure Service nebo Azure Functions musíte rozhodnout o úrovni izolace, kterou chcete použít. Projděte si modely tenantů, které byste měli zvážit pro víceklientské řešení, a pokyny uvedené v přístupech architektury k výpočetním prostředkům ve víceklientských řešeních, které vám pomůžou vybrat nejlepší model izolace pro váš scénář.

Při práci se službou Aplikace Azure Service a Azure Functions byste měli znát následující klíčové koncepty:

  • Ve službě Aplikace Azure Service představuje plán vaši infrastrukturu hostování. Aplikace představuje jednu aplikaci spuštěnou v této infrastruktuře. Do jednoho plánu můžete nasadit více aplikací.
  • Ve službě Azure Functions jsou hostování a aplikace také oddělené, ale máte k dispozici další možnosti hostování pro elastické hostování, kde azure Functions spravuje škálování za vás. Pro zjednodušení odkazujeme na infrastrukturu hostování jako na plán v tomto článku, protože principy popsané zde platí pro Službu App Service i Azure Functions bez ohledu na model hostování, který používáte.

Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro službu Aplikace Azure Service a Azure Functions:

Situace Sdílené aplikace Aplikace na tenanta se sdílenými plány Plány na tenanta
Izolace konfigurace nízkou Střední. Nastavení na úrovni aplikace jsou vyhrazená pro tenanta, nastavení na úrovni plánu se sdílí. Vysoká. Každý tenant může mít vlastní konfiguraci.
Izolace výkonu nízkou Nízká střední. Potenciálně vystavené problémům s hlučnou sousedou Vyšší
Složitost nasazení nízkou Medium Vyšší
Provozní složitost Malý zájem Velký zájem Vyšší
Náklady na zdroje nízkou Nízká-vysoká v závislosti na aplikaci Vyšší
Ukázkový scénář Velké víceklientové řešení se sdílenou aplikační vrstvou Migraceaplikacích Aplikační vrstva s jedním tenantem

Sdílené aplikace

Sdílenou aplikaci můžete nasadit do jednoho plánu a použít sdílenou aplikaci pro všechny vaše tenanty.

Jedná se o nákladově nejefektivnější možnost a vyžaduje nejnižší provozní režii, protože ke správě je méně prostředků. Celkový plán můžete škálovat na základě zatížení nebo poptávky a všichni tenanti, kteří plán sdílejí, budou těžit ze zvýšené kapacity.

Je důležité vědět o kvótách a omezeních služby App Service, jako je maximální počet vlastních domén, které je možné přidat do jedné aplikace, a maximální počet instancí plánu, který je možné zřídit.

Abyste mohli tento model používat, musí být kód aplikace s podporou víceklientské architektury.

Aplikace na tenanta se sdílenými plány

Svůj plán můžete také sdílet mezi více tenanty, ale pro každého tenanta nasadit samostatné aplikace. Díky tomu máte logickou izolaci mezi každým tenantem a tímto přístupem získáte následující výhody:

  • Efektivita nákladů: Sdílením hostitelské infrastruktury můžete obecně snížit celkové náklady na tenanta.
  • Oddělení konfigurace: Aplikace každého tenanta může mít svůj vlastní název domény, certifikát TLS, omezení přístupu a zásady autorizace tokenů.
  • Oddělení upgradů: Binární soubory aplikací každého tenanta je možné upgradovat nezávisle na ostatních aplikacích ve stejném plánu.

Vzhledem k tomu, že jsou výpočetní prostředky plánu sdílené, můžou být aplikace předmětem problému Hlučný soused. Kromě toho platí omezení počtu aplikací, které je možné nasadit do jednoho plánu.

Poznámka

Nepoužívejte sloty nasazení pro různé tenanty. Sloty neposkytují izolaci prostředků. Jsou navržené pro scénáře nasazení, když potřebujete mít několik verzí aplikace spuštěných na krátkou dobu, například modrá-zelená nasazení a kanárná strategie zavedení.

Plány na tenanta

Nejsilnější úrovní izolace je nasazení vyhrazeného plánu pro tenanta. Tento vyhrazený plán zajistí, že tenant bude plně používat všechny prostředky serveru, které jsou k tomuto plánu přiděleny.

Tento přístup umožňuje škálovat řešení tak, aby poskytovalo izolaci výkonu pro každého tenanta a vyhnuli se problému s hlučným sousedem. Má ale také vyšší náklady, protože prostředky se nesdílí s více tenanty. Musíte také zvážit maximální počet plánů , které je možné nasadit do jedné skupiny prostředků Azure.

Rozhraní API hostitele

Rozhraní API můžete hostovat jak ve službě Aplikace Azure, tak ve službě Azure Functions. Volba platformy bude záviset na konkrétní sadě funkcí a možnostech škálování, které potřebujete.

Bez ohledu na platformu, kterou používáte k hostování rozhraní API, zvažte použití služby Azure API Management před vaší aplikací API. SLUŽBA API Management poskytuje mnoho funkcí, které můžou být užitečné pro víceklientské řešení, včetně následujících:

  • Centralizovaný bod pro veškeré ověřování. To může zahrnovat určení identifikátoru tenanta z deklarace identity tokenu nebo jiných metadat požadavků.
  • Směrování požadavků na různé back-endy rozhraní API, které můžou být založené na identifikátoru tenanta požadavku. To může být užitečné, když hostujete více razítek nasazení s vlastními nezávislými aplikacemi API, ale pro všechny požadavky musíte mít jednu adresu URL rozhraní API.

Sítě a víceklientská architektura

Adresy IP

Mnoho víceklientských aplikací se musí připojit k místním sítím tenantů, aby bylo možné odesílat data.

Pokud potřebujete odesílat odchozí provoz ze známé statické IP adresy nebo ze sady známých statických IP adres, zvažte použití služby NAT Gateway. Další informace o tom, jak používat SLUŽBU NAT Gateway ve víceklientských řešeních, najdete v tématu Důležité informace o službě Azure NAT Gateway pro víceklientské prostředí. App Service poskytuje pokyny k integraci se službou NAT Gateway.

Pokud nepotřebujete statickou odchozí IP adresu, ale potřebujete občas zkontrolovat IP adresu, kterou vaše aplikace používá pro odchozí provoz, můžete dotazovat aktuální IP adresy nasazení služby App Service.

Kvóty

Vzhledem k tomu, že služba App Service je sama o víceklientských službách, musíte se postarat o to, jak používáte sdílené prostředky. Sítě jsou oblast, na kterou je potřeba věnovat zvláštní pozornost, protože existují omezení , která ovlivňují způsob, jakým může vaše aplikace pracovat s příchozími i odchozími síťovými připojeními, včetně limitů překladu zdrojových síťových adres (SNAT) a portů TCP.

Pokud se vaše aplikace připojuje k velkému počtu databází nebo externích služeb, může být vaše aplikace ohrožena vyčerpáním portů SNAT. Obecně platí, že vyčerpání portů SNAT značí, že váš kód správně nereusuje připojení TCP, a dokonce i v řešení s více tenanty, měli byste zajistit, abyste postupli podle doporučených postupů pro opakované použití připojení.

V některých víceklientských řešeních ale počet odchozích připojení k odlišným IP adresám může vést k vyčerpání portů SNAT, i když dodržujete osvědčené postupy kódování. V těchto scénářích zvažte jednu z následujících možností:

I s těmito ovládacími prvky můžete přistupovat k omezením s velkým počtem tenantů, takže byste měli naplánovat škálování na další plány služby App Service nebo razítka nasazení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

  • John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Projděte si materiály pro architekty a vývojáře víceklientských řešení.