Proszę o wyjaśnienie monolitu i mikroserwisu.

Question

Siemka :). Może mi ktoś wytłumaczyć swoimi słowami czym są oraz czym się różnią monolity od mikroserwisów? Wiem, że dopóki sam tego nie pojmę na chłopski rozum to za cholere nie wejdzie mi to do głowy. Przykład: robię prostą stronkę, back-end w javie, front osobno w react. Jak to nazwać? Czy jest to zwyczajny wzorzec CRUD? A może MVC? Kiedy mogę nazwać to mikroserwisem a kiedy monolitem? Przykład:

Answer 1

To są koncepty na różnych skalach projektowania.

Czy jest to zwyczajny wzorzec CRUD? A może MVC?

MVC to wzorzec tworzenia aplikacji z interfejsem użytkownika. Samo zdanie "aplikacja z reactem" nie mówi czy używasz MVC czy nie; ale jeśli tak, to sama warstwa reacta to po prostu część komponentu V(iew).

CRUD to ogólny termin na styl aplikacji/systemów służących do przeglądania i modyfikowania danych; osobiście w ogóle tego bym nie nazwał wzorcem. W każdym razie to zupełnie inny podział; zdanie "CRUD czy MVC" nie ma sensu. 

Kiedy mogę nazwać to mikroserwisem a kiedy monolitem? 

A to jest podział na zupełnie innym, większym poziomie tworzenia złożonych systemów. Tak, prosta strona w javie technicznie jest "monolitem", ale w tej skali takiej terminologii i tak się nie używa. Mikroserwisy dotyczą znacznie większych systemów, gdzie podział na komponenty jest realizowany nie przez logiczną organizację kodu jednej aplikacji, lecz na podział na wiele aplikacji realizujących konkretne cele. Na przykład... gdybyś miał kilka stron, ale wszystkie ze współdzielonym logowaniem do kont - jeśli logikę dotyczącą zarządzania użytkownikami zawrzesz w osobnej aplikacji z którą wewnętrznie komunikują się wszystkie strony, to byłby to jeden mikroserwis.

Comments

Powoli zaczynam ogarniać :D. Mam zamiar napisać interfejs dla użytkownika w React, coś w rodzaju sklepu. Będzie on się odwoływał właśnie do tego Tomcata ze Spring Boota który zawiera kontrolery i modele, wyciągał co potrzebne z bazy danych. Rozumiem, że to już można nazwać wzorcem MVC tak :)?

Drugie pytanko, fajnie to wytłumaczyłeś z mikroserwisem. Powiedz mi jeszcze czy dobrze to interpretuje. Takie banalne kilkustronicowe web-apki gdzie cała logika (logowanie, security, DB, sklep) jest umieszczona na JEDNYM serwerze, jak u mnie na Tomcacie nazywamy monolitami. Duże aplikacje nazywamy mikroserwisami gdy każda część logiki działa osobno na innym serwerze, tak?

---

to czy poszczególne mikroserwisy działają na wielu serwerach nie ma znaczenia, to jest architektura na poziomie aplikacji, a nie sprzętowej.

Fakt, że w dużych apkach najczęściej właśnie tak jest, że usługi są rozsiane po wielu serwerach ale wcale nie oznacza to, że 1 serwer == 1 usługa...

Mikroserwisy odpowiadają za poszczególne elementy biznesowe, na przykład w takim sklepie online możesz mieć serwis odpowiedzialny za logowanie, przechowywanie danych usera, obsługę płatności, obsługę koszyka, rabatów, historii zakupów itp. itd. Niektóre duże aplikacje są rozsiane na setki mikroserwisów.

Generalnie zaletą mikroserwisów w backendzie jak również mikrofrontendów jest to, że można bardzo łatwo podzielic odpowiedzialność za poszczególne klocki do odpowiednich zespołów, latwiej się to wdraza - ewentualne problemy wdrożeniowe itp. nie dotkną (najczęściej) całej aplikacji lecz tylko jakąś jej część, łatwiej się to skaluje, łatwiej zarządza monitoringiem (o czym wiele osób tu na forum zapomina, napisanie apki to jedno, ale jej utrzymanie i monitoring awarii to druga sprawa... bardzo istotna).

Pracuję na codzień w takiej właśnie architekturze aplikacji i przyznam, że jest to bardzo fajny kierunek dający naprawdę wiele zalet. Generalnie coraz więcej firm przechodzi w apkach na takie rozwiązania. Oczywiście nie jest to architektura dla małej strony czyh nawet małego esklepu... mówimy tu o większych aplikacjach.

W mikroserwisach możesz ładnie rozdzielić pelną odpowiedzialność, nie tylko za logikę biznesową ale również za trzymanie danych, bazy danych, kwestie RODO itp. itd. Przechowujesz tylko te dane, które potrzebuje Twój serwis lub pobierasz od innych serwisów tylko niezbędne dane. Nie interesujesz się jako developer/zespół wszystkimi danymi w aplikacji.