czy zatoczyliśmy koło z mikrousługami, wracając do bardzo oldschoolowych podejść?

9

Jeśli chodzi o architekturę i projekt oprogramowania, w jaki sposób mikrousługi „nakładają się” (zamierzone) na oprogramowanie pośrednie? Pochodzę z Javy i wygląda na to, że odsuwając się od prostej wersji REST jako interfejsu API i abstrahując od różnych warstw i parametrów połączenia, przynajmniej w Javie, prawie zatoczyłeś koło kilku bardzo starych pomysłów szkolnych . Wróciliśmy do wirtualizacji ... gdzie JVM jest już wirtualna.

W agnostyczny sposób możesz, i powiedziałbym, zalety, abstrakcji RESTful API na CORBA. Lub, w sposób bardziej zorientowany na java, JMS lub MDB.

Kiedyś EJB był wielką sprawą w Javie, potem został rozpoznany jako efekt klastra, ale teraz wracamy do początku?

Czy też mikrousługi oferują coś, czego brakuje CORBA, a nawet lepiej, MDB? Kiedy czytam (TLDR) Martina Fowlera wyjaśniającego mikrousługi, wydaje mi się to dobrym rozwiązaniem na zły problem, jeśli wolisz. A raczej podejście z zamkniętym umysłem, które wprowadza poziom złożoności, który tylko popycha problem. Jeśli usługi są naprawdę mikro i są liczne, to każda z nich kosztuje dolara, aby je uruchomić i utrzymać.

Co więcej, jeśli jedna z wielu usług mikro zmieni swój interfejs API, wówczas wszystko zależne od tej usługi ulegnie awarii. Nie wydaje się luźno sprzężony, wydaje się przeciwieństwem zwinności. Czy też niewłaściwie używam tych słów?

Oczywiście istnieje nieokreślona ilość wyborów między tymi skrajnościami.

Rekin kontra goryl ... idź! (Dla pedantycznych, to ma być ironiczne i wcale nie jest to moim zamiarem. Pytanie powinno być traktowane na pierwszy rzut oka. Jeśli pytanie można poprawić, zrób to, lub skomentuj, a ja naprawię. )

Wyobraź sobie wiele mikrousług działających w oknie dokowanym, wszystkie na jednym komputerze, rozmawiające ze sobą ... szaleństwo. Trudne w utrzymaniu lub administrowaniu, a prawie nigdy nic nie można zmienić, ponieważ każda zmiana kaskadowo spowoduje nieprzewidziane błędy. Jak to jest lepsze, że te usługi są rozproszone na różnych komputerach? A jeśli są rozproszone, to z pewnością niektóre bardzo, bardzo stare techniki szkolne rozwiązały, przynajmniej w pewnym stopniu, rozproszone obliczenia.

Dlaczego skalowanie w poziomie jest tak powszechne, a przynajmniej pożądane?

