Bezserwerowa aplikacja internetowa

Ta architektura referencyjna przedstawia bezserwerową aplikację internetową. Aplikacja obsługuje zawartość statyczną z usługi Azure Blob Storage i implementuje interfejs API przy użyciu usługi Azure Functions. Interfejs API odczytuje dane z usługi Azure Cosmos DB i zwraca wyniki do aplikacji internetowej.

Dwie implementacje referencyjne dla tej architektury są dostępne w usłudze GitHub: Aplikacja do dostarczania przy użyciu dronów (ARM i Azure Pipelines) oraz Aplikacja do wykonania (Bicep i GitHub Actions).

Architektura

Pobierz plik programu Visio z tą architekturą.

Termin bezserwerowy ma dwa odrębne, ale powiązane znaczenie:

• Zaplecze jako usługa (BaaS). Usługi w chmurze zaplecza, takie jak bazy danych i magazyn, udostępniają interfejsy API, które umożliwiają aplikacjom klienckim bezpośrednie łączenie się z tymi usługami.
• Funkcje jako usługa (FaaS). W tym modelu "funkcja" to fragment kodu, który jest wdrażany w chmurze i działa w środowisku hostingu, który całkowicie abstrahuje serwery, na których jest uruchamiany kod.

Obie definicje mają wspólną koncepcję, że deweloperzy i pracownicy devOps nie muszą wdrażać, konfigurować ani zarządzać serwerami. Ta architektura referencyjna koncentruje się na usłudze FaaS korzystającej z usługi Azure Functions, chociaż obsługa zawartości internetowej z usługi Azure Blob Storage może być przykładem usługi BaaS. Oto niektóre ważne cechy FaaS:

1. Zasoby obliczeniowe są przydzielane dynamicznie zgodnie z potrzebami platformy.
2. Ceny oparte na użyciu: opłaty są naliczane tylko za zasoby obliczeniowe używane do wykonywania kodu.
3. Zasoby obliczeniowe są skalowane na żądanie na podstawie ruchu bez konieczności wykonywania jakiejkolwiek konfiguracji przez dewelopera.

Funkcje są wykonywane po wystąpieniu wyzwalacza zewnętrznego, takiego jak żądanie HTTP lub komunikat przychodzący do kolejki. Dzięki temu styl architektury opartej na zdarzeniach jest naturalny dla architektur bezserwerowych. Aby koordynować pracę między składnikami w architekturze, rozważ użycie brokerów komunikatów lub wzorców pub/podrzędnych. Aby uzyskać pomoc dotyczącą wybierania między technologiami obsługi komunikatów na platformie Azure, zobacz Wybieranie między usługami platformy Azure, które dostarczają komunikaty.

Składniki

Niniejsza architektura zawiera następujące składniki:

Blob Storage. Statyczna zawartość internetowa, taka jak pliki HTML, CSS i JavaScript, są przechowywane w usłudze Azure Blob Storage i obsługiwane dla klientów przy użyciu hostingu statycznej witryny internetowej. Cała interakcja dynamiczna odbywa się za pośrednictwem kodu JavaScript wykonującego wywołania interfejsów API zaplecza. Nie ma kodu po stronie serwera do renderowania strony internetowej. Hostowanie statycznej witryny internetowej obsługuje dokumenty indeksu i niestandardowe strony błędów 404.

Sieć CDN. Użyj usługi Azure Content Delivery Network (CDN), aby buforować zawartość w celu zapewnienia mniejszego opóźnienia i szybszego dostarczania zawartości, a także zapewnienia punktu końcowego HTTPS.

Aplikacje funkcji. Usługa Azure Functions to opcja obliczeniowa bezserwerowa. Używa ona modelu sterowanego zdarzeniami, w którym element kodu (funkcja) jest wywoływany przez wyzwalacz. W tej architekturze funkcja jest wywoływana, gdy klient wysyła żądanie HTTP. Żądanie jest zawsze kierowane za pośrednictwem bramy interfejsu API opisanej poniżej.

Usługa API Management. Usługa Azure API Management udostępnia bramę interfejsu API, która znajduje się przed funkcją HTTP. Usługa API Management umożliwia publikowanie interfejsów API używanych przez aplikacje klienckie i zarządzanie nimi. Użycie bramy ułatwia oddzielenie aplikacji frontonu od interfejsów API zaplecza. Na przykład usługa API Management może ponownie napisać adresy URL, przekształcać żądania, zanim dotrą do zaplecza, ustawić nagłówki żądania lub odpowiedzi itd.

