[Kostikov]

Cześć mirki!
Piszę pracę inżynierską o mikroserwisach. W pracy chcę opisać różnice między architekturą monolityczną i mikrousługami, wady i zalety obu architektur, sposoby dekompozycji dziedziny na mikroserwisy, popularne wzorce (głównie chodzi o sposoby autoryzacji/autentykacji, database per service, event sourcing, Saga, CQRS), a następnie pokazać realizację tych wzorców na przykładzie prostej aplikacji backendowej, wdrożonej w środowisku lokalnym z wykorzystaniem Docker Compose. Nie będę opisywał wzorców związanych z wdrożeniami na Kubernetesie, health checkami, service discovery itd. - każdy serwis będzie mieć dokładnie jedną instancję, będzie jedna kolejka itd.

Nigdy wcześniej nie pisałem całego systemu w mikroserwisach, jedynie monolit komunikujący się z mniejszą aplikacją przez REST API, stąd jest we mnie dużo niepewności - mimo wszystko jednak uważam, że dobrze wybrałem temat, bo mam doświadczenie z backendem. Mam kilka pytań:

-Aplikację chciałem napisać w Pythonie. Mam komercyjne doświadczenie z Django Rest Framework/Django Channels/Celery, ale zastanawiam się, czy nie nauczyć się asynchronicznego FastAPI. Czy Django to będzie overkill do tego zadania? Jak duże znaczenie ma ta asynchroniczność i czy FastAPI to dobry kierunek? Apki będą się komunikować przez kolejkę, najpewniej RabbitMQ.

-Jako przykład chcę stworzyć mini serwis społecznościowy, złożony z: AccountService (konta i autoryzacja/autentykacja), BlogService (tworzenie postów, lajkowanie, komentarze) i NotificationService(powiadomienia push i przez email). Czy taka dekompozycja spełnia zasady DDD i założenia teoretyczne tej architektury?
Przemek Bykowski na YT mówił, że w ogóle powinny być rozdzielone serwisy do małych funkcjonalności, jak reset hasła, logowanie, autoryzacja, ale dla mnie to trochę bez sensu. Nawet Martin Fowler pisał, że ludzie tworząc mikrousługi zbyt skupiają się na słowie "mikro" i zasadniczo mogą to być też większe serwisy.

Będę bardzo wdzięczny za pomoc!

#informatyka #mikroserwisy #programowanie

[Whiskeyjack29]

@Kostikov: Zgadzam się z tym że "mikro" serwisy powinny być większe, najlepiej wyjść od dobrze napisanego modularnego monolitu a mikroserwisy dodać poprostu jako warstwę architektury, wtedy dekompozycja jest zdecydowanie bardziej naturalna. Ciężko mi mówić z perspektywy pythona ale każdy programista c# wiedząc że ma rozbić reset hasła, rejstrowanie i logowanie na 3 oddzielne projekty złapał by się za głowę tymczasem jak robimy mikroserwisy to nie widzimy w tym problemu. Co do

[FantaZy]

@Whiskeyjack29: polecasz może jakieś dobre książki albo YouTube nt system design czy mikro serwisów?

[WhiskyRomeo]

Wydaje mi sie, ze możesz wspomniec jak wiele definicji czym mikroserwis jest, istnieje w necie. Kazdy wielki swiata it ma swoja i warto zebrac je do kupy. Podkreślając, że nie jest to łatwe do uchwycenia. Osobiście podoba mi sie definicja pochodząca z DDD o bounded context. Jak myślę o mikroserwisach to w glowie mam zbior funkcjonalnisci skladajacy się na submodel wiekszej calosci.

[metaforyczny_kierowca]

@FantaZy: Przejrzyj sobie "Microservices Patterns" Chrisa Richardsona, powinieneś znaleźć tam 80% swojej pracy dyplomowej.

[Shumitu]

@Kostikov: w swojej inżynierce robiłem bezstanowy monolit SPA i też robiłem porównania monolitu do mikroserwisów.

Jakbyś szukał fajnych źródeł do bibliografii to polecam:
https://ieeexplore.ieee.org/ - jak masz dostęp przez uczelnię
https://books.google.pl/ - szukając konkretnych rzeczy
http://notesofaprogrammer.blogspot.com/2014/11/bibtex-entries-for-ietf-rfcs-and.html - fajna stronka do generowania bibtexu dla dokumentów RFC, oczywiście jeżeli piszesz w latexie ( ͡° ͜ʖ ͡°)

Jakbym miał coś od siebie doradzić to tak jak też wspomniałeś, niech to

[Kostikov]

@Whiskeyjack29 @FantaZy @WhiskyRomeo @metaforyczny_kierowca @Shumitu Dziękuję wam bardzo za odpowiedzi!

[Kostikov]

@Shumitu: Tak, apka ma posłużyć tylko do prezentacji wzorców i dobrych praktyk. Chciałbym jak najszybciej zacząć kodować, ale nadal zastanawiam się nad frameworkiem. ;)