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

Azure Container Apps

.NET

Azure SQL Database

Azure Cosmos DB

Azure Cache for Redis

W tym artykule opisano rozwiązanie do uruchamiania systemu zarządzania zamówieniami, który ma 10 mikrousług w usłudze Azure Container Apps. Rozwiązanie korzysta również z najlepszych rozwiązań dotyczących mikrousług za pośrednictwem rozproszonego środowiska uruchomieniowego aplikacji (Dapr) i skalowania opartego na zdarzeniach za pomocą skalowania automatycznego opartego na zdarzeniach (KEDA) platformy Kubernetes.

Dapr i Traefik są znakami towarowymi swoich firm. Użycie tych znaków nie jest dorozumiane.

Architektura

Obraz przedstawia system zarządzania zamówieniami z mikrousługami w usłudze Container Apps. Zawiera kroki od 1 do 9. Strzałka wskazuje z ikony użytkownika na Traefik. Dwie strzałki wskazują od Traefik do sekcji usługi księgowej i sekcję usługi Makeline. Dwukierunkowe punkty strzałek z Traefik do sekcji interfejsu użytkownika. Strzałka wskazuje od sekcji wirtualnego klienta do sekcji usługi zamówienia. Strzałka wskazuje sekcję usługi zamówienia do sekcji tematu Publikuj-subskrybowanie. Cztery strzałki wskazują od sekcji tematu Publish-subskrybuj: do sekcji usługi księgowej, do sekcji usługi paragonu, do sekcji usługi lojalnościowej i do sekcji Usługa linii makeline. Strzałka wskazuje z sekcji usługi księgowej do usługi Azure SQL Database za pośrednictwem programu Entity Framework. Punkt wiersza z sekcji usługi paragonu do powiązania usługi Azure Blob Storage. Wiersz wskazuje sekcję usługi lojalnościowej do usługi Azure Cosmos DB. Punkty linii z sekcji Usługa Makeline do usługi Azure Cache for Redis. I dwukierunkowe punkty strzałki z sekcji Usługa Makeline do sekcji wirtualnego procesu roboczego.

Pobierz plik programu PowerPoint tej architektury.

Przepływ danych

W tym rozwiązaniu opisano fikcyjny system zarządzania zamówieniami red dog i jego pomocniczą infrastrukturę platformy Azure. Architektura składa się z jednego środowiska usługi Container Apps, które hostuje 10 aplikacji mikrousług platformy .NET Core. Rozwiązanie używa zestawu DAPR SDK do integracji z zasobami platformy Azure za pośrednictwem bloków konstrukcyjnych publish-subscribe, state i binding. Usługi korzystają również z reguł skalowania KEDA, aby umożliwić skalowanie na podstawie wyzwalaczy zdarzeń i scenariuszy skalowania do zera.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

1. Traefik: podstawowy serwer proxy routingu żądań użytkowników z interfejsu użytkownika do usług księgowych i Makeline dla interaktywnego pulpitu nawigacyjnego.

2. interfejs użytkownika: Pulpit nawigacyjny przedstawiający zamówienie w czasie rzeczywistym i zagregowane dane sprzedaży dla systemu zarządzania zamówieniami red dog.

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

4. Zamów usługę: Interfejs API tworzenia, odczytywania, aktualizowania i usuwania w celu 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, które prezentuje 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 uzupełnianie zamówień przez usługę wirtualnego procesu roboczego.

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

Usługa	Ruch przychodzący	Składniki języka Dapr	Reguły skalowania KEDA
Traefik	Zewnętrzne	Nie włączono języka Dapr	HTTP
interfejs użytkownika	Wewnętrzny	Nie włączono języka Dapr	HTTP
Klient wirtualny	Brak	Wywołanie typu service-to-service	Nie dotyczy
Zamawianie usługi	Wewnętrzny	Publikowanie-subskrybowanie: Azure Service Bus	HTTP
Usługa ewidencjonowania aktywności	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus	Długość tematu usługi Service Bus, HTTP
Usługa paragonów	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Powiązanie: Azure Blob Storage	Długość tematu usługi Service Bus
Usługa lojalnościowa	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Stan: Azure Cosmos DB	Długość tematu usługi Service Bus
Usługa makeline	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Stan: Azure Cache for Redis	Długość tematu usługi Service Bus, HTTP
Wirtualny proces roboczy	Brak	Wywołanie typu service-to-service Powiązanie: Cron	Nie dotyczy