Usługa API Management może również służyć do implementowania zagadnień obejmujących międzycięcie, takich jak:

• Wymuszanie limitów przydziału użycia i limitów szybkości
• Weryfikowanie tokenów OAuth na potrzeby uwierzytelniania
• Włączanie żądań między źródłami (CORS)
• Buforowanie odpowiedzi
• Monitorowanie i rejestrowanie żądań

Jeśli nie potrzebujesz wszystkich funkcji udostępnianych przez usługę API Management, inną opcją jest użycie serwerów proxy usługi Functions. Ta funkcja usługi Azure Functions umożliwia zdefiniowanie pojedynczej powierzchni interfejsu API dla wielu aplikacji funkcji przez utworzenie tras do funkcji zaplecza. Serwery proxy funkcji mogą również wykonywać ograniczone przekształcenia w żądaniu HTTP i odpowiedzi. Nie zapewniają jednak tych samych zaawansowanych funkcji opartych na zasadach usługi API Management.

Azure Cosmos DB. Azure Cosmos DB to wielomodelowa usługa bazy danych. W tym scenariuszu aplikacja funkcji pobiera dokumenty z usługi Azure Cosmos DB w odpowiedzi na żądania HTTP GET od klienta.

Microsoft Entra ID (Microsoft Entra ID). Użytkownicy logują się do aplikacji internetowej przy użyciu poświadczeń identyfikatora Entra firmy Microsoft. Identyfikator entra firmy Microsoft zwraca token dostępu dla interfejsu API, którego aplikacja internetowa używa do uwierzytelniania żądań interfejsu API (zobacz Uwierzytelnianie).

Azure Monitor. Usługa Azure Monitor zbiera metryki wydajności dotyczące usług platformy Azure wdrożonych w rozwiązaniu. Wizualizując je na pulpicie nawigacyjnym, możesz uzyskać wgląd w kondycję rozwiązania. Zebrano również dzienniki aplikacji.

Azure Pipelines. Azure Pipelines to usługa ciągłej integracji i ciągłego dostarczania (CD), która kompiluje, testuje i wdraża aplikację.

Funkcja GitHub Actions. Przepływ pracy to zautomatyzowany proces (CI/CD), który został skonfigurowany w repozytorium GitHub. Możesz tworzyć, testować, pakować, wydać lub wdrażać dowolny projekt w usłudze GitHub za pomocą przepływu pracy.

Szczegóły scenariusza

Potencjalne przypadki użycia

To rozwiązanie do dostarczania dronów jest idealne dla samolotów, lotnictwa, lotnictwa, lotnictwa i robotyki.

Zalecenia

Plany aplikacji funkcji

Usługa Azure Functions obsługuje dwa modele hostingu. W przypadku planu zużycia moc obliczeniowa jest przydzielana automatycznie po uruchomieniu kodu. Plan usługi App Service umożliwia przydzielanie zestawu maszyn wirtualnych dla kodu. Plan usługi App Service definiuje liczbę maszyn wirtualnych i rozmiar maszyny wirtualnej.

Należy pamiętać, że plan usługi App Service nie jest ściśle bezserwerowy, zgodnie z definicją podaną powyżej. Jednak model programowania jest taki sam — ten sam kod funkcji może być uruchamiany zarówno w planie zużycia, jak i w planie usługi App Service.

Poniżej przedstawiono kilka czynników, które należy wziąć pod uwagę podczas wybierania typu planu do użycia:

