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

Ale we frontendzie to może być trudne do osiągnięcia. Typowy frontend nad aplikacją mikroserwisową nadal może być monolitem, który jest wdrażany i zmieniany jako pojedynczy byt (rys. 3.21). Specjalistyczne frontendy, w szczególności aplikacje mobilne, często wymagają dedykowanych zespołów, co powoduje, że praktycznie niemożliwe jest zbudowanie kompleksowej własności funkcjonalności.

36935.jpg

      Rysunek 3.21. Typowy klient frontendowy w aplikacji mikroserwisowej może być monolitem

      UWAGA  Więcej będziemy mówić o kompleksowej własności (i dlaczego jest to pożądane i korzystne przy opracowywaniu aplikacji mikroserwisowych) w rozdziale 13.

      3.6.2. Mikrofrontendy

      W miarę jak aplikacje frontendowe będą coraz większe, będą napotykać te same problemy z koordynacją i tarciami, które nękają rozwój wielkoskalowych backendów. Byłoby wspaniale, gdyby programowanie frontendu można podzielić w ten sam sposób co usługi backendu. Wyłaniającym się trendem w aplikacjach internetowych są mikrofrontendy – udostępniające fragmenty interfejsu użytkownika jako niezależnie spakowane i możliwe do wdrożenia komponenty, które można łączyć. Na rysunku 3.22 pokazano to podejście.