Uwaga

Możesz również zaimplementować bootstrap w aplikacji kontenera. Jednak ta usługa jest uruchamiana jednorazowo w celu utworzenia bazy danych, a następnie jest skalowana do zera po utworzeniu niezbędnych obiektów w usłudze Azure SQL Database.

Składniki

• Application Insights to rozszerzalna usługa zarządzania wydajnością aplikacji, której można użyć do monitorowania aplikacji na żywo i automatycznego wykrywania anomalii wydajności. W tej architekturze usługa Application Insights z usługą Azure Monitor służy do wyświetlania dzienników kontenerów i zbierania metryk z mikrousług.

• Blob Storage to oparte na chmurze rozwiązanie do przechowywania ogromnych ilości danych bez struktury, takich jak pliki tekstowe lub binarne. W tej architekturze usługa paragonu używa usługi Blob Storage za pośrednictwem powiązania danych wyjściowych dapr do przechowywania paragonów zamówień.

• Usługa Azure Cache for Redis to rozproszona, skalowalna pamięć podręczna Redis Cache zarządzana w pamięci. W tej architekturze jest używany jako składnik magazynu stanów Dapr dla usługi Makeline do przechowywania danych w przetwarzanych zamówieniach.

• Azure Cosmos DB to usługa bazy danych NoSQL, zarządzana wieloma modelami. W tej architekturze jest używany jako składnik magazynu stanów Dapr dla usługi lojalnościowej do przechowywania danych lojalnościowych klientów.

• Azure Monitor to ujednolicona platforma, która umożliwia zbieranie, analizowanie i wykonywanie działań na temat danych zawartości klienta ze środowisk infrastruktury platformy Azure. W tej architekturze używasz usługi Azure Monitor z usługą Application Insights do wyświetlania dzienników kontenerów i zbierania metryk z mikrousług.

• Service Bus to w pełni zarządzany broker komunikatów przedsiębiorstwa, który zawiera kolejki i tematy publikowania-subskrybowania. W tej architekturze używasz usługi Service Bus do implementacji składnika publikowania-subskrybowania języka 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 kontenera używana do tworzenia i wdrażania nowoczesnych aplikacji na dużą skalę. W tej architekturze hostujesz wszystkie 10 mikrousług w usłudze Container Apps i wdrażasz je w jednym środowisku usługi Container Apps. To środowisko służy jako bezpieczna granica wokół systemu.

• SQL Database to inteligentna, skalowalna, relacyjna usługa bazy danych utworzona dla chmury. W tej architekturze pełni rolę magazynu danych dla usługi księgowej, która używa platformy Entity Framework Core do interfejsu z bazą danych. Usługa programu inicjowania jest odpowiedzialna za konfigurowanie tabel SQL w bazie danych. Następnie jest uruchamiany jeden raz przed nawiązaniem połączenia z usługą księgowości.

• Traefik to zwrotny serwer proxy i moduł równoważenia obciążenia używany do kierowania ruchu sieciowego do mikrousług. W tej architekturze użyj funkcji konfiguracji dynamicznej Traefik do wykonywania routingu opartego na ścieżkach z interfejsu użytkownika, który jest aplikacją jednostronicową Vue.js. Ta konfiguracja umożliwia również bezpośrednie wywołania interfejsu API do usług zaplecza na potrzeby testowania.

Alternatywy

W tej architekturze wdrożysz serwer proxy Traefik, aby włączyć routing oparty na ścieżkach dla interfejsu API Vue.js. Istnieje wiele alternatywnych serwerów proxy typu open source, których można używać w tym celu. Dwa inne typowe projekty to NGINX i HAProxy.

