Microservice - Jak to ugryźć Opcje

[Pyton_000]

Temat nadaje się raczej do Pro (IMG:style_emoticons/default/wink.gif)

Do rzeczy. Mamy dość pokaźną aplikację która została napisana już wieki temu. Przyszedł czas aby zacząć ją migrować na nowe rozwiązania.
Aplikacja z biznesowego pkt. jest podzielona na modułu np. Wyszukiwarka, Klienci, Kontrakty, Firmy itd.

Ogólnie jest to aplikacja do zarządzania rekrutacjami.

Chcemy to zmigrować i postawić w oparciu o Microservices. Tylko jak to ugryźć.
Nie mam doświadczenia w tej materii więc może będzie ktoś kto udzieli jakichś wskazówek.

Założenia są takie że migrujemy na Laravel 5.1 (nie pytajcie dla czego (IMG:style_emoticons/default/tongue.gif) , hejt i tak nic nie wniesie (IMG:style_emoticons/default/smile.gif) ), PHP 5.6 (lub 7).
Jest to dość złożona struktura, dla tego musimy się "wpiąć" w stary system i robić przekierowanie do nowych elementów tak aby móc powoli wyłączać stare rzeczy.

Może ktoś ma jakieś ciekawe materiały na ten temat, jak to ładnie powinno wyglądać.
Wiem tyle że całość ma się opierać o REST i Events.

Czy każdy moduł stawiać jako w pełni działająca aplikacja na FW czy może jakieś inne rozwiązania.

[by_ikar]

Założenie mikrosewisów nie jest takie że wszystko działa zupełnie odrębnie i żaden nie wie nic o drugim. To jest tak jak w przypadku aplikacji MVC, gdzie poszczególne kontrolery nie są na sztywno powiązane z widokami czy modelami. Te same modele czy widoki możesz również wykorzystać w innej części swojej aplikacji. A taka baza danych to jest część wspólna tych mikroserwisów, bo w jakiś sposób trzeba uwierzytelniać requesty, a najlepiej byłoby tymi samymi danymi. Skoro w tym momencie jakoś już przydzielasz poszczególne bazy danych użytkownikom, to nie ma problemu aby powstało API dzięki któremu takie rzeczy będziesz mógł robić.

Kilka miesięcy temu w końcu w firmie w której pracuje została podjęta decyzja o przepisaniu aplikacji, właśnie z monolita, gdzie wszystko było w jednym repo, wszystko działało na jednym serwerze, rozbudowywanie było trudne, deployment jeszcze trudniejszy etc, przez co jak przyszedł większy ruch, aplikacji zwyczajnie nie dało się skalować, a po mimo moich (nie tylko) uporczywych niekiedy argumentach decyzja za każdym razem była ustala na termin może kiedyś, ja tylko czekałem na większy ruch który ubije aplikację. Kiedy tak się stało, nagle dział marketingu który twierdził że do czegoś takiego nie dojdzie, ocknął się z ręką w nocniku i aplikacje trzeba było przepisywać na wczoraj. Więc im szybciej małymi kroczkami, tym lepiej, a jak ktoś z działu marketingu twierdzi inaczej, to niech to napisze na papieru i się pod tym podpisze, że jeżeli będą problemy w przyszłości, to za nie wszystkie odpowiada właśnie on. Inaczej z tymi mendami się nie da czasami :/

[Dejmien_85]

Założenie mikrosewisów nie jest takie że wszystko działa zupełnie odrębnie i żaden nie wie nic o drugim.

A kto powiedział, że żaden nie wie o innych?

Założenie jest takie, że serwis jest osobną jednostką, która sobie sama żyje i jest niezależna. Jeśli masz w aplikacji serwis odpowiedzialny za zapis plików (przypuśćmy, że jest osobny serwis, na który wgrywa się wszystkie pliki, czy to zdjęcia, czy PDF, cokolwiek), i teraz wszędzie tam, gdzie aplikacja wymaga wczytywania/odczytywania plików, to "rozmawia" z tym serwisem.

Jedne serwisy mogą tez komunikować się z innymi, ale jeśli przy operacji X serwis A ciągle gada do serwisu B, wtedy lepiej jest połączyć te dwa serwisy w jeden.

Należy unikać sytuacji, kiedy serwisy zbyt często siebie odpytują, bo to jest tylko niepotrzebny "coupling", który później odbija się przy zmianach - w grę wchodzą podstawowe zasady SOLID. Jeśli jeden serwis "rozmawia" z 10 innymi, wtedy przy zmianie tego serwisu może nagle pierdyknąć Ci te 10 serwisów.

Najlepiej narysować sobie na kartce serwisy i narysować strzałki kto z kim gada. Jeśli większość serwisów gada ze sobą nawzajem, wtedy jest to znak, że stworzyłeś cudowny przykład tego, jak nie robić mikroserwisów. ; )

A teraz wracając do Pythona - idźcie małymi kroczkami, znajdźcie jeden moduł, który jest niezależny i po prostu wyrzućcie go na oddzielny serwer. Tylko zanim go wywalicie na serwer, wtedy warto byłoby przeprowadzić najpierw refactoring kodu, postarać się usunąć wszelki niepotrzebny "coupling" tego modułu z innymi. Na waszym miejscu też postarałbym się ograniczyć liczbę zbędnych wywołań tego modułu (w sensie wywołań w kodzie, tylu moduł->metoda), bo podstawą jest, ze każde obecne wywołanie danego modułu będzie zastąpione callem do API.

Łato się mówi, ale oczywiście robi znacznie trudniej. Mikroserwisy to kawał trudnej roboty, powodzenia mogę jedynie życzyć. I koniecznie weź jakąś lekturę, same artykuły Cię wiele nie nauczą. Polecam tą książkę: http://shop.oreilly.com/product/0636920033158.do (czytałem ją w tamtym roku, bardzo fajna, przedstawia konkretne przypadki i problemy z jakimi się boryka, w tym jak dzielić aplikację na serwisy i jak radzić sobie z bazą, np. z transakcjami pomiędzy serwisami).

Weź się za porządną literaturę, ona Ci pomoże, tam ludzie opisują swoje doświadczenia, tutaj jest za dużo teoretyków. ; P