Wdrażanie mikrousług za pomocą usług Azure Container Apps i Dapr

W tym artykule opisano rozwiązanie do uruchamiania systemu zarządzania zamówieniami jako zestawu usług konteneryzowanych w Azure Container Apps. Rozwiązanie korzysta z bloków konstrukcyjnych Distributed Application Runtime (Dapr) na potrzeby komunikacji i dostępu do stanu oraz Kubernetes Event-driven Autoscaling (KEDA) na potrzeby skalowania opartego na zdarzeniach.

Dapr jest znakiem towarowym swojej firmy. Użycie tego znaku nie implikuje poparcia.

Architektura

Pobierz plik programu PowerPoint tej architektury.

Przepływ danych

W tym rozwiązaniu opisano fikcyjny system zarządzania zamówieniami i jego pomocniczą infrastrukturę Azure. Architektura używa jednego środowiska usługi Container Apps, które hostuje usługi .NET, interfejs użytkownika Vue.js i program inicjujący. Usługa Container Apps udostępnia zarządzaną warstwę ruchu przychodzącego opartą na usłudze Envoy, więc obciążenie robocze nie wdraża własnej warstwy serwera proxy. Wewnętrzne wywołania typu service-to-service używają wywołania usługi Dapr, które są kierowane przez infrastrukturę proxy środowiska. Rozwiązanie używa zestawu SDK platformy Dapr do integracji z zasobami Azure za pomocą bloków konstrukcyjnych pub/sub, stanu, wywołania usługi i bindingów. Usługi używają reguł skalowania opartych na KEDA do skalowania w odpowiedzi na ruch HTTP i wolumin komunikatów w Azure Service Bus.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi.

1. Zarządzany ingres: Usługa Container Apps udostępnia zarządzaną warstwę ingresu opartą na usłudze Envoy. Konfiguracja routingu oparta na regułach na poziomie środowiska publikuje jedną nazwę hosta, obsługuje interfejs użytkownika ze ścieżki głównej i przekazuje ścieżki interfejsu API pulpitu nawigacyjnego do usług księgowych i Makeline. Te dwie usługi korzystają z wewnętrznego ingressu, ponieważ konfiguracja trasy może dotyczyć aplikacji, która nie jest uwidoczniona zewnętrznie.

2. Interfejs użytkownika: Pulpit nawigacyjny przedstawiający dane o zamówieniach w czasie rzeczywistym i zagregowane dane sprzedaży dla systemu zarządzania zamówieniami.

3. Wirtualny klient: program symulacji klienta, który symuluje klientom składanie zamówień za pośrednictwem usługi zamówienia.

4. Usługa zamówień: Interfejs API tworzenia, odczytywania, aktualizowania i usuwania do składania zamówień i zarządzania nimi.

5. Usługa księgowości: usługa, która przetwarza, przechowuje i agreguje dane zamówień. Przekształca zamówienia klientów w znaczące metryki sprzedaży wyświetlane przez interfejs użytkownika.

6. Usługa paragonów: program archiwalny, który generuje i przechowuje potwierdzenia zamówień na potrzeby inspekcji i celów historycznych.

7. Usługa lojalnościowa: usługa, która zarządza programem lojalnościowym, śledząc punkty nagród klientów na podstawie wydatków na zamówienie.

8. Usługa makeline: Usługa, która zarządza kolejką bieżących zamówień oczekujących na spełnienie. Śledzi przetwarzanie i realizację zamówień przez usługę wirtualnego pracownika.

9. Wirtualny proces roboczy:program symulacji procesu roboczego, który symuluje ukończenie zamówień klientów.

Usługa Container Apps obsługuje tylko podzestaw składników, które są dostępne w projekcie open source Dapr. Składniki Service Bus, Azure Cosmos DB i Blob Storage w tej architekturze to składniki poziomu 1. Magazyn stanów usługi Redis i powiązanie Cron to składniki poziomu 2, które otrzymują niższy priorytet pomocy technicznej. Przejrzyj bieżące poziomy obsługi składników Dapr w usłudze Container Apps i upewnij się, że każdy składnik spełnia wymagania dotyczące obsługi Twojego obciążenia.

