#programowanie #php #laravel Hej, mam problem z zaplanowaniem architektury mikroserwisów. Mam 3 webserwisy orders, users i products. Do tego utworzyłem serwis API gateway(AG), który zajmuje się autoryzacją oraz obsługuje przyjmuje i dystrybuuje komunikacje z web do mikroserwisów. Tutaj nasuwają mi się takie pytania: 1. Czy mikroserwisy orders,products,users komunikują się między sobą? Jeśli tak, to bezpośrednio czy przez API gateway? 2. Czy AG powinno zajmować się tylko proxowaniem ruchu, powinno łączyć requesty z mikroserwisów czy jeszcze do tego przetwarzać dane? 3. Mam widok, na którym chcę wyświetlić zamówienia klienta o emailu test@gmail.com. a) odpytuje 2 razy AG, raz /users?email=test@gmail.com, dostaje pozniej /orders?userid={id} b) odpytuje raz AG /orders/findByUserEmail?email=test@gmail.com a AG odpytuje raz /users i /orders c) odpytuje raz AG /orders/findByUserEmail?email=test@gmail.com a AG odpytuje /orders/findByUserEmail?email=test@gmail.com i mikroserwis orders juz sobie wyciąga usera z mikroserwisu users? Generalnie chodzi mi o ogólny problem komunikacji pomiędzy serwisami. Mam więcej pytań ale takie mi się nasunęły na początku pracy z mikroserwisami.
@cinek181992: Piękny przykład robienia modnych rzeczy dla samego ich robienia. W dodatku mój ulubiony przypadek, tj. połączony z kompletnym brakiem zrozumienia. (｡◕‿‿◕｡)
Mam więcej pytań ale takie mi się nasunęły na początku pracy z mikroserwisami.
Czy jednym z tych pytań jest może "w jakim celu", lub "jaki problem próbuję rozwiązać"?
@cinek181992: podział aplikacji na mikrosewisy nie powinien być podyktowany technicznymi przesłankami, tylko wynikać z potrzeb "biznesu". Dzielenie aplikacji "po tabelkach", ma tendencje do zrujnowania wydajności, problemów z debugowaniem, logowaniem, security i ogólnym późniejszym utrzymaniem.
Jeżeli potrzebą biznesową jest "wyświetlenie zamówień klienta" to bym to wrzucił wszystko do jednego mikroserwisu. Piszę tutaj skrótowo, bo nie wiem czy nie będę odebrany jako "hejter", ale jak chcesz rozwinięcia myśli to pisz albo poszukaj
podział aplikacji na mikrosewisy nie powinien być podyktowany technicznymi przesłankami, tylko wynikać z potrzeb "biznesu".
@hydrocyfolumpus: Nie do końca bym się tu zgodził. Często mikroserwisy są dobrym rozwiązaniem na problemy ze skalowaniem monolitu, lub problem przy dużym projekcie z wdrażaniem całego monolitu przy każdej zmianie kodu - zarówno ze względu na czas wdrożenia, jak i złożoność. Czyli jak najbardziej techniczne przesłanki. Choć pewnie miałeś na myśli innego rodzaju przesłanki. ;-)
@hydrocyfolumpus: no wlasnie projekt jest w ramach nauki ale jakby sie udało zrobić produkt to do użytku bo pomysł mam nawet spoko. Jeśli sie nie uda i miałby to być czas stracony to niech przynajmniej coś z tego wyciągnę. @hydrocyfolumpus: dzięki, poczytam o DDD więcej
z tymi users orders products - takich serwisów nie mam, to tak przykładowo dałem. Chodziło mi bardziej o komunikację pomiędzy mikroserwisami, w którą
Czyli jak najbardziej techniczne przesłanki. Choć pewnie miałeś na myśli innego rodzaju przesłanki. ;-)
@zakopiak: źle się wyraziłem, za duży skrót myślowy... zgadzam się, wydajność może być przesłanką do podziału na mikroserwisy i może być traktowana jako "techniczna przesłanka". Może być też traktowana jako potrzeba biznesowa, bo jak wyświetlenie zestawienia zamówień klienta trwa powyżej 10 sekund... to użytkownik może chcieć przejść na inne rozwiązanie... ale taką "potrzebę" można również próbować zrealizować
Hej, mam problem z zaplanowaniem architektury mikroserwisów. Mam 3 webserwisy orders, users i products. Do tego utworzyłem serwis API gateway(AG), który zajmuje się autoryzacją oraz obsługuje przyjmuje i dystrybuuje komunikacje z web do mikroserwisów. Tutaj nasuwają mi się takie pytania:
1. Czy mikroserwisy orders,products,users komunikują się między sobą? Jeśli tak, to bezpośrednio czy przez API gateway?
2. Czy AG powinno zajmować się tylko proxowaniem ruchu, powinno łączyć requesty z mikroserwisów czy jeszcze do tego przetwarzać dane?
3. Mam widok, na którym chcę wyświetlić zamówienia klienta o emailu test@gmail.com.
a) odpytuje 2 razy AG, raz /users?email=test@gmail.com, dostaje pozniej /orders?userid={id}
b) odpytuje raz AG /orders/findByUserEmail?email=test@gmail.com a AG odpytuje raz /users i /orders
c) odpytuje raz AG /orders/findByUserEmail?email=test@gmail.com a AG odpytuje /orders/findByUserEmail?email=test@gmail.com i mikroserwis orders juz sobie wyciąga usera z mikroserwisu users?
Generalnie chodzi mi o ogólny problem komunikacji pomiędzy serwisami.
Mam więcej pytań ale takie mi się nasunęły na początku pracy z mikroserwisami.
Czy jednym z tych pytań jest może "w jakim celu", lub "jaki problem próbuję rozwiązać"?
Jeżeli potrzebą biznesową jest "wyświetlenie zamówień klienta" to bym to wrzucił wszystko do jednego mikroserwisu. Piszę tutaj skrótowo, bo nie wiem czy nie będę odebrany jako "hejter", ale jak chcesz rozwinięcia myśli to pisz albo poszukaj
@hydrocyfolumpus: Nie do końca bym się tu zgodził. Często mikroserwisy są dobrym rozwiązaniem na problemy ze skalowaniem monolitu, lub problem przy dużym projekcie z wdrażaniem całego monolitu przy każdej zmianie kodu - zarówno ze względu na czas wdrożenia, jak i złożoność. Czyli jak najbardziej techniczne przesłanki. Choć pewnie miałeś na myśli innego rodzaju przesłanki. ;-)
@hydrocyfolumpus: dzięki, poczytam o DDD więcej
z tymi users orders products - takich serwisów nie mam, to tak przykładowo dałem. Chodziło mi bardziej o komunikację pomiędzy mikroserwisami, w którą
@zakopiak: źle się wyraziłem, za duży skrót myślowy... zgadzam się, wydajność może być przesłanką do podziału na mikroserwisy i może być traktowana jako "techniczna przesłanka". Może być też traktowana jako potrzeba biznesowa, bo jak wyświetlenie zestawienia zamówień klienta trwa powyżej 10 sekund... to użytkownik może chcieć przejść na inne rozwiązanie... ale taką "potrzebę" można również próbować zrealizować
Komentarz usunięty przez autora
dzięki o to mi chodziło, jest konkret