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

Warstwa klienta, podobnie jak warstwa prezentacji w architekturze trójwarstwowej, udostępnia użytkownikom interfejs do aplikacji. Oddzielenie tej warstwy od tych pod nią pozwala na tworzenie interfejsów użytkownika w sposób szczegółowy i zaspokajanie potrzeb różnych typów klientów. Oznacza to również, że możemy rozwijać frontend niezależnie od funkcjonalności backendu. Jak wspomniano w poprzedniej części, aplikacja może wymagać obsługi wielu różnych klientów: urządzeń mobilnych, witryn internetowych, zarówno wewnętrznych, jak i zewnętrznych, z których każdy ma inne możliwości i ograniczenia technologiczne.

Nie jest typowe dla pojedynczego mikroserwisu udostępnianie swojego własnego interfejsu. Zazwyczaj funkcjonalności udostępnione danemu zbiorowi użytkowników są szersze niż możliwości pojedynczej usługi. Na przykład pracownicy administracyjni SimpleBanku mogą zajmować się zarządzaniem zleceniami, konfiguracją rachunku, zgodami, podatkami itd. Obejmuje to zagadnienia przekrojowe: uwierzytelnianie, dzienniki inspekcji, zarządzanie użytkownikami – z pewnością nie są to zdolności oferowane przez usługę obsługi zleceń czy rachunku.

3.6.1. Monolity frontendowe

Nasz backend jest prosty do podzielenia na niezależnie wdrażalne i utrzymywane usługi – chociaż do przejścia wciąż mamy jeszcze 10 rozdziałów. 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/).

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.