Mikroserwisy: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
(LinkTitles.) |
||
| Linia 13: | Linia 13: | ||
</ul> | </ul> | ||
}} | }} | ||
'''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ą. | ||
==Architektura mikroserwisów== | ==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<ref name="J. Frankowski, 2018">J. Frankowski, 2018</ref>. 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<ref name="S. Flower, 2017, s. 28-31">S. Flower, 2017, s. 28-31</ref>. 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<ref name="J. Frankowski, 2018"/>. 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<ref name="S. Flower, 2017, s. 28-31"/>. | 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<ref name="J. Frankowski, 2018">J. Frankowski, 2018</ref>. 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<ref name="S. Flower, 2017, s. 28-31">S. Flower, 2017, s. 28-31</ref>. 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<ref name="J. Frankowski, 2018"/>. 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]]<ref name="S. Flower, 2017, s. 28-31"/>. | ||
<google>t</google> | <google>t</google> | ||
| Linia 25: | Linia 25: | ||
Istnieje wiele korzyści wynikających z zastosowania architektury mikroserwisów, poniżej przedstawiono kilka z nich<ref name="J. Frankowski, 2018"/><ref>S. Newman, 2015, s. 22-26</ref>: | Istnieje wiele korzyści wynikających z zastosowania architektury mikroserwisów, poniżej przedstawiono kilka z nich<ref name="J. Frankowski, 2018"/><ref>S. Newman, 2015, s. 22-26</ref>: | ||
* '''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. | * '''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. | * '''[[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ą. | * '''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. | * '''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. | * '''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. | ||
| Linia 36: | Linia 36: | ||
==Bibliografia== | ==Bibliografia== | ||
* Burakowski P. (2019), [https://thestory.is/pl/journal/mikroserwisy-co-to-jak-pomagaja-w-tworzeniu-aplikacji/ ''Mikroserwisy: jak ułatwiają prowadzenie biznesu i tworzenie aplikacji''], thestory. is | * Burakowski P. (2019), [https://thestory.is/pl/journal/mikroserwisy-co-to-jak-pomagaja-w-tworzeniu-aplikacji/ ''Mikroserwisy: jak ułatwiają prowadzenie biznesu i tworzenie aplikacji''], thestory. is | ||
* Flower S. (2017), ''Mikrousługi. Wdrażanie i standaryzacja systemów w organizacji inżynierskiej'', Helion, Gliwice | * Flower S. (2017), ''Mikrousługi. Wdrażanie i [[standaryzacja]] systemów w organizacji inżynierskiej'', Helion, Gliwice | ||
* Frankowski J. (2018), [https://www.cloudforum.pl/2018/08/10/mikrouslugi-vs-monolit-nie-zawsze-architektura-oparta-o-mikroserwisy-to-najlepszy-pomysl/ ''Mikrousługi vs monolit. Nie zawsze architektura oparta o mikroserwisy to najlepszy pomysł''], cloudforum | * Frankowski J. (2018), [https://www.cloudforum.pl/2018/08/10/mikrouslugi-vs-monolit-nie-zawsze-architektura-oparta-o-mikroserwisy-to-najlepszy-pomysl/ ''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 | * Newman S. (2015), ''Budowanie mikrousług. Wykorzystaj [[potencjał]] architektury usług!'' Helion, Gliwice | ||
* Taibi D. (red.) (2017), [https://ieeexplore.ieee.org/abstract/document/8125558, ''Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation''], "IEEE Cloud Computing. Vol 4", nr 5 | * Taibi D. (red.) (2017), [https://ieeexplore.ieee.org/abstract/document/8125558, ''Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation''], "IEEE Cloud Computing. Vol 4", nr 5 | ||
[[Kategoria:Informatyka]] | [[Kategoria:Informatyka]] | ||
{{a|Justyna Dominik}} | {{a|Justyna Dominik}} | ||
Wersja z 06:56, 20 maj 2020
| 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ą.
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
Bibliografia
- Burakowski P. (2019), Mikroserwisy: jak ułatwiają prowadzenie biznesu i tworzenie aplikacji, thestory. is
- 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