Składniki

• Application Insights to usługa zarządzania wydajnością aplikacji. W tej architekturze instrumentujesz kod aplikacji w celu wysyłania żądań, zależności, wyjątków i rozproszonych śladów do usługi Application Insights. Usługa Container Apps nie zapewnia automatycznej instrumentacji usługi Application Insights.

• Blob Storage to magazyn obiektowy dla danych bez struktury. W tej architekturze usługa potwierdzeń odbioru używa powiązania wyjściowego Dapr do przechowywania potwierdzeń odbioru zamówień w Blob Storage.

• Usługa Azure Managed Redis udostępnia magazyn danych w pamięci oparty na oprogramowaniu Redis Enterprise. W tej architekturze jest używany jako składnik magazynu stanów Dapr dla usługi Makeline do przechowywania danych dotyczących przetwarzanych zamówień.

• Azure Cosmos DB jest zarządzaną rozproszoną usługą bazy danych. W tej architekturze usługa lojalnościowa korzysta z niego za pośrednictwem składnika magazynu stanów Dapr do przechowywania danych lojalnościowych klientów.

• Azure Monitor zbiera i analizuje dane telemetryczne z zasobów platformy Azure i aplikacji. W tej architekturze używasz Azure Monitor do monitorowania metryk platformy usługi Container Apps, dzienników konsoli i systemu, alertów i telemetrii aplikacji usługi Application Insights.

• Service Bus jest w pełni zarządzanym brokerem komunikatów klasy korporacyjnej, który udostępnia kolejki i tematy publikowania-subskrypcji. W tej architekturze używasz usługi Service Bus do implementacji składnika publikowanie-subskrybowanie w ramach Dapr. Ten składnik jest używany przez wiele usług. Usługa zamówienia publikuje komunikaty w autobusie, a usługi Makeline, księgowość, lojalność i paragony subskrybują te wiadomości.

• Container Apps to w pełni zarządzana bezserwerowa usługa kontenerowa dla konteneryzowanych aplikacji. W tej architekturze hostuje wszystkie aplikacje kontenerów w jednym środowisku i zapewnia zarządzany ingress oparty na Envoy na potrzeby routingu zewnętrznego do interfejsu użytkownika. Traktuj środowisko jako udostępnioną sieć, wdrożenie i granicę zaufania oraz umieszczaj obciążenia wymagające izolacji w oddzielnych środowiskach.

• SQL Database to zarządzana usługa relacyjnej bazy danych. W tej architekturze pełni rolę magazynu danych dla usługi księgowej, która używa Entity Framework Core w celu uzyskania dostępu do bazy danych. Bootstrapper tworzy wymagane obiekty bazy danych przed rozpoczęciem przetwarzania zamówień przez usługę księgowania.

• Dapr to środowisko uruchomieniowe typu open source, które udostępnia interfejsy API do zadań związanych z aplikacjami rozproszonymi. W tej architekturze Container Apps uruchamia zarządzany składnik sidecar Dapr obok każdej włączonej usługi, a usługi korzystają z bloków składowych: publikowania/subskrybowania, stanu, powiązań i wywoływania usług.

• KEDA to mechanizm automatycznego skalowania oparty na zdarzeniach o otwartym kodzie źródłowym. W tej architekturze zarządzana integracja KEDA w usłudze Container Apps skaluje usługi na podstawie współbieżności HTTP i liczby komunikatów w subskrypcji usługi Service Bus.

Alternatywy

