Czy podczas opracowywania systemu powinienem używać mikrousług?

Zaczynam nowy projekt w pracy i prawdopodobnie będę prawie jedynym programistą w projekcie, chociaż jeden lub dwóch innych programistów będzie musiało zintegrować istniejące aplikacje lub proste skrypty z głównym projektem. Projekt musi poradzić sobie z przetwarzaniem / przetwarzaniem danych masowych i przesyłaniem strumieniowym na małą skalę, a także uruchamianiem kodu sterowanym zdarzeniami i na żądanie. Niektóre części frameworka będą mocno powiązane z procesorem, a niektóre mogą być mocno powiązane z I / O; większość danych musi znajdować się na jednym komputerze, ale jesteśmy w stanie utworzyć klaster i połączyć maszyny wirtualne, aby zwiększyć dostępną moc obliczeniową. Prawdopodobnie będzie istniała jedna lub więcej małych aplikacji internetowych, które zależą od usług zapewnianych przez tę podstawową strukturę. Głównym językiem będzie Python do wszystkiego.

Moje pytanie brzmi, czy powinienem zastosować podejście mikrousługowe do takiego wysiłku, czy też trzymać się monolitycznej aplikacji, biorąc pod uwagę, że większość rozwoju będę robił sam. Uważam, że mikrousługi (wykorzystujące Nameko) zapewniają naturalny rozdział między elementami frameworka, które mają różne modele wykonawcze (potoki danych, uruchamiane zdarzeniami, aplikacje na żądanie, aplikacje internetowe itp.) Oraz jasny sposób na rozłożenie obciążenia i komunikacja między wieloma procesami. Obawiam się, że prawdopodobnie skończę z klastrem Kubernetes do zarządzania (znam Docker, ale wciąż dość nowy w Kubernetes), wielu usług (królikmq, redis itp.) Wymaganych tylko w celu ułatwienia uruchomienia systemu, i potencjalnie wiele małych fragmentów kodu, aby faktycznie wdrożyć wszystkie niezbędne możliwości, które „

Czy w przypadku projektu z niewiele więcej niż jednym deweloperem mikrousługi nadal upraszczają tworzenie i utrzymywanie tak skomplikowanego systemu? Czy istnieją metody / systemy / frameworki, które należy rozważyć zamiast tego, lub aby zmniejszyć narzut związany z projektowaniem systemu w ten sposób?

Mikrousługi są na ogół niepożądane, ponieważ zmieniają oprogramowanie w system rozproszony - a systemy rozproszone sprawiają, że wszystko jest znacznie trudniejsze. Ale architektura zorientowana na usługi ma kilka ważnych zalet:

• różne usługi mogą być opracowywane i wdrażane niezależnie przez różne zespoły
• różne usługi mogą być skalowane niezależnie

Ponieważ będziesz jedynym programistą, nie potrzebujesz elastyczności, aby samodzielnie rozwijać usługi.

Zauważ jednak, że niektóre części mogą być związane z procesorem. Może więc być pożądane skalowanie ich niezależnie od reszty aplikacji. Jeśli tak jest, nie oznacza to, że musisz przekształcić cały projekt w architekturę mikrousług. Tę część wymagającą dużej mocy procesora wystarczy przenieść do własnej usługi, a resztę można przechowywać w wygodnym monolicie. Trudno powiedzieć, w których liniach należy rozdzielić system, ale ogólnie idea „ograniczonych kontekstów” DDD jest dobrą wskazówką.

Zauważ, że monolity nie są złe. Monolity nie są równoznaczne z wielkim bałaganem, którego nie da się utrzymać. Tam, gdzie możesz podzielić system na różne mikrousługi, możesz także podzielić system na różne komponenty w ramach monolitu. Separacja między tymi komponentami jest po prostu bardziej widoczna i bardziej wymuszona w architekturze zorientowanej na usługi. Oznacza to również, że w przypadku dobrze zaprojektowanego systemu przekształcenie komponentu w usługę powinno być dość łatwe w późniejszym terminie. Więc nie musisz teraz decydować, możesz przejść do mikrousług, jeśli i kiedy monolit okaże się nieodpowiedni.

Zastanów się także nad koncepcją Microservice Premium (2015) Martina Fowlera : mikrousługi wprowadzają własną złożoność, oprócz podstawowej złożoności twojego systemu. Musisz zapłacić tę „premię” pod względem obniżonej wydajności. Oznacza to, że w przypadku prostych projektów mikrousługi zmniejszają produktywność. Zmienia się to w przypadku bardziej złożonych projektów: podczas gdy monolityczne rozwiązanie może być coraz trudniejsze do pracy, architektura mikrousług skaluje się znacznie lepiej i wymaga mniej więcej stałego wysiłku. Musisz wiedzieć, czy dodatkowy początkowy wysiłek związany z mikrousługami jest tego wart, biorąc pod uwagę twój system oprogramowania. Ponieważ zadajesz to pytanie, odpowiedź brzmi prawdopodobnie „nie”. Fowler kontynuuje:

Tak więc moją podstawową wytyczną nie byłoby nawet rozważanie mikrousług, chyba że masz system, który jest zbyt skomplikowany, aby zarządzać nim jak monolit. Większość systemów oprogramowania powinna być zbudowana jako pojedyncza aplikacja monolityczna. Zwróć uwagę na dobrą modułowość w tym monolicie, ale nie próbuj rozdzielać go na osobne usługi.