Architektura mikroserwisów

0

Czytam sobie nt architektury mikroserwisów i trochę nie rozumiem jak to ma wyglądać. Przykładowo mamy system do wynajmu samochodu, w którym mamy główne encje:

  • klientów
  • faktury
  • samochody

Jak powinna wyglądać architektura mikroserwisów:

Odpowiedź a)

1) Serwer klientów, który przechowuje tyko klientów
2) Serwer faktury, który przechowuje tylko faktury
3) Serwer samochodów, który przechowuje tylko faktury
4) Front, który to wszystko łączy, łaczy się z 3ma powyższymi i ściąga wszystkie dane.

Odpowiedź b)

1) Serwer klientów, który przechowuje tyko klientów
2) Serwer faktur, które są powiązane z klientami i samochodami, więc posiadają ich KOPIĘ
3) Serwer samochodów
4) Front, który potrafi się połączyć z każdym z tych 3 i pad jednego nie zrobi awarii?

3

Odpowieź c)
1) Serwis klientów
2) Serwis faktur, które są powiązane z klientami i samochodami, więc łączy się z tymi serwisami jeśli potrzebuje,
3) Serwis samochodów
4) Gateway obsługujący komunikację z frontem
4) Front, który wysyła requesty do gatewaya

0
Maciej Cąderek napisał(a):

Odpowieź c)
1) Serwis klientów
2) Serwis faktur, które są powiązane z klientami i samochodami, więc łączy się z tymi serwisami jeśli potrzebuje,
3) Serwis samochodów
4) Gateway obsługujący komunikację z frontem
4) Front, który wysyła requesty do gatewaya

A teraz wyłaczamy serwer samochodów. Czy możemy pobrać jakiekolwiek faktury i zobaczyć że wypożyczony był Ford Mondeo, ale może bez jego rocznika, ewidencji przebiegu i listy napraw?

3

Tylko ze mikroserwisy to nie jest panaceum na wszystkie bolączki. Jeśli masz silnie powiązane ze sobą serwisy to mikroserwisy niekoniecznie są dobrą drogą i tyle. Właśnie dlatego że niby masz mikro, ale w praktyce wszystko od wszystkiego zależy ;)

Zresztą zaletą mikroserwisów nie jest to ze możesz któryś wyłączyć, tylko raczej to że możesz je wygodnie skalować dodając nowe nody.

0
Uczynny Ogórek napisał(a):

A teraz wyłaczamy serwer samochodów. Czy możemy pobrać jakiekolwiek faktury i zobaczyć że wypożyczony był Ford Mondeo, ale może bez jego rocznika, ewidencji przebiegu i listy napraw?

No jak zaprogramujesz tak będziesz miał, co mają do tego mikroserwisy?

4

Wszystkie trzy odpowiedzi są poprawne w próżni, gdy nie mamy żadnego kontekstu, i żadnych dodatkowych wymagań poza funkcjonalnych nałożonych na system. A zwykle to właśnie wymagania poza funkcjonalne mają największy wpływ na kształt architektury mikroserwisów czy też innych tworów rozproszonych.

Dodałeś jedno wymaganie jakim jest dostępność systemu w przypadku nie działania któregoś z serwisów (wyłaczamy serwer samochodów), najłatwiej jest to osiągnąć sprawiając by serwisy te były autonomiczne(co zwykle leży blisko bounded contextu z ddd), czyli nie zależały od innych, bo inaczej wszystko się posypie jak domino, (zresztą z biznesowej perspektywy i prawnej faktury się raczej nie zmieniają), więc odpowiedź C odpada na tym wymaganiu.

Odnośnie tego w którym miejscu składać nasze UI, czy po stronie użytkownika czy serwera, to też zależy oczywiście od konkretnego przypadku, ale można sobie tutaj poczytać dywagacje na ten temat robione przez Jimmiego Bogarda:
A primer

Mikroserwisy, czy też SOA, rozwiązują wiele problemów, ale też sporo nowych dokładają, głównie wynikających z tego że sieć jest zawodna, więc dla przypomnienia pierwsze prawo systemów rozproszonych według Martin Fowlera: "My First Law of Distributed Object Design: Don't distribute your objects" :)

2

Mikroserwisy w takim przypadku to np.:

  1. serwis crudowy z klientami, fakturami i samochodami
  2. serwis obsługujący płatności
  3. serwisy obsługujące np. integrację z systemami linii lotniczych (które podczas sprzedaży biletów wyświetlają oferty wypożyczalni samochodów)
  4. brama, która wystawia potrzebną część funkcjonalności dla aplikacji webowych, mobilnych, itd.

W mikroserwisach chodzi o dzielenie na komponenty, które są w stanie pracować niezależnie, a nie o stawianie oddzielnego serwisu dla każdej tabeli w bazie.

2

W sumie uważam, że używanie mikroserwisów dotyczy tylko części niefunkcjonalnej aplikacji i mocno ją komplikuje w szczególności deployment. Mikroserwisy rozwiązują problem, gdy nagle obsługujemy 10 req/s, a zaraz może być przez chwilę 200 req/s, a potem nagle mniej co wymaga dynamicznej alokacji zasobów np. w chmurowych serwerowniach np. podczas tworzenia produktów na wolny rynek. Najwięcej pracy jest jak dla mnie po stronie DevOps i mało kto potrafi to zrobić dobrze.

Jak dla mnie mikroserwisy nie pasują dla 95% typowych biznesowych aplikacji. Uważam, że lepiej zacząć pracę od dobrze zrobionego, bezstanowego monolitu ze wsparciem dla centralnej dynamicznej auto-konfiguracji i auto-scalingu i potem dzielić (jak nie ma sesji powinno być to proste). W sumie podoba mi się też idea rozpraszania aplikacji na różne serwerownie tak, że można wyłączyć serwerownie w jednym kraju, a aplikacja wciąż będzie dostępna. Mało kto ma takie wymagania.

Myślę, że warto zainwestować w umiejętność budowania auto-skalujących się aplikacji: może być z tego kasa, ale to bardziej DevOps.

1

@margor90
Zgodzę się z tobą, ale jest też druga strona - o wiele łatwiej wprowadzić zmianę i wdrożyć jeden mikroserwis niż wielkiego molocha. IMHO mikroserwisy mogą pasować do większości pisanych aplikacji, ale faktycznie lepiej zacząć od dobrego monolitu niż ciąć serwisy na ślepo.

0

@hcubyc: Mikroserwisow wcsle sie latwo nie wdraza. Trzeba mieć niezłą infrastrukturę zeby to miało sens. I na pewno nie pasuja do wielszosci aplikacji. Byc moze do wiekszosci webowych a i to bym sie zastanawial. Byc może w większości aplialcji można wydzielić pewne funkcje, ktore mozna z jakichs przyczyn zamienic na mikro. Dobrze @neves napisał.

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