Cała infrastruktura platformy Azure, z wyjątkiem usługi SQL Database, używa składników języka Dapr do współdziałania. Jedną z zalet języka Dapr jest możliwość zamiany wszystkich tych składników przez zmianę konfiguracji wdrożenia aplikacji kontenera. W tym scenariuszu usługi Service Bus, Azure Cosmos DB, Azure Cache for Redis i Blob Storage przedstawiają niektóre z ponad 70 dostępnych składników języka Dapr. Lista alternatywnych brokerów publikowania i subskrybowania, magazynów stanów i powiązań wyjściowych jest dostępna w dokumentacji języka Dapr.

Szczegóły scenariusza

Mikrousługi są powszechnie przyjętym stylem architektury. Zapewniają one korzyści, takie jak skalowalność, elastyczność i niezależne wdrożenia. Kontenery można używać jako mechanizmu do wdrażania aplikacji mikrousług, a następnie używać orkiestratora kontenerów, takiego jak Kubernetes, aby uprościć operacje. Istnieje wiele czynników, które należy wziąć pod uwagę w przypadku architektur mikrousług na dużą skalę. Zazwyczaj platforma infrastruktury wymaga znaczącego zrozumienia złożonych technologii, takich jak orkiestratory kontenerów.

Container Apps to w pełni zarządzana bezserwerowa usługa kontenera do uruchamiania nowoczesnych aplikacji na dużą skalę. Umożliwia wdrażanie konteneryzowanych aplikacji za pomocą abstrakcji podstawowej platformy. Korzystając z tej metody, nie trzeba zarządzać skomplikowaną infrastrukturą.

Ta architektura korzysta z integracji usługi Container Apps z zarządzaną wersją języka Dapr. Dapr to projekt typu open source, który pomaga deweloperom przezwyciężyć nieodłączne wyzwania związane z aplikacjami rozproszonymi, takimi jak zarządzanie stanem i wywoływanie usług.

Usługa Container Apps udostępnia również zarządzaną wersję usługi KEDA. Usługa KEDA umożliwia automatyczne skalowanie kontenerów na podstawie zdarzeń przychodzących z usług zewnętrznych, takich jak Service Bus i Azure Cache for Redis.

Możesz również włączyć ruch przychodzący HTTPS w usłudze Container Apps bez tworzenia większej liczby zasobów sieciowych platformy Azure. Możesz użyć serwera proxy usługi Envoy, który umożliwia również scenariusze podziału ruchu.

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

W tym artykule opisano rozwiązanie do uruchamiania systemu zarządzania zamówieniami z 10 mikrousług w usłudze Container Apps. Rozwiązanie korzysta również z najlepszych rozwiązań dotyczących mikrousług za pośrednictwem języka Dapr i skalowania opartego na zdarzeniach za pomocą usługi KEDA.

Potencjalne przypadki użycia

To rozwiązanie dotyczy każdej organizacji, która używa bezstanowych i stanowych mikrousług dla systemów rozproszonych. Rozwiązanie jest najlepsze dla konsumentów pakowanych towarów i przemysłu produkcyjnego, które mają system zamawiania i realizacji.

Następujące rozwiązania mają podobne projekty:

• 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).

Usługa Container Apps jest oparta na podstawach platformy Kubernetes, która działa jako podstawowa infrastruktura. Mechanizmy odporności są wbudowane w platformę Kubernetes, która monitoruje i uruchamia ponownie kontenery lub zasobniki, jeśli występują problemy. Mechanizmy odporności obejmują wbudowany moduł równoważenia obciążenia, który dystrybuuje ruch między wieloma replikami każdej aplikacji kontenera. Ta nadmiarowość umożliwia systemowi pozostanie operacyjnym, nawet jeśli jedna replika stanie się niedostępna.

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

Poniższa lista zawiera kilka funkcji zabezpieczeń, które zostały pominięte w tej architekturze, wraz z innymi zaleceniami i zagadnieniami:

• Ta architektura nie używa prywatnych punktów końcowych, które umożliwiają bezpieczniejszą, prywatną łączność z usługami platformy Azure przez przypisanie im adresu IP z sieci wirtualnej. W przypadku użycia prywatnych punktów końcowych można wyłączyć dostęp do sieci publicznej. Takie podejście utrzymuje ruch w sieci szkieletowej firmy Microsoft i zwiększa bezpieczeństwo i zgodność.

