Udostępnij za pośrednictwem

Zalecenia dotyczące projektowania pod kątem prostoty i wydajności

  • Artykuł

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

RE:01 Zaprojektuj obciążenie tak, aby było zgodne z celami biznesowymi i uniknąć niepotrzebnej złożoności lub nakładu pracy. Użyj praktycznego i zrównoważonego podejścia do podejmowania decyzji projektowych, które dostarczają pożądanych wyników. Zawierać projekt w celu zmniejszenia nieefektywności i potencjalnych problemów.

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 składniki, aby wykonać niezbędne zadania obciążenia, aby zoptymalizować niezawodność obciążenia. Aby zmniejszyć obciążenia związane z programowaniem i zarządzaniem, skorzystaj z zalet oferowanych przez platformę usług. Ten projekt ułatwia tworzenie architektury obciążenia, która jest odporna, powtarzalna, skalowalna i zarządzalna.

Definicje

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

Kluczowe strategie projektowania

Kluczowym zestawem projektowania pod kątem niezawodności jest zapewnienie prostoty i wydajności. Skoncentruj się na projekcie obciążenia, aby spełnić wymagania biznesowe, aby zmniejszyć ryzyko niepotrzebnej złożoności lub nadmiernego obciążenia. 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.

Musisz 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 projektowe.

Kompromis: złożone rozwiązanie może oferować więcej funkcji i elastyczności, ale może to mieć wpływ na niezawodność obciążenia, ponieważ wymaga większej koordynacji, komunikacji i zarządzania składnikami. 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ólne ćwiczenia projektowe

Współpracuj z uczestnikami projektu, aby:

  • Zdefiniuj i przypisz poziom krytyczny do przepływów użytkownika i przepływów systemowych obciążenia. Skoncentruj się na przepływach krytycznych , aby ułatwić określenie wymaganych składników i najlepsze podejście do osiągnięcia wymaganego poziomu odporności.

  • Definiowanie wymagań funkcjonalnych i niefunkcyjnych. 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.

  • Dekompiluj obciążenia do składników. Określanie priorytetów 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 adresuje, 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 trybu awarii.

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

  • Zdefiniuj cele dostępności i odzyskiwania dla przepływów, aby poinformować 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 (RP). Zdefiniuj wartości docelowe dla tych metryk. To ćwiczenie może wymagać kompromisu i wzajemnego zrozumienia między technologiami a zespołami biznesowymi w celu zapewnienia, ż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.

Dodatkowe zalecenia dotyczące projektowania

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 szczegółowości dla składników i usług. Unikaj nadmiernej inżynierii lub niedoprojektowania rozwiązania. Jeśli na przykład podzielisz kod na wiele małych funkcji, trudno jest zrozumieć, przetestować i utrzymać.

  • Przyznaj, że wszystkie pomyślne aplikacje zmieniają się w czasie, czy naprawić usterki, zaimplementować nowe funkcje lub technologie, czy też uczynić istniejące systemy bardziej skalowalnymi i odpornymi.

  • Jeśli to możliwe, użyj opcji platformy jako usługi (PaaS) zamiast infrastruktury jako usługi (IaaS). Korzystanie z rozwiązania IaaS przypomina zabawę klockami — 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.

  • Użyj asynchronicznej obsługi komunikatów , aby rozdzielić producenta komunikatów od konsumenta.

  • Oddziel infrastrukturę od logiki domeny. Upewnij się, że logika domeny nie zakłóca funkcji związanych z infrastrukturą, takich 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 z dobrze zdefiniowanymi interfejsami, 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ń użyteczność typowych wzorców i praktyk dla Twoich potrzeb. Unikaj obserwowanych trendów lub zaleceń, które mogą nie być najlepsze dla twojego kontekstu lub wymagań. Na przykład mikrousługi nie są najlepszą opcją dla każdej aplikacji, ponieważ mogą one wprowadzać złożoność, obciążenie i problemy z 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 obciążeniu ustal funkcjonalność zapewnianą przez składnik. Twórz przepływy, aby korzystać z tej funkcji. Weź pod uwagę następujące zalecenia dotyczące praktyk programistycznych:

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

  • Korzystanie z bibliotek i struktur.

  • Wprowadzenie sesji programowania parowego lub dedykowanego przeglądu kodu jako praktyki programistycznej.

  • Zaimplementuj podejście do identyfikowania martwego kodu. Bądź sceptyczny w kodzie, który nie obejmuje testów automatycznych.

