• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Podział strony na mikroserwisy - na przykładzie serwisu z ogłoszeniami: OtoMoto.pl

Object Storage Arubacloud
0 głosów
259 wizyt
pytanie zadane 13 lutego w Inne języki przez reaktywny Nałogowiec (41,090 p.)

Cześć,

chciałem zapytać jak podchodzicie do podziału projektu na mikroserwisy? Jak wydzielacie mikrousługi?

Dobrym przykładem użycia mikroserwisów jest Allegro.pl, ale to skomplikowany, bardzo zaawansowany system składający się z ponad 400 serwisów! Weźmy coś prostszego, chyba każdy zna OLX, OtoDom czy OtoMoto.... Przykładowo ten ostatni (wiem, że lubicie samochody)... Jak byście podzielili Otomoto.pl na mikroserwisy??

Najważniejsze funkcjonalności OtoMoto.pl to:

1. Wyszukiwarka ogłoszeń

2. Prezentacja ogłoszeń (ofert aut)

3. Dodawanie nowych ogłoszeń

4. Dodawanie nowych użytkowników (prywatnych i firmowych)

5. Artykuły, porady - część "blogowa"

6. Informacje o portalu - kontakt, cennik ogłoszeń, itp.

7. Pierdółki różnego rodzaju (Biuro prasowe,  Polityka prywatności, Polityka plików "cookies",  Ustawienia plików cookie)

Oczywiste jest, że większość użytkowników serwisu korzysta głównie z funkcjonalności 1) i 2), rzadziej z 3) i 4), a pozostałe odwiedzane są jeszcze rzadziej, wręcz sporadycznie.

Jak podzielić taki portal na mikroserwisy żeby wyszukiwarka ogłoszeń czy część prezentacji ogłoszeń nie dostały czkawki (podobnie, funkcjonalności 3) i 4)  ? Wiadomo, że części portalu najbardziej oblegane generują największe obciążenie serwera, jak je wydzielić (i może podzielić dodatkowo) żeby uniknąć hiccupu?

Ile byście tu zaproponowali mikroserwisów i jakie?

Mam nadzieje, że wywiąże się z tego ciekawa dyskusja :) !

 

 

 

2 odpowiedzi

+2 głosów
odpowiedź 13 lutego przez rafal.budzis Szeryf (85,260 p.)
Wszystko zależy od potrzeb biznesowych.

A ich określonych nie ma. Jeśli biznes nie wie po co miałby dzielić aplikacje na mikroserwisy to znaczy że nie powinien jej dzielić. Mikroserwisy to rozwiązanie. A aby stosować jakieś rozwiązanie trzeba znać problem.

Co do obciążenia serwera to w przypadku mikro serwisów moim zdaniem jest prościej. Bo widzisz dokładnie która cześć aplikacji ma czkawkę i możesz ją  odpowiednio doskalować :)   

Wymieniłeś kilka funkcji ale zapomniałeś o obrazkach :P Przechowywanie / tworzenie miniaturek i zarzadzanie obrazkami to dla mnie mógłby być osobny serwis ;P Jednak nie rozumiem jakich odpowiedzi szukasz?
2
komentarz 13 lutego przez Ehlert Ekspert (212,870 p.)

Jeśli biznes nie wie po co miałby dzielić aplikacje na mikroserwisy to znaczy że nie powinien jej dzielić. 

Który biznes wie co to mikroserwisy?

komentarz 13 lutego przez rafal.budzis Szeryf (85,260 p.)
Bardziej mi chodzi o to że biznes powinien mieć jakąś potrzebę. A programiści mogą jako jedno z rozwiązań sugerować mikroserwisy.

Jeśli biznes przychodzi i mówi "zróbcie mikro serwisy" ale gdy się spytamy "Po co??" Nie potrafi odpowiedzieć to znaczy że nie powinniśmy dzielić na mikroserwisy ;) O to mi chodziło Może nie fortunnie to napisałem.
komentarz 13 lutego przez reaktywny Nałogowiec (41,090 p.)

@rafal.budzis, 

Miliony użytkowników wchodzą miesięcznie na OtoMoto by znaleźć sobie samochód, więc (nie wiem czy to dobrze wyeksponowałem) najbardziej obciążone są serwisy odpowiedzialne rzecz jasna za:

1. Wyszukiwarka ogłoszeń

2. Prezentacja ogłoszeń (ofert aut)