• Aktywność sieci powinna być stale monitorowana w celu wykrywania i zapobiegania nadużyciom. To podejście można osiągnąć przy użyciu usługi Azure Firewall i tabel tras. Tabele tras umożliwiają najpierw przekazywanie ruchu, który pozostawia sieć wirtualną przez zaporę. Ten proces jest ważnym krokiem w celu zapewnienia, że architektura nie jest podatna na ataki eksfiltracji danych.

• Użyj zapory aplikacji internetowej (WAF), aby chronić przed typowymi lukami w zabezpieczeniach. Użyj usługi Azure Front Door lub Azure Application Gateway, aby zaimplementować zaporę aplikacji internetowej w tej architekturze.

• Rozważ użycie wbudowanej funkcji uwierzytelniania i autoryzacji dla usługi Container Apps, znanej jako Easy Auth. Usługa Easy Auth obsługuje integrację z dostawcami tożsamości spoza aplikacji internetowej, co może zmniejszyć ilość kodu potrzebnego do utrzymania.

• Użyj tożsamości zarządzanej dla tożsamości obciążeń. Tożsamość zarządzana eliminuje konieczność zarządzania poświadczeniami uwierzytelniania przez deweloperów. Na przykład podstawowa architektura uwierzytelnia się w programie SQL Server za pomocą hasła w parametrach połączenia. Jeśli to możliwe, użyj identyfikatorów Entra firmy Microsoft do uwierzytelniania w programie Azure SQL Server.

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.

Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszt usług w tej architekturze.

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.

Usługi Azure Monitor i Application Insights można używać do monitorowania usługi Container Apps. Dzienniki kontenerów można wyświetlić, przechodząc w portalu do okienka Dzienniki w każdej aplikacji kontenera, a następnie uruchamiając następujące zapytanie Kusto. W tym przykładzie przedstawiono dzienniki aplikacji usługi Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Mapa aplikacji w usłudze Application Insights pokazuje również, jak usługi komunikują się w czasie rzeczywistym. Następnie można ich używać do debugowania scenariuszy. Przejdź do mapy aplikacji w obszarze zasobu usługi Application Insights, aby wyświetlić zawartość podobną do poniższej mapy.

Zrzut ekranu przedstawia mapę aplikacji w usłudze Application Insights. Obraz zawiera siedem okręgów reprezentujących wystąpienia. Nazwy wystąpień to virtual-customers, order-service, receipt-gen... ion-service, virtual-worker, make-line-service, loyalty-service i accounting-service. Wiele krzywych linii przepływa między tymi wystąpieniami. Obraz zawiera również powiązania stanu dapr i języka Dapr.

Aby uzyskać więcej informacji, zobacz Monitorowanie aplikacji 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 opiera się w dużej mierze na implementacji KEDA w usłudze Container Apps na potrzeby skalowania opartego na zdarzeniach. Podczas wdrażania wirtualnej obsługi klienta stale umieszcza zamówienia. To skalowanie powoduje, że usługa zamówienia jest skalowana w górę za pośrednictwem modułu skalowania KEDA HTTP. Gdy usługa zamówienia publikuje zamówienia w magistrali usług, skalowanie KEDA magistrali usług powoduje, że księgowość, paragon, makeline i usługi lojalnościowe są skalowane w górę. Aplikacje kontenerów interfejsu użytkownika i traefik konfigurują również moduły skalowania HTTP KEDA, aby aplikacje skalowały się w miarę uzyskiwania dostępu do pulpitu nawigacyjnego przez większej liczby użytkowników.

Gdy wirtualny klient nie jest uruchomiony, wszystkie mikrousługi w tym rozwiązaniu są skalowane do zera, z wyjątkiem wirtualnych procesów roboczych i usług Makeline. Wirtualny proces roboczy nie jest skalowany w dół, ponieważ stale sprawdza realizację zamówienia. Aby uzyskać więcej informacji, zobacz Ustawianie reguł skalowania w usłudze Container Apps.

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
• Ciągła integracja i ciągłe dostarczanie aplikacji usługi AKS za pomocą usługi Azure Pipelines

