Úvodní webová aplikace pro vývoj SaaS

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.

Workflow

1. Správce zákazníka SaaS přejde na web hostovaný v aplikaci Onboarding a admin.

2. Správce zákazníka SaaS se přihlásí pomocí pracovního postupu přihlašování uživatele.

3. Správce zákazníka SaaS dokončí tok onboardingu.

4. Správce zákazníka SaaS přejde do oblasti pro správu tenanta v aplikaciOnboarding a admin a přidá uživatele SaaS Customer do nově vytvořeného tenanta.

5. 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ů:

1. Koncový uživatel přejde do front-endové aplikace a vybere tlačítko Přihlásit se.

2. Front-endová aplikace přesměruje koncového uživatele na přihlašovací stránku, která je hostovaná zprostředkovatelem identity.

3. Koncový uživatel zadá informace o účtu a odešle přihlašovací formulář zprostředkovateli identity.

4. Zprostředkovatelidentity vydá požadavek POST s e-mailovou adresou koncového uživatele a ID objektu, aby načetl svá oprávnění a role.

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

6. Zprostředkovatel identity přidá oprávnění a role jako vlastní deklarace identity do tokenu ID, což je webový token JSON (JWT).

7. Zprostředkovatel identity vrátí koncovému uživateli token ID a zahájí přesměrování na front-endovou aplikaci.

8. Koncový uživatel se přesměruje do koncového bodu přihlášení v front-endové aplikaci a zobrazí token ID.

9. Front-endová aplikace ověří uvedený token ID.

10. 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 OpenID Připojení protokol.

Připojení nového tenanta

Pracovní postup onboardingu tenanta se skládá z následujících kroků:

1. Správce zákazníka SaaS přejde do aplikace Onboarding a admin a dokončí registrační formulář.

2. Aplikace onboardingu a správce vydává požadavek POST na rozhraní API pro data tenanta za účelem vytvoření nového tenanta.

3. Rozhraní API pro data tenanta vytvoří nového tenanta v úložišti dat tenanta.

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

5. Rozhraní API pro data oprávnění vytvoří nový záznam oprávnění v úložišti dat oprávnění.

6. Rozhraní API pro data oprávnění se úspěšně vrátí.

7. Rozhraní API pro data tenanta se úspěšně vrátí.

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

9. Poskytovatel e-mailových oznámení odešle e-mail.

10. Poskytovatel e-mailových oznámení se úspěšně vrátí.

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

12. Zprostředkovatelidentity vydá žádost POST s e-mailovou adresou a ID objektu správce SaaS za účelem načtení svých oprávnění a rolí.

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

14. Zprostředkovatel identity přidá oprávnění a role jako vlastní deklarace identity do tokenu ID.

15. Zprostředkovatel identity vrátí token ID do aplikace pro onboarding a Správa.

16. Aplikace onboardingu a správce vrátí zprávu o úspěchu a nový token ID pro zákazníka SaaS Správa.

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

1. Správce zákazníka SaaS požádá o zobrazení seznamu tenantů z oblasti pro správu tenanta v aplikaci Onboarding a admin.

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

3. 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í.

4. Rozhraní API pro data oprávnění vrátí seznam oprávnění tenanta.

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

6. Aplikace Pro onboarding a správu vrátí seznam dat tenanta správci SaaS.

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

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

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

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

11. Rozhraní API pro data oprávnění vydá žádost GET zprostředkovateli identity, aby vyhledala uživatele SaaS podle zadané e-mailové adresy.

12. Zprostředkovatel identity vrátí ID objektu uživatele SaaS zákazníka.

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

14. Rozhraní API pro data oprávnění se úspěšně vrátí.

15. Rozhraní API pro data tenanta se úspěšně vrátí.

16. 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 nástroje grafického uživatelského rozhraní.

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ý spouští aplikaci, 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 (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
• Wing Tipy 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