Architektury backendu dla backendów aplikacji internetowych opartych na treści

Architektura backendu to struktura backendu aplikacji internetowej. Architektura backendu określa, w jaki sposób części aplikacji komunikują się ze sobą podczas przetwarzania żądań przychodzących i tworzenia odpowiedzi. Tworząc aplikację internetową, wybierz architekturę backendu zgodnie ze swoimi konkretnymi wymaganiami i czynnikami, takimi jak koszty (stałe i na dużą skalę), złożoność aplikacji, skalowanie celów i kompetencje zespołu.

Szczególnie w przypadku aplikacji internetowych opartych na treści, takich jak e-commerce, gazety czy blogi, kluczowe wymagania obejmują spójność danych i wydajności działania. Dotyczy to zwłaszcza aplikacji, które można rozwijać na skalę globalną i rozpowszechniać się w większym stopniu. W przypadku aplikacji internetowych opartych na treści pamięć masowa również ma kluczowe znaczenie. Szczegółowo opisujemy to w przewodniku po miejscu na dane. Wyjście poza typową architekturę aplikacji, hostowanie treści i zapewnianie do nich dostępu ma kluczowe znaczenie przy optymalizacji wydajności aplikacji. Więcej informacji o wyborze odpowiedniej strategii hostingu i optymalizowaniu aplikacji znajdziesz w przewodniku dotyczącym hostingu.

Jeśli masz już backend dla aplikacji internetowej, weź pod uwagę ograniczenia obecnej architektury. Na przykład gdy Twoja aplikacja skaluje się w górę i zwiększa wydajność oraz niezawodność, zastanów się, czy nie należy jej refaktoryzować, czy przenieść do innej architektury, która jest lepiej dopasowana do zwiększonej skali. Na przykład architektury hybrydowe (lub wielochmurowe) umożliwiają przeniesienie niektórych zadań do chmury przed pełnym przejściem. Warto też wziąć pod uwagę koszty, czas i ryzyko związane z taką migracją.

Architektury monolityczne

Architektura monolityczna ma ujednoliconą strukturę, ze wszystkimi komponentami aplikacji ściśle zintegrowanymi w jedną bazę kodu. Cała aplikacja jest zbudowana jako jedna, niezależna jednostka. Monolityczna architektura jest wielowarstwowa, w której różne warstwy aplikacji wykonują określone zadania.

Warstwy konstrukcyjne

• Interfejs użytkownika, który zawiera komponenty do prezentowania funkcji aplikacji, to zwykle aplikacja internetowa lub komputerowa, która współdziała z użytkownikami.
• Logika aplikacji to miejsce, gdzie znajduje się jej główna funkcjonalność.Ta część bazy kodu zawiera reguły, obliczenia i operacje, które określają sposób działania aplikacji.
• Warstwa dostępu do danych zawiera funkcje do odczytywania i zapisywania danych oraz tłumaczenia między strukturami danych aplikacji a schematem bazy danych. Ta warstwa odpowiada za interakcję z bazą danych lub magazynem danych aplikacji.
• Ta baza danych to miejsce, w którym aplikacja przechowuje dane. Wszystkie dane aplikacji, w tym dane użytkownika, konfiguracje i inne informacje, znajdują się zwykle w jednej bazie danych.
• Komponenty oprogramowania pośredniczącego obsługują takie zadania jak uwierzytelnianie, routing żądań i weryfikacja danych. Pomagają one zarządzać przepływem danych i żądań.
• Niektóre aplikacje monolityczne mają punkty integracji z usługami zewnętrznymi lub interfejsami API. Punkty te umożliwiają aplikacji interakcję z usługami, źródłami danych lub innymi systemami innych firm.

Warstwy strukturalne stanowią zwykle część pojedynczej bazy kodu. Ta baza kodu zawiera całą aplikację i zwykle jest podzielona na katalogi, moduły i klasy. Programiści tworzą i utrzymują aplikacje na różnych częściach bazy kodu. Zwykle jednak cała aplikacja jest wdrażana jako pojedyncza jednostka. Po wprowadzeniu zmian lub aktualizacji cała aplikacja jest ponownie wdrażana.

Potencjalne wyzwania