W tym artykule opisano rozwiązanie do uruchamiania systemu zarządzania zamówieniami, który ma 10 mikrousług w usłudze Azure Container Apps. Rozwiązanie korzysta również z najlepszych rozwiązań dotyczących mikrousług za pośrednictwem rozproszonego środowiska uruchomieniowego aplikacji (Dapr) i skalowania opartego na zdarzeniach za pomocą skalowania automatycznego opartego na zdarzeniach (KEDA) platformy Kubernetes.

Dapr i Traefik są znakami towarowymi swoich firm. Użycie tych znaków nie jest dorozumiane.

Architektura

Obraz przedstawia system zarządzania zamówieniami z mikrousługami w usłudze Container Apps. Zawiera kroki od 1 do 9. Strzałka wskazuje z ikony użytkownika na Traefik. Dwie strzałki wskazują od Traefik do sekcji usługi księgowej i sekcję usługi Makeline. Dwukierunkowe punkty strzałek z Traefik do sekcji interfejsu użytkownika. Strzałka wskazuje od sekcji wirtualnego klienta do sekcji usługi zamówienia. Strzałka wskazuje sekcję usługi zamówienia do sekcji tematu Publikuj-subskrybowanie. Cztery strzałki wskazują od sekcji tematu Publish-subskrybuj: do sekcji usługi księgowej, do sekcji usługi paragonu, do sekcji usługi lojalnościowej i do sekcji Usługa linii makeline. Strzałka wskazuje z sekcji usługi księgowej do usługi Azure SQL Database za pośrednictwem programu Entity Framework. Punkt wiersza z sekcji usługi paragonu do powiązania usługi Azure Blob Storage. Wiersz wskazuje sekcję usługi lojalnościowej do usługi Azure Cosmos DB. Punkty linii z sekcji Usługa Makeline do usługi Azure Cache for Redis. I dwukierunkowe punkty strzałki z sekcji Usługa Makeline do sekcji wirtualnego procesu roboczego.

Pobierz plik programu PowerPoint tej architektury.

Przepływ danych

W tym rozwiązaniu opisano fikcyjny system zarządzania zamówieniami red dog i jego pomocniczą infrastrukturę platformy Azure. Architektura składa się z jednego środowiska usługi Container Apps, które hostuje 10 aplikacji mikrousług platformy .NET Core. Rozwiązanie używa zestawu DAPR SDK do integracji z zasobami platformy Azure za pośrednictwem bloków konstrukcyjnych publish-subscribe, state i binding. Usługi korzystają również z reguł skalowania KEDA, aby umożliwić skalowanie na podstawie wyzwalaczy zdarzeń i scenariuszy skalowania do zera.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

1. Traefik: podstawowy serwer proxy routingu żądań użytkowników z interfejsu użytkownika do usług księgowych i Makeline dla interaktywnego pulpitu nawigacyjnego.

2. interfejs użytkownika: Pulpit nawigacyjny przedstawiający zamówienie w czasie rzeczywistym i zagregowane dane sprzedaży dla systemu zarządzania zamówieniami red dog.

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

4. Zamów usługę: Interfejs API tworzenia, odczytywania, aktualizowania i usuwania w celu 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, które prezentuje 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 uzupełnianie zamówień przez usługę wirtualnego procesu roboczego.

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

Usługa	Ruch przychodzący	Składniki języka Dapr	Reguły skalowania KEDA
Traefik	Zewnętrzne	Nie włączono języka Dapr	HTTP
interfejs użytkownika	Wewnętrzny	Nie włączono języka Dapr	HTTP
Klient wirtualny	Brak	Wywołanie typu service-to-service	Nie dotyczy
Zamawianie usługi	Wewnętrzny	Publikowanie-subskrybowanie: Azure Service Bus	HTTP
Usługa ewidencjonowania aktywności	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus	Długość tematu usługi Service Bus, HTTP
Usługa paragonów	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Powiązanie: Azure Blob Storage	Długość tematu usługi Service Bus
Usługa lojalnościowa	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Stan: Azure Cosmos DB	Długość tematu usługi Service Bus
Usługa makeline	Wewnętrzny	Publikowanie-subskrybowanie: Service Bus Stan: Azure Cache for Redis	Długość tematu usługi Service Bus, HTTP
Wirtualny proces roboczy	Brak	Wywołanie typu service-to-service Powiązanie: Cron	Nie dotyczy