Thufir
źródło
4
Głosowanie na zakończenie. Nie jest jasne, o co pytasz i dlaczego o to pytasz. Architektura mikrousług to kolejna architektura. Nic dodać nic ująć.
davidk01
1
Warto również znaleźć ten artykuł: devweek.com/blog/microservices-the-good-the-bad-and-the-ugly
davidk01
1
Wolę „Więc teraz mają setki małych fałszywych usług i zamiast monolitu, muszą się martwić, co się stanie, gdy ktoś będzie chciał zmienić kontrakt jednej z tych usług. Kulka przędzy pod inną nazwą. Zamiast tego zastanawiając się, czy kod się skompiluje, jeśli dokonają zmiany, zastanawiają się, czy zadziała w praktyce ”. - mikrousług dla zrzędliwego zrzeczenia się szyi : nie, nie jestem brodą, to tylko humorystyczny artykuł.
Thufir
„Zamiast zastanawiać się, czy kod się skompiluje ... zastanawiają się, czy zadziała ...” W rzeczywistości nie stanowi to żadnego problemu. Po prostu dlatego, że jeśli programista zmieni umowę bez powiadamiania wszystkich zaangażowanych stron - deweloperowi należy liczyć bardzo mocno. Dosłownie Jeśli korzystamy z umowy na czas określony, wyobraź sobie, że Twój operator komórkowy zmienia warunki umowy bez pytania / poinformowania Cię? Właśnie dlatego jest to umowa - wszystkie zaangażowane strony muszą zdawać sobie sprawę ze zmian w umowie / uzgadniać je, a kiedy ta zmiana nastąpi (przy założeniu prawidłowego przebiegu prac rozwojowych), wszystko należy przetestować i działać płynnie.
Alexey Kamenskiy
1
@Thufir Jak powiedziano przed stwardnieniem rozsianym, to tylko inne podejście, będzie miało swoje zalety i wady. Właściwie pracowałem z tym podejściem (nawet zanim usłyszałem, że ma ono swoją specjalną nazwę) przy wielu projektach. Na marginesie - to nie jest wodospad, ale to, co go tworzy. Ponieważ pracowałem dla jednego projektu rozwijającego (w zespole) część mobilnego systemu operacyjnego, takie podejście jest jedynym sposobem, ponieważ nie można go stworzyć giant blob, ponieważ musi mieć interfejsy, więc każda część zaczynająca się od jądra jest rodzajem MS, a przede wszystkim jakikolwiek zespół zaczął pisać kod w celu uzgodnienia specyfikacji v0.0.1.
Alexey Kamenskiy

Odpowiedzi:

2

TL; DR. Miałem przyjemność pić dużo Kool-Aid o smaku Microserver, więc mogę trochę powiedzieć o przyczynach.

Plusy:

  • Usługi wiedzą, że ich zależności są stabilne i zdążyły się upiec
  • Zezwalaj na ciągłe wdrażanie nowych wersji
  • Zezwól na cofanie komponentów bez wpływu na wyższe warstwy.

Cons:

  • Nie możesz korzystać z nowych i błyszczących funkcji swoich zależności.
  • Nigdy nie można złamać kompatybilności wstecznej API (a przynajmniej nie przez wiele cykli programowania).

Myślę, że zasadniczo nie rozumiesz, jak powinna działać architektura mikrousług. Sposób, w jaki powinien być uruchomiony, polega na tym, że każda mikrousługa (określana odtąd jako MS) ma sztywne API, na które zgadzają się wszyscy jej klienci. MS może dokonywać dowolnych zmian, o ile API jest zachowane. MS może zostać wyrzucone i przepisane od nowa, o ile API jest zachowane.

Aby wspomóc luźne sprzęganie, każde MS zależy od wersji n-1 jego zależności. Dzięki temu obecna wersja usługi jest mniej stabilna i nieco bardziej ryzykowna. Pozwala również na wersje wychodzące falowo. Najpierw aktualizowany jest 1 serwer, potem połowa, a na końcu reszta. Jeśli w bieżącej wersji wystąpią jakiekolwiek poważne problemy, MS można przywrócić do poprzedniej wersji bez utraty funkcjonalności na innych warstwach.

Jeśli interfejs API wymaga zmiany, należy go zmienić w sposób zgodny z poprzednimi wersjami.

Konstantin Tarashchanskiy
źródło
„MS można wyrzucić i przepisać od nowa, o ile interfejs API jest zachowany”. - nic nowego, ale ok. Pod względem wydajności, na drugim końcu spektrum, jak wszystkie te państwa członkowskie mają się do monolitycznej aplikacji / usługi / systemu? Jeśli chodzi o dystrybucję, brzmi to i popraw mnie, jeśli się mylę, że potencjalny wzrost wydajności może wynikać z umieszczenia n MS na jednej maszynie ... zwirtualizowanej na komputerze mainframe? To prawie tak, jak im bardziej skalujesz stwardnienie rozsiane w poziomie, tym łatwiej jest skalować je w pionie ...? Punkty bonusowe za brak czytania mojego pytania :)
Thufir
1
Podobnie jak w przypadku każdej warstwy pośredniej, osiągasz hit wydajności w porównaniu do dużej kuli błota. W przypadku MS jest to szczególnie kosztowne, ponieważ podczas każdej rozmowy korzystasz z sieci w obie strony. Zastosowanie wirtualizacji lub kontenerów znacznie skraca tę podróż w obie strony, ponieważ połączenie nigdy nie opuszcza maszyny. Oznacza to również, że zyskujesz większą izolację (niekontrolowana usługa nie może zranić rówieśników) przy niższym koszcie sprzętu.
Konstantin Tarashchanskiy
5