• W miarę rozwoju aplikacji monolitycznych baza kodu staje się złożona i trudna w utrzymaniu. Może to prowadzić do długich cykli programowania i trudności w zrozumieniu całej bazy kodu.
• Wdrażanie zmian w aplikacji monolitycznej może być ryzykowne, ponieważ zmiany wprowadzone w jednej części kodu mogą nieumyślnie wpłynąć na inne części aplikacji. Może to prowadzić do długiego i podatnego na błędy procesu wdrażania.
• Skalowanie aplikacji monolitycznych może być trudne, ponieważ są one wdrażane jako pojedyncza jednostka. Musisz skalować całą aplikację, nawet jeśli tylko jeden komponent wykazuje wzrost.
• Aplikacje monolityczne opierają się często na jednym stosie technologicznym lub języku programowania. Możliwość korzystania z najlepszego narzędzia do konkretnego zadania w aplikacji może być ograniczona.
• Nawet w okresach niskiego zapotrzebowania aplikacje monolityczne wymagają do działania dużych zasobów. W miarę upływu czasu aplikacji koszty obsługi również rosną, ponieważ aktualizowanie i poprawianie aplikacji bez powodowania regresji staje się coraz trudniejsze.
• Zespoły programistyczne pracujące nad aplikacjami monolitycznymi są często zorganizowane wokół całej aplikacji, co prowadzi do powstania większych zespołów i bardziej złożonej koordynacji między członkami zespołów.

Sugerowane zastosowanie

Architektura monolityczna jest odpowiednia, gdy aplikacja ma skromne wymagania, a zespół programistów jest niewielki. W miarę jak aplikacja staje się coraz bardziej złożony i skalowalna, jej poszczególne części wymagają odmiennych technologii lub strategii wdrażania, architektury monolityczne mogą stać się mniej elastyczne i trudniejsze w utrzymaniu.

Możesz tworzyć maszyny wirtualne, które mogą uruchamiać aplikacje monolityczne w Compute Engine, i zarządzać nimi. Masz pełną kontrolę nad systemami operacyjnymi i oprogramowaniem oraz zarządzaniem maszynami wirtualnymi, w przypadku których uruchamiasz swoją aplikację monolityczną.

Dzięki usłudze platformy jako usługi, takiej jak App Engine, możesz utworzyć aplikację i uruchamiać ją w pełni zarządzanej infrastrukturze, która automatycznie skaluje się wraz z żądaniami.

Jeśli aplikacja monolityczna jest skonteneryzowana, możesz ją uruchomić za pomocą Google Kubernetes Engine (GKE) lub Cloud Run. Do przechowywania danych aplikacji monolitycznych można używać takich usług jak Cloud SQL czy CloudSpanner. Zależnie od konkretnych wymagań aplikacji zastanów się nad połączeniem usług i systemów.

Architektury bezserwerowe

Dzięki architekturze bezserwerowej możesz tworzyć i uruchamiać aplikacje bez konieczności zarządzania serwerami fizycznymi lub wirtualnymi. Dostawca chmury automatycznie zarządza infrastrukturą, skalowaniem i alokacją zasobów, dzięki czemu deweloperzy mogą się skupić na pisaniu kodu aplikacji. Architektury bezserwerowe mogą uprościć programowanie, zmniejszyć obciążenie operacyjne i zoptymalizować koszty dzięki eliminacji konieczności konserwacji serwerów. Są one szczególnie przydatne w przypadku mikroserwisów, przetwarzania danych w czasie rzeczywistym, aplikacji internetowych o zmiennych zadaniach i przetwarzania zdarzeń.

Architektury bezserwerowe oparte na zdarzeniach

Architektury bezserwerowe oparte na zdarzeniach to specyficzny typ architektury bezserwerowej przetwarzania danych, który inicjuje wykonywanie funkcji lub mikroserwisów na podstawie zdarzeń lub aktywatorów. Komponenty systemu komunikują się za pomocą zdarzeń, a funkcje są wywoływane w odpowiedzi na zdarzenia. Często bazują one na komunikacji asynchronicznej, ponieważ funkcje są aktywowane przez zdarzenia, a potem przetwarzają je niezależnie oraz mogą wywoływać zdarzenia, które aktywują kolejne działania. Ten typ architektury bezserwerowej to dobry sposób na tworzenie skalowalnych, elastycznych i luźno sprzężonych systemów.