Jak im pomóc żeby nie dostały zadyszki? Można przyjąć teoretycznie, że serwer z czterema procesorami EPYC nie wyrabia, tyle milionów osób ma ochotę zobaczyć Lanosa marzeń i potrzeba tutaj podjąć jakieś działania.

W poprzednim wątku o mikroserwisach jeden z kolegów na forum sugerował w takim wypadku podział serwisów i baz danych na kilka, proponując podział (tu np. wg. marek aut - pierwsza litera nazwy):

A...D,. E....G,  F....I, itd. itd.

Doskonale zdaję sobie sprawę że tu byłoby to na wyrost, ale mówimy o takim oderwanym od realu przypadku,

 

komentarz 13 lutego przez rafal.budzis Szeryf (85,260 p.)
Jeden serwer nie wyrabia to dokładaj drugi jako drugą instancje i rozdzielaj ruch miedzy serwerami. Nie pchaj się w mikro serwisy ;)

Moim zdaniem mikroserwisy rozwiązują w głównej mierze tylko jeden problem. Dają możliwość pracy nad projektem w dużo więcej osób. A co za tym idzie gdy już się uporamy z problemami takiej architektury możemy rozwijać projekt szybciej.  A każdy developer zna reguły biznesowe tylko w małym zakresie dzięki czemu nie musi znać całego systemu.

Więc jeśli PROBLEMEM biznesu był by zbyt wolny rozwój to można proponować mikroserwisy.

Jeśli jednak PROBLEMEM biznesu jest strata pieniędzy na utrzymywanie legacy kodu to tu też można rozważyć mikro serwisy. Wówczas sugerował bym zacząć od wydzielenia reguł biznesowych które zabierają najwięcej czasu lub najczęściej występują w nich błędy. Jednak przy tym problemie lepiej by było napisać coś od zera w monolicie moim zdaniem ;)

W twoim teoretycznym przykładzie brakuje PROBLEMU jaki chcesz rozwiązać ;)
2
komentarz 13 lutego przez Ehlert Ekspert (212,870 p.)

@reaktywny, dlatego do takich celów używa się rozwiązań cloudowych

  • Frontend piszesz w react.js i builda serwujesz z S3 + cloudfronta
  • Backend piszesz w node
  • Stawiasz klaster redisa - rzeczy które rzadko się modyfikuje pchasz w cache
  • Obrazki serwujesz przez S3 + CDNy
  • Kilka instancji backendu spięte load balancerem
  • Testy obciążeniowe na k6
  • Full text search na elasticsearchu
  • Przy naprawdę dużym ruchu możesz posiłkować się serverlessowymi narzędziami które pozwolą Ci zapomnieć o konfiguracji autoscalingu np. fargate, albo lambda.

Jest serio mnóstwo narzędzi i możliwości aby to udźwignąć.

komentarz 13 lutego przez rafal.budzis Szeryf (85,260 p.)
Jako frontend nie zgadzam się aby statyczny build aplikacji w react.js był najlepszym rozwiązaniem. Zdecydowanie ciekawszym jest next.js który oczywiście byłby schowany za warstwą cloudfronta. Obrazki wtedy mogą być tworzone przez next.js i serwowane przez tego samego cloudfronta co inne requesty frontendowe ;)

Wiem że to tylko przykład ale wspominam o tym bo nie wiedzieć czemu osoby spoza frontendu często biorą statyczny build jako oczywistość. A nie powinni ;)
komentarz 14 lutego przez jankustosz1 Nałogowiec (35,880 p.)
Czy ciut szybsze załadowanie pierwszy raz strony jest aż tak warte takiego komplikowania sobie życia? Dziś prawie każdy ma światłowód.

Słyszałem złe opinie o nextjs.
komentarz 14 lutego przez rafal.budzis Szeryf (85,260 p.)
Wszystko zależy od potrzeb. Te "ciut szybsze" załadowanie to czasem różnica kilku sekund na metryce LCP (Largest Contentful Paint).

Dodatkowo next.js może generować stronę raz na kilka minut dzięki czemu odciąża BE.

Amozon kiedyś przeprowadził badania (dodali opóźnienie o 100 ms do requestów) i spadek wczytywania o 100 ms realnie wpływał na ilość zamówień.

Trudno mi się odnieść do złych opinii skoro nie znam ich treści. Ale jak każde rozwiązanie ma swoje plusy i minusy.