Korzystanie z najlepszego magazynu danych dla 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 sprzężeń.

  • Musisz znormalizować dane i zrestrukturyzować je na potrzeby schematu zapisu.

  • Rywalizacja o blokadę może mieć wpływ 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 par klucz-wartość

  • Bazy danych dokumentów

  • Bazy danych aparatu wyszukiwania

  • Bazy danych szeregów czasowych

  • Bazy danych rodziny 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 najlepiej pasuje do danych i jak jej używasz.

Na przykład katalog produktów można przechowywać w bazie danych dokumentów, takiej jak Usługa Azure Cosmos DB, która obsługuje elastyczny schemat. Każdy opis produktu to samodzielny dokument. W przypadku zapytań w całym wykazie można indeksowania katalogu i przechowywania indeksu w 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 Omówienie modeli magazynu 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.

  • Zastosowanie trwałości wielolotowej lub rozwiązań korzystających z kombinacji technologii magazynu danych.

  • Weź pod uwagę typ posiadanych danych. Na przykład zapisz:

    • Dane transakcyjne w bazie danych SQL.

    • Dokumenty JSON w bazie danych dokumentów.

    • Telemetria w bazie danych szeregów czasowych.

    • Dzienniki aplikacji w Azure Cognitive Search.

    • Obiekty blob w Azure Blob Storage.

  • Określanie priorytetów dostępności na 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 zastosować model spójności ostatecznej w celu uzyskania wyższej dostępności.

  • Rozważ zestaw umiejętności twojego zespołu deweloperów. Istnieją zalety łączenia różnych technologii magazynowania, można jednak przesadzić. Wymaga to nowych zestawów umiejętności, aby wdrożyć nową technologię magazynu danych. Aby jak najlepiej wykorzystać technologię, twój zespół programistyczny musi:

    • Optymalizowanie zapytań.

    • Dostrajanie pod kątem wydajności.

    • Praca z odpowiednimi wzorcami użycia.

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

  • Używaj transakcji wyrównujących. W przypadku trwałości wielolotowej jedna transakcja może zapisywać dane w wielu magazynach. Jeśli wystąpi błąd, użyj transakcji wyrównywujących, aby cofnąć wszystkie zakończone kroki.

  • 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 można zamapować na poddomenę domeny biznesowej. Rozważ trwałość wielolotu dla powiązanych kontekstów w systemie. Na przykład produkty mogą pojawić się w poddomenie katalogu 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, której można użyć do tworzenia aranżacji przy użyciu minimalnej ilości kodu.

  • Azure Logic Apps to bezserwerowa platforma integracji przepływu pracy, której można użyć do kompilowania aranżacji za pomocą graficznego interfejsu użytkownika lub edytowania pliku konfiguracji.

  • Azure Event Grid to wysoce skalowalna, w pełni zarządzana usługa dystrybucji komunikatów publikowania-subskrybowania, która oferuje elastyczne wzorce zużycia komunikatów korzystające z protokołów MQTT i HTTP. Za pomocą usługi Event Grid można tworzyć potoki danych za pomocą danych urządzeń, tworzyć architektury bezserwerowe oparte na zdarzeniach i integrować aplikacje.

Aby uzyskać więcej informacji, zobacz:

Przykład

Przykładowe obciążenie, które określa składniki i ich funkcje na podstawie wymagań, zobacz Wzorzec niezawodnej aplikacji internetowej.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności