Podejścia architektury do wdrażania i konfigurowania rozwiązań wielodostępnych

Niezależnie od architektury i składników używanych do jej implementacji należy wdrożyć i skonfigurować składniki rozwiązania. W środowisku wielodostępnym należy wziąć pod uwagę sposób wdrażania zasobów platformy Azure, szczególnie podczas wdrażania dedykowanych zasobów dla każdej dzierżawy lub ponownego konfigurowania zasobów na podstawie liczby dzierżaw w systemie. Na tej stronie udostępniamy architektom rozwiązań wskazówki dotyczące wdrażania rozwiązań wielodostępnych i przedstawiamy kilka podejść do rozważenia podczas planowania strategii wdrażania.

Kluczowe zagadnienia i wymagania

Przed zaplanowaniem strategii wdrażania ważne jest, aby mieć jasne pojęcie o wymaganiach. Konkretne zagadnienia obejmują następujące kwestie:

• Oczekiwana skala: Czy spodziewasz się obsługi niewielkiej liczby dzierżaw (takich jak pięć lub mniej), czy będzie rosnąć do dużej liczby dzierżaw?
• Automatyczne lub obsługiwane dołączanie: Czy gdy dzierżawa jest gotowa do dołączenia, będzie mogła wykonać sam proces, wykonując procedurę zautomatyzowaną? Czy też nowe dzierżawy inicjują żądanie i ręcznie dołączasz je po otrzymaniu żądania? Czy istnieją czynności ręcznego zatwierdzania wymagane przez zespół, takie jak zapobieganie nadużyciom usługi?
• Czas aprowizacji: kiedy dzierżawa jest gotowa do dołączenia, jak szybko należy ukończyć proces dołączania? Jeśli nie masz jasnej odpowiedzi, zastanów się, czy ma to być mierzone w sekundach, minutach, godzinach lub dniach.
• Azure Marketplace: Czy planujesz zainicjować wdrożenie przy użyciu witryny Azure Marketplace? Jeśli tak, istnieją wymagania, które należy spełnić, aby dodać nowe dzierżawy.

Należy również rozważyć kroki dołączania i aprowizacji, automatyzacji i zarządzania zasobami.

Kroki dołączania i aprowizacji

Należy wziąć pod uwagę wszystko, co należy zrobić podczas dołączania dzierżawy, a także udokumentować tę listę i przepływ pracy, nawet jeśli jest wykonywana ręcznie. Przepływ pracy dołączania zwykle obejmuje następujące elementy:

• Akceptacja umów handlowych.
• Zbieranie informacji potrzebnych do skonfigurowania systemu dla nowej dzierżawy.
• Ręczne kroki zatwierdzania, na przykład w celu zapobiegania oszustwom lub nadużyciom usługi.
• Aprowizowanie zasobów na platformie Azure.
• Tworzenie lub konfigurowanie nazw domen.
• Wykonaj zadania konfiguracji po wdrożeniu, takie jak utworzenie pierwszego konta użytkownika dla dzierżawy i bezpieczne przesyłanie poświadczeń do dzierżawy.
• Ręczne zmiany konfiguracji, takie jak zmiany rekordów DNS.

Jasno udokumentować przepływ pracy wymagany do dołączenia nowej dzierżawy.

Ponadto należy wziąć pod uwagę konkretne zasoby platformy Azure, które należy aprowizować dla dzierżawy. Nawet jeśli nie aprowizujesz dedykowanych zasobów dla każdej dzierżawy, zastanów się, czy czasami trzeba wdrażać zasoby podczas dołączania nowej dzierżawy. Może się tak zdarzyć, gdy dzierżawa wymaga, aby ich dane były przechowywane w określonym regionie lub gdy zbliżasz się do limitów sygnatury lub składnika w rozwiązaniu i trzeba utworzyć inne wystąpienie dla następnej partii dzierżaw.

Zastanów się, czy proces dołączania może być zakłócany dla innych dzierżaw, zwłaszcza dla tych, którzy korzystają z tej samej infrastruktury. Jeśli na przykład konieczne jest zmodyfikowanie udostępnionych baz danych, może to spowodować wpływ na wydajność, jaki mogą zauważyć inne dzierżawy? Zastanów się, czy można uniknąć tych efektów, czy ograniczyć je, wykonując proces dołączania poza normalnymi godzinami pracy.

