Podsumowanie: Tworzenie architektury aplikacji natywnych dla chmury
Porada
Ta zawartość to fragment książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępny w witrynie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Podsumowując, poniżej przedstawiono ważne wnioski z tego przewodnika:
Natywne dla chmury jest projektowanie nowoczesnych aplikacji, które obejmują szybkie zmiany, dużą skalę i odporność, w nowoczesnych, dynamicznych środowiskach, takich jak chmury publiczne, prywatne i hybrydowe.
Cloud Native Computing Foundation (CNCF) jest wpływowym konsorcjum open source ponad 300 dużych korporacji. Jest on odpowiedzialny za wspieranie wdrażania natywnych dla chmury obliczeń w różnych technologiach i stosach w chmurze.
Wytyczne FIRMY CNCF zalecają, aby aplikacje natywne dla chmury obejmowały sześć ważnych filarów, jak pokazano na rysunku 11–1:
Rysunek 11–1. Podstawowe filary natywne dla chmury
Te filary natywne dla chmury obejmują:
- Chmura i jej podstawowy model usług
- Nowoczesne zasady projektowania
- Mikrousługi
- Konteneryzacja i orkiestracja kontenerów
- Oparte na chmurze usługi tworzenia kopii zapasowych, takie jak bazy danych i brokery komunikatów
- Automatyzacja, w tym infrastruktura jako kod i wdrażanie kodu
Platforma Kubernetes to wybrane środowisko hostingu dla większości aplikacji natywnych dla chmury. Mniejsze, proste usługi są czasami hostowane na platformach bezserwerowych, takich jak Azure Functions. Wśród wielu kluczowych funkcji automatyzacji oba środowiska zapewniają automatyczne skalowanie w celu obsługi zmiennych woluminów obciążeń.
Komunikacja z usługą staje się znaczącą decyzją projektową podczas tworzenia aplikacji natywnej dla chmury. Aplikacje zwykle uwidaczniają bramę interfejsu API w celu zarządzania komunikacją klienta frontonu. Następnie mikrousługi zaplecza dążą do komunikowania się ze sobą implementowania wzorców komunikacji asynchronicznej, jeśli jest to możliwe.
gRPC to nowoczesna, wysokowydajna struktura, która rozwija odwieczne zdalne wywołanie procedury (RPC). Aplikacje natywne dla chmury często korzystają z usługi gRPC, aby usprawnić obsługę komunikatów między usługami zaplecza. Usługa gRPC używa protokołu HTTP/2 dla protokołu transportowego. Może to być do 8 razy szybsze niż serializacja JSON z rozmiarami komunikatów o rozmiarach 60–80% mniejszych. gRPC jest open source i zarządzany przez Cloud Native Computing Foundation (CNCF).
Rozproszone dane to model często implementowany przez aplikacje natywne dla chmury. Aplikacje dzielą funkcje biznesowe na małe, niezależne mikrousługi. Każda mikrousługa hermetyzuje własne zależności, dane i stan. Klasyczny model udostępnionej bazy danych ewoluuje w jedną z wielu mniejszych baz danych, z których każda jest zgodna z mikrousługą. Kiedy dym czyści, wyłaniamy się z projektem, który ujawnia
database-per-microservice
model.Bazy danych No-SQL odwołują się do magazynów danych o wysokiej wydajności, nierelacyjnych. Doskonale sprawdzają się w swoich cechach łatwości użycia, skalowalności, odporności i dostępności. Usługi o dużej ilości, które wymagają czasu odpowiedzi na sekundę podrzędne, preferują magazyny danych NoSQL. Nie można zawyżać rozprzestrzeniania technologii NoSQL dla rozproszonych systemów natywnych dla chmury.
NewSQL to nowa technologia bazy danych, która łączy rozproszoną skalowalność bazy danych NoSQL i gwarancje ACID relacyjnej bazy danych. Bazy danych NewSQL są przeznaczone dla systemów biznesowych, które muszą przetwarzać duże ilości danych w środowiskach rozproszonych z pełną zgodnością transakcyjną/ACID. Program Cloud Native Computing Foundation (CNCF) oferuje kilka projektów bazy danych NewSQL.
Odporność to zdolność systemu do reagowania na awarie i pozostania funkcjonalna. Systemy natywne dla chmury obejmują architekturę rozproszoną, w której awaria jest nieunikniona. Aplikacje muszą być skonstruowane tak, aby reagowały elegancko na awarie i szybko wracały do w pełni funkcjonalnego stanu.
Siatki usług to konfigurowalna warstwa infrastruktury z wbudowanymi funkcjami do obsługi komunikacji z usługami i innymi wyzwaniami krzyżowymi. Oddzielają one obowiązki krzyżowe od kodu biznesowego. Te obowiązki są przenoszone do serwera proxy usługi. Określany jako
Sidecar pattern
, serwer proxy jest wdrażany w osobnym procesie w celu zapewnienia izolacji od kodu biznesowego.Wgląd to kluczowy element projektowania aplikacji natywnych dla chmury. Ponieważ usługi są dystrybuowane w klastrze węzłów, scentralizowane rejestrowanie, monitorowanie i alerty stają się obowiązkowe. Usługa Azure Monitor to kolekcja narzędzi opartych na chmurze, która zapewnia wgląd w stan systemu.
Infrastruktura jako kod jest powszechnie akceptowaną praktyką, która automatyzuje aprowizowanie platformy. Infrastruktura i wdrożenia są zautomatyzowane, spójne i powtarzalne. Narzędzia, takie jak azure Resource Manager, Terraform i interfejs wiersza polecenia platformy Azure, umożliwiają deklaratywne tworzenie skryptów wymaganej infrastruktury chmury.
Automatyzacja kodu jest wymagana w przypadku aplikacji natywnych dla chmury. Nowoczesne systemy ciągłej integracji/ciągłego wdrażania pomagają spełnić tę zasadę. Zapewniają one oddzielne kroki kompilacji i wdrażania, które pomagają zapewnić spójny i jakościowy kod. Etap kompilacji przekształca kod w artefakt binarny. Etap wydania pobiera artefakt binarny, stosuje konfigurację środowiska zewnętrznego i wdraża go w określonym środowisku. Usługi Azure DevOps i GitHub to w pełni funkcjonalne środowiska DevOps.
Opinia
Prześlij i wyświetl opinię dla