• Zimny start. W przypadku planu zużycia funkcja, która nie została ostatnio wywołana, spowoduje pewne dodatkowe opóźnienie przy następnym uruchomieniu. To dodatkowe opóźnienie jest spowodowane przydzielaniem i przygotowywaniem środowiska uruchomieniowego. Zwykle jest to kolejność sekund, ale zależy od kilku czynników, w tym liczby zależności, które należy załadować. Aby uzyskać więcej informacji, zobacz Understanding Serverless Cold Start (Opis bezserwerowego zimnego uruchamiania). Zimny start jest zwykle bardziej problemem dla obciążeń interaktywnych (wyzwalaczy HTTP) niż asynchroniczne obciążenia sterowane komunikatami (wyzwalacze kolejek lub centrów zdarzeń), ponieważ dodatkowe opóźnienie jest bezpośrednio obserwowane przez użytkowników.
• Limit czasu. W planie zużycia limit czasu wykonywania funkcji jest przekroczony po konfigurowalnym okresie (do maksymalnie 10 minut)
• Izolacja sieci wirtualnej. Użycie planu usługi App Service umożliwia uruchamianie funkcji wewnątrz środowiska App Service Environment, które jest dedykowanym i izolowanym środowiskiem hostingu.
• Model cen. Plan zużycia jest rozliczany według liczby wykonań i użycia zasobów (× czasu wykonywania pamięci). Plan usługi App Service jest rozliczany co godzinę na podstawie jednostki SKU wystąpienia maszyny wirtualnej. Często plan zużycia może być tańszy niż plan usługi App Service, ponieważ płacisz tylko za używane zasoby obliczeniowe. Jest to szczególnie istotne, jeśli ruch występuje w szczytach i korytach. Jeśli jednak aplikacja ma stałą dużą przepływność, plan usługi App Service może kosztować mniej niż plan zużycia.
• Skalowanie. Dużą zaletą modelu zużycia jest to, że jest ona skalowana dynamicznie zgodnie z potrzebami na podstawie ruchu przychodzącego. Chociaż skalowanie odbywa się szybko, nadal istnieje okres zwiększania skali. W przypadku niektórych obciążeń warto celowo przeprowizować maszyny wirtualne, dzięki czemu można obsługiwać wzrosty ruchu z zerowym czasem zwiększania wydajności. W takim przypadku rozważmy plan usługi App Service.

Granice aplikacji funkcji

Aplikacja funkcji hostuje wykonywanie co najmniej jednej funkcji. Możesz użyć aplikacji funkcji, aby zgrupować kilka funkcji razem jako jednostkę logiczną. W aplikacji funkcji funkcje współdzielą te same ustawienia aplikacji, plan hostingu i cykl życia wdrożenia. Każda aplikacja funkcji ma własną nazwę hosta.

Użyj aplikacji funkcji, aby grupować funkcje, które mają ten sam cykl życia i ustawienia. Funkcje, które nie współużytkują tego samego cyklu życia, powinny być hostowane w różnych aplikacjach funkcji.

Rozważ zastosowanie podejścia mikrousług, w którym każda aplikacja funkcji reprezentuje jedną mikrousługę, prawdopodobnie składającą się z kilku powiązanych funkcji. W architekturze mikrousług usługi powinny mieć luźne sprzężenia i wysoką spójność funkcjonalną. Luźno powiązane oznacza, że można zmienić jedną usługę bez konieczności jednoczesnego aktualizowania innych usług. Cohesive oznacza, że usługa ma jeden, dobrze zdefiniowany cel. Aby uzyskać więcej informacji na temat tych pomysłów, zobacz Projektowanie mikrousług: analiza domeny.

Powiązania funkcji

Jeśli to możliwe, użyj powiązań usługi Functions. Powiązania zapewniają deklaratywny sposób łączenia kodu z danymi i integracji z innymi usługami platformy Azure. Powiązanie wejściowe wypełnia parametr wejściowy z zewnętrznego źródła danych. Powiązanie wyjściowe wysyła wartość zwracaną funkcji do ujścia danych, takiego jak kolejka lub baza danych.

Na przykład GetStatus funkcja w implementacji referencyjnej używa powiązania wejściowego usługi Azure Cosmos DB. To powiązanie jest skonfigurowane do wyszukiwania dokumentu w usłudze Azure Cosmos DB przy użyciu parametrów zapytania pobranych z ciągu zapytania w żądaniu HTTP. Jeśli dokument zostanie znaleziony, zostanie przekazany do funkcji jako parametr.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Za pomocą powiązań nie trzeba pisać kodu, który komunikuje się bezpośrednio z usługą, co sprawia, że kod funkcji jest prostszy, a także abstrakcje szczegółów źródła danych lub ujścia. W niektórych przypadkach może być jednak potrzebna bardziej złożona logika niż zapewnia powiązanie. W takim przypadku użyj bezpośrednio zestawów SDK klienta platformy Azure.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Skalowalność

