Скачать книгу

1.5. Nieprawidłowe decyzje dotyczące zakresu usług mogą wymagać złożonej i kosztownej refaktoryzacji w obrębie granic usług

      Każdy kto projektował API, wie, jak trudno osiągnąć takie cechy. Kontrakty są spoiwem między usługami. Z czasem kontrakty mogą ewoluować, ale jednocześnie muszą zachować wsteczną kompatybilność dla istniejących współpracowników. Te sprzeczne dążenia – między stabilnością a zmianą – są trudne do zarządzania.

      APLIKACJE MIKROSERWISOWE SĄ PROJEKTOWANE PRZEZ ZESPOŁY

      W większych firmach prawdopodobnie wiele zespołów będzie budować i uruchamiać aplikację mikroserwisową, z których każdy będzie odpowiedzialny za różne mikroserwisy. Każdy zespół może mieć własne cele, sposób pracy i cykl życia dostarczania. Projektowanie spójnego systemu może być trudne, gdy trzeba pogodzić harmonogramy i priorytety wielu niezależnych zespołów. Koordynacja rozwoju poważniejszych aplikacji mikroserwisowych będzie zatem wymagać porozumienia i uzgodnienia priorytetów oraz praktyk w wielu zespołach.

      APLIKACJE MIKROSERWISOWE SĄ SYSTEMAMI ROZPROSZONYMI

      Projektowanie aplikacji mikroserwisowych oznacza projektowanie systemów rozproszonych. W projektowaniu systemów rozproszonych pojawia się wiele błędnych założeń, takich jak:

      ■ sieć jest niezawodna;

      ■ opóźnienie jest zerowe;

      ■ przepustowość jest nieograniczona;

      ■ koszt transportu jest zerowy.

      Założenia, które można zastosować do systemów scentralizowanych, takie jak szybkość i niezawodność wywołań metod, w tych przypadkach są oczywiście nieodpowiednie i mogą prowadzić do złej, niestabilnej implementacji. Należy uwzględnić opóźnienia, niezawodność i spójność stanów w całym obszarze aplikacji.

      W aplikacji rozproszonej, gdzie dane o stanie aplikacji są rozmieszczone w wielu miejscach, spójność staje się wyzwaniem. Możemy nie mieć gwarancji kolejności operacji. Nie będzie można zapewnić gwarancji transakcyjnych podobnych do ACID, gdy działania mają miejsce w wielu usługach. Wpłynie to na projektowanie na poziomie aplikacji – należy się zastanowić, w jaki sposób usługa może działać w niespójnym stanie i jak wycofać się w przypadku niepowodzenia transakcji.

      1.2.2. Wyzwania związane z działaniem

      Podejście mikroserwisowe z natury mnoży możliwe miejsca awarii w systemie. Aby to zilustrować, wróćmy do narzędzia inwestycyjnego, o którym wspominaliśmy wcześniej. Na rysunku 1.6 są wskazane możliwe punkty awarii w tej aplikacji. Łatwo zauważyć, że w wielu miejscach coś może pójść nie tak i może mieć wpływ na normalne przetwarzanie zlecenia.

      Zastanówmy się, na jakie pytania należy odpowiedzieć, gdy aplikacja jest na etapie produkcji:

      ■ Jeśli coś pójdzie nie tak i zlecenie użytkownika nie zostanie złożone, to w jaki sposób ustalimy, gdzie doszło do błędu?

      ■ Jak wdrożyć nową wersję usługi bez wpływu na składanie zleceń?

      ■ Skąd wiadomo, które usługi miały zostać wywołane?

      ■ Jak sprawdzić, czy dane zachowanie działa poprawnie między wieloma usługami?

      ■ Co się stanie, gdy usługa będzie niedostępna?

      Zamiast eliminować ryzyko, mikroserwisy przenoszą te koszty na późniejszy etap cyklu życia systemu – zmniejszają tarcia w rozwoju, ale zwiększają złożoność sposobu wdrażania, weryfikacji i obserwacji działania aplikacji.

      Rysunek 1.6. Możliwe punkty awarii przy składaniu zlecenia sprzedaży

      Podejście mikroserwisowe sugeruje ewolucyjne podejście do projektowania systemu – umożliwia dodawanie nowych funkcjonalności niezależnie, bez zmiany istniejących usług. Minimalizuje to koszty i ryzyko zmian.

      Ale w samodzielnym systemie, który ciągle się zmienia, może być niezwykle trudno śledzić obraz całości, co sprawia, że diagnoza problemu i wsparcie są bardziej kłopotliwe. Kiedy coś pójdzie nie tak, musimy mieć jakiś sposób śledzenia zachowania się systemu (jakie usługi wywołał, w jakiej kolejności, jaki był wynik), ale potrzebujemy również sposobu, aby dowiedzieć się, jak system powinien się zachowywać.

      W mikroserwisach zatem napotykamy dwa operacyjne wyzwania: obserwowalność i wiele punktów awarii. Skupmy się na każdym z nich.

      OBSERWOWALNOŚĆ JEST TRUDNA DO OSIĄGNIĘCIA

      Na znaczenie przejrzystości zwróciliśmy uwagę w punkcie 1.1.2. Ale dlaczego jest to trudniejsze w aplikacjach mikroserwisowych? Jest tak, ponieważ musimy zrozumieć szerszy kontekst. Musimy go zebrać z wielu elementów układanki po to, żeby skorelować i połączyć dane, które generuje każda usługa, aby móc zrozumieć, co każda usługa robi w szerszym kontekście dostarczania wyników biznesowych. Poszczególne dzienniki usług zapewniają częściowy widok na działanie systemu, co jest pomocne, ale do pełnego zrozumienia całości potrzebne są zarówno mikroskop, jak i obiektyw szerokokątny.

      Ponadto, ponieważ uruchamiamy wiele aplikacji, w zależności od tego, jak zostały wdrożone, powiązania między podstawowymi parametrami infrastruktury – takimi jak wykorzystanie pamięci i procesora – a aplikacją mogą być mniej oczywiste. Te parametry nadal mogą być użyteczne, ale są mniej przydatne niż mogłyby być w systemie monolitycznym.

      ZWIĘKSZANIE LICZBY MIKROSERWISÓW ZWIĘKSZA LICZBĘ PUNKTÓW AWARII

      Prawdopodobnie nie będziemy zbytnimi pesymistami, jeśli powiemy, że wszystko, co może zawieść, zawiedzie. Ważne jest, żeby tak o tym myśleć – jeśli założymy słabość i niestabilność usług tworzących nasz system, to ułatwi nam to jego projektowanie, wdrażanie i monitorowanie i nie będziemy zaskoczeni, gdy coś pójdzie nie tak.

      Musimy się zastanowić, jak system będzie działał mimo awarii poszczególnych komponentów. Oznacza to, że indywidualne usługi będą musiały być bardziej niezawodne – pod względem sprawdzania błędów, działania w sytuacjach awaryjnych i powrotu do normalnej pracy – ale także to, że cały system powinien działać niezawodnie, nawet jeśli poszczególne komponenty nigdy nie są w 100% niezawodne.

      Rysunek 1.7. Kluczowe powtarzane etapy – projekt, wdrażanie i obserwacja – w cyklu życia mikroserwisu

      1.3. Cykl rozwojowy mikroserwisu

      Na poziomie poszczególnych usług każda z nich powinna wyglądać znajomo – nawet jeśli jest czymś mniejszym. Aby zbudować mikroserwis, będziemy korzystać z wielu takich samych frameworków i technik, które normalnie stosujemy podczas tworzenia aplikacji: frameworków aplikacji internetowych, baz danych SQL, testów jednostkowych, bibliotek itd.

      Na poziomie systemu wybór architektury dla mikroserwisu będzie miał znaczący wpływ na sposób projektowania i uruchamiania aplikacji. W tej książce skupimy się na trzech kluczowych etapach cyklu życia aplikacji mikroserwisowej: projektowania usług, wdrażania ich do produkcji i obserwowania ich zachowania. Ten cykl przedstawiono na rysunku 1.7.

      Podejmowanie dobrze uzasadnionych decyzji na każdym z tych trzech etapów pomoże budować aplikacje, które będą odporne nawet w obliczu zmieniających się wymagań i rosnącej złożoności. Przejdźmy przez każdy etap i rozważmy kroki, które należy podjąć, aby dostarczyć

Скачать книгу