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

pytanie zadane 13 lutego w Inne języki przez reaktywny Nałogowiec (44,780 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

odpowiedź 13 lutego przez rafal.budzis Szeryf (85,380 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 (214,530 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,380 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 (44,780 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,380 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ć ;)

komentarz 13 lutego przez Ehlert Ekspert (214,530 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,380 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 (36,800 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,380 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 ;)

odpowiedź 13 lutego przez Ehlert Ekspert (214,530 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 (44,780 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).

komentarz 13 lutego przez Ehlert Ekspert (214,530 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 (44,780 p.)

Nie mam projektu i nie jestem szefem OtoMoto ;) Pytam teoretycznie - to są tylko teoretyczne rozważania!

komentarz 13 lutego przez adrian17 Mentor (351,140 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 (44,780 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 (36,800 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.