Automation

Wdrożenia automatyczne są zawsze zalecane w przypadku rozwiązań hostowanych w chmurze. Podczas pracy z rozwiązaniami wielodostępnymi automatyzacja wdrażania staje się jeszcze ważniejsza z następujących powodów:

• Skala: Procesy wdrażania ręcznego stają się coraz bardziej złożone i czasochłonne w miarę wzrostu populacji dzierżawy. Zautomatyzowane podejście do wdrażania jest łatwiejsze do skalowania w miarę wzrostu liczby dzierżaw.
• Powtarzalne: w środowisku wielodostępnym użyj spójnego procesu wdrażania we wszystkich dzierżawach. Procesy ręczne wprowadzają prawdopodobieństwo wystąpienia błędu lub kroków wykonywanych dla niektórych dzierżaw, a nie innych. Te procesy ręczne pozostawiają środowisko w stanie niespójnym, co utrudnia zespołowi zarządzanie rozwiązaniem.
• Wpływ awarii: wdrożenia ręczne są znacznie bardziej ryzykowne i podatne na awarie niż wdrożenia automatyczne. W środowisku wielodostępnym wpływ awarii całego systemu (z powodu błędu wdrożenia) może być wysoki, ponieważ może to mieć wpływ na każdą dzierżawę.

Podczas wdrażania w środowisku wielodostępnym należy używać potoków wdrażania i używać technologii infrastruktury jako kodu (IaC), takich jak Bicep, szablony arm JSON, Terraform lub zestawy SDK platformy Azure.

Jeśli planujesz oferować rozwiązanie za pośrednictwem witryny Azure Marketplace, należy udostępnić w pełni zautomatyzowany proces dołączania dla nowych dzierżaw. Ten proces został opisany w dokumentacji interfejsów API realizacji SaaS.

Maksymalna pojemność zasobu

Podczas programowego wdrażania zasobów dzierżawy na zasobach udostępnionych należy wziąć pod uwagę limit pojemności dla każdego zasobu. W przypadku zbliżania się do tego limitu może być konieczne utworzenie innego wystąpienia zasobu w celu obsługi dalszej skali. Należy wziąć pod uwagę limity każdego wdrażanego zasobu oraz warunki, które wyzwolą Cię w celu wdrożenia innego wystąpienia.

Załóżmy na przykład, że twoje rozwiązanie zawiera serwer logiczny Usługi Azure SQL, a rozwiązanie aprowizuje dedykowaną bazę danych na tym serwerze dla każdej dzierżawy. Jeden serwer logiczny ma limity, które obejmują maksymalną liczbę baz danych, które obsługuje serwer logiczny. W miarę zbliżania się do tych limitów może być konieczne aprowizowania nowych serwerów, aby móc nadal dołączać dzierżawy. Zastanów się, czy automatyzujesz ten proces, czy ręcznie monitorujesz wzrost.

Odpowiedzialność za zarządzanie zasobami

W niektórych wielodostępnych rozwiązaniach wdrażasz dedykowane zasoby platformy Azure dla każdej dzierżawy, takie jak baza danych dla każdej dzierżawy. Możesz też zdecydować o określonej liczbie dzierżaw do domu w jednym wystąpieniu zasobu, więc liczba dzierżaw, które zostały wdrożone na platformie Azure, określa zestaw zasobów wdrażanych na platformie Azure. W innych rozwiązaniach wdrażasz pojedynczy zestaw zasobów udostępnionych, a następnie konfigurujesz ponownie zasoby podczas dołączania nowych dzierżaw.

Każdy z tych modeli wymaga wdrożenia zasobów i zarządzania nimi na różne sposoby. Należy rozważyć sposób wdrażania i zarządzania cyklem życia aprowizowania zasobów. Dwa typowe podejścia są następujące:

• Aby traktować dzierżawy jako konfigurację wdrażanych zasobów i używać potoków wdrażania do wdrażania i konfigurowania tych zasobów.
• Aby traktować dzierżawy jako dane i mieć aprowizację płaszczyzny sterowania i konfigurowanie infrastruktury dla dzierżaw.

Poniżej przedstawiono dalszą dyskusję na temat tych podejść.

Testowanie