PS. Mieszkam w centrum Wrocławia i nie mam możliwości założenia światłowodu ;)
+2 głosów
odpowiedź 13 lutego przez Ehlert Ekspert (212,870 p.)
To co opisałeś to idealny case na monolit - który z resztą można skutecznie skalować do pewnego stopnia.

Podział mikroserwisów można wyłapać takimi technikami np. jak event sourcing. Sam w sobie mikroserwis często się też definiuje jako niezależną jednostkę wdrożeniową.

Architektura mikroserwisów wymusza również zmiany w zarządzaniu - nie pchałbym się w to bez kilkudziesięciu developerów i wszyscy na backendzie.
komentarz 13 lutego przez reaktywny Nałogowiec (41,090 p.)
OK, ja dałem tą stronę tylko jako przykład (może nie idealny). Sam napisałeś, że monolit można skalować do pewnego stopnia - przyjmijmy, że już go przekroczono i serwer nie wyrabia, w rezultacie trzeba przejść na mikroserwisy. (Nie wiem jaki ma ruch ta strona, ale myślę, że co najmniej kilka-kilkanaście milionów odwiedzin miesięcznie).
2
komentarz 13 lutego przez Ehlert Ekspert (212,870 p.)

Wydaje mi się że dość ciężko przekroczyć taką barierę, grube blachy na aws+skalowanie horyzontalne. Do tego redis jako cache, cloudflare jak http cache.

Nie szukałbym na siłę powodów do mikroserwisów bo dodają one mnóstwo wyzwań:

  • Całkowita automatyzacja
  • Service Discovery 
  • Wdrożenia
  • Testy kontraktowe 
  • Komunikacja między nimi, at least once delivery, idempotencja 
  • API gateway

Jest tego dużo więcej. Jak masz projekt, zacznij na spokojnie od monolitu.

komentarz 13 lutego przez reaktywny Nałogowiec (41,090 p.)
Nie mam projektu i nie jestem szefem OtoMoto ;) Pytam teoretycznie - to są tylko teoretyczne rozważania!
1
komentarz 13 lutego przez adrian17 Ekspert (345,600 p.)
edycja 13 lutego przez adrian17

przyjmijmy, że już go przekroczono i serwer nie wyrabia, w rezultacie trzeba przejść na mikroserwisy

Chwila moment - dałbym głowę, że mikroserwisy z założenia są techniką organizacyjną w projektach skali FAANG, a nie techniką optymalizacji (jak już, to trochę tracisz na wydajności). Od kiedy potrzeba mikroserwisów żeby skalować aplikację ponad jeden serwer...?

Popieram to co napisał Ehlert, "nie pchałbym się w to bez kilkudziesięciu developerów", tylko bardziej "kilkuset".

komentarz 13 lutego przez reaktywny Nałogowiec (41,090 p.)
Nie tylko 10 czy nawet 1000 największych firm korzysta z mikroserwisów. Dziś  znacznie więcej firm korzysta z tego rozwiązania, a czy to słuszny wybór to inna para kaloszy. Może wynika to z mody, jest trendy :) Nie wiem, ale chciałem się trochę zapoznać z tą tematyką.
komentarz 14 lutego przez jankustosz1 Nałogowiec (35,880 p.)
U nas w firmie jest ogromny monolit i ostatnio pojawiają się problemy z wydajnością. Serwer pada na produkcji, a analizowanie co poszło nie tak jest bardzo trudne. Już od dłuższego czasu jest temat by przenieść się na mikroserwisy.

Mieliście jakieś doświadczenia z mikroserwisami? Ja w swoim nie wielkim projekcie zrobiłem kilka serwisów i komunikację po Rabbitmq. Wydaje mi się to całkiem wygodne i fajne.

Podobne pytania

0 głosów
1 odpowiedź 704 wizyt
0 głosów
4 odpowiedzi 308 wizyt
pytanie zadane 20 października 2023 w Inne języki przez reaktywny Nałogowiec (41,090 p.)
+1 głos
1 odpowiedź 296 wizyt
pytanie zadane 20 marca 2023 w JavaScript przez icytower Bywalec (2,110 p.)

92,654 zapytań

141,543 odpowiedzi

319,958 komentarzy

62,023 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Kolejna edycja największej imprezy hakerskiej w Polsce, czyli Mega Sekurak Hacking Party odbędzie się już 20 maja 2024r. Z tej okazji mamy dla Was kod: pasjamshp - jeżeli wpiszecie go w koszyku, to wówczas otrzymacie 40% zniżki na bilet w wersji standard!

Więcej informacji na temat imprezy znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...