37110.jpg

      Rysunek 3.22. Interfejs użytkownika złożony z niezależnych fragmentów

      Umożliwia to każdemu zespołowi mikroserwisowemu dostarczanie kompleksowych funkcjonalności. Jeśli mamy na przykład zespół zajmujący się zleceniami, może on niezależnie dostarczać zarówno mikroserwisy zarządzania zleceniami, jak i interfejs internetowy wymagany do składania zleceń i zarządzania nimi.

      Chociaż to podejście jest obiecujące, to ma jednak wiele wyzwań:

      ■ wizualna i interakcyjna spójność między różnymi komponentami wymaga nietrywialnego wysiłku w celu zbudowania i utrzymania poszczególnych komponentów i zasad projektowania;

      ■ rozmiar (a tym samym czas ładowania) może być trudny w zarządzaniu podczas ładowania kodu JavaScript z wielu źródeł;

      ■ przeładowania i odświeżenia interfejsu mogą zmniejszać ogólną wydajność.

      Mikrofrontendy nie są jeszcze powszechne, natomiast obecnie są stosowane różne inne podejścia techniczne, w tym:

      ■ udostępnianie fragmentów UI jako komponentów webowych z przejrzystym interfejsem opartym na zdarzeniach;

      ■ integrowanie fragmentów przez zawieranie ich po stronie klienta;

      ■ używanie elementów iframe do udostępniania mikroaplikacji w oddzielnych sekcjach ekranu;

      ■ integrowanie komponentów w warstwie pamięci podręcznej za pomocą Edge Side Includes (ESI).

      Aby dowiedzieć się więcej, dobrze zacząć od Micro Frontends (https://micro-frontends.org/) oraz Project Mosaic Zalando (https://www.mosaic9.org/).

PODSUMOWANIE

      ■ Indywidualnie mikroserwisy są wewnętrznie podobne do aplikacji monolitycznych.

      ■ Aplikacja mikroserwisowa jest jak sąsiedztwo – jej ostateczny kształt nie jest opisany, ale zamiast tego jest oparty na pewnych zasadach i modelu koncepcyjnym wysokiego poziomu.

      ■ Zasady określające architekturę mikroserwisową odzwierciedlają cele organizacyjne i informują o praktykach zespołu.

      ■ Plan architektoniczny powinien zachęcać do rozwoju w dobrym kierunku, a nie narzucać podejścia do całej aplikacji.

      ■ Aplikacja mikroserwisowa składa się z czterech warstw: platformy, usługi, granicy i klienta.

      ■ Warstwa platformy zapewnia narzędzia, elementy i infrastrukturę, aby wspierać rozwój mikroserwisów zorientowanych na produkt.

      ■ Komunikacja synchroniczna jest często pierwszym wyborem w aplikacji mikroserwisowej i najlepiej nadaje się do interakcji opartej na poleceniach, ale ma też wady i może zwiększać powiązanie i słabość.

      ■ Komunikacja asynchroniczna jest bardziej elastyczna i ułatwia szybką ewolucję systemu kosztem dodatkowej złożoności.

      ■ Typowe asynchroniczne wzorce komunikacyjne obejmują kolejki oraz publish-subscribe.

      ■ Warstwa granicy stanowi fasadę dla aplikacji mikroserwisowej odpowiednią dla zewnętrznych użytkowników.

      ■ Typowe rodzaje granic obejmują bramy API i bramy consumer-driven, takie jak GraphQL.

      ■ Aplikacje klienckie, takie jak strony internetowe i aplikacje mobilne, wchodzą w interakcję z backendem za pośrednictwem warstwy granicznej.

      ■ Isnieje ryzyko, że klienci mogą stać się monolitami, natomiast zaczynają powstawać techniki stosowania zasad mikroserwisowych w aplikacjach frontendowych.

      4. Projektowanie nowych funkcjonalności

      Niniejszy rozdział dotyczy:

      ■ określania zakresu mikroserwisów w oparciu na zdolnościach biznesowych i przypadkach użycia;

      ■ przypadków, w których należy określać zakres mikroserwisów, aby reprezentowały zdolności techniczne;

      ■ dokonywania wyborów projektowych, gdy granice usług są niejasne;

      ■ skutecznego określania zakresu, gdy mikroserwisy są w posiadaniu wielu zespołów.

      Projektowanie nowej funkcjonalności w aplikacji mikroserwisowej wymaga starannego i dobrze uzasadnionego określenia zakresu mikroserwisów. Musimy zdecydować, czy zbudować nowe, czy rozszerzyć istniejące usługi, gdzie znajdują się granice między tymi usługami, oraz w jaki sposób te usługi powinny współpracować.

      Dobrze zaprojektowane usługi mają trzy kluczowe cechy: są odpowiedzialne za jedną zdolność, niezależnie wdrażane i wymienne. Jeśli nasze mikroserwisy mają niewłaściwe granice lub są zbyt małe, mogą stać się ściśle powiązane, co utrudnia ich samodzielne wdrażanie lub zastępowanie. Ścisłe powiązanie zwiększa wzajemny wpływ, a tym samym ryzyko zmiany. Jeśli nasze usługi są zbyt duże – biorąc na siebie zbyt dużą odpowiedzialność – stają się mniej spójne, co zwiększa tarcia w trakcie rozwoju.

      Nawet jeśli za pierwszym razem uzyskamy odpowiednią dokładność, musimy pamiętać, że wymagania i potrzeby najbardziej złożonych aplikacji będą ewoluować w miarę upływu czasu, a podejścia, które sprawdzały się na wczesnym etapie życia tej aplikacji, nie zawsze mogą być odpowiednie. Żaden projekt nie jest idealny zawsze.

      W dłużej działających aplikacjach (i większych firmach) napotkamy dodatkowe wyzwania. Nasze usługi mogą polegać na sieci zależności zarządzanych przez wiele zespołów – inżynier w danym zespole może musieć zaprojektować spójną funkcjonalność, korzystając z usług, które niekoniecznie będą pod naszą kontrolą. Musimy wiedzieć, kiedy zrezygnować i migrować od usług, które nie spełniają już wymagań systemu w szerszym zakresie.

      W tym rozdziale przejdziemy przez proces projektowania nowej funkcjonalności za pomocą mikroserwisów. Wykorzystamy przykład do zbadania technik i praktyk, które można wykorzystać do kierowania projektowaniem łatwych do utrzymania mikroserwisów zarówno w nowych, jak i już działających aplikacjach mikroserwisowych.

      4.1. Nowa funkcjonalność w SimpleBanku

      Pamiętacie SimpleBank? Zespół wykonuje dobrą robotę – klienci

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