Uwaga

Możesz również zaimplementować bootstrap w aplikacji kontenera. Jednak ta usługa jest uruchamiana jednorazowo w celu utworzenia bazy danych, a następnie jest skalowana do zera po utworzeniu niezbędnych obiektów w usłudze Azure SQL Database.

Składniki

• Application Insights to rozszerzalna usługa zarządzania wydajnością aplikacji, której można użyć do monitorowania aplikacji na żywo i automatycznego wykrywania anomalii wydajności. W tej architekturze usługa Application Insights z usługą Azure Monitor służy do wyświetlania dzienników kontenerów i zbierania metryk z mikrousług.

• Blob Storage to oparte na chmurze rozwiązanie do przechowywania ogromnych ilości danych bez struktury, takich jak pliki tekstowe lub binarne. W tej architekturze usługa paragonu używa usługi Blob Storage za pośrednictwem powiązania danych wyjściowych dapr do przechowywania paragonów zamówień.

• Usługa Azure Cache for Redis to rozproszona, skalowalna pamięć podręczna Redis Cache zarządzana w pamięci. W tej architekturze jest używany jako składnik magazynu stanów Dapr dla usługi Makeline do przechowywania danych w przetwarzanych zamówieniach.

• Azure Cosmos DB to usługa bazy danych NoSQL, zarządzana wieloma modelami. W tej architekturze jest używany jako składnik magazynu stanów Dapr dla usługi lojalnościowej do przechowywania danych lojalnościowych klientów.

• Azure Monitor to ujednolicona platforma, która umożliwia zbieranie, analizowanie i wykonywanie działań na temat danych zawartości klienta ze środowisk infrastruktury platformy Azure. W tej architekturze używasz usługi Azure Monitor z usługą Application Insights do wyświetlania dzienników kontenerów i zbierania metryk z mikrousług.

• Service Bus to w pełni zarządzany broker komunikatów przedsiębiorstwa, który zawiera kolejki i tematy publikowania-subskrybowania. W tej architekturze używasz usługi Service Bus do implementacji składnika publikowania-subskrybowania języka 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 kontenera używana do tworzenia i wdrażania nowoczesnych aplikacji na dużą skalę. W tej architekturze hostujesz wszystkie 10 mikrousług w usłudze Container Apps i wdrażasz je w jednym środowisku usługi Container Apps. To środowisko służy jako bezpieczna granica wokół systemu.

• SQL Database to inteligentna, skalowalna, relacyjna usługa bazy danych utworzona dla chmury. W tej architekturze pełni rolę magazynu danych dla usługi księgowej, która używa platformy Entity Framework Core do interfejsu z bazą danych. Usługa programu inicjowania jest odpowiedzialna za konfigurowanie tabel SQL w bazie danych. Następnie jest uruchamiany jeden raz przed nawiązaniem połączenia z usługą księgowości.

• Traefik to zwrotny serwer proxy i moduł równoważenia obciążenia używany do kierowania ruchu sieciowego do mikrousług. W tej architekturze użyj funkcji konfiguracji dynamicznej Traefik do wykonywania routingu opartego na ścieżkach z interfejsu użytkownika, który jest aplikacją jednostronicową Vue.js. Ta konfiguracja umożliwia również bezpośrednie wywołania interfejsu API do usług zaplecza na potrzeby testowania.

Alternatywy

W tej architekturze wdrożysz serwer proxy Traefik, aby włączyć routing oparty na ścieżkach dla interfejsu API Vue.js. Istnieje wiele alternatywnych serwerów proxy typu open source, których można używać w tym celu. Dwa inne typowe projekty to NGINX i HAProxy.

