Strategie architektury do projektowania pod kątem prostoty i wydajności

Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:

RE:01	Skoncentruj projektowanie obciążenia na prostocie i wydajności. Użyj praktycznego podejścia, aby uniknąć niepotrzebnej złożoności podczas spełniania celów i wymagań biznesowych.

W tym przewodniku opisano zalecenia dotyczące minimalizowania niepotrzebnej złożoności i nakładu pracy w celu zapewnienia prostych i wydajnych obciążeń. Wybierz najlepsze komponenty, aby wykonać niezbędne zadania związane z obciążeniem i zoptymalizować niezawodność Twojego obciążenia. Aby zmniejszyć obciążenia związane z programowaniem i zarządzaniem, skorzystaj z wydajności oferowanych przez platformę usług. Ten projekt ułatwia tworzenie architektury obciążenia, która jest odporna, powtarzalna, skalowalna i zarządzalna.

Definicje

Termin	Definicja
Obciążenie	Dyskretne możliwości lub zadania obliczeniowe, które można logicznie oddzielić od innych zadań.

Kluczową zasadą projektowania z myślą o niezawodności jest zachowanie prostoty i efektywności. Skoncentruj projektowanie obciążeń na spełnieniu wymagań biznesowych, aby ograniczyć ryzyko niepotrzebnej złożoności lub zbędnego narzutu. Zapoznaj się z zaleceniami w tym artykule, aby ułatwić podejmowanie decyzji dotyczących projektu w celu utworzenia oszczędnego, wydajnego i niezawodnego obciążenia. Różne obciążenia mogą mieć różne wymagania dotyczące dostępności, skalowalności, spójności danych i odzyskiwania po awarii.

Należy uzasadnić każdą decyzję projektową z wymaganiem biznesowym. Ta zasada projektowania może wydawać się oczywista, ale ma kluczowe znaczenie dla projektowania obciążeń. Czy aplikacja obsługuje miliony użytkowników, czy kilka tysięcy? Czy występują duże wzrosty ruchu, czy stałe obciążenie? Jaki poziom awarii aplikacji jest akceptowalny? Wymagania biznesowe napędzają te zagadnienia dotyczące projektowania.

Kompromis: Złożone rozwiązanie może oferować więcej funkcji i elastyczności, ale może wpłynąć na niezawodność obciążenia roboczego, ponieważ wymaga większej koordynacji, komunikacji i zarządzania komponentami. Alternatywnie prostsze rozwiązanie może nie spełniać w pełni oczekiwań użytkowników lub może mieć negatywny wpływ na skalowalność i rozszerzalność w miarę rozwoju obciążenia.

Współpraca z uczestnikami projektu na ćwiczeniach projektowych

Współpracuj z uczestnikami projektu, aby:

• Zdefiniuj i przypisz poziom krytyczności do przepływów użytkownika i przepływów systemowych obciążenia. Skoncentruj projekt na krytycznych przepływach, aby określić wymagane komponenty i najlepsze podejście do osiągnięcia wymaganego poziomu odporności.

• Zdefiniuj wymagania funkcjonalne i niefunkcjonalne. Rozważ wymagania funkcjonalne, aby określić, czy aplikacja wykonuje zadanie. Rozważ niefunkcjonalne wymagania, aby określić, jak dobrze aplikacja wykonuje zadanie. Upewnij się, że rozumiesz wymagania niefunkcjonalne, takie jak skalowalność, dostępność i opóźnienie. Te wymagania wpływają na decyzje projektowe i wybory technologiczne.

• Rozłóż obciążenia na składniki. Określ priorytety prostoty, wydajności i niezawodności w projekcie. Określ składniki potrzebne do obsługi przepływów. Niektóre składniki obsługują wiele przepływów. Zidentyfikuj, które wyzwanie składnik koncepcyjnie rozwiązuje, i rozważ usunięcie składnika z poszczególnych przepływów, aby uprościć ogólny projekt, zapewniając jednocześnie pełną funkcjonalność. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące przeprowadzania analizy rodzajów uszkodzeń.

• Użyj analizy trybu awarii, aby zidentyfikować pojedyncze punkty awarii i potencjalne zagrożenia. Zastanów się, czy należy uwzględnić mało prawdopodobne sytuacje, na przykład obszar geograficzny, który doświadcza poważnej klęski żywiołowej, która ma wpływ na wszystkie strefy dostępności w regionie. Jest to kosztowne i wiąże się ze znacznymi kompromisami w celu ograniczenia tych nietypowych zagrożeń. Jasno zrozumieć tolerancję twojej firmy na ryzyko. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące przeprowadzania analizy rodzajów uszkodzeń.

• Zdefiniuj cele dostępności i odzyskiwania po awarii dla swoich przepływów, aby określić architekturę obciążenia. Metryki biznesowe obejmują cele poziomu usług (SLO), umowy dotyczące poziomu usług (SLA), średni czas odzyskiwania (MTTR), średni czas między awarią (MTBF), cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO). Zdefiniuj wartości docelowe dla tych metryk. To ćwiczenie może wymagać kompromisu i wzajemnego zrozumienia między zespołami technologicznymi i biznesowymi, aby zapewnić, że cele każdego zespołu spełniają cele biznesowe i są realistyczne. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące definiowania celów niezawodności.

