Witam, Mógłby ktoś wytłumaczyć na czym polega tworzenie aplikacji opartej na tej architekturze?
Może macie jakieś fajne blogi lub artykuły, które poruszają to zagadnienie i pokazują przykładowe aplikacje?
0
5
Zdecydowanie warto przeczytać książkę podlinkowaną wyżej. W dużym skrócie, chodzi o budowanie aplikacji (systemów) na podstawie kilku lub więcej "lekkich" aplikacji (serwisów) komunikujących się ze sobą sieciowo (głównie HTTP lub tzw. message-based communication). Każdy serwis ma określony zakres odpowiedzielności oraz odpowiedzialny jest za utrzymywanie swoich własnych danych. A przynajmniej tak to wygląda teoretycznie.
Taki przykładowy system sprzedaży online mógłby mieć oddzielny serwis odpowiedzialny za użytkowników, zamówienia, płatności czy magazynowanie/wysyłkę produktów.
0
Czy tabela w bazie danych mogła by być takim łącznikiem mikroserwisów w przypadku message-based communication?
0
Weź sobie znajdź na udemy kurs jakiś i zobaczysz jak to mniej więcej wygląda. Bo tak tylko z samego czytania tylko raczej nie zrozumiesz szczegółowo. Ja naprzykład przerabiam ten: https://www.udemy.com/course/getting-started-net-core-microservices-rabbitmq/
6
Kristof napisał(a):
Czy tabela w bazie danych mogła by być takim łącznikiem mikroserwisów w przypadku message-based communication?
Ogólnie jeśli mowa o message-based communication to w grę prawie zawsze wchodzą jakieś brokery (np. RabbitMQ lub Kafka). Oczywiście można zaimplementować coś samemu w oparciu chociażby o wymienioną przez Ciebie tabele w bazie danych. Rzecz tylko w tym czy miałoby to służyć rozwiązaniu jakiegoś konkretnego problemu, czy być "sztuką dla sztuki"? Jeśli to drugie to lepiej sięgnąć po sprawdzone rozwiązania które biorą na siebie cały ciężar zarządzania wiadomościami, kolejkowaniem ich, niezawodnym dostarczaniem itp. Szczególnie jeśli ktoś dopiero uczy się mikroserwisów i message-based communication- w takim przypadku lepiej skupić się na nauce właśnie tego zamiast zajmować się szczegółami implementacyjnymi czegoś co jedynie ma wspierać taką architekturę. Tym bardziej że- nie oszukujmy się- i tak nie napiszesz rozwiązania lepszego niż to co już szeroko dostępne, sprawdzone i napisane dla społeczności przez zespoły programistów.
0
Do komunikacji można używać różnych protokołów, ale rozwiązanie, które tobie by "leżało" byłby Redis taka hybryda bazy danych w pamięci i protokół redisa + MQ z paroma ficzerami.
0
To ja się podepnę z dość ogólnym pytaniem. Kiedy lepiej stosować mikroserwisy, a kiedy typowe podejście? Tzn. dajmy na to WebApi, który ma wydzielone serwisy w postaci klas
3
Juhas napisał(a):
To ja się podepnę z dość ogólnym pytaniem. Kiedy lepiej stosować mikroserwisy, a kiedy typowe podejście?
Co rozumiesz przez typowe podejście? W czasach przed mikrowerwisami istniały gigaktyczne monolity tworzone przez wiele zespołów które się nie znały. Ilość kodu była tak wielka że niektóre projekty napisane w Javie nie chciały ładować się do Eclipsa.
- Jednoosobowy projekt prawie na pewno nie zyska po podziale na mikroserwisy bo pojedynczy programista raczej nie napisze tyle kodu żeby to miało sens
- 10 osobowy, wieloletni projekt można podzielić na microserwisy, ale nie za dużo i nie za małych. Dodatkowo trzeba zrobić to naprawdę z sensem żeby nie okazało się że monolit byłby lepszy
- 1000 osobowy projekt trzeba podzielić na microserwisy, webserwisy lub po prostu osobne projekty bo ludzie się pozabijają przy próbie zrobienia tego
6
@Juhas Ogólnie to często wystarczy rozsądne podejście i zastosowanie modularnego monolitu. Niestety na fali mikroserwisów przyjęło się że monolit to synonim złej architektury. W rzeczywistości stosując monolit można uniknąć wielu problemów, bo mikroserwisy tak jak wszystko ma swoje wady i zalety. Ponadto jeśli ktoś nie jest w stanie napisać modularnego monolitu, to tym bardziej niech się nie bierze za mikroserwisy bo będzie wtedy miał monolit (w tym złym znaczeniu tego słowa) rozproszony sieciowo, czyli przepis na porażkę.
Co do Twojego pytania:
Kiedy lepiej stosować mikroserwisy, a kiedy typowe podejście? Tzn. dajmy na to WebApi, który ma wydzielone serwisy w postaci klas
Z pewnością nie mieszał bym mikroserwisów z serwisami w sensie klasy dostarczające pewnej funkcjonalności. Mikroserwisy to nie jest alternatywa dla takich serwisów w procesie, to całkowicie coś innego. Nie mówiąc już o tym że sam uważam że serwisy z których korzysta aplikacja czy też endpointy w API to do pewnego stopnia antywzorzec, bo często spotykam się z nadużywaniem serwisów, ładowanie wszystkiego w jedno miejsce i mamy taki "serwis" który w rzeczywistości jest słynną klasą manager opakowaną w nową nazwę.
Mikro-serwisy najlepiej stosować tam gdzie mamy duże projekty, z dużą ilością programistów, złożone procesy biznesowe oraz wymagania co do niezależnego rozwoju poszczególnych modułów systemu. Do tego dochodzą również wymagania wydajności i skalowalności. Np. w takim złożonym systemie pewna część tego systemu możę być używana znacznie częściej niż inne- przy użyciu mikroserwisów możemy zeskalować tylko ten konkretny element systemu.
2
Z pewnością mikroserwisy są nieodzowne, gdy w projekcie jest kilka technologii na raz (bez względu z jakich powodów), typu np. funkcjonalność A jest w serwisie w Pythonie, funkcjonalność B w serwisie napisanym w C#, funkcjonalność C w Go powiedzmy, a funkcjonalność D w Rust. Tego typu druciarstwa nie da się zrobić za pomocą monolitu, bo niby jak? Nie w każdym języku FFI zapnie się do dowolnego innego języka, pomijając w ogóle fakt, że to wprowadza zupełnie nową klasę problemów (np. CGo w Go). Wtedy lepiej "odseparować" funkcjonalność z innej technologii i w niej ją napisać i pogłowić się nad potencjalnym sposobem komunikacji pomiędzy takimi serwisami, bo suma summarum będzie to prostsze.
8
Oto sposób na pisanie mikroserwisów:
- (6 miesięcy) Zatrudniasz się w firmie gdzie pisze się wymagający biznesowo / domenowo kod.
- (6 miesięcy) Implementujesz wymagania biznesu pisząc jedną aplikację. Tzw monolit. Cały czas myślisz jakie agregaty masz w systemie. Organizujesz je w zwarte moduły. Kontrolujesz w jakich kierunkach powinny być kierowane zależności między modułami. Piszesz testy dla swoich przypadków użycia cały czas usprawniasz, reorganizujesz i strukturyzujesz logikę w coraz bardziej zwarte moduły.
- (6 miesięcy) Mijają miesiące, okazuje się, że struktura twoich modułów nie jest dobra - łączysz starte moduły w jeden lub rozbijasz je na mniejsze, zmieniasz kierunki zależności między nowymi modułami.
4.(6 miesięcy) Po czasie, aplikacja osiąga sukces biznesowy. Rośnie liczba użytkowników. Licznik $ nie nadąża nabijać kasy. Pojawiają się nowe problemy np wydajnościowe lub poszczególne moduły są zbyt duże. - (6 miesięcy) Dopiero teraz mając wiedzę i doświadczenie - dzielisz system na osobne aplikacje, głównie granicami modułów. Jako że masz dobre i spójne moduły to konfigurujesz między nimi komunikację asynchroniczną. Oczywiście tylko wówczas gdy firma ma możliwości techniczne aby tych kilka aplikacji utrzymywać. Tj. automatyzacja budowania i wdrażania. automatyczny monitoring. Utrzymywanie infrastruktury etc.
Mikroserwisy gotowe.