Udostępnij za pośrednictwem

Odporność i wysoka dostępność w ramach mikrousług

  • Artykuł

Napiwek

Ta zawartość jest fragmentem książki eBook, architektury mikrousług platformy .NET dla konteneryzowanych aplikacji platformy .NET dostępnych na platformie .NET Docs lub jako bezpłatnego pliku PDF, który można odczytać w trybie offline.

Pobierz plik PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Radzenie sobie z nieoczekiwanymi awariami jest jednym z najtrudniejszych problemów do rozwiązania, zwłaszcza w systemie rozproszonym. Większość kodu, który piszą deweloperzy, obejmuje obsługę wyjątków i jest to również miejsce, w którym najwięcej czasu poświęca się na testowanie. Problem jest bardziej zaangażowany niż pisanie kodu do obsługi błędów. Co się stanie, gdy maszyna, na której uruchomiono mikrousługę, ulegnie awarii? Nie tylko musisz wykryć tę awarię mikrousługi (twardy problem na własną rękę), ale także coś potrzebnego do ponownego uruchomienia mikrousługi.

Mikrousługi muszą być odporne na awarie i być w stanie uruchomić ponownie często na innej maszynie w celu zapewnienia dostępności. Ta odporność sprowadza się również do stanu zapisanego w imieniu mikrousługi, gdzie mikrousługa może odzyskać ten stan z i czy mikrousługę można pomyślnie uruchomić ponownie. Innymi słowy, w możliwości obliczeniowej musi istnieć odporność (proces może zostać uruchomiony ponownie w dowolnym momencie), a także odporność w stanie lub danych (bez utraty danych, a dane pozostają spójne).

Problemy z odpornością są komplikowane w innych scenariuszach, na przykład w przypadku awarii podczas uaktualniania aplikacji. Mikrousługa, pracując z systemem wdrażania, musi określić, czy może kontynuować przechodzenie do nowszej wersji, czy zamiast tego wycofać się do poprzedniej wersji, aby zachować spójny stan. Pytania, takie jak to, czy są dostępne wystarczające maszyny, aby kontynuować, i jak odzyskać poprzednie wersje mikrousługi, należy wziąć pod uwagę. Takie podejście wymaga, aby mikrousługa emitować informacje o kondycji, dzięki czemu ogólna aplikacja i orkiestrator mogą podejmować te decyzje.

Ponadto odporność jest związana z zachowaniem systemów opartych na chmurze. Jak wspomniano, system oparty na chmurze musi obejmować błędy i musi spróbować automatycznie odzyskać dane z nich. Na przykład w przypadku awarii sieci lub kontenera aplikacje klienckie lub usługi klienckie muszą mieć strategię ponawiania próby wysyłania komunikatów lub ponawiania żądań, ponieważ w wielu przypadkach błędy w chmurze są częściowe. Sekcja Implementowanie aplikacji odpornych na błędy w tym przewodniku dotyczy sposobu obsługi częściowych awarii. W tym artykule opisano techniki, takie jak ponawianie prób z wykładniczym wycofywaniem lub wzorcem wyłącznika na platformie .NET przy użyciu bibliotek takich jak Polly, które oferują szeroką gamę zasad do obsługi tego tematu.

Zarządzanie kondycją i diagnostyka w mikrousługach

Może wydawać się oczywiste i często pomijane, ale mikrousługa musi zgłosić swoją kondycję i diagnostykę. W przeciwnym razie z perspektywy operacji niewiele jest szczegółowych informacji. Korelowanie zdarzeń diagnostycznych w zestawie niezależnych usług i radzenie sobie ze niesymetrycznością zegara maszynowego, aby zrozumieć kolejność zdarzeń, jest trudne. W taki sam sposób, w jaki korzystasz z mikrousługi za pośrednictwem uzgodnionych protokołów i formatów danych, istnieje potrzeba standaryzacji w sposobie rejestrowania zdarzeń kondycji i diagnostyki, które ostatecznie znajdują się w magazynie zdarzeń na potrzeby wykonywania zapytań i wyświetlania. W podejściu mikrousług kluczowe jest, aby różne zespoły uzgodniły jeden format rejestrowania. Konieczne jest spójne podejście do wyświetlania zdarzeń diagnostycznych w aplikacji.

Kontrole kondycji

Kondycja różni się od diagnostyki. Kondycja dotyczy mikrousługi raportowania bieżącego stanu w celu podjęcia odpowiednich działań. Dobrym przykładem jest praca z mechanizmami uaktualniania i wdrażania w celu zachowania dostępności. Mimo że usługa może być obecnie w złej kondycji z powodu awarii procesu lub ponownego uruchomienia maszyny, usługa może nadal działać. Ostatnią rzeczą, którą musisz zrobić, jest to, aby pogorszyć wydajność uaktualnienia. Najlepszym rozwiązaniem jest przeprowadzenie badania po raz pierwszy lub zezwolenie na odzyskanie mikrousługi. Zdarzenia dotyczące kondycji z mikrousługi pomagają nam podejmować świadome decyzje, a w efekcie pomóc w tworzeniu usług samonaprawiania.

