Software jako služba (SaaS) je komplexní téma s mnoha body, které je potřeba zvážit. Nezávislí dodavatelé softwaru (ISV), kteří vytvářejí řešení SaaS v Azure, potřebují řešit problémy a rozhodovat se například takto:
- Který model tenantů mám použít?
- Návody nastavit řešení identit pro použití v architektuře s více tenanty?
- Návody zvládnout onboarding nových zákazníků?
Cílem této architektury je zodpovědět některé z těchto otázek a poskytnout počáteční místo ve světě SaaS. Tato architektura je přizpůsobitelná tak, aby vyhovovala široké škále scénářů.
Potenciální případy použití
Tady je několik příkladů případů použití, ve kterých můžete použít tuto architekturu:
- Modernizujte stávající aplikaci, která podporuje plnou víceklientské prostředí jako součást přechodu na obchodní model založený na SaaS.
- Vytvořte zcela novou nabídku SaaS.
- Migrace nabídky SaaS z jiné cloudové služby do Azure
Architektura
Stáhněte si soubor PowerPointu této architektury.
Terminologie
Následující tabulka popisuje termíny, které se zobrazují v tomto článku.
Období | Popis | Příklad |
---|---|---|
Dodavatel SaaS nebo isV | Entita, která vlastní aplikaci SaaS a kód a prodává produkt SaaS. | Společnost Contoso Inc, která prodává svou aplikaci SaaS: Lístky společnosti Contoso. |
Tenant | Zakoupená instance aplikace SaaS od dodavatele SaaS | Čtvrtá kavárna. |
Správce zákazníků SaaS | Lidé, kteří si kupují nebo spravují tenanta aplikace. | Joe, majitel čtvrté kavárny. |
Uživatel SaaS zákazníka | Lidé, kteří používají tenanta aplikace, aniž by ho spravovali, a obvykle patří do stejné společnosti nebo skupiny jako správce zákazníka SaaS. | Jill, event manager ve čtvrté kavárně a Susan, zákazník čtvrté kavárny. |
Koncový uživatel | Správce zákazníka SaaS, uživatel zákazníka SaaS nebo jakékoli jiné typy uživatelů, které jsou zavedeny. Toto je obecný termín, který popisuje uživatele, kteří se přihlašují k aplikaci. | Joe, Jill a Susan jsou všichni koncoví uživatelé (z pohledu ISV). |
Front-endová aplikace | Libovolná front-endová aplikace. | Aplikace onboardingu a správce a aplikace SaaS jsou jak front-endové aplikace, tak i aplikace SaaS. |
Workflow
Správce zákazníka SaaS přejde na web hostovaný v aplikaci Onboarding a admin.
Správce zákazníka SaaS se přihlásí pomocí pracovního postupu přihlašování uživatele.
Správce zákazníka SaaS dokončí tok onboardingu.
Správce zákazníka SaaS přejde do oblasti pro správu tenanta v aplikaci Onboarding a admin a přidá uživatele SaaS Customer do nově vytvořeného tenanta.
Uživatel SaaS přejde do aplikace aplikace SaaS a používá aplikaci SaaS.
Přihlášení uživatele
Pracovní postup přihlašování uživatele se skládá z následujících kroků:
Koncový uživatel přejde do front-endové aplikace a vybere tlačítko Přihlásit se.
Front-endová aplikace přesměruje koncového uživatele na přihlašovací stránku, která je hostovaná zprostředkovatelem identity.
Koncový uživatel zadá informace o účtu a odešle přihlašovací formulář zprostředkovateli identity.
Zprostředkovatel identity vydá požadavek POST s e-mailovou adresou koncového uživatele a ID objektu, aby načetl svá oprávnění a role.
Rozhraní API pro data oprávnění vyhledá informace koncového uživatele v úložišti dat oprávnění a vrátí seznam oprávnění a rolí přiřazených danému koncovému uživateli.
Zprostředkovatel identity přidá oprávnění a role jako vlastní deklarace identity do tokenu ID, což je webový token JSON (JWT).
Zprostředkovatel identity vrátí koncovému uživateli token ID a zahájí přesměrování na front-endovou aplikaci.
Koncový uživatel se přesměruje do koncového bodu přihlášení v front-endové aplikaci a zobrazí token ID.
Front-endová aplikace ověří uvedený token ID.
Front-endová aplikace vrátí úspěšnou přihlašovací stránku a koncový uživatel je teď přihlášený.
Další informace o tom, jak tento tok přihlašování funguje, najdete v tématu Protokol OpenID Connect.
Připojení nového tenanta
Pracovní postup onboardingu tenanta se skládá z následujících kroků:
Správce zákazníka SaaS přejde do aplikace Onboarding a admin a dokončí registrační formulář.
Aplikace onboardingu a správce vydává požadavek POST na rozhraní API pro data tenanta za účelem vytvoření nového tenanta.
Rozhraní API pro data tenanta vytvoří nového tenanta v úložišti dat tenanta.
Rozhraní API pro data tenanta vydává požadavek POST na rozhraní API pro data oprávnění, aby udělilo nově vytvořenému tenantovi oprávnění správce zákazníka SaaS.
Rozhraní API pro data oprávnění vytvoří nový záznam oprávnění v úložišti dat oprávnění.
Rozhraní API pro data oprávnění se úspěšně vrátí.
Rozhraní API pro data tenanta se úspěšně vrátí.
Aplikace onboardingu a správce vydá žádost POST poskytovateli e-mailových oznámení, aby odeslala e-mailovou zprávu o vytvoření tenanta správci zákazníka SaaS.
Poskytovatel e-mailových oznámení odešle e-mail.
Poskytovatel e-mailových oznámení se úspěšně vrátí.
Aplikace onboardingu a správce vydá žádost zprostředkovateli identity, aby aktualizoval token ID správce zákazníka SaaS, aby zahrnoval deklaraci identity do nově vytvořeného tenanta.
Zprostředkovatel identity vydá žádost POST s e-mailovou adresou a ID objektu správce SaaS za účelem načtení svých oprávnění a rolí.
Rozhraní API pro data oprávnění vyhledá informace správce zákazníka SaaS v úložišti dat oprávnění a vrátí seznam oprávnění a rolí přiřazených správci zákazníka SaaS.
Zprostředkovatel identity přidá oprávnění a role jako vlastní deklarace identity do tokenu ID.
Zprostředkovatel identity vrátí token ID do aplikace onboardingu a správce.
Aplikace onboardingu a správce vrátí zprávu o úspěchu a novému tokenu ID pro správce zákazníka SaaS.
Přidání uživatele do tenanta
Přidání uživatele do pracovního postupu tenanta se skládá z následujících kroků:
Správce zákazníka SaaS požádá o zobrazení seznamu tenantů z oblasti pro správu tenanta v aplikaci Onboarding a admin.
Aplikace Pro onboarding a správu vydává požadavek GET na rozhraní API pro data tenanta, aby získal seznam tenantů pro správce zákazníka SaaS.
Rozhraní API pro data tenanta vydává požadavek GET na rozhraní API pro data oprávnění, aby získal seznam tenantů, ke kterým má správce zákazníka SaaS přístup k zobrazení.
Rozhraní API pro data oprávnění vrátí seznam oprávnění tenanta.
Rozhraní API dat tenanta vyhledá informace o tenantovi v úložišti dat tenanta a vrátí seznam dat tenanta na základě seznamu přijatých oprávnění tenanta.
Aplikace Pro onboarding a správu vrátí seznam dat tenanta správci SaaS.
Správce zákazníka SaaS vybere ze seznamu tenanta a přidá uživatele zákazníka SaaS a zadá e-mailovou adresu pro uživatele zákazníka SaaS.
Aplikace onboardingu a správce vydá žádost POST do rozhraní API pro data tenanta, aby v zadaném tenantovi přidala oprávnění pro zákazníka SaaS.
Rozhraní API dat tenanta ověřuje, že správce zákazníka SaaS má platnou deklaraci identity JWT pro zadaného tenanta a má k němu oprávnění k zápisu uživatele.
Rozhraní API pro data tenanta vydává požadavek POST na rozhraní API pro data oprávnění pro přidání oprávnění pro uživatele SaaS zákazníka v zadaném tenantovi.
Rozhraní API pro data oprávnění vydá žádost GET zprostředkovateli identity, aby vyhledala uživatele SaaS podle zadané e-mailové adresy.
Zprostředkovatel identity vrátí ID objektu uživatele SaaS zákazníka.
Rozhraní API pro data oprávnění přidá záznam oprávnění v úložišti dat oprávnění pro uživatele SaaS v zadaném tenantovi pomocí ID objektu.
Rozhraní API pro data oprávnění se úspěšně vrátí.
Rozhraní API pro data tenanta se úspěšně vrátí.
Aplikace pro onboarding a správu se úspěšně vrátí.
Komponenty
Tato architektura používá následující služby Azure:
App Service umožňuje vytvářet a hostovat webové aplikace a aplikace API v programovacím jazyce, který si zvolíte, aniž byste museli spravovat infrastrukturu.
Azure Active Directory B2C umožňuje snadnou správu identit a přístupu pro aplikace koncových uživatelů.
Azure SQL Database je spravovaná služba relační databáze pro obecné účely, která podporuje relační data, prostorová data, JSON a XML.
Azure Logic Apps umožňuje rychle vytvářet výkonné integrace pomocí jednoduchého grafického uživatelského rozhraní (GUI).
Alternativy
Efektivita jakékoli alternativní volby závisí výrazně na modelu tenantů, který máte v úmyslu, aby vaše aplikace SaaS podporovala. Následuje několik příkladů alternativních přístupů, které můžete sledovat při implementaci tohoto řešení:
Aktuální řešení jako zprostředkovatele identity používá Azure Active Directory B2C. Místo toho můžete použít jiné zprostředkovatele identity, například ID Microsoft Entra.
V případě přísnějších požadavků na zabezpečení a dodržování předpisů byste se mohli rozhodnout implementovat privátní sítě pro komunikaci mezi službami.
Místo volání REST mezi službami můžete implementovat styl architektury řízený událostmi pro zasílání zpráv mezi službami.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete využít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
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í.
Toto řešení spoléhá na identitu jako své paradigmatu zabezpečení. Ověřování a autorizace webových aplikací a rozhraní API se řídí platformou Microsoft Identity Platform, která zodpovídá za vydávání a ověřování tokenů ID uživatele (JWT).
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ů.
Komponenty v tomto řešení mají určité náklady spojené s jejich provozem, ale náklady jsou pro většinu webových aplikací a řešení SaaS skromné. Náklady můžete řídit také správou následujících nastavení prostředků:
Plán služby App Service, který aplikaci spouští, můžete škálovat tak, aby odpovídal požadované propustnosti. Kromě toho můžete každou aplikaci spustit v samostatném plánu, pokud potřebujete vyšší propustnost, ale v důsledku toho se vám budou vyžadovat vyšší náklady. Další informace najdete v tématu Aplikace Azure Přehled plánu služby.
Azure AD B2C poskytuje dvě skladové položky: Premium P1 a Premium P2. Obě skladové položky zahrnují bezplatný příspěvek pro počet aktivních měsíčních uživatelů (MAU), ale musíte vyhodnotit, které funkce jednotlivé skladové položky poskytují k určení, které jsou pro váš případ použití potřeba. Další informace najdete v tématu Microsoft Entra Externí ID cenách.
Azure SQL má několik nákupních modelů, které odpovídají široké škále případů použití, včetně možnosti automatického škálování. Abyste měli jistotu, že je velikost správně nastavte, musíte vyhodnotit využití na vlastních databázích. Další informace najdete v tématu Porovnání nákupních modelů založených na virtuálních jádrech a DTU služby Azure SQL Database.
Efektivita výkonu
Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v tématu Přehled pilíře efektivity výkonu.
Tato architektura by měla být schopná škálovat tak, aby splňovala většinu středně až středně velkých úloh. Vzhledem k tomu, že architektura většinou využívá služby Platformy Azure (platforma jako služba (PaaS), máte mnoho možností, jak upravit škálování řešení na základě vašich požadavků a zatížení.
Nasazení tohoto scénáře
Pokud chcete tento scénář nasadit, podívejte se na sadu Azure SaaS Dev Kit na GitHubu. Jedná se o nasaditelnou referenční implementaci této architektury.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Landon Pierce | Customer Engineer
Další přispěvatelé:
- Chris Ayers | Vedoucí zákaznický inženýr
- John Downs | Vedoucí zákaznický inženýr
- LaBrina Láska | Hlavní technický manažer SVC
- Gary Moore | Programátor/zapisovač
- Nick Pinheiro | Vedoucí konzultant
- William Salazar | Vedoucí zákaznický inženýr
- Ali Sanjabi | Vedoucí zákaznický inženýr
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr
- Jason Young | Hlavní technický manažer SVC
Další kroky
Tady je několik dalších doporučených prostředků pro vytvoření aplikace SaaS v Azure:
- Navrhování víceklientských řešení v Azure – Popisuje osvědčené postupy.
- Důležité informace o nezávislých výrobců softwaru pro cílové zóny Azure
- Dobře navržená architektura Microsoft Azure
- Aplikace WingTips Tickets SaaS – poskytuje podrobnosti o kompromisech mezi různými modely tenantů v rámci databázové vrstvy.
Související prostředky
- Modely tenantů, které je potřeba zvážit pro víceklientské řešení
- Přístupy architektury pro výpočetní prostředky ve víceklientských řešeních
- Přístupy k architektuře pro ukládání a data ve víceklientských řešeních
- Aspekty služby Aplikace Azure a Azure Functions pro víceklientské prostředí
- Víceklientské SaaS v Azure
- Vzory návrhu cloudu