Ta architektura używa wbudowanej warstwy ingress usługi Container Apps, która działa jako zarządzany serwer proxy Envoy wraz z konfiguracją tras na poziomie środowiska. Ta kombinacja zastępuje kontener proxy, który zespół odpowiedzialny za obciążenie musiałby w przeciwnym razie wdrożyć, skalować i aktualizować. Uprawnienia do konfiguracji tras są ograniczone do środowiska, a nie do poszczególnych aplikacji, a trasa na poziomie środowiska może uwidaczniać aplikację, która w przeciwnym razie ma wewnętrzny ingress, dlatego należy ograniczyć, kto może tworzyć trasy, i weryfikować cel każdej trasy.

W przypadku obciążeń produkcyjnych dostępnych z Internetu użyj zarządzanej usługi ruchu przychodzącego z funkcjami zapory aplikacji internetowej, takimi jak Azure Application Gateway lub Azure Front Door, na podstawie wymagań dotyczących routingu regionalnego lub globalnego. Preferuj zarządzany ingress zamiast samodzielnie hostowanego serwera proxy, aby zespół obciążeń nie odpowiadał za obraz serwera proxy, poprawki luk w zabezpieczeniach, konfigurację wysokiej dostępności i cykl życia skalowania. Używaj własnego serwera proxy tylko wtedy, gdy wymagana funkcja nie jest dostępna w opcjach zarządzanych, a także udokumentuj jego procesy wzmacniania zabezpieczeń, stosowania poprawek, monitorowania i odzyskiwania.

Usługi docierają do Service Bus, Azure Cosmos DB, Azure Managed Redis i Blob Storage za pośrednictwem składników Dapr, a usługa księgowa łączy się z usługą SQL Database bezpośrednio za pośrednictwem Entity Framework Core. Gdy dwa składniki implementują zgodne zachowanie interfejsu API platformy Dapr, często można zmienić konfigurację składnika bez zmiany kodu aplikacji. Możliwości składników, modele spójności, metody uwierzytelniania, zachowanie operacyjne i warstwy obsługi usługi Container Apps różnią się, dlatego przed przełączeniem zweryfikuj rozwiązanie zastępcze. Dokumentacja Dapr zawiera listę alternatywnych brokerów publikowania-subskrypcji, magazynów stanów i powiązań wyjściowych.

Szczegóły scenariusza

Mikrousługi zapewniają niezależne granice wdrażania i skalowania, ale także wprowadzają złożoność związaną z systemami rozproszonymi i operacjami. Usługi konteneryzowane wymagają platformy, która zapewnia możliwości wdrażania, sieciowania, skalowania i obserwowalność.

Ta architektura korzysta z zarządzanej integracji Dapr w usłudze Container Apps. Dapr udostępnia interfejsy API dotyczące zagadnień aplikacji rozproszonych, takich jak zarządzanie stanem, obsługa komunikatów publikowania i subskrybowania, powiązania i wywołanie usługi.

Usługa Container Apps używa usługi KEDA do skalowania aplikacji kontenerów na podstawie ruchu HTTP i zdarzeń z usług, takich jak Service Bus i Azure Managed Redis.

Wbudowany mechanizm wejściowy usługi Container Apps zapewnia punkty końcowe HTTPS, wewnętrzne odnajdywanie usług, równoważenie obciążenia i dzielenie ruchu między wersjami. Ta architektura korzysta z routingu opartego na regułach, aby interfejs użytkownika i interfejsy API pulpitu nawigacyjnego korzystały ze wspólnej nazwy hosta, podczas gdy usługi zaplecza korzystają z wewnętrznego ingressu. Dodaj Azure Front Door lub usługę Application Gateway, gdy obciążenie robocze wymaga WAF, routingu globalnego lub innych kontrolek brzegowych.

Aby uzyskać więcej informacji, zobacz Porównanie aplikacji kontenera z innymi opcjami kontenera platformy Azure.

Potencjalne przypadki użycia

