Zalecenia dotyczące projektowania pod kątem prostoty i wydajności
Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:
| RE:01 | Zaprojektuj obciążenie, aby dostosować je do celów biznesowych 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. Zawierają swój projekt, aby zmniejszyć nieefektywność i potencjalne problemy. |
|---|
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 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
| Okres | Definicja |
|---|---|
| Obciążenie | Dyskretne możliwości lub zadania obliczeniowe, które można logicznie oddzielić od innych zadań. |
Kluczowe strategie projektowania
Kluczowym zestawem projektowania pod kątem niezawodności jest utrzymanie prostych i wydajnych rzeczy. 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.
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 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ółpraca z uczestnikami projektu na ćwiczeniach projektowych
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 krytycznych przepływach , aby ułatwić określenie wymaganych składników 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.
Dekompiluj obciążenia do składników. 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 trybu awarii.
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 trybu awarii.
Zdefiniuj cele dostępności i odzyskiwania dla przepływów, aby poinformować o architekturze 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 pomyślne aplikacje zmieniają się w czasie, czy naprawiać usterki, implementować nowe funkcje lub technologie, czy 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 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 obserwowanych trendów lub zaleceń, które mogą nie być najlepsze dla kontekstu lub 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. Twórz swoje 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ą 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.
Wprowadzenie do programowania par lub dedykowanych sesji przeglądu kodu jako praktyki programistycznej.
Zaimplementuj podejście do identyfikowania martwego kodu. Bądź sceptycznie nastawiony do kodu, który nie obejmuje testów automatycznych.
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 sprzężeń.
Należy znormalizować dane i zrestrukturyzować je dla schematu podczas 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 rodzin 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ń w całym wykazie można indeksowania katalogu i przechowywania indeksu 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 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.
Korzystaj z trwałości wielolotowej lub rozwiązań korzystających z kombinacji technologii magazynu 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.
Określanie priorytetów dostępności przez 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ść.
Rozważ zestaw umiejętności 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ę przechowywania danych. Aby jak najlepiej wykorzystać technologię, 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 awaria, 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 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, 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 tworzenia aranżacji za pomocą graficznego interfejsu użytkownika lub edytowania pliku konfiguracji.
Usługa Azure Event Grid to wysoce skalowalna, w pełni zarządzana usługa dystrybucji komunikatów publikowania-subskrybowania, która oferuje elastyczne wzorce użycia komunikatów korzystające z 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:
- Wybieranie usługi obliczeniowej platformy Azure
- Wybieranie opcji obliczeniowej dla mikrousług
- Przeglądanie opcji danych
Przykład
Przykładowe obciążenie określające składniki i ich funkcje na podstawie wymagań można znaleźć w temacie Reliable Web App pattern (Wzorzec niezawodnej aplikacji internetowej).
Pokrewne łącza
Lista kontrolna dotycząca niezawodności
Zapoznaj się z pełnym zestawem zaleceń.