Wątek przeniesiony 2020-06-06 19:41 z C# i .NET przez somekind.

Na czym polega tworzenie aplikacji webowych w oparciu o mikroserwisy?

0

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?

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/[...]-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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0