Funkcje. W przypadku planu zużycia wyzwalacz HTTP jest skalowany na podstawie ruchu. Istnieje limit liczby współbieżnych wystąpień funkcji, ale każde wystąpienie może przetwarzać więcej niż jedno żądanie jednocześnie. W przypadku planu usługi App Service wyzwalacz HTTP jest skalowany zgodnie z liczbą wystąpień maszyn wirtualnych, które mogą być wartością stałą lub mogą być skalowane automatycznie na podstawie zestawu reguł skalowania automatycznego. Aby uzyskać informacje, zobacz Skalowanie i hostowanie usługi Azure Functions.

Azure Cosmos DB. Pojemność przepływności dla usługi Azure Cosmos DB jest mierzona w jednostkach żądań (RU). Przepływność 1 RU odpowiada przepływności wymaganej do pobrania dokumentu o rozmiarze 1 KB. Aby skalować kontener usługi Azure Cosmos DB w ciągu ostatnich 10 000 RU, należy określić klucz partycji podczas tworzenia kontenera i uwzględnić klucz partycji w każdym utworzonym dokumencie. Aby uzyskać więcej informacji na temat kluczy partycji, zobacz Partition and scale in Azure Cosmos DB (Partycjonowanie i skalowanie w usłudze Azure Cosmos DB).

Usługa API Management. Usługa API Management może skalować w poziomie i obsługiwać skalowanie automatyczne oparte na regułach. Proces skalowania trwa co najmniej 20 minut. Jeśli ruch jest rozsyłany, należy aprowizować maksymalny oczekiwany ruch z serii. Skalowanie automatyczne jest jednak przydatne do obsługi zmian godzinowych lub dziennych w ruchu. Aby uzyskać więcej informacji, zobacz Automatyczne skalowanie wystąpienia usługi Azure API Management.

Odzyskiwanie po awarii

Wdrożenie pokazane tutaj znajduje się w jednym regionie świadczenia usługi Azure. Aby uzyskać bardziej odporne podejście do odzyskiwania po awarii, skorzystaj z funkcji dystrybucji geograficznej w różnych usługach:

• Usługa API Management obsługuje wdrażanie w wielu regionach, które może służyć do dystrybucji pojedynczego wystąpienia usługi API Management w dowolnej liczbie regionów świadczenia usługi Azure. Aby uzyskać więcej informacji, zobacz Jak wdrożyć wystąpienie usługi Azure API Management w wielu regionach świadczenia usługi Azure.

• Usługa Traffic Manager umożliwia kierowanie żądań HTTP do regionu podstawowego. Jeśli aplikacja funkcji uruchomiona w tym regionie stanie się niedostępna, usługa Traffic Manager może przejść w tryb failover do regionu pomocniczego.

• Usługa Azure Cosmos DB obsługuje wiele regionów zapisu, co umożliwia zapisywanie w dowolnym regionie dodanym do konta usługi Azure Cosmos DB. Jeśli nie włączysz wielu zapisów, nadal możesz przejść w tryb failover w regionie podstawowego zapisu. Zestawy SDK klienta usługi Azure Cosmos DB i powiązania funkcji platformy Azure automatycznie obsługują tryb failover, więc nie trzeba aktualizować żadnych ustawień konfiguracji aplikacji.

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

Uwierzytelnianie

Interfejs GetStatus API w implementacji referencyjnej używa identyfikatora Entra firmy Microsoft do uwierzytelniania żądań. Identyfikator Entra firmy Microsoft obsługuje protokół Połączenie OpenID, który jest protokołem uwierzytelniania opartym na protokole OAuth 2.

W tej architekturze aplikacja kliencka jest jednostronicową aplikacją działającą w przeglądarce. Ten typ aplikacji klienckiej nie może ukrywać wpisu tajnego klienta ani kodu autoryzacji, więc odpowiedni jest niejawny przepływ udzielania. (Zobacz Którego przepływu protokołu OAuth 2.0 należy użyć?). Oto ogólny przepływ:

1. Użytkownik klika link "Zaloguj się" w aplikacji internetowej.
2. Przeglądarka jest przekierowywana na stronę logowania firmy Microsoft Entra.
3. Użytkownik loguje się.
4. Identyfikator Entra firmy Microsoft przekierowuje z powrotem do aplikacji klienckiej, w tym token dostępu w fragmentze adresu URL.
5. Gdy aplikacja internetowa wywołuje interfejs API, zawiera token dostępu w nagłówku Uwierzytelnianie. Identyfikator aplikacji jest wysyłany jako oświadczenie odbiorców ('aud') w tokenie dostępu.
6. Interfejs API zaplecza weryfikuje token dostępu.