Zaplanuj dokładne przetestowanie rozwiązania podczas i po każdym wdrożeniu. Możesz użyć zautomatyzowanego testowania, aby zweryfikować funkcjonalne i niefunkcjonalne zachowanie rozwiązania. Upewnij się, że testujesz model izolacji dzierżawy i rozważ użycie narzędzi takich jak Azure Chaos Studio , aby celowo wprowadzać błędy symulujące awarie w świecie rzeczywistym i sprawdzić, czy rozwiązanie działa nawet wtedy, gdy składnik jest niedostępny lub działa nieprawidłowo.

Podejścia i wzorce do rozważenia

Kilka wzorców projektowych z Centrum architektury platformy Azure i szerszej społeczności ma znaczenie dla wdrażania i konfigurowania wielodostępnych rozwiązań.

Wzorzec sygnatur wdrażania

Wzorzec sygnatur wdrażania obejmuje wdrażanie dedykowanej infrastruktury dla dzierżawy lub grupy dzierżaw. Pojedyncza sygnatura może zawierać wiele dzierżaw lub może być przeznaczona dla jednej dzierżawy. Możesz wybrać wdrożenie pojedynczej sygnatury lub koordynować wdrożenie między wieloma sygnaturami. W przypadku wdrażania dedykowanych sygnatur dla każdej dzierżawy można również rozważyć programowe wdrażanie całych sygnatur.

Pierścienie wdrażania

Pierścienie wdrażania umożliwiają wprowadzanie aktualizacji do różnych grup infrastruktury w różnym czasie. To podejście jest często używane ze wzorcem sygnatur wdrażania, a grupy sygnatur można przypisać do odrębnych pierścieni na podstawie preferencji dzierżawy, typów obciążeń i innych zagadnień. Aby uzyskać więcej informacji, zobacz Pierścienie wdrażania.

Flagi funkcji

Flagi funkcji umożliwiają stopniowe uwidacznienie nowych funkcji lub wersji rozwiązania w różnych dzierżawach przy zachowaniu pojedynczej bazy kodu. Rozważ użycie aplikacja systemu Azure Configuration do zarządzania flagami funkcji. Aby uzyskać więcej informacji, zobacz Flagi funkcji.

Czasami trzeba selektywnie włączyć określone funkcje dla niektórych klientów. Na przykład możesz mieć różne warstwy cenowe , które umożliwiają dostęp do określonych możliwości. Flagi funkcji nie są zwykle właściwym wyborem dla tych scenariuszy. Zamiast tego rozważ utworzenie procesu śledzenia i wymuszania uprawnień licencji, które ma każdy klient.

Antywzorzecy, aby uniknąć

Podczas wdrażania i konfigurowania rozwiązań wielodostępnych należy unikać sytuacji, które hamują możliwość skalowania. Należą do nich następujące funkcje:

• Ręczne wdrażanie i testowanie. Jak opisano powyżej, procesy wdrażania ręcznego dodają ryzyko i spowolnią wdrażanie. Rozważ użycie potoków na potrzeby wdrożeń automatycznych, programowe tworzenie zasobów na podstawie kodu rozwiązania lub kombinację obu tych rozwiązań.
• Wyspecjalizowane dostosowania dla dzierżaw. Unikaj wdrażania funkcji lub konfiguracji, która ma zastosowanie tylko do jednej dzierżawy. Takie podejście zwiększa złożoność wdrożeń i procesów testowania. Zamiast tego należy używać tych samych typów zasobów i bazy kodu dla każdej dzierżawy i używać strategii, takich jak flagi funkcji dla tymczasowych zmian lub funkcji, które są wdrażane stopniowo lub używać różnych warstw cenowych z uprawnieniami licencji, aby selektywnie włączyć funkcje dla dzierżaw, które ich wymagają. Używaj spójnego i zautomatyzowanego procesu wdrażania, nawet w przypadku dzierżaw, które mają izolowane lub dedykowane zasoby.

Listy dzierżaw jako konfiguracja lub dane

Podczas wdrażania zasobów w rozwiązaniu wielodostępnym można rozważyć następujące dwa podejścia:

