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

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?

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.

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.

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).