Google Cloud Functions i Cloud Functions dla Firebase umożliwiają kompilowanie i wdrażanie funkcji opartych na zdarzeniach w w pełni zarządzanym i bezserwerowym środowisku. Pozwala uruchamiać kod w odpowiedzi na różne zdarzenia i aktywatory, w tym żądania HTTP, wiadomości Cloud Pub/Sub, zmiany w Google Cloud Storage i aktualizacje Bazy danych czasu rzeczywistego Firebase, bez konieczności zarządzania infrastrukturą. Kluczowe funkcje to obsługa wielu języków, skalowalność, szczegółowe płatności, integracje z usługami innych firm, niezawodne logowanie i monitorowanie oraz integracja z innymi usługami Google i Firebase.

Architektury bezserwerowe mogą być ekonomiczne w wielu przypadkach, zwłaszcza w przypadku aplikacji o zróżnicowanych obciążeniach, potrzebach w zakresie szybkiego rozwoju i nieprzewidywalnych ruchu. Niezawodność zależy od dostawcy chmury i zapewnia gwarancję jakości usług w celu zapewnienia określonych celów w zakresie wydajności i niezawodności. Musisz ocenić konkretny przypadek użycia i określone wymagania, aby określić, czy architektura bezserwerowa to dla Ciebie najlepsza opcja.

Konteneryzacja

Konteneryzacja pozwala na łączenie aplikacji i ich zależności w lekkie, przenośne kontenery. Zapewniają spójne środowisko aplikacji, które ułatwia programowanie i wdrażanie w różnych systemach i platformach. Niektóre platformy bezserwerowe umożliwiają uruchamianie zbiorów zadań skonteneryzowanych. Uruchamianie kontenerów w środowisku bezserwerowym może być korzystne, gdy masz złożone lub stanowe zbiory zadań, których nie można wyrazić jako funkcji podstawowych. Zapewnia elastyczność pod względem obsługi języków i środowisk wykonawczych.

Cloud Run to bezserwerowa platforma obliczeniowa, która umożliwia programistom wdrażanie i uruchamianie skonteneryzowanych aplikacji w środowisku w pełni zarządzanym. Umożliwia on proste tworzenie, wdrażanie i skalowanie aplikacji bez konieczności zarządzania bazową infrastrukturą. Sprawdza się w przypadku szerokiej gamy aplikacji internetowych i mikroserwisowych, zwłaszcza tych ze zmiennymi zadaniami, w których konteneryzowanie zapewnia korzyści w zakresie pakowania i spójności aplikacji.

Architektury mikroserwisów

Aplikacje są podzielone na małe części, które są luźno sprzężone i obejmują różne funkcje lub możliwości. Mogą one komunikować się za pomocą komunikatów asynchronicznych, kanałów opartych na zdarzeniach lub bezpośrednio przez udostępnienie interfejsu. Każda usługa jest opracowywana, testowana i skalowana w swoim kontenerze niezależnie, którym często zarządza usługa administrowania, np. Kubernetes, lub wdrażana za pomocą zarządzanej platformy, takiej jak Cloud Run.

Wdrożenia mikroserwisów zwykle korzystają też z modelu aplikacji bezserwerowych, nie polegając na scentralizowanym serwerze.

Rozdzielenie aplikacji na usługi autonomiczne może uprościć złożony system. Dobrze wyznaczone granice i cele mogą przyspieszyć rozwój i zapewnić utrzymanie. Każdy mikroserwis można rozwijać niezależnie za pomocą najefektywniejszych platform lub narzędzi. Komunikacja między usługami często jest obsługiwana za pomocą zdarzeń, komunikacji publikowania i subskrybowania, potoków wiadomości lub zdalnych wywołań procedur, takich jak gRPC.

W przypadku administrowania zadaniami w ramach architektury mikroserwisu rozważ użycie platformy obsługującej platformy, na które kierujesz reklamy, wystarczającej złożoności zadań i typów przepływów pracy, które administrujesz, a także obsługi błędów i telemetrii w celu debugowania problemów. Popularne opcje to Kierownik lub oferty dostawcy usług w chmurze, takiego jak Google Workflows.

