Mikroserwisy / Webserwisy

Programowanie w Springu nie kończy się na tworzeniu aplikacji webowych, których komunikacja odbywa się tylko między przeglądarką, a serwerem, pod którym znajduje się jedna baza danych.

Mikroserwisy

Obecnie popularne są systemy oparte o architekturę rozproszoną, gdzie owszem na końcu najczęściej znajduje się aplikacja webowa, ale po drugiej stronie (po stronie backendu) znajduje się nie jeden "software przetwarzający dane", a cała sieć współpracujących usług na osobnych maszynach, które posiadają swoje niezależne bazy danych.

W takiej architekturze każda maszyna jest najczęściej wirtualnie wydzieloną przestrzenią w ramach dużej chmury obliczeniowej, np. AWS, czyli Amazon Web Services. Usługi, które działają na odseparowanych maszynach mają swoje dedykowane zadania do wykonania. I tak na przykład jeśli w ten sposób tworzymy system zarządzania rejestracją biletów na wydarzenia kulturalne, możemy jedną usługą na jednej maszynie zarządzać rejestracją użytkowników, a na drugiej obsługiwać zakup biletów. Zalety takiego rozwiązania?

• Każda usługa ma swoją wąską specjalizację, przez co wyłączenie lub zepsucie się jednej z nich nie deaktywuje całego systemu.
• Można dowolnie skalować daną usługę, czyli zwiększać jej moc obliczeniową, jeśli jest bardziej obciążona niż pozostałe elementy systemu. Zwiekszanie mocy odbywa się przez dokładanie kolejnych maszyn z kodem tej samej usługi (nowe instancje usługi), co powoduje, że w krótkim czasie taki powiekszony zestaw jest w stanie obsłużyć więcej zadań.
• Aktualizacja kodu jednej usługi nie wymaga wdrożenia na nowo całego systemu.

Usługi takie nazywamy mikrousługami, co po przetłumaczeniu na angielski oznacza bardzo popularne ostatnio określenie - microservices. Z tego rozwiązania korzysta znany serwis streamingowy Netflix. Swego czasu napisaliśmy nawet artykuł w tym temacie Netflix postawił na Spring Boota, który pokazuje jak ważny jest Spring i Spring Boot w dzisiejszym świecie nowoczesnych technologii.

Webserwisy

Webserwis to dosyć szeroko pojęte określenie usługi sieciowej, czyli usługi udostępnianej nam zdalnie przez sieć. Na przykład, pod konkretnym adresem sieciowym może istnieć usługa zwracająca wyniki notowań giełdowych i my odpowiednią metodą podłączymy się do tej usługi i pobierzemy wyniki. Jak to zrobić? Tutaj wszystko zależy od tego z jakim rodzajem webserwisu mamy do czynienia. Dawniej bardzo popularnym rozwiązaniem były usługi oparte o protokół SOAP, dziś rządzi i dzieli coś co ogólnie nazywamy REST.

W przypadku SOAP-a było tak, że chcąc wywołać zdalną metodę musieliśmy najpierw zaznajomić się i dospasować do definicji usługi, która była wykonana w pliku WSDL. Dopasowanie wszystkich parametrów po stronie wywołującego i tego, który udostępniał usługę było dosyć problematyczne. Obecnie nie potrzebujemy dodatkowych plików WSDL i na szczęście możemy skupić się na źródle danych. Choć powiedzmy sobie uczciwie, że nie zawsze tak jest. Możemy bowiem trafić do projektu, który nie jest najświeższy technologicznie i będzie się trzeba nauczyć starego podejścia, żeby zaprogramować kod. Skupmy się jednak teraz na bardziej nowoczesnym rozwiązaniu.

Przy podejściu typu REST mamy do czynienia z zasobem. To on jest najważniejszy i to na niego ukierunkowane są wszelkie działania. W naszym przykładzie taki zasobem jest wynik notowań giełdowych, który może zostać nam wystawiony do pobrania pod konkretnym adresem URL, do którego odwołamy się zwyczajnie metodą HTTP. Wygląda to tak samo jakbyśmy z frontu naszej aplikacji chcieli odwołać się do adresu na naszym serwerze, gdybyśmy sami zwracali takie wyniki. Tyle, że tutaj dostawcą jest ktoś inny i może znajdować się w dowolnym miejscu na świecie.

W przypadku webserwisów opartych o REST kierujemy się podobnymi zasadami, co te spisane w punkcie numer 5 na naszej mapie - REST. Można zapytać - jak to jest możliwe, że webserwis będący zdalną usługą opiera się na tym samym mechanizmie co nasza lokalna aplikacja webowa? Otóż budując aplikację webową de facto sami wystawiamy usługi REST, w postaci punktów dostępowych (endpointów), które następnie są wywoływane przez klienta, jakim jest frontend naszej aplikacji. Nie ma to znaczenia czy usługi REST są przez nas napisane i podłączamy się do nich z naszego frontendu, czy też dostarcza je inna firma i podłączamy się do nich z naszego backendu.

Na koniec jeszcze jedna ciekawostka w temacie samych aplikacji webowych. Dzięki temu, że nasz backend jest odseparowany od frontendu, może "stać" na zupełnie innej maszynie niż frontend. Może też być połączeniem kilku usług komunikujących się ze sobą w ramach jednego ekosystemu mikroserwisów! Appa Notka. Jeśli chcesz dowiedzieć się więcej w temacie mikrousług (z ang. microservices), polecamy zapoznać się z następującymi linkami:

Wprowadzenie do architektury mikroserwisów
Mikroserwisy - Dlaczego warto
Mikroserwisy w Springu
Consul - Dostęp do usług w chmurze
Netflix Zuul - Jak to działa Mapa umiejętności programisty Java