Mikroserwisy w akcji. Отсутствует
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.
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.
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/).
■ 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