Mikroserwisy: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
mNie podano opisu zmian |
||
| (Nie pokazano 13 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''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. | |||
'''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> | |||
<google>n</google> | |||
==Mikroserwisy vs. monolit== | ==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 | 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== | ==Zalety architektury mikroserwisów== | ||
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. | ||
* '''Możliwość niezależnego wdrażania każdej usługi.''' | * '''Możliwość niezależnego wdrażania każdej usługi.''' | ||
{{infobox5|list1={{i5link|a=[[SQL]]}} — {{i5link|a=[[Topologia sieci]]}} — {{i5link|a=[[Sieć komputerowa]]}} — {{i5link|a=[[Kontrola wersji]]}} — {{i5link|a=[[UML]]}} — {{i5link|a=[[Programowanie parami]]}} — {{i5link|a=[[Programowanie strukturalne]]}} — {{i5link|a=[[Interfejs]]}} — {{i5link|a=[[Teamware]]}} — {{i5link|a=[[Zdolność absorpcyjna]]}} }} | |||
==Przypisy== | ==Przypisy== | ||
| Linia 35: | Linia 27: | ||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | |||
* 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), | * 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 | * Newman S. (2015), ''Budowanie mikrousług. Wykorzystaj potencjał architektury usług!'', Helion, Gliwice | ||
* Taibi D. (red.) (2017) | * Taibi D. (red.) (2017), ''Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation'', IEEE Cloud Computing. Vol 4, nr 5 | ||
[[Kategoria: | </noautolinks> | ||
[[Kategoria:Internet]] | |||
{{a|Justyna Dominik}} | {{a|Justyna Dominik}} | ||
{{#metamaster:description|Mikroserwisy to małe aplikacje, które wykonują jedno zadanie. Łatwo wymienialne, rozwijane i niezależnie używane. Tworzą systemy mikroserwisowe.}} | |||
Aktualna wersja na dzień 08:37, 12 sty 2024
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.
| Mikroserwisy — artykuły polecane |
| SQL — Topologia sieci — Sieć komputerowa — Kontrola wersji — UML — Programowanie parami — Programowanie strukturalne — Interfejs — Teamware — Zdolność absorpcyjna |
Przypisy
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