Należy wziąć pod uwagę tę architekturę dla systemów zamówień i realizacji opartych na zdarzeniach, które wymagają samodzielnie wdrażalnych usług HTTP oraz usług działających w tle, asynchronicznych komunikatów i zarządzanych magazynów stanów. Scenariusz dotyczy handlu detalicznego, towarów szybkozbywalnych (CPG) i zastosowań produkcyjnych.

Powiązane podejścia architektoniczne obejmują:

• Architektura mikrousług w usłudze Azure Kubernetes Service (AKS)
• Architektura mikrousług w usłudze Azure Functions
• Architektury sterowane zdarzeniami

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Niezawodność

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

Ta architektura używa jednego środowiska usługi Container Apps w jednym regionie Azure, więc regionalna awaria sprawia, że aplikacja jest niedostępna. W przypadku wdrożenia produkcyjnego należy użyć następujących rozwiązań dotyczących niezawodności:

• Włącz nadmiarowość strefową podczas tworzenia środowiska usługi Container Apps. Skonfiguruj co najmniej dwie repliki dla usług, które muszą pozostać dostępne podczas awarii strefy. W przypadku usług wystawionych przez ingress należy wziąć pod uwagę co najmniej trzy repliki na podstawie celu dostępności i testów wydajności.

• Skonfiguruj sondy uruchamiania, gotowości i żywotności dla każdej usługi. Sondy umożliwiają usłudze Container Apps ponowne uruchamianie kontenerów, które zakończyły się niepowodzeniem, i usuwanie replik w złej kondycji z równoważenia obciążenia.

• Ustaw minimalną liczbę replik i reguły skalowania , które zachowują wymaganą pojemność po awarii repliki lub strefy. Skalowanie do zera jest odpowiednie tylko dla usług, które mogą tolerować opóźnienie zimnego startu i okresy bez uruchomionych replik.

• Zastosuj obsługę błędów przejściowych do wywołań między usługami i do zależności platformy Azure. Użyj ograniczonych ponownych prób z odstępami między próbami, przekroczeniami limitu czasu i wyłącznikami awaryjnymi. Koordynowanie zasad ponawiania prób między warstwami w celu uniknięcia pomnożenia prób. Utwórz ponawiane operacje i moduły obsługi komunikatów jako idempotentne, ponieważ ponawianie prób i ponowne dostarczenie przez Service Bus mogą powtarzać pracę.

• Skonfiguruj funkcje niezawodności i odzyskiwania usługi SQL Database, Azure Cosmos DB, Azure Managed Redis, Service Bus i Blob Storage w celu spełnienia celów odzyskiwania obciążenia. Container Apps nie replikuje danych aplikacji ani nie udostępnia kopii zapasowej danych.

• Nie używaj Azure Managed Redis jako głównego systemu ewidencji dla danych, których nie można odtworzyć. Usługa księgowości przechowuje każde zamówienie i rejestruje datę ukończenia, podczas gdy usługa Managed Redis Azure przechowuje tylko kolejkę roboczą usługi Makeline. Jeśli stan usługi Redis zostanie utracony, należy odbudować oczekującą kolejkę.

Jeśli obciążenie musi tolerować awarię regionalną, wdróż oddzielne środowiska usługi Container Apps i zasoby zależne w różnych regionach. Użyj Azure Front Door lub Azure Traffic Manager na potrzeby trybu failover ruchu, a następnie zdefiniuj strategię replikacji danych i odzyskiwania między regionami.

Usługa Container Apps zapewnia zasady odporności dla odnajdywania usług (wersja zapoznawcza) dla wywołań wykonanych za pośrednictwem odnajdywania usługi Container Apps. Te zasady nie mają zastosowania do wywołania usługi Dapr. W przypadku wywołań Dapr tej architektury zaimplementuj limity czasu, ograniczone ponowienia i wyłączniki awaryjne w aplikacji wywołującej.

W przypadku usług obsługujących Dapr włącz i skonfiguruj testy kondycji aplikacji Dapr wraz z sondami kondycji usługi Container Apps. Dapr łączy kondycję sidecar z stanem aplikacji.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

