LITMIR.BIZ

      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:

      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:

      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ć

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