Podstawowe składniki tej architektury to fronton internetowy, obsługujący żądania klienta, oraz proces roboczy, który wykonuje zadania wsadowe i zadania intensywnie obciążające zasoby oraz uruchamia długotrwałe przepływy pracy. Fronton internetowy komunikuje się z procesem roboczym za pośrednictwem kolejki komunikatów.
Oto inne, typowe składniki tej architektury:
- Co najmniej jedna baza danych.
- Pamięć podręczna umożliwiająca szybkie odczytywanie wartości z bazy danych.
- Sieć CDN do udostępniania zawartości statycznej.
- Usługi zdalne, takie jak usługa poczty e-mail lub usługa wiadomości SMS. Często te funkcje są udostępniane przez osoby trzecie.
- Dostawca tożsamości do uwierzytelniania.
Element internetowy i proces roboczy są bezstanowe. Stan sesji można przechowywać w rozproszonej pamięci podręcznej. Wszystkie długotrwałe zadania są wykonywane asynchronicznie przez proces roboczy. Proces roboczy może być wyzwalany przez komunikaty w kolejce lub uruchamiany zgodnie z harmonogramem przetwarzania wsadowego. Proces roboczy jest opcjonalny. Jeśli nie ma operacji długotrwałych, proces roboczy można pominąć.
Fronton może się składać z internetowego interfejsu API. Po stronie klienta z internetowego interfejsu API może korzystać aplikacja jednostronicowa, która używa wywołań AJAX, lub natywna aplikacja kliencka.
Kiedy stosować tę architekturę
Architektura Internet-kolejka-proces roboczy jest zwykle implementowana przy użyciu zarządzanych usług obliczeniowych — usługi Azure App Service lub Azure Cloud Services.
Ten styl architektury sprawdza się w następujących scenariuszach:
- Aplikacje ze stosunkowo prostą domeną.
- Aplikacje z długotrwałymi przepływami pracy lub operacjami wsadowymi.
- Sytuacje, w których lepszym rozwiązaniem jest użycie usług zarządzanych zamiast infrastruktury jako usługi (IaaS).
Świadczenia
- Stosunkowo prosta, przejrzysta architektura.
- Łatwość wdrażania i zarządzania.
- Wyraźna separacja problemów.
- Rozdzielenie frontonu i procesu roboczego dzięki komunikatom asynchronicznym.
- Możliwość niezależnego skalowania frontonu i procesu roboczego.
Wyzwania
- Nieuważne projektowanie frontonu i procesu roboczego może spowodować, że staną się one dużymi, monolitycznymi składnikami, co będzie utrudniać ich utrzymywanie i aktualizowanie.
- Współdzielenie schematów danych lub modułów kodu przez fronton i proces roboczy może prowadzić do występowania ukrytych zależności.
- Fronton internetowy może działać nieprawidłowo po pomyślnym utrwalonej bazie danych, ale przed emitowaniem komunikatów do kolejki. Może to spowodować ewentualne problemy ze spójnością, ponieważ proces roboczy nie będzie wykonywał swojej części logiki. Techniki, takie jak wzorzec transakcyjnej skrzynki odbiorczej, mogą służyć do rozwiązywania tego problemu, ale wymagają zmiany routingu komunikatów wychodzących na pierwszą pętlę wstecz przez oddzielną kolejkę. Jedną z bibliotek, która zapewnia obsługę tej techniki, jest sesja transakcyjna NServiceBus.
Najlepsze rozwiązania
- Udostępnianie klientowi dobrze zaprojektowanego interfejsu API. Zobacz Najlepsze rozwiązania dotyczące projektowania interfejsów API.
- Używanie skalowania automatycznego do obsługi zmian obciążenia. Zobacz Autoscaling best practices (Najlepsze rozwiązania dotyczące skalowania automatycznego).
- Buforowanie danych częściowo statycznych. Zobacz Caching best practices (Najlepsze rozwiązania dotyczące buforowania).
- Korzystanie z sieci CDN hostującej zawartość statyczną. Zobacz Najlepsze praktyki dotyczące usługi CDN.
- Korzystanie z różnych technologii magazynowania w razie potrzeby. Zobacz [Użyj najlepszego magazynu danych dla zadania][polyglot].
- Partycjonowanie danych w celu zwiększenia skalowalności, zmniejszenia rywalizacji o zasoby i zoptymalizowania wydajności. Zobacz Najlepsze rozwiązania dotyczące partycjonowania danych.
Architektura Internet-kolejka-proces roboczy w usłudze Azure App Service
W tej sekcji opisano zalecaną architekturę Internet-kolejka-proces roboczy, która korzysta z usługi Azure App Service.
Pobierz plik programu Visio z tą architekturą.
Przepływ pracy
Fronton jest implementowany jako aplikacja internetowa usługi aplikacja systemu Azure Service, a proces roboczy jest implementowany jako aplikacja usługi Azure Functions. Aplikacja internetowa i aplikacja funkcji są skojarzone z planem usługi App Service, który udostępnia wystąpienia maszyn wirtualnych.
Kolejki komunikatów można używać w usłudze Azure Service Bus lub Azure Storage. (Na diagramie przedstawiono kolejkę usługi Azure Storage).
Usługa Azure Cache for Redis przechowuje stan sesji i inne dane, które wymagają dostępu do małych opóźnień.
Usługa Azure CDN służy do buforowania zawartości statycznej, takiej jak obrazy, CSS lub HTML.
Należy wybrać technologie magazynowania, które najlepiej odpowiadają potrzebom aplikacji. Można używać wielu technologii magazynowania. Aby zilustrować ten pomysł, diagram przedstawia usługi Azure SQL Database i Azure Cosmos DB.
Aby uzyskać więcej informacji, zobacz architekturę referencyjną aplikacji internetowej usługi App Service oraz sposób tworzenia aplikacji biznesowych opartych na komunikatach za pomocą sieci NServiceBus i usługi Azure Service Bus.
Inne uwagi
Nie wszystkie transakcje muszą przechodzić przez kolejkę i proces roboczy, a następnie trafiać do magazynu. Fronton internetowy może bezpośrednio wykonywać proste operacje odczytu/zapisu. Procesy robocze obsługują zadania intensywnie obciążające zasoby oraz długotrwałe przepływy pracy. W niektórych przypadkach proces roboczy nie jest potrzebny.
Wbudowana funkcja automatycznego skalowania usługi App Service umożliwia skalowanie w poziomie liczby wystąpień maszyn wirtualnych. Jeśli wzorzec obciążenia aplikacji jest przewidywalny, utwórz harmonogram automatycznego skalowania. W przeciwnym razie użyj reguł automatycznego skalowania opartych na metrykach.
Rozważ umieszczenie aplikacji internetowej i aplikacji funkcji w oddzielnych planach usługi App Service. W ten sposób można je skalować niezależnie.
Utwórz oddzielne plany usługi App Service dla celów produkcyjnych i testowych. W przypadku używania tego samego planu w środowisku produkcyjnym i testowym testy będą uruchamiane na maszynach wirtualnych w środowisku produkcyjnym.
Wdrożeniami zarządzaj za pomocą miejsc wdrożenia. Ta metoda umożliwia wdrożenie zaktualizowanej wersji w miejscu przejściowym, a następnie zamianę na nową wersję. Umożliwia to również powrót do poprzedniej wersji, jeśli wystąpi problem z aktualizacją.