W tej przykładowej architekturze priorytetem jest demonstrowanie Dapr i skalowania opartego na zdarzeniach. Używa poświadczeń administratora lub kluczy dostępu dla kilku usług danych, nie wdraża środowiska usługi Container Apps w sieci wirtualnej i nie zawiera zapory aplikacji internetowej. Nie używaj tych ustawień dla wdrożenia produkcyjnego.

• Przypisz oddzielną tożsamość zarządzaną do każdej aplikacji kontenera. Przyznaj każdej tożsamości tylko role płaszczyzny danych, których wymaga jej usługa. Użyj uwierzytelniania Microsoft Entra dla usługi SQL Database, Service Bus, Blob Storage, Azure Cosmos DB i usługi Azure Managed Redis, jeśli jest to obsługiwane przez wybranego klienta lub składnik Dapr.

• Skonfiguruj składniki Dapr oparte na Azure, aby używały tożsamości zarządzanej. Jeśli składnik nie obsługuje tożsamości zarządzanej, zapisz poświadczenia w Azure Key Vault i odwołuj się do nich za pośrednictwem magazynu sekretów Dapr. Ogranicz zakres każdego komponentu Dapr tylko do aplikacji, które go używają.

• Użyj tożsamości zarządzanej do uwierzytelniania reguły skalowania Service Bus KEDA. Nie umieszczaj parametrów połączenia na poziomie przestrzeni nazw w wpisach tajnych aplikacji kontenerowej.

• Wdróż środowisko usługi Container Apps w sieci wirtualnej. Użyj prywatnych punktów końcowych dla obsługiwanych usług danych i wyłącz ich dostęp do sieci publicznej. Kontroluj ruch wychodzący przy użyciu tras zdefiniowanych przez użytkownika i Azure Firewall, gdy obciążenie wymaga inspekcji lub ograniczeń ruchu wychodzącego.

• Ochrona publicznego ruchu HTTP za pomocą Azure Web Application Firewall. Użyj usługi Application Gateway z Web Application Firewall dla ruchu przychodzącego regionalnego lub użyj Azure Front Door Premium z Azure Private Link na potrzeby globalnego ruchu przychodzącego. Źródła pochodzenia Private Link wymagają warstwy Premium i środowiska profilów obciążeń. Wyłącz dostęp do sieci publicznej w środowisku usługi Container Apps, gdy cały ruch przychodzący korzysta z łączności prywatnej.

• Włącz uwierzytelnianie i autoryzację usługi Container Apps dla punktów końcowych przeznaczonych dla użytkowników, jeśli obciążenie spełnia wymagania dotyczące tożsamości. Zastosuj autoryzację w obciążeniu roboczym w celu podejmowania decyzji na poziomie zasobów. Wywołanie usługi Dapr zapewnia TLS z wzajemnym uwierzytelnianiem dla wywołań między aplikacjami obsługującymi Dapr, ale nie zastępuje autoryzacji aplikacji.

• Przechowuj obrazy w prywatnym wystąpieniu Azure Container Registry. Ściąganie obrazów przy użyciu tożsamości zarządzanej, przypinanie obrazów możliwych do wdrożenia za pomocą skrótu kontrolnego lub niezmiennego tagu wersji, skanowanie obrazów w potoku dostarczania i unikanie kontenerów uprzywilejowanych.

• Wyczyść poświadczenia, dane osobowe i poufne dane biznesowe z dzienników aplikacji i dzienników Dapr. Wysyłaj dzienniki związane z zabezpieczeniami do centralnego miejsca docelowego i konfiguruj alerty dotyczące niepowodzeń uwierzytelniania, nieoczekiwanego ruchu wychodzącego oraz zmian dotyczących tożsamości lub dostępu do sieci.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji kosztów.

