Oprogramowanie jako usługa (SaaS) to złożony temat z wieloma punktami do rozważenia. Niezależni dostawcy oprogramowania (ISV), którzy tworzą swoje rozwiązania SaaS na platformie Azure, muszą rozwiązywać problemy i podejmować decyzje, takie jak:
- Którego modelu dzierżawy należy używać?
- Jak mogę skonfigurować rozwiązanie tożsamości do użycia w architekturze wielodostępnej?
- Jak mogę obsługiwać dołączanie nowych klientów?
Ta architektura ma na celu udzielenie odpowiedzi na niektóre z tych pytań i zapewnienie początkowego miejsca w świecie saaS. Ta architektura jest dostosowywana w celu dopasowania do szerokiej gamy scenariuszy.
Potencjalne przypadki użycia
Poniżej przedstawiono przykładowe przypadki użycia, w których można użyć tej architektury:
- Modernizowanie istniejącej aplikacji w celu obsługi pełnej wielodostępności w ramach przejścia na model biznesowy oparty na modelu SaaS.
- Opracuj zupełnie nową ofertę SaaS.
- Migrowanie oferty SaaS z innej usługi w chmurze na platformę Azure.
Architektura
Pobierz plik programu PowerPoint tej architektury.
Terminologia
W poniższej tabeli opisano terminy, które pojawiają się w tym artykule.
| Okres | opis | Przykład |
|---|---|---|
| Dostawca SaaS lub niezależnego dostawcy oprogramowania | Jednostka, która jest właścicielem aplikacji SaaS i kodu oraz sprzedaje produkt SaaS. | Contoso Inc, sprzedając swoją aplikację SaaS: Contoso Tickets. |
| Dzierżawa | Zakupione wystąpienie aplikacji SaaS od dostawcy SaaS. | Czwarty kawiarnia. |
| Administrator klienta SaaS | Osoby, którzy kupują dzierżawę aplikacji lub zarządzają nią. | Joe, właściciel Fourth Coffee Shop. |
| Użytkownik klienta SaaS | Osoby, którzy korzystają z dzierżawy aplikacji bez administrowania nią i zazwyczaj należą do tej samej firmy lub grupy co administrator klienta SaaS. | Jill, kierownik ds. zdarzeń w Fourth Coffee Shop i Susan, klient czwartej kawiarni. |
| Użytkownik końcowy | Administrator klienta SaaS, użytkownik klienta SaaS lub inne wprowadzone typy użytkowników. Jest to ogólny termin opisujący użytkowników logujących się do aplikacji. | Joe, Jill i Susan są użytkownikami końcowymi (z perspektywy niezależnego dostawcy oprogramowania). |
| Aplikacja frontonu | Dowolna aplikacja frontonu. | Aplikacja onboarding & admin i aplikacja SaaS są aplikacjami frontonu. |
Przepływ pracy
Administrator klienta SaaS przechodzi do witryny hostowanej w aplikacji Onboarding & admin.
Administrator klienta SaaS loguje się przy użyciu przepływu pracy logowania użytkownika.
Administrator klienta SaaS kończy przepływ dołączania.
Administrator klienta SaaS przechodzi do obszaru administracyjnego dzierżawy w aplikacji Onboarding & admin i dodaje użytkownika klienta SaaS do nowo utworzonej dzierżawy.
Użytkownik klienta SaaS przechodzi do aplikacji SaaS i korzysta z aplikacji SaaS.
Logowanie użytkowników
Przepływ pracy logowania użytkownika składa się z następujących kroków:
Użytkownik końcowy przechodzi do aplikacji frontonu i wybiera przycisk Zaloguj.
Aplikacja frontonu przekierowuje użytkownika końcowego do strony logowania hostowanej przez dostawcę tożsamości.
Użytkownik końcowy wprowadza informacje o koncie i przesyła formularz logowania do dostawcy tożsamości.
Dostawca tożsamości wysyła żądanie POST z adresem e-mail użytkownika końcowego i identyfikatorem obiektu w celu pobrania uprawnień i ról.
Interfejs API danych uprawnień wyszukuje informacje użytkownika końcowego w magazynie danych uprawnień i zwraca listę uprawnień i ról przypisanych do tego użytkownika końcowego.
Dostawca tożsamości dodaje uprawnienia i role jako oświadczenia niestandardowe do tokenu identyfikatora, który jest tokenem internetowym JSON (JWT).
Dostawca tożsamości zwraca token identyfikatora użytkownikowi końcowemu i inicjuje przekierowanie do aplikacji frontonu.
Użytkownik końcowy jest przekierowywany do punktu końcowego logowania w aplikacji frontonu i przedstawia token identyfikatora.
Aplikacja frontonu weryfikuje przedstawiony token identyfikatora.
Aplikacja frontonu zwraca pomyślną stronę logowania, a użytkownik końcowy jest teraz zalogowany.
Aby uzyskać więcej informacji na temat działania tego przepływu logowania, zobacz OpenID Połączenie protocol (Protokół OpenID Połączenie).
Dołączanie nowej dzierżawy
Przepływ pracy dołączania dzierżawy składa się z następujących kroków:
Administrator klienta SaaS przechodzi do aplikacji Onboarding & admin i kończy formularz rejestracji.
Aplikacja dołączania i administratora wysyła żądanie POST do interfejsu API danych dzierżawy w celu utworzenia nowej dzierżawy.
Interfejs API danych dzierżawy tworzy nową dzierżawę w magazynie danych dzierżawy.
Interfejs API danych dzierżawy wysyła żądanie POST do interfejsu API danych uprawnień w celu udzielenia uprawnień administratora klienta SaaS do nowo utworzonej dzierżawy.
Interfejs API danych uprawnień tworzy nowy rekord uprawnień w magazynie danych uprawnień.
Interfejs API danych uprawnień zostanie zwrócony pomyślnie.
Interfejs API danych dzierżawy zostanie zwrócony pomyślnie.
Aplikacja Onboarding & admin wysyła żądanie POST do dostawcy powiadomień e-mail w celu wysłania wiadomości e-mail "utworzonej dzierżawy" do administratora klienta SaaS.
Dostawca powiadomień e-mail wysyła wiadomość e-mail.
Dostawca powiadomień e-mail zostanie zwrócony pomyślnie.
Aplikacja Dołączanie i administrator wysyła żądanie do dostawcy tożsamości w celu odświeżenia tokenu identyfikatora administratora klienta SaaS, tak aby zawierała oświadczenie JWT do nowo utworzonej dzierżawy.
Dostawca tożsamości wysyła żądanie POST z adresem e-mail administratora klienta SaaS i identyfikatorem obiektu w celu pobrania uprawnień i ról.
Interfejs API danych uprawnień wyszukuje informacje administratora klienta SaaS w magazynie danych uprawnień i zwraca listę uprawnień i ról przypisanych do administratora klienta SaaS.
Dostawca tożsamości dodaje uprawnienia i role jako oświadczenia niestandardowe do tokenu identyfikatora.
Dostawca tożsamości zwraca token identyfikatora do aplikacji Dołączanie i Administracja.
Aplikacja Onboarding & admin zwraca komunikat o powodzeniu i nowy token identyfikatora do Administracja Klienta SaaS.
Dodawanie użytkownika do dzierżawy
Dodanie użytkownika do przepływu pracy dzierżawy składa się z następujących kroków:
Administrator aplikacji SaaS żąda wyświetlenia listy dzierżaw z obszaru administratora dzierżawy w aplikacji Onboarding & admin.
Aplikacja Dołączanie i administrator wysyła żądanie GET do interfejsu API danych dzierżawy, aby uzyskać listę dzierżaw dla administratora klienta SaaS.
Interfejs API danych dzierżawy wysyła żądanie GET do interfejsu API danych uprawnień, aby uzyskać listę dzierżaw, do których administrator klienta SaaS ma dostęp do wyświetlania.
Interfejs API danych uprawnień zwraca listę uprawnień dzierżawy.
Interfejs API danych dzierżawy wyszukuje informacje o dzierżawie w magazynie danych dzierżawy i zwraca listę danych dzierżawy na podstawie listy odebranych uprawnień dzierżawy.
Aplikacja Onboarding & admin zwraca listę danych dzierżawy do administratora klienta SaaS.
Administrator klienta SaaS wybiera dzierżawę z listy, aby dodać użytkownika klienta SaaS do i wprowadza adres e-mail dla użytkownika klienta SaaS.
Aplikacja Onboarding & admin wystawia żądanie POST do interfejsu API danych dzierżawy, aby dodać uprawnienie dla użytkownika klienta SaaS w określonej dzierżawie.
Interfejs API danych dzierżawy sprawdza, czy administrator klienta SaaS ma prawidłowe oświadczenie JWT do określonej dzierżawy i ma uprawnienia do zapisu użytkownika.
Interfejs API danych dzierżawy wysyła żądanie POST do interfejsu API danych uprawnień, aby dodać uprawnienie dla użytkownika klienta SaaS w określonej dzierżawie.
Interfejs API danych uprawnień wysyła żądanie GET do dostawcy tożsamości w celu wyszukania użytkownika saaS przez podany adres e-mail.
Dostawca tożsamości zwraca identyfikator obiektu użytkownika klienta SaaS.
Interfejs API danych uprawnień dodaje rekord uprawnień w magazynie danych uprawnień dla użytkownika klienta SaaS w określonej dzierżawie przy użyciu identyfikatora obiektu.
Interfejs API danych uprawnień zostanie zwrócony pomyślnie.
Interfejs API danych dzierżawy zostanie zwrócony pomyślnie.
Aplikacja onboarding & admin zwraca pomyślnie.
Składniki
Ta architektura korzysta z następujących usług platformy Azure:
Usługa App Service umożliwia tworzenie i hostowanie aplikacji internetowych i aplikacji interfejsu API w wybranym języku programowania bez konieczności zarządzania infrastrukturą.
Usługa Azure Active Directory B2C umożliwia łatwe zarządzanie tożsamościami i dostępem dla aplikacji użytkowników końcowych.
Azure SQL Database to usługa zarządzana relacyjnymi bazami danych ogólnego przeznaczenia, która obsługuje dane relacyjne, dane przestrzenne, dane JSON i XML.
Usługa Azure Logic Apps umożliwia szybkie tworzenie zaawansowanych integracji przy użyciu prostego narzędzia graficznego interfejsu użytkownika.
Alternatywy
Skuteczność wszelkich alternatywnych wyborów zależy znacznie od modelu dzierżawy, który zamierzasz obsługiwać aplikację SaaS. Poniżej przedstawiono kilka przykładów alternatywnych metod, które można zastosować podczas implementowania tego rozwiązania:
Bieżące rozwiązanie używa usługi Azure Active Directory B2C jako dostawcy tożsamości. Zamiast tego można użyć innych dostawców tożsamości, takich jak Microsoft Entra ID.
Aby uzyskać bardziej rygorystyczne wymagania dotyczące zabezpieczeń i zgodności, można wdrożyć sieć prywatną na potrzeby komunikacji między usługami.
Zamiast używać wywołań REST między usługami, można zaimplementować styl architektury opartej na zdarzeniach na potrzeby obsługi komunikatów między usługami.
Kwestie wymagające rozważenia
Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, które można zastosować, aby poprawić jakość obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Zabezpieczenia
Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.
To rozwiązanie opiera się na tożsamości jako modelu zabezpieczeń. Uwierzytelnianie i autoryzacja aplikacji internetowych i interfejsów API podlegają Platforma tożsamości Microsoft, która jest odpowiedzialna za wystawianie i weryfikowanie tokenów identyfikatora użytkownika (JWTs).
Optymalizacja kosztów
Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.
Składniki w tym rozwiązaniu mają pewne koszty związane z ich działaniem, ale koszt jest niewielki dla większości aplikacji internetowych i rozwiązań SaaS. Ponadto możesz kontrolować koszt, zarządzając następującymi ustawieniami zasobów:
Możesz skalować plan usługi App Service, który uruchamia aplikację w celu dopasowania do wymaganej przepływności. Ponadto można uruchomić każdą aplikację w osobnym planie, jeśli potrzebujesz wyższej przepływności, ale w rezultacie poniesiesz wyższe koszty. Aby uzyskać więcej informacji, zobacz omówienie planu usługi aplikacja systemu Azure.
Usługa Azure AD B2C udostępnia dwie jednostki SKU: Premium P1 i Premium P2. Obie jednostki SKU obejmują bezpłatny zasiłek dla liczby aktywnych użytkowników miesięcznie (MAU), ale należy ocenić, które funkcje zapewnia każda jednostka SKU, aby określić, które funkcje są wymagane dla danego przypadku użycia. Aby uzyskać więcej informacji, zobacz Tożsamość zewnętrzna Microsoft Entra cennik.
Usługa Azure SQL ma kilka modeli zakupów w celu dopasowania do szerokiej gamy przypadków użycia, w tym możliwości automatycznego skalowania. Musisz ocenić użycie własnych baz danych, aby upewnić się, że rozmiar jest poprawny. Aby uzyskać więcej informacji, zobacz Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database.
Efektywność wydajności
Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.
Ta architektura powinna być w stanie skalować w celu łatwego spełnienia większości średnich i średnich obciążeń. Ponieważ architektura korzysta głównie z usług platformy Azure (PaaS), istnieje wiele opcji dostosowywania skali rozwiązania na podstawie wymagań i obciążenia.
Wdrażanie tego scenariusza
Jeśli chcesz wdrożyć ten scenariusz, zobacz zestaw Azure SaaS Dev Kit w witrynie GitHub. Jest to wdrażalna implementacja referencyjna tej architektury.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Landon Pierce | Inżynier klienta
Inni współautorzy:
- Chris Ayers | Starszy inżynier klienta
- John Downs | Starszy inżynier klienta
- LaBrina Loving | Główny menedżer inżynierów SVC
- Gary Moore | Programista/pisarz
- Nick Pinheiro | Starszy konsultant
- William Salazar | Starszy inżynier klienta
- Ali Sanjabi | Starszy inżynier klienta
- Arsen Vladimirskiy | Główny inżynier klienta
- Jason Young | Główny menedżer inżynierów SVC
Następne kroki
Poniżej przedstawiono kilka dodatkowych zalecanych zasobów dotyczących tworzenia aplikacji SaaS na platformie Azure:
- Tworzenie architektury wielodostępnych rozwiązań na platformie Azure — opisuje najlepsze rozwiązania.
- Zagadnienia dotyczące niezależnego dostawcy oprogramowania dla stref docelowych platformy Azure
- Platforma Microsoft Azure — dobrze zaprojektowana struktura
- Aplikacja Wing Wskazówki Tickets SaaS — zawiera szczegółowe informacje o kompromisach między różnymi modelami dzierżawy w warstwie bazy danych.
Powiązane zasoby
- Modele dzierżawy do rozważenia w przypadku rozwiązania wielodostępnego
- Podejścia architektury do obliczeń w rozwiązaniach wielodostępnych
- Podejścia architektury do przechowywania i danych w rozwiązaniach wielodostępnych
- aplikacja systemu Azure Service and Azure Functions considerations for multitenancy (Zagadnienia dotyczące usługi aplikacja systemu Azure i usługi Azure Functions dotyczące wielodostępności)
- Wielodostępna usługa SaaS na platformie Azure
- Wzorce projektowe chmury