• Użyj zautomatyzowanego potoku wdrażania, aby wdrożyć każdy zasób. Po dodaniu nowych dzierżaw skonfiguruj ponownie potok, aby aprowizować zasoby dla każdej dzierżawy.
• Użyj potoku wdrażania zautomatyzowanego, aby wdrożyć udostępnione zasoby, które nie zależą od liczby dzierżaw. W przypadku zasobów wdrożonych dla każdej dzierżawy utwórz je w aplikacji.

Biorąc pod uwagę te dwa podejścia, należy rozróżnić traktowanie listy dzierżaw jako konfiguracji lub jako danych. To rozróżnienie jest również ważne, jeśli wziąć pod uwagę sposób tworzenia płaszczyzny sterowania dla systemu.

Lista dzierżaw jako konfiguracja

W przypadku traktowania listy dzierżaw jako konfiguracji wszystkie zasoby są wdrażane z scentralizowanego potoku wdrażania. Po dołączeniu nowych dzierżaw należy ponownie skonfigurować potok lub jego parametry. Zazwyczaj ponowna konfiguracja odbywa się poprzez ręczne zmiany, jak pokazano na poniższym diagramie.

Proces dołączania nowej dzierżawy może być podobny do następującego:

1. Zaktualizuj listę dzierżaw. Zazwyczaj odbywa się to ręcznie przez skonfigurowanie samego potoku lub zmodyfikowanie pliku parametrów uwzględnionego w konfiguracji potoku.
2. Wyzwól potok do uruchomienia.
3. Potok ponownie wdraża kompletny zestaw zasobów platformy Azure, w tym wszelkie nowe zasoby specyficzne dla dzierżawy.

Takie podejście ma tendencję do dobrego działania w przypadku niewielkiej liczby dzierżaw i architektur, w których są współużytkowane wszystkie zasoby. Jest to proste podejście, ponieważ wszystkie zasoby platformy Azure można wdrażać i konfigurować przy użyciu jednego procesu.

Jednak w przypadku podejścia do większej liczby dzierżaw, powiedzmy, od 5 do 10 lub więcej, staje się kłopotliwe, aby ponownie skonfigurować potok podczas dodawania dzierżaw. Czas potrzebny na uruchomienie potoku wdrażania często znacznie się zwiększa. Takie podejście nie jest również łatwe do obsługi samoobsługowego tworzenia dzierżawy, a czas realizacji przed dołączeniem dzierżawy może być dłuższy, ponieważ należy wyzwolić potok do uruchomienia.

Lista dzierżaw jako dane

W przypadku traktowania listy dzierżaw jako danych nadal wdrażasz składniki udostępnione przy użyciu potoku. Jednak w przypadku zasobów i ustawień konfiguracji, które należy wdrożyć dla każdej dzierżawy, musisz wdrożyć lub skonfigurować zasoby. Na przykład płaszczyzna sterowania może użyć zestawów SDK platformy Azure do utworzenia określonego zasobu lub zainicjowania wdrożenia sparametryzowanego szablonu.

Proces dołączania nowej dzierżawy może być podobny do następującego i przebiegałby asynchronicznie:

1. Zażądaj dołączenia dzierżawy, na przykład przez zainicjowanie żądania interfejsu API do płaszczyzny sterowania systemu.
2. Składnik przepływu pracy odbiera żądanie utworzenia i organizuje pozostałe kroki.
3. Przepływ pracy inicjuje wdrażanie zasobów specyficznych dla dzierżawy na platformie Azure. Można to osiągnąć przy użyciu modelu programowania imperatywnego, takiego jak użycie zestawów SDK platformy Azure lub przez wywołanie wdrożenia szablonu Bicep lub Terraform.
4. Po zakończeniu wdrażania przepływ pracy zapisuje szczegóły nowej dzierżawy w centralnym wykazie dzierżawy. Dane przechowywane dla każdej dzierżawy mogą obejmować identyfikator dzierżawy i identyfikatory zasobów dla wszystkich zasobów specyficznych dla dzierżawy utworzonych przez przepływ pracy.

Dzięki temu można aprowizować zasoby dla nowych dzierżaw bez ponownego wdrażania całego rozwiązania. Czas związany z aprowizowaniem nowych zasobów dla każdej dzierżawy może być krótszy, ponieważ należy wdrożyć tylko te zasoby.