Cała infrastruktura platformy Azure, z wyjątkiem usługi SQL Database, używa składników języka Dapr do współdziałania. Jedną z zalet języka Dapr jest możliwość zamiany wszystkich tych składników przez zmianę konfiguracji wdrożenia aplikacji kontenera. W tym scenariuszu usługi Service Bus, Azure Cosmos DB, Azure Cache for Redis i Blob Storage przedstawiają niektóre z ponad 70 dostępnych składników języka Dapr. Lista alternatywnych brokerów publikowania i subskrybowania, magazynów stanów i powiązań wyjściowych jest dostępna w dokumentacji języka Dapr.

Szczegóły scenariusza

Mikrousługi są powszechnie przyjętym stylem architektury. Zapewniają one korzyści, takie jak skalowalność, elastyczność i niezależne wdrożenia. Kontenery można używać jako mechanizmu do wdrażania aplikacji mikrousług, a następnie używać orkiestratora kontenerów, takiego jak Kubernetes, aby uprościć operacje. Istnieje wiele czynników, które należy wziąć pod uwagę w przypadku architektur mikrousług na dużą skalę. Zazwyczaj platforma infrastruktury wymaga znaczącego zrozumienia złożonych technologii, takich jak orkiestratory kontenerów.

Container Apps to w pełni zarządzana bezserwerowa usługa kontenera do uruchamiania nowoczesnych aplikacji na dużą skalę. Umożliwia wdrażanie konteneryzowanych aplikacji za pomocą abstrakcji podstawowej platformy. Korzystając z tej metody, nie trzeba zarządzać skomplikowaną infrastrukturą.

Ta architektura korzysta z integracji usługi Container Apps z zarządzaną wersją języka Dapr. Dapr to projekt typu open source, który pomaga deweloperom przezwyciężyć nieodłączne wyzwania związane z aplikacjami rozproszonymi, takimi jak zarządzanie stanem i wywoływanie usług.

Usługa Container Apps udostępnia również zarządzaną wersję usługi KEDA. Usługa KEDA umożliwia automatyczne skalowanie kontenerów na podstawie zdarzeń przychodzących z usług zewnętrznych, takich jak Service Bus i Azure Cache for Redis.

Możesz również włączyć ruch przychodzący HTTPS w usłudze Container Apps bez tworzenia większej liczby zasobów sieciowych platformy Azure. Możesz użyć serwera proxy usługi Envoy, który umożliwia również scenariusze podziału ruchu.

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

W tym artykule opisano rozwiązanie do uruchamiania systemu zarządzania zamówieniami z 10 mikrousług w usłudze Container Apps. Rozwiązanie korzysta również z najlepszych rozwiązań dotyczących mikrousług za pośrednictwem języka Dapr i skalowania opartego na zdarzeniach za pomocą usługi KEDA.

Potencjalne przypadki użycia

To rozwiązanie dotyczy każdej organizacji, która używa bezstanowych i stanowych mikrousług dla systemów rozproszonych. Rozwiązanie jest najlepsze dla konsumentów pakowanych towarów i przemysłu produkcyjnego, które mają system zamawiania i realizacji.

Następujące rozwiązania mają podobne projekty:

• 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).

Usługa Container Apps jest oparta na podstawach platformy Kubernetes, która działa jako podstawowa infrastruktura. Mechanizmy odporności są wbudowane w platformę Kubernetes, która monitoruje i uruchamia ponownie kontenery lub zasobniki, jeśli występują problemy. Mechanizmy odporności obejmują wbudowany moduł równoważenia obciążenia, który dystrybuuje ruch między wieloma replikami każdej aplikacji kontenera. Ta nadmiarowość umożliwia systemowi pozostanie operacyjnym, nawet jeśli jedna replika stanie się niedostępna.

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

Poniższa lista zawiera kilka funkcji zabezpieczeń, które zostały pominięte w tej architekturze, wraz z innymi zaleceniami i zagadnieniami:

• Ta architektura nie używa prywatnych punktów końcowych, które umożliwiają bezpieczniejszą, prywatną łączność z usługami platformy Azure przez przypisanie im adresu IP z sieci wirtualnej. W przypadku użycia prywatnych punktów końcowych można wyłączyć dostęp do sieci publicznej. Takie podejście utrzymuje ruch w sieci szkieletowej firmy Microsoft i zwiększa bezpieczeństwo i zgodność.