Aby skonfigurować uwierzytelnianie:

• Zarejestruj aplikację w dzierżawie firmy Microsoft Entra. Spowoduje to wygenerowanie identyfikatora aplikacji, który klient zawiera z adresem URL logowania.

• Włącz uwierzytelnianie entra firmy Microsoft w aplikacji funkcji. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja w usłudze Azure App Service.

• Dodaj zasady validate-jwt do usługi API Management, aby wstępnie autoryzować żądanie, weryfikując token dostępu.

Aby uzyskać więcej informacji, zobacz plik readme usługi GitHub.

Zaleca się utworzenie oddzielnych rejestracji aplikacji w usłudze Microsoft Entra ID dla aplikacji klienckiej i interfejsu API zaplecza. Udziel aplikacji klienckiej uprawnienia do wywoływania interfejsu API. Takie podejście zapewnia elastyczność definiowania wielu interfejsów API i klientów oraz kontrolowania uprawnień dla każdego z nich.

W interfejsie API użyj zakresów , aby zapewnić aplikacjom szczegółową kontrolę nad uprawnieniami, których żądają od użytkownika. Na przykład interfejs API może mieć Read zakresy i Write , a określona aplikacja kliencka może poprosić użytkownika o autoryzowanie Read tylko uprawnień.

Autoryzacja

W wielu aplikacjach interfejs API zaplecza musi sprawdzić, czy użytkownik ma uprawnienia do wykonywania danej akcji. Zaleca się używanie autoryzacji opartej na oświadczeniach, gdzie informacje o użytkowniku są przekazywane przez dostawcę tożsamości (w tym przypadku identyfikator Entra firmy Microsoft) i używane do podejmowania decyzji dotyczących autoryzacji. Na przykład podczas rejestrowania aplikacji w usłudze Microsoft Entra ID można zdefiniować zestaw ról aplikacji. Gdy użytkownik loguje się do aplikacji, identyfikator Entra firmy Microsoft zawiera roles oświadczenie dla każdej roli, którą użytkownikowi przyznano, w tym role dziedziczone za pośrednictwem członkostwa w grupie.

Token identyfikatora zwracany przez identyfikator Entra firmy Microsoft do klienta zawiera niektóre oświadczenia użytkownika. W aplikacji funkcji te oświadczenia są dostępne w nagłówku X-MS-CLIENT-PRINCIPAL żądania. Jednak łatwiej jest odczytać te informacje z danych powiązania. W przypadku innych oświadczeń użyj programu Microsoft Graph , aby wysłać zapytanie do identyfikatora Entra firmy Microsoft. (Użytkownik musi wyrazić zgodę na tę akcję podczas logowania).

Aby uzyskać więcej informacji, zobacz Praca z tożsamościami klientów.

CORS

W tej architekturze referencyjnej aplikacja internetowa i interfejs API nie współużytkują tego samego źródła. Oznacza to, że gdy aplikacja wywołuje interfejs API, jest to żądanie między źródłami. Zabezpieczenia przeglądarki uniemożliwiają stronie internetowej wysyłanie żądań AJAX do innej domeny. To ograniczenie jest nazywane zasadami tego samego źródła i uniemożliwia złośliwej witrynie odczytywanie poufnych danych z innej witryny. Aby włączyć żądanie między źródłami, dodaj zasady współużytkowania zasobów między źródłami (CORS) do bramy usługi API Management:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

W tym przykładzie atrybut allow-credentials ma wartość true. Umożliwia to przeglądarce wysyłanie poświadczeń (w tym plików cookie) za pomocą żądania. W przeciwnym razie przeglądarka domyślnie nie wysyła poświadczeń z żądaniem między źródłami.

Wymuszanie protokołu HTTPS

Aby uzyskać maksymalne bezpieczeństwo, należy wymagać protokołu HTTPS w całym potoku żądania:

• Sieć CDN. Usługa Azure CDN domyślnie obsługuje protokół HTTPS w *.azureedge.net poddomenie. Aby włączyć protokół HTTPS w usłudze CDN dla niestandardowych nazw domen, zobacz Samouczek: konfigurowanie protokołu HTTPS w domenie niestandardowej usługi Azure CDN.