Faworyzowanie prostszych wyborów projektowych

Możesz wykonać następujące zalecenia bez zaangażowania uczestników projektu:

• Staraj się dążyć do prostoty i jasności w projekcie . Użyj odpowiedniego poziomu abstrakcji i stopnia szczegółowości dla składników i usług. Unikaj nadmiernej inżynierii lub niedostatecznej inżynierii rozwiązania. Jeśli na przykład podzielisz kod na wiele małych funkcji, trudno jest zrozumieć, przetestować i utrzymać.

• Przyznaj, że wszystkie udane aplikacje ewoluują z czasem, czy to po to, by naprawiać błędy, wdrażać nowe funkcje lub technologie, czy zwiększać skalowalność i odporność istniejących systemów.

• Jeśli to możliwe, użyj opcji platformy jako usługi (PaaS) zamiast infrastruktury jako usługi (IaaS). IaaS jest jak pudełko z częściami. można zbudować prawie wszystko, ale trzeba zrobić to samodzielnie. Opcje paaS są łatwiejsze do skonfigurowania i administrowania. Nie trzeba konfigurować maszyn wirtualnych ani sieci wirtualnych. Nie trzeba również wykonywać zadań konserwacji, takich jak instalowanie poprawek i aktualizacji.

• Zmniejsz ściśle powiązane zależności między składnikami obciążenia, aby zmniejszyć ryzyko awarii kaskadowych podczas częściowych awarii. Na przykład asynchroniczne komunikaty to dobre podejście do oddzielenia producenta komunikatów od konsumenta.

• Oddziel infrastrukturę od logiki domeny. Upewnij się, że logika domeny nie zakłóca działania związane z infrastrukturą, takie jak obsługa komunikatów lub trwałość.

• Odciąż przekrojowe zagadnienia do oddzielnej usługi. Zminimalizuj potrzebę duplikowania kodu w różnych funkcjach, preferuj ponowne używanie usług za pomocą dobrze zdefiniowanych interfejsów, które mogą być łatwo używane przez różne składniki. Jeśli na przykład kilka usług wymaga uwierzytelnienia żądań, możesz przenieść tę funkcję do własnej usługi. Następnie możesz rozwinąć usługę uwierzytelniania. Możesz na przykład dodać nowy przepływ uwierzytelniania bez dotykania żadnej z usług, które z niej korzystają.

• Oceń odpowiedniość typowych wzorców i praktyk dla Twoich potrzeb. Unikaj podążania za trendami lub zaleceniami, które mogą nie być najlepsze w Twoim przypadku lub dla Twoich wymagań. Na przykład mikrousługi nie są najlepszą opcją dla każdej aplikacji, ponieważ mogą one wprowadzać problemy ze złożonością, obciążeniem i zależnościami.

Opracowywanie wystarczającej ilości kodu

Zasady prostoty, wydajności i niezawodności mają również zastosowanie do praktyk programistycznych. W luźno powiązanym, składnikowym obciążeniu określ funkcje zapewniane przez składnik. Projektuj przepływy tak, aby korzystać z tej funkcjonalności. Weź pod uwagę następujące zalecenia dotyczące praktyk programistycznych:

• Korzystaj z możliwości platformy, gdy spełniają twoje wymagania biznesowe. Aby na przykład odciążyć programowanie i zarządzanie, użyj rozwiązań z małą ilością kodu, bez kodu lub bezserwerowych, które oferuje dostawca usług w chmurze.

• Korzystanie z bibliotek i struktur.

• Wprowadź programowanie w parach lub dedykowane sesje przeglądu kodu jako praktykę programistyczną.

• Zaimplementuj podejście do identyfikowania martwego kodu. Podchodź sceptycznie do kodu, którego nie pokrywają testy automatyczne.

Wybieranie odpowiedniego magazynu danych

W przeszłości wiele organizacji przechowywało wszystkie swoje dane w dużych relacyjnych bazach danych SQL. Relacyjne bazy danych zapewniają gwarancje niepodzielne, spójne, izolowane i trwałe (ACID) dla transakcji danych relacyjnych. Jednak te bazy danych mają wady:

• Zapytania mogą wymagać kosztownych operacji łączenia.

• Należy znormalizować dane i zrestrukturyzować je dla schematu podczas zapisu.

• Konflikt blokad może wpływać na wydajność.

Alternatywy dla relacyjnych baz danych

W dużym rozwiązaniu jedna technologia magazynu danych prawdopodobnie nie spełnia wszystkich Twoich potrzeb. Alternatywy dla relacyjnych baz danych to:

• Magazyny klucz-wartość

• Bazy danych dokumentów

• Bazy danych aparatu wyszukiwania

• Bazy danych szeregów czasowych

