Podsumowanie: Tworzenie architektury aplikacji natywnych dla chmury

Napiwek

Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.

Pobierz plik PDF

Podsumowując, poniżej przedstawiono ważne wnioski z tego przewodnika:

• Chmura natywna polega na projektowaniu 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 głównych korporacji. Jest on odpowiedzialny za wspieranie wdrażania natywnych dla chmury obliczeń w obrębie technologii i stosów w chmurze.

• Wytyczne DOTYCZĄCE TECHNOLOGII 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 chmury

• Te filary natywne dla chmury obejmują:

  • Chmura i jej bazowy 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 do obsługi zmieniających się 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 do 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 stary protokół zdalnego wywołania procedury (RPC). Aplikacje natywne dla chmury często korzystają z usługi gRPC, aby usprawnić obsługę komunikatów między usługami zaplecza. 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 rozmiarze 60–80% mniejszym. 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 rozdzielają 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 zmienia się w jedną z wielu mniejszych baz danych, z których każda jest zgodna z mikrousługą. Gdy dym wyczyszczy się, pojawiamy się z projektem, który uwidacznia 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 drugiej odpowiedzi, faworyzują magazyny danych NoSQL. Proliferacji technologii NoSQL dla rozproszonych systemów natywnych dla chmury nie można przecenić.

• 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 nadal pozostaje funkcjonalna. Systemy natywne dla chmury obejmują architekturę rozproszoną, w której awaria jest nieunikniona. Aplikacje muszą być skonstruowane tak, aby reagowały elegancko na awarię i szybko wracały do w pełni funkcjonalnego stanu.

• Siatki usług to konfigurowalna warstwa infrastruktury z wbudowanymi możliwościami obsługi komunikacji z usługami i innymi wyzwaniami krzyżowymi. Odcinają one obowiązki krzyżowe od kodu biznesowego. Te obowiązki przechodzą na serwer proxy usługi. Określany jako Sidecar pattern, serwer proxy jest wdrażany w osobnym procesie w celu zapewnienia izolacji od kodu biznesowego.

• Obserwowanie to kluczowa kwestia 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 zbiór narzędzi opartych na chmurze zaprojektowanych w celu zapewnienia wglądu w stan systemu.

• Infrastruktura jako kod jest powszechnie akceptowaną praktyką automatyzującą aprowizację 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 dla 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.

Poprzednie