W sekcji Implementowanie kontroli kondycji w ASP.NET Podstawowych usług w tym przewodniku wyjaśniono, jak używać nowej biblioteki ASP.NET HealthChecks w mikrousług, aby umożliwić zgłaszanie ich stanu do usługi monitorowania w celu podjęcia odpowiednich działań.

Istnieje również możliwość korzystania z doskonałej biblioteki open source o nazwie AspNetCore.Diagnostics.HealthChecks, dostępnej w witrynie GitHub i jako pakietu NuGet. Ta biblioteka wykonuje również kontrole kondycji z twistem, obsługuje dwa typy kontroli:

  • Liveness: sprawdza, czy mikrousługa jest aktywna, czyli jeśli jest w stanie akceptować żądania i odpowiadać.
  • Gotowość: sprawdza, czy zależności mikrousługi (baza danych, usługi kolejki itp.) są gotowe, więc mikrousługi mogą robić to, co ma zrobić.

Korzystanie z diagnostyki i dzienników strumieni zdarzeń

Dzienniki zawierają informacje o sposobie działania aplikacji lub usługi, w tym wyjątków, ostrzeżeń i prostych komunikatów informacyjnych. Zazwyczaj każdy dziennik jest w formacie tekstowym z jednym wierszem na zdarzenie, chociaż wyjątki często pokazują ślad stosu w wielu wierszach.

W aplikacjach opartych na serwerze monolitycznym można zapisywać dzienniki w pliku na dysku (plik dziennika), a następnie analizować je za pomocą dowolnego narzędzia. Ponieważ wykonywanie aplikacji jest ograniczone do stałego serwera lub maszyny wirtualnej, zazwyczaj nie jest zbyt skomplikowane do analizowania przepływu zdarzeń. Jednak w aplikacji rozproszonej, w której wiele usług jest wykonywanych w wielu węzłach w klastrze orkiestratora, możliwość skorelowania zdarzeń rozproszonych jest wyzwaniem.

Aplikacja oparta na mikrousługach nie powinna próbować przechowywać strumienia wyjściowego zdarzeń lub plików dziennika, a nawet nie próbować zarządzać routingiem zdarzeń do centralnego miejsca. Powinno być przezroczyste, co oznacza, że każdy proces powinien po prostu zapisywać strumień zdarzeń do standardowych danych wyjściowych, które poniżej będą zbierane przez infrastrukturę środowiska wykonawczego, w której jest uruchomiona. Przykładem tych routerów strumienia zdarzeń jest Microsoft.Diagnostic.EventFlow, który zbiera strumienie zdarzeń z wielu źródeł i publikuje je w systemach wyjściowych. Mogą one obejmować proste standardowe dane wyjściowe dla środowiska deweloperskiego lub systemów w chmurze, takich jak Usługa Azure Monitor i Diagnostyka Azure. Istnieją również dobre platformy i narzędzia do analizy dzienników innych firm, które mogą wyszukiwać, alerty, raport i monitorować dzienniki, nawet w czasie rzeczywistym, takie jak Splunk.

Koordynatorzy zarządzający informacjami o kondycji i diagnostyki

Podczas tworzenia aplikacji opartej na mikrousługach należy radzić sobie ze złożonością. Oczywiście pojedyncza mikrousługa jest prosta do rozwiązania, ale dziesiątki lub setki typów i tysiące wystąpień mikrousług jest złożonym problemem. Nie chodzi tylko o tworzenie architektury mikrousług — potrzebujesz również wysokiej dostępności, możliwości adresowania, odporności, kondycji i diagnostyki, jeśli zamierzasz mieć stabilny i spójny system.

Diagram of clusters supplying a support platform for microservices.

Rysunek 4–22. Platforma mikrousług ma podstawowe znaczenie dla zarządzania kondycją aplikacji

Złożone problemy przedstawione na rysunku 4–22 są trudne do samodzielnego rozwiązania. Zespoły programistyczne powinny skupić się na rozwiązywaniu problemów biznesowych i tworzeniu niestandardowych aplikacji za pomocą metod opartych na mikrousługach. Nie powinny one skupiać się na rozwiązywaniu złożonych problemów z infrastrukturą; Gdyby tak było, koszt każdej aplikacji opartej na mikrousługach byłby ogromny. W związku z tym istnieją platformy zorientowane na mikrousługi, nazywane orkiestratorami lub klastrami mikrousług, które próbują skutecznie rozwiązywać problemy związane z tworzeniem i uruchamianiem usługi oraz używaniem zasobów infrastruktury. Takie podejście zmniejsza złożoność tworzenia aplikacji korzystających z podejścia mikrousług.

Różne orkiestratory mogą wydawać się podobne, ale diagnostyka i kontrole kondycji oferowane przez poszczególne z nich różnią się funkcjami i stanem dojrzałości, czasami w zależności od platformy systemu operacyjnego, jak wyjaśniono w następnej sekcji.

Dodatkowe zasoby

PoprzedniNastępny