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.

[lukaskolista]

Poniżej moja propozycja, głównie architektura, o implementacji nie będę się rozpisywał.

Na podstawie wiedzy, doświadczenia oraz 2-godzinnego review na temat microservice proponuję takie rozwiązanie:
1. Wyznaczcie autonomiczne obszary biznesowe. Autonomiczne to nie takie, które nie mają powiązań z innymi, bo to by było bez sensu. Chodzi mi o obszary typu: fakturowanie, płatności, marketing itp. Gdybyś przybliżył szczegóły projektu było by łatwiej.
2. Powyższe obszary bezpośrednio mapują się na architekturę SOA - każdy obszar to odrębna usługa. Dobrze to zrobić tak, że każda usługa jest pod dedykowanym load balancerem, bo usługi mogą pracować na kilku węzłach klastra active-active (są nadmiarowe nogi tak, aby w przypadku awarii jednej z nich usługa dalej mogła obsługiwać większe obciążenie). Oczywiście jeśli obciążenie jest małe, to nie ma sensu, wtedy wystarczy active-passive po 1 węźle aktywnym i pasywnym.

Krótko mówiąc: obszar biznesowy = usługa w ujęciu SOA.

Usługi należy rozdzielić pomiędzy zespoły. Jak Was jest np. 5, to macie trochę problem organizacyjny, ale pewnie dacie radę.

Jak już są usługi, to teraz należy zastanowić się nad ich implementacją. Zakładam, że będzie to PHP (pewnie framework) + jakaś baza. Sugeruję użyć wzorców:
Oddzielone wywołanie
Usługa transakcyjna
Usługa aktywna (na 99% się przyda)
Workflow (jeżeli potrzeby biznesu są dynamiczne, np. często tworzone są nowe oferty w ramach tej samej funkcjonalności, ale są różnie obsługiwane, to biznes będzie bardzo zadowolony z użycia tego wzorca)
Potoki równoległe (też pewnie użyjecie, bardzo fajnie się skalują, można wykorzystać system kolejnowania, np. rabbitMQ czy Gearman - gearman w Symfony ma bardzo fajny pakiet, jeżeli byście symfony używali)

Wzorce typu komponent brzegowy pomijam, bo to nie problem zespołu deweloperów danej usługi (chyba, że będziecie utrzymywać serwery produkcyjne).

Następnie zastanowił bym się nad tym, jak poszczególne usługi zaprojektować. Niektóre pewnie można zrealizować na microservice (usługa w pojęciu SOA to niekoniecznie jeden monolit, to raczej jakiś byt z interfacem komunikacji). Taki interface może przyjmować zapytania i przekazywać je wewnętrzenie gdziekolwiek i robić z nimi cokolwiek.

Nie należy każdej usługi robić na microservice, to już zależy konkretnie od potrzeb.

Na koniec:
SOA != microservice
SOA - ujmuje obszary biznesowe jako usługi, może wykonywać wiele czynności
microservice - ujmuje pojedyncze funkcjonalności jako usługi, wykonuje mało czynności, a najlepiej jedną, w której jest wyspecjalizowana (np. generowanie faktury to jeden mikroserwis, bo z punktu widzenia biznesu to jedna czynność)
Należy jedynie zdefiniować pojęcie czynność na odpowiednim poziomie szczegółowości (wystawienie faktury to czynność, wysłanie emaila też, ale mają różny poziom szczegółowości)

Ten post edytował lukaskolista 29.01.2016, 15:57:08