Każda technika opracowywania oprogramowania, którą kiedykolwiek wymyśliliśmy, w jakiś sposób polegała na zarządzaniu złożeniem. Ogromna ich część była i nadal dotyczy abstrakcji, enkapsulacji i luźnego łączenia. Mikrousługi to jeszcze jeden sposób robienia tych rzeczy i prawdopodobnie dlatego przypomina wiele starszych technik na wysokim poziomie teoretycznym, ale to nie czyni go mniej przydatnym ani istotnym.

Jeśli chodzi o luźne połączenie, myślę, że trochę źle zrozumiałeś cel. Jeśli zadanie A musi wywołać zadanie B, nigdy nie będzie sposobu, aby A i B były w 100% rozdzielone. Nigdy się nie wydarzy. Co możesz zrobić, to upewnić się, że jeśli zadanie B wywołuje zadanie C, to zadanie C nigdy nie powinno się martwić o zmiany w A. Jeśli wszystkie te trzy zadania są ze sobą połączone w jeden duży obiekt blob, przekazując struktury do siebie, wówczas istnieje znaczną szansę, że wszyscy będą musieli się zmienić, jeśli którykolwiek z nich to zrobi. Ale jeśli wszystkie trzy są mikrousługami, to w zasadzie masz gwarancję, że zmiana na A zmusi B tylko do aktualizacji (chyba że jest to tak ogromna zmiana w podstawowej funkcjonalności A, że prawdopodobnie powinieneś uczynić ją zupełnie nową usługą). Jest to szczególnie prawdziwe, jeśli wszystkie aktualizacje mikrousług są wykonywane w sposób zgodny wstecz, co powinno być.

Jeśli chodzi o zwinny komentarz, z własnego doświadczenia mogę powiedzieć, że nasz kod mikrousługowy gra znacznie lepiej z zwinnym niż nasz kod „połączony w duży obiekt blob”. W drugim przypadku za każdym razem, gdy ktoś naprawia błąd w funkcji niskiego poziomu, dosłownie musi wysłać do całego działu R&D wiadomość e-mail z informacją: „proszę ponownie połączyć swoje zadania, inaczej wszystkie ulegną awarii w piątek”. Dostajemy kilka z nich co tydzień . Jeśli jego kod znajdowałby się w mikrousługi, wszyscy moglibyśmy automatycznie skorzystać z poprawki, gdy tylko wdrożył nową wersję.

Nie do końca rozumiem komentarz na temat COBRA i MDB, ponieważ nie wydają się one architekturami oprogramowania, ale raczej elementami jednego; o ile rozumiem, są to potencjalne sposoby definiowania protokołów przesyłania komunikatów mikrousług i / lub wdrażania wspomnianych mikrousług, które same w sobie nie stanowią alternatywy dla mikrousług.