• Hostowanie statycznej witryny internetowej. Włącz opcję "Wymagany bezpieczny transfer" na koncie magazynu. Po włączeniu tej opcji konto magazynu zezwala tylko na żądania z bezpiecznych połączeń HTTPS.

• Usługa API Management. Skonfiguruj interfejsy API tak, aby używały tylko protokołu HTTPS. Można to skonfigurować w witrynie Azure Portal lub za pomocą szablonu usługi Resource Manager:

  {
      "apiVersion": "2018-01-01",
      "type": "apis",
      "name": "dronedeliveryapi",
      "dependsOn": [
          "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
      ],
      "properties": {
          "displayName": "Drone Delivery API",
          "description": "Drone Delivery API",
          "path": "api",
          "protocols": [ "HTTPS" ]
      },
      ...
  }
  

• Usługa Azure Functions. Włącz ustawienie "Tylko https".

Blokowanie aplikacji funkcji

Wszystkie wywołania funkcji powinny przechodzić przez bramę interfejsu API. Można to osiągnąć w następujący sposób:

• Skonfiguruj aplikację funkcji, aby wymagać klucza funkcji. Brama usługi API Management będzie zawierać klucz funkcji, gdy wywołuje aplikację funkcji. Uniemożliwia to klientom bezpośrednie wywoływanie funkcji przez pominięcie bramy.

• Brama usługi API Management ma statyczny adres IP. Ogranicz funkcję platformy Azure, aby zezwalać tylko na wywołania z tego statycznego adresu IP. Aby uzyskać więcej informacji, zobacz aplikacja systemu Azure Service Static IP Restrictions (Ograniczenia statycznych adresów IP usługi aplikacja systemu Azure Service). (Ta funkcja jest dostępna tylko dla usług w warstwie Standardowa).

Ochrona wpisów tajnych aplikacji

Nie przechowuj wpisów tajnych aplikacji, takich jak poświadczenia bazy danych, w kodzie lub plikach konfiguracji. Zamiast tego użyj ustawień aplikacji, które są przechowywane zaszyfrowane na platformie Azure. Aby uzyskać więcej informacji, zobacz Zabezpieczenia w usługach aplikacja systemu Azure Service i Azure Functions.

Alternatywnie można przechowywać wpisy tajne aplikacji w usłudze Key Vault. Dzięki temu można scentralizować przechowywanie wpisów tajnych, kontrolować ich dystrybucję i monitorować sposób uzyskiwania dostępu do wpisów tajnych. Aby uzyskać więcej informacji, zobacz Konfigurowanie aplikacji internetowej platformy Azure w celu odczytania wpisu tajnego z usługi Key Vault. Należy jednak pamiętać, że wyzwalacze i powiązania usługi Functions ładują ustawienia konfiguracji z ustawień aplikacji. Nie ma wbudowanego sposobu konfigurowania wyzwalaczy i powiązań w celu używania wpisów tajnych usługi Key Vault.

DevOps

Wdrażanie frontonu

Fronton tej architektury referencyjnej jest aplikacją jednostronicową z dostępem do bezserwerowych interfejsów API zaplecza i zawartością statyczną zapewniającą szybkie środowisko użytkownika. Poniżej przedstawiono kilka ważnych zagadnień dotyczących takiej aplikacji:

