Mikroserwisy: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
(LinkTitles.)
m (Dodanie TL;DR)
Linia 14: Linia 14:
}}
}}
'''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ą<ref>S. Flower, 2017, s. 19</ref>. 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ą.
'''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ą<ref>S. Flower, 2017, s. 19</ref>. 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==
==Architektura mikroserwisów==

Wersja z 14:55, 24 wrz 2023

Mikroserwisy
Polecane artykuły

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[4].

Zalety architektury mikroserwisów

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

  • 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.

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. P. Burakowski, 2019
  5. S. Newman, 2015, s. 22-26

Bibliografia

Autor: Justyna Dominik