Ixrec
źródło
1
„Jeśli wszystkie trzy zadania są ze sobą połączone w jeden duży obiekt blob ...” Mam tylko perspektywę Java, ale powiedziałbym „nie”, zły pomysł, nie rób tego. Stwórz bibliotekę, API nr 1, API nr 2 itd., Aby osiągnąć dokładny punkt „..zadanie C nigdy nie powinno się martwić o zmiany w A”, ponieważ C jest klientem tylko B, a wcale nie A . W tym względzie nie uważam tego za nowe, przepraszam. Wiem, że pytanie, które zadałem, było rozmyte. To niewyraźne pytanie, ponieważ nie rozumiem, o co w tym wszystkim chodzi. Każda odpowiedź była dla mnie przydatna, choćby po to, by pomóc w moim słownictwie.
Thufir
1
@Thufir Jeśli wszystkie biblioteki są dynamicznie połączone, a wszystkie zadania działają na dokładnie tym samym zestawie komputerów, to masz rację, co rzeczywiście pozwoliłoby na osobne wdrożenie. Ale mikrousługi pozwalają odrzucić nawet te założenia, jeśli chcesz posunąć się tak daleko od oddzielenia. Jest całkowicie rozsądne, aby tego nie robić.
Ixrec,
CORBA jest (była) technologią rozproszoną, która umożliwiła architekturom rozproszonym w tym samym czasie (pod koniec 1990 r.), Kiedy nie było jeszcze powszechnych nazw, aby je zdefiniować. Miałeś swobodę wdrażania gruboziarnistych lub drobnoziarnistych systemów opartych na CORBA, kończąc na czymś, co później nazwano by SOA lub Microservices. CORBA nie przetrwała, ale robimy to ponownie, wykorzystując inną technologię. Problemem nie była jednak technologia. Więc tak, zataczamy pełne koło. Mam nadzieję, że nauczyliśmy się czegoś w tym procesie.
xtian
4

Jak to jest lepsze, że te usługi są rozproszone na różnych komputerach?

Z powodu chmury.

Zrobiłeś już śmiech? Poważnie - dla wielu firm największym kosztem oprogramowania nie jest już oprogramowanie. Jest to przepustowość, sprzęt, koszty CDN itp. Teraz, gdy wszyscy mają urządzenia mobilne, ruch jest znacznie większy. A to tylko pogorszy się, gdy toster uzyska własną łączność z Internetem.

Firmy chcą więc zarządzać tymi kosztami. W szczególności starają się poradzić sobie z problemem biznesowym: „jeśli to się wysadzi, jak mogę służyć milionom ludzi korzystających z mojego oprogramowania / bez korzystania z niego - nie płacąc z góry za serwery obsługujące miliony ludzi korzystających / korzystających z mojego oprogramowania ? ”.

Dlaczego skalowanie w poziomie jest tak powszechne, a przynajmniej pożądane?

Ponieważ odpowiada na ten (ogromny i narastający) problem biznesowy.

Gdy masz kilkunastu użytkowników, możesz podrzucić wszystkie usługi na jednym pudełku. To dobrze, ponieważ chcesz zapłacić tylko za jedno pudełko. Nie chcesz też płacić za zmiany w aplikacji, aby podzielić różne usługi, gdy Twoja firma się skaluje. W dzisiejszych czasach nie masz czasu na zrobienie tego, zanim tłum klientów i tak zapali twoje serwery.

Jest to również dobre, ponieważ pozwala żonglować przydziałami serwerów, dzięki czemu można:

  1. wykorzystaj większość posiadanych serwerów, pozostawiając niewiele do „zmarnowania”.
  2. mierzyć wydajność poszczególnych elementów oprogramowania.
  3. skrócić czas wdrażania / przestoju spowodowany wydaniami.

Posiadanie bardzo szczegółowych wdrożeń sprawia, że ​​te dwie rzeczy są łatwiejsze / lepsze (oprócz pomocy w wymuszeniu lepszego rozdzielenia problemów).

Telastyn
źródło
Ok, widzę przewagę. Istnieje niska bariera wejścia, ale można ją zwiększyć. Przypuszczam, że tym, co rzuca mi się w oczy, jest to, że kiedy skalujesz poziomo w stwardnieniu rozsianym, to wydaje się ... bardzo ... retro? Coś. Nie umiem wyrazić, dlaczego to po prostu wydaje się złe.
Thufir
Skalowanie aplikacji to problem, który niekoniecznie wymaga mikrousług: możesz bardzo łatwo zwiększyć moc maszyny wirtualnej w AWS (nawet na żądanie) lub możesz dodać więcej maszyn wirtualnych za modułem równoważenia obciążenia w tradycyjnej architekturze.
xtian
@xtian - jasne, ale często skalujesz niewłaściwe rzeczy i w ten sposób wydajesz więcej pieniędzy, niż potrzebujesz. Ideą mikrousług jest to, że po prostu skalujesz to, czego potrzebujesz (procesor, pamięć, dysk, przepustowość,
GPU