• Wdróż aplikację równomiernie dla użytkowników w szerokim obszarze geograficznym przy użyciu globalnej usługi CDN z zawartością statyczną hostowaną w chmurze. Pozwala to uniknąć konieczności korzystania z dedykowanego serwera internetowego. Przeczytaj Temat Integrowanie konta usługi Azure Storage z usługą Azure CDN , aby rozpocząć pracę. Zabezpieczanie aplikacji przy użyciu protokołu HTTPS. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi używania sieci dostarczania zawartości, aby uzyskać dodatkowe zalecenia.
• Użyj szybkiej i niezawodnej usługi ciągłej integracji/ciągłego wdrażania, takiej jak Azure Pipelines lub GitHub Actions, aby automatycznie kompilować i wdrażać każdą zmianę źródła. Źródło musi znajdować się w systemie kontroli wersji online. Aby uzyskać więcej informacji na temat usługi Azure Pipelines, zobacz Tworzenie pierwszego potoku. Aby dowiedzieć się więcej na temat funkcji GitHub Actions dla platformy Azure, zobacz Wdrażanie aplikacji na platformie Azure.
• Kompresuj pliki witryny internetowej, aby zmniejszyć zużycie przepustowości w sieci CDN i zwiększyć wydajność. Usługa Azure CDN umożliwia kompresję na bieżąco na serwerach brzegowych. Alternatywnie potok wdrażania w tej architekturze referencyjnej kompresuje pliki przed wdrożeniem ich w usłudze Blob Storage. Zmniejsza to wymaganie magazynowania i zapewnia większą swobodę wyboru narzędzi kompresji, niezależnie od ograniczeń sieci CDN.
• Sieć CDN powinna mieć możliwość przeczyszczania pamięci podręcznej , aby zapewnić, że wszyscy użytkownicy będą obsługiwać najświeższą zawartość. Czyszczenie pamięci podręcznej jest wymagane, jeśli procesy kompilacji i wdrażania nie są niepodzielne, na przykład jeśli zastąpią stare pliki nowo utworzonymi w tym samym folderze pochodzenia.
• Inna strategia pamięci podręcznej, taka jak przechowywanie wersji przy użyciu katalogów, może nie wymagać przeczyszczenia przez sieć CDN. Potok kompilacji w tej aplikacji frontonu tworzy nowy katalog dla każdej nowo utworzonej wersji. Ta wersja jest przesyłana jako jednostka niepodzielna do magazynu obiektów blob. Usługa Azure CDN wskazuje tę nową wersję dopiero po zakończeniu wdrażania.
• Zwiększ czas wygaśnięcia pamięci podręcznej, buforując pliki zasobów przez dłuższy czas trwania, obejmujący miesiące. Aby upewnić się, że buforowane pliki są aktualizowane podczas ich zmiany, odcisk palca nazw plików podczas ich odbudowy. Ta aplikacja frontonu odciski palców wszystkich plików z wyjątkiem plików publicznych, takich jak index.html. Ponieważ index.html jest często aktualizowana, odzwierciedla zmienione nazwy plików powodujące odświeżanie pamięci podręcznej. Aby uzyskać więcej informacji, zobacz Zarządzanie wygasaniem zawartości internetowej w usłudze Azure CDN.

Wdrażanie zaplecza

Aby wdrożyć aplikację funkcji, zalecamy używanie plików pakietów ("Uruchom z pakietu"). Korzystając z tego podejścia, przekazujesz plik zip do kontenera usługi Blob Storage, a środowisko uruchomieniowe usługi Functions instaluje plik zip jako system plików tylko do odczytu. Jest to operacja niepodzielna, która zmniejsza prawdopodobieństwo, że wdrożenie nie powiodło się, pozostawi aplikację w stanie niespójnym. Może również poprawić czasy zimnego uruchamiania, zwłaszcza w przypadku aplikacji Node.js, ponieważ wszystkie pliki są zamieniane jednocześnie.

Obsługa wersji interfejsu API

Interfejs API to kontrakt między usługą a klientami. W tej architekturze kontrakt interfejsu API jest definiowany w warstwie usługi API Management. Usługa API Management obsługuje dwa odrębne, ale uzupełniające pojęcia dotyczące przechowywania wersji:

• Wersje umożliwiają użytkownikom interfejsu API wybór wersji interfejsu API na podstawie ich potrzeb, takich jak wersja 1 i wersja 2.

• Poprawki umożliwiają administratorom interfejsu API wprowadzanie zmian niełamujących się w interfejsie API i wdrażanie tych zmian wraz z dziennikiem zmian w celu informowania użytkowników interfejsu API o zmianach.

Jeśli wprowadzisz zmianę powodującą niezgodność w interfejsie API, opublikuj nową wersję w usłudze API Management. Wdróż nową wersję obok oryginalnej wersji w oddzielnej aplikacji funkcji. Dzięki temu można migrować istniejących klientów do nowego interfejsu API bez przerywania aplikacji klienckich. W końcu możesz wycofać poprzednią wersję. Usługa API Management obsługuje kilka schematów przechowywania wersji: ścieżkę adresu URL, nagłówek HTTP lub ciąg zapytania. Aby uzyskać więcej informacji na temat przechowywania wersji interfejsu API w ogóle, zobacz Przechowywanie wersji internetowego interfejsu API RESTful.