Tworzenie i utrzymywanie aplikacji opartych na mikroserwisach może być skomplikowane ze względu na ich rozproszony charakter i konieczność komunikacji wewnątrz usług. Z tego powodu zarządzanie wdrożeniami, monitorowanie i logowanie jest bardziej skomplikowane niż w przypadku innych opcji architektury. Niezawodność zależy od architektury poszczególnych usług, dlatego rozproszona natura może zapewniać dodatkową odporność, zwłaszcza jeśli wdrożone i włączone są monitorowanie i dane telemetryczne (w razie potrzeby).

Porównanie różnych architektur backendów aplikacji internetowych opartych na treści

W tabeli poniżej porównano architektury z kluczowymi wymaganiami dotyczącymi backendu aplikacji internetowej opartej na treści.

	Architektury monolityczne	Architektury bezserwerowe oparte na zdarzeniach	Architektury bezserwerowe z mikroserwisami
Złożoność i obsługa	Łatwe wdrożenie w przypadku małych, samodzielnych projektów, ale złożoność zwiększa się wraz z skalą. Wymaga ręcznej obsługi i koordynacji.	Skalowanie jest dobrze obsługiwane i wbudowane w platformę. Rozwiązywanie problemów i debugowanie może być trudne. Nie musisz zarządzać infrastrukturą.	Samodzielne usługi, które są testowane i wdrażane niezależnie, co ułatwia konserwację każdej jednostki. Wymaga ścisłej komunikacji między usługami. Do zarządzania na większą skalę wymagają narzędzi do zarządzania i administracji.
Skalowalność i wydajność	Wydajny na małą skalę, trudny do wykroczenia poza określony rozmiar. Określone potrzeby dotyczące infrastruktury, ograniczenia opcji skalowania dynamicznego. Skalowanie ręczne (lub korzystanie z usług ręcznych) w architekturze, na przykład za pomocą równoważenia obciążenia.	Wbudowana skalowalność przy użyciu zarządzanej platformy. Skaluje w dowolnym kierunku.	Każda usługa jest dostosowana do konkretnych potrzeb i można ją skalować i optymalizować niezależnie.
Strategie odporności i awaryjnej	Wdrażanie jest złożone i może prowadzić do przestojów („wszystko lub nic”).	Nieodłączna od dostawcy chmury. Każdą funkcję niezależną można ponowić niezależnie.	Każda usługa jest samodzielna, dzięki czemu ogólny system jest bardziej odporny na niezależne testy i programowanie.
Doświadczenie w programowaniu	Szybkie tworzenie aplikacji na małą skalę dzięki ścisłemu powiązaniu architektury (np. przez wydajne zapytania). Wraz ze wzrostem złożoności są długie czasy tworzenia oraz trudne do współpracy i testowania.	Nie wymagają one utrzymywania żadnej infrastruktury ani zarządzania nią, co przyspiesza programowanie. Testowanie i debugowanie aktywnej aplikacji zależy od usług dostawcy chmury.	Usługi są samodzielne i można je rozwijać niezależnie od siebie. W przypadku dużej liczby usług konieczne jest skoordynowanie i zarządzanie.
Koszt	Złożony proces programowania może skutkować wzrostem kosztów. Wymagane są znaczne inwestycje w sprzęt lub infrastrukturę, zwłaszcza na większą skalę. Oszczędności wynikające ze skalowania w górę i w dół są trudne do osiągnięcia.	Brak kosztów dedykowanego sprzętu. Skalowanie w górę i w dół w celu optymalizacji wykorzystania zasobów i kosztów (do zera).	Brak kosztów dedykowanego sprzętu. Skalowanie w górę i w dół w celu optymalizacji wykorzystania zasobów i kosztów w granicach. Dodatkowe koszty związane z monitorowaniem dużej liczby niezależnych usług i zarządzaniem nimi.

Więcej informacji o architekturach backendu dla aplikacji internetowych opartych na treści

Oto zasoby, z których dowiesz się więcej o architekturach aplikacji internetowych opartych na treści i o tym, jak przenieść aplikację do innej architektury:

• Dowiedz się więcej o luźno sprzężonych architekturach backendu aplikacji internetowych, w tym o warstwowych monolitycznych i bezserwerowych aplikacjach internetowych.

• Migracja aplikacji monolitycznej do architektury mikroserwisu.

• Typowe przypadki użycia bezserwerowych funkcji w Cloud Functions.