Jednak takie podejście jest często znacznie bardziej czasochłonne do kompilowania, a nakład pracy należy uzasadnić liczbą dzierżaw lub przedziałami czasu aprowizacji, które należy spełnić.

Aby uzyskać więcej informacji na temat tego podejścia, zobacz Zagadnienia dotyczące wielodostępnych płaszczyzn sterowania.

Przykład

Firma Contoso uruchamia wielodostępne rozwiązanie dla swoich klientów. Obecnie mają sześć dzierżaw i spodziewają się, że w ciągu najbliższych 18 miesięcy wzrosną do 300 dzierżaw. Firma Contoso jest zgodna z aplikacją wielodostępną z dedykowanymi bazami danych dla każdego podejścia dzierżawy . Wdrożono jeden zestaw zasobów usługi App Service i serwera logicznego Azure SQL, który jest współużytkowany między wszystkimi dzierżawami, a także wdraża dedykowaną bazę danych Azure SQL Database dla każdej dzierżawy, jak pokazano na poniższym diagramie.

Firma Contoso wdraża swoje zasoby platformy Azure przy użyciu platformy Bicep.

Opcja 1 — używanie potoków wdrażania dla wszystkich elementów

Firma Contoso może rozważyć wdrożenie wszystkich swoich zasobów przy użyciu potoku wdrażania. Potok wdraża plik Bicep zawierający wszystkie zasoby platformy Azure, w tym bazy danych Azure SQL Database dla każdej dzierżawy. Plik parametrów definiuje listę dzierżaw, a plik Bicep używa pętli zasobów do wdrożenia bazy danych dla każdej z wymienionych dzierżaw, jak pokazano na poniższym diagramie.

Jeśli firma Contoso jest zgodna z tym modelem, musi zaktualizować plik parametrów w ramach dołączania nowej dzierżawy. Następnie muszą ponownie uruchomić potok. Ponadto muszą ręcznie śledzić, czy zbliżają się do jakichkolwiek limitów, na przykład jeśli rosną one w nieoczekiwanie wysokim tempie i zbliżają się do maksymalnej liczby baz danych obsługiwanych na jednym serwerze logicznym usługi Azure SQL.

Opcja 2 — używanie kombinacji potoków wdrażania i tworzenia zasobów imperatywnych

Alternatywnie firma Contoso może rozważyć rozdzielenie odpowiedzialności za wdrożenia platformy Azure.

Firma Contoso używa pliku Bicep definiującego udostępnione zasoby, które mają zostać wdrożone. Udostępnione zasoby obsługują wszystkie dzierżawy i zawierają bazę danych mapy dzierżawy, jak pokazano na poniższym diagramie.

Następnie zespół firmy Contoso tworzy płaszczyznę sterowania obejmującą interfejs API dołączania dzierżawy. Gdy ich zespół ds. sprzedaży zakończy sprzedaż dla nowego klienta, usługa Microsoft Dynamics wyzwoli interfejs API, aby rozpocząć proces dołączania. Firma Contoso udostępnia również samoobsługowy interfejs internetowy dla klientów, który również wyzwala interfejs API.

Asynchronicznie interfejs API uruchamia przepływ pracy, który dołącza nowe dzierżawy. Przepływ pracy inicjuje wdrożenie nowej bazy danych Azure SQL Database, która może być wykonywana przy użyciu jednej z następujących metod:

• Użyj zestawu Azure SDK, aby zainicjować wdrożenie drugiego pliku Bicep definiującego bazę danych Azure SQL Database.
• Użyj zestawu Azure SDK, aby w sposób imperatywny utworzyć bazę danych Azure SQL Database przy użyciu biblioteki zarządzania.

Po wdrożeniu bazy danych przepływ pracy dodaje dzierżawę do bazy danych listy dzierżaw, jak pokazano na poniższym diagramie.

Bieżące aktualizacje schematu bazy danych są inicjowane przez ich warstwę aplikacji.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• John Downs | Główny inżynier oprogramowania

Inni współautorzy:

• Bohdan Cherchyk | Starszy inżynier klienta, fasttrack dla platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Zapoznaj się z zagadnieniami dotyczącymi aktualizowania rozwiązania wielodostępnego.
• Rozważ podejście architektury do przechowywania i danych.
• Rozważ użycie usługi Azure Resource Manager w rozwiązaniu wielodostępnym.