W przypadku aktualizacji, które nie są powodujące niezgodność zmian interfejsu API, wdróż nową wersję w miejscu przejściowym w tej samej aplikacji funkcji. Sprawdź, czy wdrożenie zakończyło się pomyślnie, a następnie zamień etapową wersję na wersję produkcyjną. Publikowanie poprawki w usłudze API Management.

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.

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure. Rozważ te kwestie, aby zoptymalizować koszt tej architektury.

Azure Functions

Usługa Azure Functions obsługuje dwa modele hostingu.

• Plan zużycia.

  Moc obliczeniowa jest przydzielana automatycznie po uruchomieniu kodu.

• Plan usługi App Service.

  Zestaw maszyn wirtualnych jest przydzielany dla kodu. Ten plan definiuje liczbę maszyn wirtualnych i rozmiar maszyny wirtualnej.

W tej architekturze funkcja jest wywoływana, gdy klient wysyła żądanie HTTP. Ponieważ w tym przypadku użycia nie jest oczekiwana stała przepływność o dużej ilości, zaleca się użycie planu, ponieważ płacisz tylko za używane zasoby obliczeniowe.

Azure Cosmos DB

Opłaty za aprowizowaną przepływność i zużycie magazynu w usłudze Azure Cosmos DB są naliczane godzinowo. Aprowizowana przepływność jest wyrażana w jednostkach żądań na sekundę (RU/s), które mogą być używane do typowych operacji bazy danych, takich jak operacje wstawiania, odczyty. Cena jest oparta na pojemności jednostek RU/s, które rezerwujesz.

Opłata za magazyn jest naliczana za każdy GB używany dla przechowywanych danych i indeksu.

Aby uzyskać więcej informacji, zobacz Model cen usługi Azure Cosmos DB.

W tej architekturze aplikacja funkcji pobiera dokumenty z usługi Azure Cosmos DB w odpowiedzi na żądania HTTP GET od klienta. Usługa Azure Cosmos DB jest w tym przypadku opłacalna, ponieważ operacje odczytu są znacznie tańsze niż operacje zapisu wyrażone na jednostkach RU/s.

Content Delivery Network

Stawka rozliczeń może się różnić w zależności od regionu rozliczeniowego na podstawie lokalizacji serwera źródłowego dostarczającego zawartość użytkownikowi końcowemu. Lokalizacja fizyczna klienta nie jest regionem rozliczeniowym. Każde żądanie HTTP lub HTTPS, które osiąga sieć CDN, jest rozliczanym zdarzeniem, które obejmuje wszystkie typy odpowiedzi: powodzenie, niepowodzenie lub inne. Różne odpowiedzi mogą generować różne kwoty ruchu.

W tej architekturze referencyjnej wdrożenie znajduje się w jednym regionie świadczenia usługi Azure.

Aby obniżyć koszty, rozważ zwiększenie czasu wygaśnięcia pamięci podręcznej przez buforowanie plików zasobów przez dłuższy czas trwania i ustawienie najdłuższego czasu wygaśnięcia możliwego dla zawartości.

Aby uzyskać więcej informacji, zobacz sekcję Koszt w witrynie Microsoft Azure Well-Architected Framework.

Wdrażanie tego scenariusza

Aby wdrożyć implementację referencyjną dla tej architektury, zobacz plik readme usługi GitHub.

Następne kroki

Dokumentacja produktu:

• Co to jest usługa Azure Blob Storage?
• Azure Content Delivery Network (CDN)
• Wprowadzenie do usługi Azure Functions
• Informacje o usłudze API Management
• Azure Cosmos DB — Zapraszamy!
• Tożsamość Microsoft Entra
• Omówienie usługi Azure Monitor
• Co to jest usługa Azure Pipelines?

Moduły szkoleniowe:

• Wybieranie najlepszej technologii bezserwerowej platformy Azure dla scenariusza biznesowego
• Tworzenie logiki bezserwerowej za pomocą usługi Azure Functions

Powiązane zasoby

Aby dowiedzieć się więcej na temat implementacji referencyjnej, przeczytaj przewodnik po kodzie: aplikacja bezserwerowa z usługą Azure Functions.

Powiązane wskazówki:

• Najlepsze rozwiązania dotyczące korzystania z sieci CDN
• Wzorzec hostingu zawartości statycznej