Użyj tego wstępnie skonfigurowanego oszacowania w kalkulatorze cen Azure jako punktu wyjścia dla reprezentatywnego wdrożenia produkcyjnego w jednym regionie. Szacowanie obejmuje aplikacje kontenerowe i alokacje zasobów pomocniczego kontenera Dapr, skalowanie oparte na KEDA, usługę SQL Database, Azure Cosmos DB, usługę Azure Managed Redis, Service Bus, Blob Storage, Azure Monitor, Application Insights, Key Vault, Usługa Container Registry, prywatne punkty końcowe i Azure Front Door Premium z zaporą aplikacji internetowej i obsługą Private Link.

Oszacowanie korzysta z cennika płatności zgodnie z rzeczywistym użyciem i reprezentatywnego woluminu żądań, liczby replik, pojemności danych, pojemności komunikatów i pozyskiwania danych telemetrycznych. Wyklucza plany pomocy technicznej, środowiska programistyczne i testowe, odzyskiwanie po awarii w drugim regionie i usługę Application Gateway. Dostosuj założenia dotyczące regionu, pojemności, dostępności, transferu danych i użycia, aby dopasować je do obciążenia.

• Wybierz plan usługi Container Apps oraz profile obciążenia na podstawie zmierzonych wymagań dotyczących procesora CPU, pamięci i ruchu. Skaluj usługi do zera tylko wtedy, gdy pozwalają na to ich wymagania dotyczące dostępności i zimnego uruchamiania. Ustawienie wyższej minimalnej liczby replik może zwiększyć niezawodność, ale także zwiększa koszty obliczeń. Uwzględnij stale uruchomioną replikę wirtualnego procesu roboczego i jej sondowanie usługi Makeline. Zatrzymanie ruchu klientów i ruchu związanego z pulpitami nawigacyjnymi nie eliminuje kosztów obliczeń dla tych dwóch usług.

• Uwzględnij sposób, w jaki rozliczany jest każdy profil obciążenia. Koszty zużycia zasobów używanych przez uruchomione repliki. Dedykowane rachunki za każde przydzielone wystąpienie profilu, niezależnie od tego, czy uruchomione na nim aplikacje są obciążone, oraz opłata za zarządzanie dedykowanym planem dla środowiska. Prywatne punkty końcowe w środowisku również generują opłatę za zarządzanie, nawet jeśli nie używasz profilów dedykowanych. Aby uzyskać więcej informacji, zobacz Rozliczenia w usłudze Container Apps.

• Uwzględnij użycie zasobów sidecaru Dapr podczas określania rozmiaru każdej repliki. Ustaw jawne alokacje procesora CPU i pamięci dla kontenerów aplikacji, monitoruj rzeczywiste użycie i uwzględnij narzut zarządzanego kontenera sidecar w planowaniu pojemności.

• Traktuj usługę SQL Database, Azure Cosmos DB, Azure managed Redis, Service Bus, Blob Storage, Log Analytics, Application Insights, prywatne punkty końcowe i brzegową zaporę aplikacji internetowej jako oddzielne składniki kosztów. Te usługi mogą nadal naliczać opłaty, gdy aplikacje kontenerów są skalowane do zera.

• Ustaw próbkowanie telemetrii, kategorie dzienników i okresy przechowywania świadomie. Duże wolumeny danych konsoli, HTTP, zależności i śledzenia mogą powodować znaczne koszty pozyskiwania i przechowywania.

• Twórz budżety i alerty kosztowe. Użyj spójnych tagów, aby przydzielić koszty do obciążenia roboczego i jego środowisk oraz regularnie porównać przydzieloną pojemność z obserwowanym użyciem.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Zdefiniuj środowisko usługi Container Apps, Container Apps, składniki Dapr, tożsamości, przypisania ról, reguły skalowania i konfigurację monitorowania przy użyciu infrastruktury jako kodu. Użyj niezmiennych wersji obrazów i wersji usługi Container Apps, aby obsługiwać wdrożenia etapowe, walidację kondycji, wycofywanie i dzielenie ruchu.

