Mikroserwisy

Z Encyklopedia Zarządzania
Wersja do druku nie jest już wspierana i może powodować błędy w wyświetlaniu. Zaktualizuj swoje zakładki i zamiast funkcji strony do druku użyj domyślnej funkcji drukowania w swojej przeglądarce.

Mikroserwisy - (nazywane również mikrousługami) to małe aplikacje, które wykonują jedno powierzone im zadanie. Każdy z mikroserwisów ma pojedynczą odpowiedzialność, można go łatwo wymienić, rozwijać, niezależnie używać oraz instalować. Mikroserwis jest częścią większego i bardziej złożonego systemu, działa on wspólnie z innymi mikroserwisami w efekcie tworząc aplikację użytkową[1]. Systemy zbudowane z pomocą mikrousług nazywamy systemami opartymi o architekturę mikroserwisów. Przeciwieństwem tego wzorca są aplikacje zbudowane w oparciu o architekturę monolityczną.

TL;DR

Mikroserwisy to małe aplikacje, które wykonują jedno zadanie. Są częścią większego systemu i mogą być łatwo wymieniane i rozwijane. Architektura mikroserwisów polega na podziale aplikacji na mniejsze usługi, które współpracują ze sobą. Mikroserwisy mają swoje własne bazy danych i komunikują się za pomocą protokołu HTTP. W przeciwieństwie do aplikacji monolitycznych, mikroserwisy mają wiele korzyści, takich jak różnorodność technologii, odporność na błędy, skalowanie i redukcja złożoności.

Architektura mikroserwisów

Główną ideą mikrousług jest podział monolitycznej aplikacji na zbiór mniejszych usług, które stale pozostają ze sobą w relacji. Mikrousługa jest aplikacją, która ma swoją architekturę, logikę biznesową i adaptery[2]. Każda z nich zasadniczo składa się z trzech elementów: strony klienta, kodu odpowiadającego za działanie serwisu oraz sposobu, w jaki przechowywane są dane. Część mikroserwisu odpowiadająca za stronę klienta jest interfejsem programowania aplikacji (ang. API) z określonymi punktami końcowymi (ang. endpoints). Interfejs zaprogramowany we właściwy sposób zapewnia łatwe i skuteczne komunikowanie się z mikrousługami, sprawiając, że wysyłane przez klienta żądania trafiają do odpowiednich punktów końcowych API[3]. We wzorcu architektury opartej o mikrousługi relacja między bazą danych, a aplikacją wygląda nieco inaczej. Mikroserwisy nie posiadają jednego, wspólnego schematu bazy danych, a każda usługa ma swój własny[2]. Mikrousługi komunikują się między sobą za pomocą mechanizmu zdalnego wołania procedur (ang. remote procedure call). Stosowane protokoły zależą od wyborów na poziomie architektury. Najcześciej stosowanym protokołem w komunikacji między mikroserwisami jest protokół HTTP[3].

Mikroserwisy vs. monolit

Podstawową różnicą między aplikacją zbudowaną w oparciu o mikroserwisy, a aplikacją monolityczną jest fakt, iż monolityczna aplikacja wszystkie cechy i funkcje zawiera w jednej aplikacji opartej o ten sam kod. ponadto aplikacje monolityczne są instalowane w tym samym czasie, a każdy serwer jest hostem dla ich kopii. Podejście to jest różne od podejścia aplikacji opartej o mikroserwisy, ponieważ tu każda mikrousługa ma swoją funkcjonalność, cechę i kod. Dodatkowo każda z nich działa wspólnie z innymi mikrousługami w ekosystemie mikroserwisów realizując określoną część funkcjonalną aplikacji.

Zalety architektury mikroserwisów

Istnieje wiele korzyści wynikających z zastosowania architektury mikroserwisów, poniżej przedstawiono kilka z nich[2][4]:

  • Niejednorodność technologii - w systemie, w którym wiele usług współpracuje między sobą w implementacji każdej z nich można wykorzystać inną technologię. Umożliwia to wybór narzędzi odpowiednich dla określonego zadania oraz sprzyja przyswajaniu i nauce nowych technologii.
  • Odporność na błędy - w sytuacji, w której jedna z usług ulegnie awarii problem można wyizolować i zająć się naprawą, natomiast reszta mikrousług może kontynuować swoją pracę. Taka sama awaria w usłudze monolitycznej powoduje całkowity brak działania aplikacji.
  • Skalowanie - w dużych aplikacjach monolitycznych wszystkie usługi muszą być skalowane razem. W przypadku mikroserwisów, skalujemy tylko te usługi, które tego wymagają.
  • Dopasowanie do organizacji pracy - rozwijanie każdej usługi odbywa się w obrębie jednego zespołu, który w pełni koncentruje się tylko na jednej części całej aplikacji.
  • Redukcja złożoności - wprowadzenie architektury mikroserwisów rozwiązuje problem złożoności aplikacji. Rozbicie jej na szereg mikrousług łatwych w zarządzaniu, szybszych w opracowaniu, utrzymaniu i zrozumieniu powoduje jej automatyczny spadek.
  • Możliwość niezależnego wdrażania każdej usługi.


Mikroserwisyartykuły polecane
SQLTopologia sieciSieć komputerowaKontrola wersjiUMLProgramowanie paramiProgramowanie strukturalneInterfejsTeamwareZdolność absorpcyjna

Przypisy

  1. S. Flower, 2017, s. 19
  2. 2,0 2,1 2,2 J. Frankowski, 2018
  3. 3,0 3,1 S. Flower, 2017, s. 28-31
  4. S. Newman, 2015, s. 22-26

Bibliografia

  • Flower S. (2017), Mikrousługi. Wdrażanie i standaryzacja systemów w organizacji inżynierskiej, Helion, Gliwice
  • Frankowski J. (2018), Mikrousługi vs monolit. Nie zawsze architektura oparta o mikroserwisy to najlepszy pomysł, cloudforum
  • Newman S. (2015), Budowanie mikrousług. Wykorzystaj potencjał architektury usług!, Helion, Gliwice
  • Taibi D. (red.) (2017), Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation, IEEE Cloud Computing. Vol 4, nr 5

Autor: Justyna Dominik