• Bazy danych z rodzinami kolumn

• Grafowe bazy danych

Każda opcja ma zalety i wady. Różne typy danych lepiej nadają się do różnych typów magazynów danych. Wybierz technologię magazynowania, która jest najlepsza dla Twoich danych i jak ich używasz.

Możesz na przykład przechowywać katalog produktów w bazie danych dokumentów, takiej jak Usługa Azure Cosmos DB, która obsługuje elastyczny schemat. Każdy opis produktu jest samodzielnym dokumentem. W przypadku zapytań obejmujących cały katalog można zindeksować katalog i przechowywać indeks w usłudze Azure Cognitive Search. Spis produktów może przejść do bazy danych SQL, ponieważ te dane wymagają gwarancji ACID.

Zalecenia

• Rozważ inne magazyny danych. Relacyjne bazy danych nie zawsze są odpowiednie. Aby uzyskać więcej informacji, zobacz Poznaj modele magazynów danych.

• Pamiętaj, że dane zawierają więcej niż tylko utrwalone dane aplikacji. To także dzienniki, zdarzenia, komunikaty i pamięci podręczne aplikacji.

• Stosuj persystencję poliglotyczną lub rozwiązania wykorzystujące kombinację technologii przechowywania danych.

• Rozważ typ posiadanych danych. Na przykład przechowaj:

  • Dane transakcyjne w bazie danych SQL.

  • Dokumenty JSON w bazie danych dokumentów.

  • Telemetria w bazie danych szeregów czasowych.

  • Dzienniki aplikacji w usłudze Azure Cognitive Search.

  • Obiekty blob w usłudze Azure Blob Storage.

• Przedkładaj dostępność nad spójność. Twierdzenie CAP oznacza, że należy dokonać kompromisów między dostępnością a spójnością w systemie rozproszonym. Nie można całkowicie uniknąć partycji sieciowych, czyli innego składnika twierdzenia CAP. Można jednak wdrożyć model spójności ostatecznej, aby uzyskać wyższą dostępność.

• Weź pod uwagę umiejętności swojego zespołu programistów. Stosowanie podejścia polyglot persistence ma swoje zalety, ale można z tym przesadzić. Wymaga to nowych zestawów umiejętności, aby wdrożyć nową technologię przechowywania danych. Aby jak najlepiej wykorzystać technologię, zespół programistyczny musi:

  • Optymalizowanie zapytań.

  • Dostosuj pod kątem wydajności.

  • Korzystaj z odpowiednich wzorców użycia.

Podczas wybierania technologii magazynowania należy wziąć pod uwagę następujące czynniki:

• Stosuj transakcje kompensujące. W przypadku trwałości poliglotycznej pojedyncza transakcja może zapisywać dane w wielu magazynach danych. Jeśli dojdzie do błędu, użyj transakcji kompensujących, aby cofnąć te kroki, które zostały już zakończone.

• Rozważ ograniczone konteksty, które są koncepcją projektowania opartą na domenie. Ograniczony kontekst jest jawną granicą wokół modelu domeny. Ograniczony kontekst definiuje części domeny, do których ma zastosowanie model. W idealnym przypadku ograniczony kontekst odpowiada poddomenie domeny biznesowej. Rozważ zastosowanie poliglotycznej persystencji dla kontekstów ograniczonych w systemie. Na przykład produkty mogą pojawić się w poddomenie wykazu produktów i poddomenie spisu produktów. Jednak najprawdopodobniej te dwie poddomeny mają różne wymagania dotyczące przechowywania, aktualizowania i wykonywania zapytań dotyczących produktów.

Ułatwienia platformy Azure

Platforma Azure oferuje następujące usługi:

• Azure Functions to bezserwerowa usługa obliczeniowa, za pomocą której można tworzyć orkiestrację przy użyciu minimalnej ilości kodu.

• Azure Logic Apps to bezserwerowa platforma integracji przepływów pracy, której można używać do tworzenia orkiestracji za pomocą interfejsu graficznego (GUI) lub przez edytowanie pliku konfiguracji.

• Azure Event Grid to wysoce skalowalna, w pełni zarządzana usługa dystrybucji komunikatów w modelu publikowanie-subskrypcja, która oferuje elastyczne wzorce odbioru komunikatów z wykorzystaniem protokołów MQTT i HTTP. Usługa Event Grid umożliwia tworzenie potoków danych za pomocą danych urządzeń, tworzenie architektur bezserwerowych opartych na zdarzeniach i integrowanie aplikacji.

Aby uzyskać więcej informacji, zobacz:

• Wybierz usługę obliczeniową Azure
• Wybierz opcję obliczeniową dla mikrousług
• Przejrzyj opcje dotyczące danych

Przykład

Opis przykładowego obciążenia roboczego, które określa składniki i ich cechy na podstawie wymagań, można znaleźć w artykule Reliable Web App pattern.

Pokrewne łącza

• Azure bezserwerowe
• Aplikacje natywne dla chmury
• Typy baz danych w usłudze Azure

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna niezawodności