• Aktywność sieci powinna być stale monitorowana w celu wykrywania i zapobiegania nadużyciom. To podejście można osiągnąć przy użyciu usługi Azure Firewall i tabel tras. Tabele tras umożliwiają najpierw przekazywanie ruchu, który pozostawia sieć wirtualną przez zaporę. Ten proces jest ważnym krokiem w celu zapewnienia, że architektura nie jest podatna na ataki eksfiltracji danych.

• Użyj zapory aplikacji internetowej (WAF), aby chronić przed typowymi lukami w zabezpieczeniach. Użyj usługi Azure Front Door lub Azure Application Gateway, aby zaimplementować zaporę aplikacji internetowej w tej architekturze.

• Rozważ użycie wbudowanej funkcji uwierzytelniania i autoryzacji dla usługi Container Apps, znanej jako Easy Auth. Usługa Easy Auth obsługuje integrację z dostawcami tożsamości spoza aplikacji internetowej, co może zmniejszyć ilość kodu potrzebnego do utrzymania.

• Użyj tożsamości zarządzanej dla tożsamości obciążeń. Tożsamość zarządzana eliminuje konieczność zarządzania poświadczeniami uwierzytelniania przez deweloperów. Na przykład podstawowa architektura uwierzytelnia się w programie SQL Server za pomocą hasła w parametrach połączenia. Jeśli to możliwe, użyj identyfikatorów Entra firmy Microsoft do uwierzytelniania w programie Azure SQL Server.

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.

Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszt usług w tej architekturze.

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.

Usługi Azure Monitor i Application Insights można używać do monitorowania usługi Container Apps. Dzienniki kontenerów można wyświetlić, przechodząc w portalu do okienka Dzienniki w każdej aplikacji kontenera, a następnie uruchamiając następujące zapytanie Kusto. W tym przykładzie przedstawiono dzienniki aplikacji usługi Makeline.

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Mapa aplikacji w usłudze Application Insights pokazuje również, jak usługi komunikują się w czasie rzeczywistym. Następnie można ich używać do debugowania scenariuszy. Przejdź do mapy aplikacji w obszarze zasobu usługi Application Insights, aby wyświetlić zawartość podobną do poniższej mapy.

Zrzut ekranu przedstawia mapę aplikacji w usłudze Application Insights. Obraz zawiera siedem okręgów reprezentujących wystąpienia. Nazwy wystąpień to virtual-customers, order-service, receipt-gen... ion-service, virtual-worker, make-line-service, loyalty-service i accounting-service. Wiele krzywych linii przepływa między tymi wystąpieniami. Obraz zawiera również powiązania stanu dapr i języka Dapr.

Aby uzyskać więcej informacji, zobacz Monitorowanie aplikacji 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 opiera się w dużej mierze na implementacji KEDA w usłudze Container Apps na potrzeby skalowania opartego na zdarzeniach. Podczas wdrażania wirtualnej obsługi klienta stale umieszcza zamówienia. To skalowanie powoduje, że usługa zamówienia jest skalowana w górę za pośrednictwem modułu skalowania KEDA HTTP. Gdy usługa zamówienia publikuje zamówienia w magistrali usług, skalowanie KEDA magistrali usług powoduje, że księgowość, paragon, makeline i usługi lojalnościowe są skalowane w górę. Aplikacje kontenerów interfejsu użytkownika i traefik konfigurują również moduły skalowania HTTP KEDA, aby aplikacje skalowały się w miarę uzyskiwania dostępu do pulpitu nawigacyjnego przez większej liczby użytkowników.

Gdy wirtualny klient nie jest uruchomiony, wszystkie mikrousługi w tym rozwiązaniu są skalowane do zera, z wyjątkiem wirtualnych procesów roboczych i usług Makeline. Wirtualny proces roboczy nie jest skalowany w dół, ponieważ stale sprawdza realizację zamówienia. Aby uzyskać więcej informacji, zobacz Ustawianie reguł skalowania w usłudze Container Apps.

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
• Ciągła integracja i ciągłe dostarczanie aplikacji usługi AKS za pomocą usługi Azure Pipelines