Mikroserwisy: Różnice pomiędzy wersjami
m (cleanup bibliografii i rotten links) |
mNie podano opisu zmian |
||
| (Nie pokazano 2 pośrednich wersji utworzonych przez tego samego użytkownika) | |||
| Linia 10: | Linia 10: | ||
==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== | ||
| Linia 28: | Linia 28: | ||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | <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), ''Mikrousługi vs monolit. Nie zawsze architektura oparta o mikroserwisy to najlepszy pomysł'', cloudforum | * 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), ''Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation'', IEEE Cloud Computing. Vol 4, nr 5 | * Taibi D. (red.) (2017), ''Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation'', IEEE Cloud Computing. Vol 4, nr 5 | ||
</noautolinks> | </noautolinks> | ||
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