Skonfiguruj środowisko tak, aby korzystało z miejsca docelowego rejestrowania Azure Monitor oraz kierowało dzienniki konsoli i systemowe za pomocą ustawień diagnostycznych. Starszy element docelowy usługi Log Analytics zapisuje do tabel niestandardowych ContainerAppConsoleLogs_CL i ContainerAppSystemLogs_CL. Bazowy interfejs API modułu zbierającego dane HTTP osiągnął koniec wsparcia 14 września 2026 r. Pozyskiwanie danych jest kontynuowane dla klientów korzystających z protokołu TLS 1.2 lub nowszego, ale interfejs API otrzymuje tylko krytyczne poprawki zabezpieczeń, więc przeprowadź migrację, aby usunąć zależność. Aby uzyskać wskazówki dotyczące migracji, zobacz Change Container Apps logging from Log Analytics to Azure Monitor.

Następujące zapytanie używa tabeli specyficznej dla zasobów Azure Monitor do wyświetlania ostatnich dzienników usługi Makeline:

ContainerAppConsoleLogs
| where ContainerAppName == "make-line-service"
| project TimeGenerated, RevisionName, ContainerName, Log
| order by TimeGenerated desc

Instrumentuj każdą aplikację przy użyciu interfejsu OpenTelemetry lub zestawu SDK usługi Application Insights. Usługa Container Apps nie instrumentuje automatycznie kodu aplikacji. Za pomocą zarządzanego agenta OpenTelemetry można kierować emitowane dzienniki i ślady do usługi Application Insights lub innego obsługiwanego miejsca docelowego, ale aplikacja musi nadal emitować dane telemetryczne.

Po skonfigurowaniu śledzenia rozproszonego między usługami mapa aplikacji usługi Application Insights wizualizuje relacje między usługami i zależnościami. Użyj go z dziennikami i metrykami, aby zbadać awarie i opóźnienia.

Poniższy zrzut ekranu przedstawia mapę aplikacji w usłudze Application Insights.

Utwórz alerty dotyczące nieudanych wersji, złej kondycji lub ponownego uruchamiania replik, niepowodzeń żądań i opóźnień, nasycenia repliki, błędów reguły skalowania, wzrostu liczby komunikatów utraconych w Service Bus, błędów składników Dapr i nieudanych zależności. Połącz alerty z procesem reagowania na zdarzenia i przetestuj powiadomienia. Aby uzyskać więcej informacji, zobacz Obserwowalność w usłudze Container Apps.

Wydajność

Wydajność odnosi się do możliwości skalowania obciążenia w celu efektywnego zaspokojenia wymagań użytkowników. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.

To rozwiązanie używa implementacji KEDA w usłudze Container Apps na potrzeby skalowania opartego na zdarzeniach. Wirtualna obsługa klienta składa zamówienia za pośrednictwem usługi zamówień, która jest skalowana na podstawie współbieżności HTTP. Usługa zamawiania publikuje komunikaty do tematu usługi Service Bus. Usługi księgowości, paragonów, Makeline i lojalnościowe są skalowane na podstawie liczby aktywnych wiadomości w ramach tych subskrypcji. Aplikacja kontenera UI jest skalowana na podstawie współbieżności HTTP.

Ustaw docelową liczbę komunikatów, współbieżność HTTP, minimalną replikę, maksymalną replikę, interwał sondowania i okres chłodzenia na podstawie wyników testu obciążeniowego. Uwzględnij zużycie zasobów przez sidecar Dapr i czas uruchamiania w teście. Liczba replik to docelowe wartości skalowania, a nie gwarancje dostępności, więc sprawdź, czy skonfigurowany limit maksymalny może sprostać szczytowemu zapotrzebowaniu i czy zależne usługi danych mogą obsłużyć wynikający z tego poziom współbieżności.

