aplikacja systemu Azure Service to zaawansowana platforma hostingu aplikacji internetowych. Usługa Azure Functions oparta na infrastrukturze usługi App Service umożliwia łatwe tworzenie bezserwerowych i opartych na zdarzeniach obciążeń obliczeniowych. Obie usługi są często używane w rozwiązaniach wielodostępnych.
Funkcje usługi aplikacja systemu Azure i usługi Azure Functions, które obsługują wielodostępność
aplikacja systemu Azure Service i Azure Functions zawierają wiele funkcji, które obsługują wielodostępność.
Niestandardowe nazwy domen
usługa aplikacja systemu Azure umożliwia używanie wieloznacznych nazw DNS i dodawanie własnych certyfikatów TLS z symbolami wieloznacznymi. W przypadku używania poddomen specyficznych dla dzierżawy wieloznaczne certyfikaty DNS i TLS umożliwiają łatwe skalowanie rozwiązania do dużej liczby dzierżaw bez konieczności ręcznej ponownej konfiguracji dla każdej nowej dzierżawy.
W przypadku używania niestandardowych nazw domen specyficznych dla dzierżawy może istnieć duża liczba niestandardowych nazw domen, które należy dodać do aplikacji. Może to stać się kłopotliwe, aby zarządzać wieloma niestandardowymi nazwami domen, zwłaszcza gdy wymagają pojedynczych certyfikatów TLS. Usługa App Service udostępnia zarządzane certyfikaty TLS, co zmniejsza ilość pracy wymaganej podczas pracy z domenami niestandardowymi. Istnieją jednak ograniczenia, takie jak liczba domen niestandardowych, które można zastosować do jednej aplikacji.
Integracja z usługą Azure Front Door
Usługa App Service i usługa Azure Functions integrują się z usługą Azure Front Door, aby działać jako składnik rozwiązania dostępny z Internetu. Usługa Azure Front Door umożliwia dodawanie zapory aplikacji internetowej (WAF) i buforowania brzegowego oraz zapewnia inne optymalizacje wydajności. Możesz łatwo ponownie skonfigurować przepływy ruchu w celu kierowania ruchu do różnych zapleczy na podstawie zmieniających się wymagań biznesowych lub technicznych.
W przypadku korzystania z usługi Azure Front Door z aplikacją wielodostępną możesz użyć jej do zarządzania niestandardowymi nazwami domen i zakończenia połączeń TLS. Aplikacja usługi App Service jest następnie skonfigurowana przy użyciu jednej nazwy hosta, a cały ruch przepływa do tej aplikacji, co pomaga uniknąć zarządzania niestandardowymi nazwami domen w wielu miejscach.
Tak jak w powyższym przykładzie, usługę Azure Front Door można skonfigurować do modyfikowania nagłówka Hostżądania. Oryginalny Host nagłówek wysyłany przez klienta jest propagowany za pośrednictwem nagłówka X-Forwarded-Host , a kod aplikacji może użyć tego nagłówka, aby zamapować żądanie na poprawną dzierżawę.
Ostrzeżenie
Jeśli aplikacja wysyła pliki cookie lub odpowiedzi przekierowania, musisz zachować szczególną ostrożność. Zmiany w nagłówkach żądania Host mogą unieważnić te odpowiedzi. Aby uzyskać więcej informacji, zobacz najlepsze rozwiązanie dotyczące zachowywania nazw hostów.
Możesz użyć prywatnych punktów końcowych lub ograniczeń dostępu usługi App Service, aby upewnić się, że ruch przepływał przez usługę Front Door przed dotarciem do aplikacji.
Aby uzyskać więcej informacji na temat korzystania z usługi Azure Front Door w rozwiązaniu wielodostępnym, zobacz Korzystanie z usługi Azure Front Door w rozwiązaniu wielodostępnym
Uwierzytelnianie i autoryzacja
usługa aplikacja systemu Azure może weryfikować tokeny uwierzytelniania w imieniu aplikacji. Gdy usługa App Service odbiera żądanie, sprawdza, czy są spełnione każde z następujących warunków:
- Żądanie zawiera token.
- Token jest prawidłowy.
- Żądanie jest autoryzowane.
Jeśli którykolwiek z warunków nie zostanie spełniony, usługa App Service może zablokować żądanie lub przekierować użytkownika do dostawcy tożsamości, aby mógł się zalogować.
Jeśli dzierżawcy używają identyfikatora Entra firmy Microsoft jako systemu tożsamości, możesz skonfigurować usługę aplikacja systemu Azure, aby używać /common endpoint do sprawdzania poprawności tokenów użytkownika. Gwarantuje to, że niezależnie od dzierżawy firmy Microsoft Entra użytkownika tokeny są weryfikowane i akceptowane.
Możesz również zintegrować usługę aplikacja systemu Azure z usługą Azure AD B2C na potrzeby uwierzytelniania użytkowników.
Więcej informacji:
- Autoryzacja usługi App Service
- Konfigurowanie uwierzytelniania w przykładowej aplikacji internetowej przy użyciu usługi Azure AD B2C
- Praca z wielodostępnymi tożsamościami firmy Microsoft Entra
Ograniczenia dostępu
Ruch do aplikacji można ograniczyć przy użyciu ograniczeń dostępu. Mogą one służyć do określania zakresów adresów IP lub sieci wirtualnych, które mogą łączyć się z aplikacją.
Podczas pracy z rozwiązaniem wielodostępnym należy pamiętać o maksymalnej liczbie reguł ograniczeń dostępu. Jeśli na przykład musisz utworzyć regułę ograniczeń dostępu dla każdej dzierżawy, możesz przekroczyć maksymalną dozwoloną liczbę reguł. Jeśli potrzebujesz większej liczby reguł, rozważ wdrożenie zwrotnego serwera proxy, takiego jak usługa Azure Front Door.
Modele izolacji
Podczas pracy z systemem wielodostępnym przy użyciu usługi aplikacja systemu Azure lub usługi Azure Functions należy podjąć decyzję o poziomie izolacji, którego chcesz użyć. Zapoznaj się z modelami dzierżawy, aby wziąć pod uwagę rozwiązanie wielodostępne oraz wskazówki podane w podejściach architektury do obliczeń w rozwiązaniach wielodostępnych, aby ułatwić wybór najlepszego modelu izolacji dla danego scenariusza.
Podczas pracy z usługą aplikacja systemu Azure i usługą Azure Functions należy pamiętać o następujących kluczowych pojęciach:
- W usłudze aplikacja systemu Azure plan reprezentuje infrastrukturę hostingu. Aplikacja reprezentuje jedną aplikację działającą w tej infrastrukturze. Możesz wdrożyć wiele aplikacji w jednym planie.
- W usłudze Azure Functions hosting i aplikacja są również oddzielone, ale masz dodatkowe opcje hostingu dostępne dla hostingu elastycznego, w którym usługa Azure Functions zarządza skalowaniem. Dla uproszczenia w tym artykule odwołujemy się do infrastruktury hostingu jako planu , ponieważ opisane tutaj zasady dotyczą zarówno usługi App Service, jak i usługi Azure Functions, niezależnie od używanego modelu hostingu.
W poniższej tabeli przedstawiono podsumowanie różnic między głównymi modelami izolacji dzierżawy dla usług aplikacja systemu Azure Service i Azure Functions:
| Kwestie wymagające rozważenia | Aplikacje udostępnione | Aplikacje na dzierżawę z planami udostępnionymi | Plany na dzierżawę |
|---|---|---|---|
| Izolacja konfiguracji | Niska | Średnia. Ustawienia na poziomie aplikacji są przeznaczone dla dzierżawy, a ustawienia na poziomie planu są współużytkowane | Wysoka. Każda dzierżawa może mieć własną konfigurację |
| Izolacja wydajności | Niska | Niski średni. Potencjalnie mogą podlegać hałaśliwym problemom z sąsiadem | Wysoka |
| Złożoność wdrożenia | Niska | Średnie | Wysoka |
| Złożoność operacyjna | Niskie | Wysokie | Wysoka |
| Koszt zasobu | Niska | Niski poziom w zależności od aplikacji | Wysoka |
| Przykładowy scenariusz | Duże rozwiązanie wielodostępne z udostępnioną warstwą aplikacji | Migrowanie aplikacji, które nie wiedzą o dzierżawie na platformę Azure przy jednoczesnym uzyskaniu oszczędności | Warstwa aplikacji z jedną dzierżawą |
Aplikacje udostępnione
Aplikację udostępnioną można wdrożyć w jednym planie i używać aplikacji udostępnionej dla wszystkich dzierżaw.
Zwykle jest to najbardziej opłacalna opcja i wymaga najmniejszego nakładu pracy operacyjnej, ponieważ istnieje mniej zasobów do zarządzania. Możesz skalować ogólny plan na podstawie obciążenia lub zapotrzebowania, a wszystkie dzierżawy współużytkują plan skorzysta ze zwiększonej pojemności.
Ważne jest, aby pamiętać o limitach przydziałów i limitach usługi App Service, takich jak maksymalna liczba domen niestandardowych, które można dodać do jednej aplikacji, oraz maksymalną liczbę wystąpień planu, które można aprowizować.
Aby móc korzystać z tego modelu, kod aplikacji musi być obsługujący wiele dzierżaw.
Aplikacje na dzierżawę z planami udostępnionymi
Możesz również udostępnić plan między wieloma dzierżawami, ale wdrożyć oddzielne aplikacje dla każdej dzierżawy. Zapewnia to izolację logiczną między poszczególnymi dzierżawami, a takie podejście zapewnia następujące korzyści:
- Efektywność kosztowa: dzięki udostępnianiu infrastruktury hostingu można ogólnie zmniejszyć ogólne koszty na dzierżawę.
- Separacja konfiguracji: każda aplikacja dzierżawy może mieć własną nazwę domeny, certyfikat TLS, ograniczenia dostępu i zasady autoryzacji tokenu.
- Rozdzielenie uaktualnień: pliki binarne aplikacji każdej dzierżawy można uaktualnić niezależnie od innych aplikacji w tym samym planie.
Jednak ze względu na to, że zasoby obliczeniowe planu są współużytkowane, aplikacje mogą podlegać problemowi Hałaśliwemu sąsiadowi. Ponadto istnieją ograniczenia dotyczące liczby aplikacji, które można wdrożyć w jednym planie.
Uwaga
Nie używaj miejsc wdrożenia dla różnych dzierżaw. Miejsca nie zapewniają izolacji zasobów. Są one przeznaczone do scenariuszy wdrażania, gdy trzeba mieć wiele wersji aplikacji uruchomionych przez krótki czas, takich jak wdrożenia niebiesko-zielone i strategia wdrażania kanary.
Plany na dzierżawę
Najsilniejszym poziomem izolacji jest wdrożenie dedykowanego planu dla dzierżawy. Ten dedykowany plan gwarantuje, że dzierżawa ma pełne wykorzystanie wszystkich zasobów serwera przydzielonych do tego planu.
Takie podejście umożliwia skalowanie rozwiązania w celu zapewnienia izolacji wydajności dla każdej dzierżawy oraz uniknięcia problemu Noisy Neighbor. Jednak ma on również wyższy koszt, ponieważ zasoby nie są współużytkowane z wieloma dzierżawami. Ponadto należy wziąć pod uwagę maksymalną liczbę planów , które można wdrożyć w jednej grupie zasobów platformy Azure.
Interfejsy API hosta
Interfejsy API można hostować zarówno w usłudze aplikacja systemu Azure, jak i w usłudze Azure Functions. Wybór platformy będzie zależeć od wybranego zestawu funkcji i opcji skalowania.
Niezależnie od platformy używanej do hostowania interfejsu API należy rozważyć użycie usługi Azure API Management przed aplikacją interfejsu API. Usługa API Management udostępnia wiele funkcji, które mogą być przydatne w przypadku rozwiązań wielodostępnych, w tym następujących:
- Scentralizowany punkt dla całego uwierzytelniania. Może to obejmować określenie identyfikatora dzierżawy z oświadczenia tokenu lub innych metadanych żądania.
- Kierowanie żądań do różnych zapleczy interfejsu API, które mogą być oparte na identyfikatorze dzierżawy żądania. Może to być przydatne w przypadku hostowania wielu sygnatur wdrożenia przy użyciu własnych niezależnych aplikacji interfejsu API, ale musisz mieć jeden adres URL interfejsu API dla wszystkich żądań.
Sieć i wielodostępność
Adresy IP
Wiele aplikacji wielodostępnych musi łączyć się z sieciami lokalnymi dzierżawców w celu wysyłania danych.
Jeśli musisz wysłać ruch wychodzący ze znanego statycznego adresu IP lub zestawu znanych statycznych adresów IP, rozważ użycie bramy translatora adresów sieciowych. Aby uzyskać więcej informacji na temat używania bramy translatora adresów sieciowych w rozwiązaniach wielodostępnych, zobacz Zagadnienia dotyczące usługi Azure NAT Gateway dotyczące wielodostępności. Usługa App Service zawiera wskazówki dotyczące sposobu integracji z bramą translatora adresów sieciowych.
Jeśli nie potrzebujesz statycznego adresu IP ruchu wychodzącego, ale zamiast tego należy od czasu do czasu sprawdzić adres IP używany przez aplikację do ruchu wychodzącego, możesz wykonać zapytanie dotyczące bieżących adresów IP wdrożenia usługi App Service.
Normy sprzedaży
Ponieważ usługa App Service jest usługą wielodostępną, musisz zadbać o sposób korzystania z zasobów udostępnionych. Sieć to obszar, do którego należy zwrócić szczególną uwagę, ponieważ istnieją ograniczenia wpływające na sposób pracy aplikacji zarówno z połączeniami sieciowymi przychodzącymi, jak i wychodzącymi, w tym z źródłowymi limitami portów sieciowych (SNAT) i TCP.
Jeśli aplikacja łączy się z dużą liczbą baz danych lub usług zewnętrznych, aplikacja może być zagrożona wyczerpaniem portów SNAT. Ogólnie rzecz biorąc, wyczerpanie portów SNAT wskazuje, że kod nie jest poprawnie ponownie używane połączenia TCP, a nawet w rozwiązaniu wielodostępnym, należy upewnić się, że należy postępować zgodnie z zalecanymi rozwiązaniami dotyczącymi ponownego korzystania z połączeń.
Jednak w niektórych rozwiązaniach wielodostępnych liczba połączeń wychodzących z różnymi adresami IP może spowodować wyczerpanie portów SNAT, nawet jeśli stosujesz dobre rozwiązania w zakresie kodowania. W tych scenariuszach rozważ jedną z następujących opcji:
- Wdróż bramę translatora adresów sieciowych, aby zwiększyć liczbę portów SNAT dostępnych do użycia przez aplikację. Aby uzyskać więcej informacji na temat używania bramy translatora adresów sieciowych w rozwiązaniach wielodostępnych, zobacz Zagadnienia dotyczące usługi Azure NAT Gateway dotyczące wielodostępności.
- Użyj punktów końcowych usługi podczas nawiązywania połączenia z usługami platformy Azure, aby pominąć limity modułu równoważenia obciążenia.
Nawet w przypadku tych kontrolek można zbliżyć się do limitów z dużą liczbą dzierżaw, więc należy zaplanować skalowanie do dodatkowych planów usługi App Service lub sygnatur wdrożenia.
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 klienta, fasttrack dla platformy Azure
Inni współautorzy:
- Thiago Almeida | Główny menedżer programu, Azure Functions
- 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
Przejrzyj zasoby dla architektów i deweloperów rozwiązań wielodostępnych.