Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 18

Część 1
Stan rzeczy
1. Projektowanie i uruchamianie mikroserwisów
1.3. Cykl rozwojowy mikroserwisu
1.3.3. Obserwowanie mikroserwisów

Оглавление

W tym punkcie omówimy przejrzystość i obserwowalność. Podczas produkcji musimy wiedzieć, co się dzieje. Znaczenie tego jest dwojakie:

■ chcemy aktywnie identyfikować i modyfikować krytyczne elementy w systemie;

■ potrzebujemy rozumieć, jak zachowuje się system.

Dokładne monitorowanie jest znacznie trudniejsze w przypadku aplikacji mikroserwisowej, ponieważ pojedyncze transakcje mogą obejmować wiele różnych usług; technicznie heterogeniczne usługi mogą generować dane w niedających się pogodzić formatach, a całkowita objętość danych operacyjnych będzie prawdopodobnie znacznie większa niż w pojedynczej aplikacji monolitycznej. Ale jeśli potrafimy zrozumieć, jak działa nasz system i monitorować to dokładnie, to mimo tej złożoności będziemy w stanie dokonać w nim skutecznych zmian.


IDENTYFIKACJA I MODYFIKOWANIE POTENCJALNIE KRYTYCZNYCH ELEMENTÓW SYSTEMU

Systemy ulegają awarii niezależnie od tego, czy zostały popełnione błędy, wystąpiły błędy środowiska wykonawczego, awarie sieci, problemy ze sprzętem. Z biegiem czasu koszty eliminacji nieznanych pomyłek i błędów stają się wyższe niż koszty szybkiego i skutecznego reagowania w momencie ich wystąpienia.

Systemy monitorowania i ostrzegania pozwalają diagnozować problemy i określać przyczyny awarii. Warto mieć zautomatyzowane mechanizmy reagujące na alarmy, które będą tworzyć nowe instancje kontenerów w różnych centrach danych lub reagować na problemy z obciążeniem, zwiększając liczbę uruchomionych wystąpień usługi.

Aby zminimalizować konsekwencje tych awarii i zapobiec ich kaskadowaniu w całym systemie, musimy móc projektować zależności między usługami w sposób, który pozwoli na częściową degradację. Awaria jednej usługi nie powinna zdestabilizować całej aplikacji. Ważne jest, aby zastanowić się nad możliwymi punktami awarii w swojej aplikacji, mieć na uwadze to, że awaria kiedyś nastąpi i odpowiednio się do niej przygotować.


ZROZUMIENIE ZACHOWANIA SETEK USŁUG

Aby zrozumieć zachowanie swoich usług, należy nadawać priorytet przejrzystości w ich projektowaniu i wdrażaniu. Gromadzenie dzienników i danych oraz ujednolicanie ich w celach analitycznych i ostrzegawczych pozwala zbudować pojedyncze źródło prawdy, do którego można się odwoływać podczas monitorowania i badania zachowania systemu.

Jak wspomniano w punkcie 1.3.2, możemy standaryzować i upraszczać wszystko oprócz unikalnej zdolności, którą oferuje każda usługa. Potraktujmy tę usługę jako cebulę. W środku tej cebuli mamy unikalne zdolności biznesowe oferowane przez tę usługę. W otoczeniu tego znajdują się inne instrumenty: wskaźniki biznesowe, dzienniki aplikacji, dane operacyjne i wskaźniki infrastrukturalne, które umożliwiają obserwowanie tej zdolności biznesowej. Za pośrednictwem tych warstw można prześledzić każde żądanie do systemu. Następnie dane zebrane z tych warstw można przesłać do operacyjnego centrum danych w celu analizy i alarmowania. Zostało to zilustrowane na rysunku 1.11.

UWAGA  W części 4 omówimy, jak zbudować system monitorowania mikroserwisów, zbierać odpowiednie dane i je wykorzystywać, aby stworzyć żywy model dla złożonej aplikacji mikroserwisowej.

Rysunek 1.11. Mikroserwis oferujący zdolność biznesową otoczony warstwami instrumentariów, przez które są do niego przekazywane żądania i jego odpowiedzi wraz z danymi zebranymi z procesu kierowanymi do operacyjnego centrum danych


Mikroserwisy w akcji

Подняться наверх