Wprowadź idempotentne procedury obsługi komunikatów, zdefiniuj zachowanie ponawiania i obsługi komunikatów dead-letter oraz dostosuj czas trwania blokady komunikatów i współbieżność, aby skalowanie w poziomie nie powodowało zduplikowanego przetwarzania ani ograniczania zależności.

Gdy klient wirtualny nie jest uruchomiony, żaden użytkownik nie uzyskuje dostępu do interfejsu użytkownika, a subskrypcje Service Bus nie mają żadnych pozostałych komunikatów, usługi zamówień, księgowości, paragonów, lojalności i interfejsu użytkownika można skalować do zera, jeśli ich minimalna liczba replik wynosi zero.

W tym przykładzie wirtualny proces roboczy jest na poziomie jednej repliki, ponieważ proces roboczy stale sonduje usługę Makeline pod kątem realizacji zamówienia. Te wywołania Dapr są liczone jako ruch przychodzący dla reguły skalowania HTTP aplikacji Makeline, nawet gdy nie ma żadnych oczekujących zamówień. Aby funkcja Makeline pozostała skalowana do zera, zatrzymaj sondowanie wirtualnego workera, a także ruch klientów i dashboardu, opróżnij jego subskrypcję usługi Service Bus i ustaw minimalną liczbę replik na zero. W przypadku usług, które muszą unikać zimnych uruchomień lub muszą pozostać dostępne podczas awarii, ustaw minimalną liczbę replik na co najmniej jedną. Aby uzyskać więcej informacji, zobacz Ustawianie reguł skalowania w usłudze Container Apps.

Profile obciążeń

Profile obciążeń umożliwiają oddzielenie usług wymagających ciepłej pojemności od usług, które korzystają najbardziej z elastyczności bezserwerowej. Na diagramie architektury usługa zamówień i usługa księgowa są wyświetlane w profilu dedykowanym, ponieważ obsługują one pracę transakcyjną i wspierają metryki biznesowe w czasie rzeczywistym. Usługa obsługi paragonów i usługa lojalnościowa są wyświetlane w profilu Zużycie, ponieważ są usługami opartymi na zdarzeniach, które mogą lepiej wykorzystać elastyczność bezserwerową.

Ten podział jest ilustracyjny. Usługi w tym przykładzie nie mają stałego wykorzystania, wymagań dotyczących zasobów ani potrzeb izolacji, które wymagają profilu dedykowanego, a profil Consumption z minimalną liczbą replik większą niż zero również utrzymuje gotową pojemność. Wybierz profil dedykowany, gdy usługa wymaga izolacji obliczeń dla jednego dzierżawcy, większej ilości procesora CPU lub pamięci na replikę, niż zapewnia profil Consumption, lub wystarczająco wysokiego wykorzystania, aby koszt rozliczania za instancję był niższy niż koszt rozliczania konsumpcyjnego.

Reguły skalowania oparte na KEDA działają zarówno w profilach obciążenia Consumption, jak i Dedicated. Plan Consumption najlepiej sprawdza się w przypadku usług, które można skalować do zera, natomiast plan Dedicated jest lepszy w przypadku usług, które nadal korzystają z automatycznego skalowania, ale wymagają wstępnie gotowych zasobów lub bardziej stabilnej wydajności.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Alice Gibbons | Natywny globalny pas chmury

Inni współautorzy:

• Lynn Orrell | Główny specjalista ds. rozwiązań (GBB)
• Kendall Roden | Starszy menedżer programu

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

Następne kroki

• Dokumentacja usługi Container Apps
• Porównanie usługi Container Apps z innymi opcjami kontenera platformy Azure

Powiązane zasoby

• Architektura mikrousług w usłudze Azure Kubernetes Service (AKS)
• Zaawansowana architektura mikrousług AKS
• Buduj pipeline CI/CD dla aplikacji AKS przy użyciu Azure Pipelines